a3dfde5cec
* conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
83 lines
3.2 KiB
Markdown
83 lines
3.2 KiB
Markdown
---
|
|
layout: "docs"
|
|
page_title: "Audit Devices"
|
|
sidebar_title: "Audit Devices"
|
|
sidebar_current: "docs-audit"
|
|
description: |-
|
|
Audit devices are mountable devices that log requests and responses in Vault.
|
|
---
|
|
|
|
# Audit Devices
|
|
|
|
Audit devices are the components in Vault that keep a detailed log of all
|
|
requests and response to Vault. Because every operation with Vault is an API
|
|
request/response, the audit log contains _every authenticated_ interaction with
|
|
Vault, including errors.
|
|
|
|
Multiple audit devices can be enabled and Vault will send the audit logs to
|
|
both. This allows you to not only have a redundant copy, but also a second copy
|
|
in case the first is tampered with.
|
|
|
|
## Format
|
|
|
|
Each line in the audit log is a JSON object. The `type` field specifies what
|
|
type of object it is. Currently, only two types exist: `request` and `response`.
|
|
The line contains all of the information for any given request and response. By
|
|
default, all the sensitive information is first hashed before logging in the
|
|
audit logs.
|
|
|
|
## Sensitive Information
|
|
|
|
The audit logs contain the full request and response objects for every
|
|
interaction with Vault. The request and response can be matched utilizing a
|
|
unique identifier assigned to each request. The data in the request and the
|
|
data in the response (including secrets and authentication tokens) will be
|
|
hashed with a salt using HMAC-SHA256.
|
|
|
|
The purpose of the hash is so that secrets aren't in plaintext within your
|
|
audit logs. However, you're still able to check the value of secrets by
|
|
generating HMACs yourself; this can be done with the audit device's hash
|
|
function and salt by using the `/sys/audit-hash` API endpoint (see the
|
|
documentation for more details).
|
|
|
|
## Enabling/Disabling Audit Devices
|
|
|
|
When a Vault server is first initialized, no auditing is enabled. Audit
|
|
devices must be enabled by a root user using `vault audit enable`.
|
|
|
|
When enabling an audit device, options can be passed to it to configure it.
|
|
For example, the command below enables the file audit device:
|
|
|
|
```text
|
|
$ vault audit enable file file_path=/var/log/vault_audit.log
|
|
```
|
|
|
|
In the command above, we passed the "file_path" parameter to specify the path
|
|
where the audit log will be written to. Each audit device has its own
|
|
set of parameters. See the documentation to the left for more details.
|
|
|
|
When an audit device is disabled, it will stop receiving logs immediately.
|
|
The existing logs that it did store are untouched.
|
|
|
|
## Blocked Audit Devices
|
|
|
|
If there are any audit devices enabled, Vault requires that at least
|
|
one be able to persist the log before completing a Vault request.
|
|
|
|
!> If you have only one audit device enabled, and it is blocking (network
|
|
block, etc.), then Vault will be _unresponsive_. Vault **will not** complete
|
|
any requests until the audit device can write.
|
|
|
|
If you have more than one audit device, then Vault will complete the request
|
|
as long as one audit device persists the log.
|
|
|
|
Vault will not respond to requests if audit devices are blocked because
|
|
audit logs are critically important and ignoring blocked requests opens
|
|
an avenue for attack. Be absolutely certain that your audit devices cannot
|
|
block.
|
|
|
|
## API
|
|
|
|
Audit devices also have a full HTTP API. Please see the [Audit device API
|
|
docs](/api/system/audit.html) for more details.
|