1--- 2layout: docs 3page_title: Audit Devices 4description: Audit devices are mountable devices that log requests and responses in Vault. 5--- 6 7# Audit Devices 8 9Audit devices are the components in Vault that keep a detailed log of all 10requests and response to Vault. Because every operation with Vault is an API 11request/response, the audit log contains _every authenticated_ interaction with 12Vault, including errors. 13 14Multiple audit devices can be enabled and Vault will send the audit logs to 15all of them. This allows you to not only have a redundant copy, but also a second copy 16in case the first is tampered with. 17 18## Format 19 20Each line in the audit log is a JSON object. The `type` field specifies what 21type of object it is. Currently, only two types exist: `request` and `response`. 22The line contains all of the information for any given request and response. By 23default, all the sensitive information is first hashed before logging in the 24audit logs. 25 26## Sensitive Information 27 28The audit logs contain the full request and response objects for every 29interaction with Vault. The request and response can be matched utilizing a 30unique identifier assigned to each request. 31 32With a few specific exceptions, all strings (including authentication tokens and lease information) contained within requests and 33responses are hashed with a salt using HMAC-SHA256. The purpose of the hash is 34so that secrets aren't in plaintext within your audit logs. However, you're 35still able to check the value of secrets by generating HMACs yourself; this can 36be done with the audit device's hash function and salt by using the 37`/sys/audit-hash` API endpoint (see the documentation for more details). 38 39Note that currently only strings coming from JSON or being returned in JSON are 40HMAC'd. Other data types, like integers, booleans, and so on, are passed 41through in plaintext. 42 43## Enabling/Disabling Audit Devices 44 45When a Vault server is first initialized, no auditing is enabled. Audit 46devices must be enabled by a root user using `vault audit enable`. 47 48When enabling an audit device, options can be passed to it to configure it. 49For example, the command below enables the file audit device: 50 51```shell-session 52$ vault audit enable file file_path=/var/log/vault_audit.log 53``` 54 55In the command above, we passed the "file_path" parameter to specify the path 56where the audit log will be written to. Each audit device has its own 57set of parameters. See the documentation to the left for more details. 58 59When an audit device is disabled, it will stop receiving logs immediately. 60The existing logs that it did store are untouched. 61 62## Blocked Audit Devices 63 64If there are any audit devices enabled, Vault requires that at least 65one be able to persist the log before completing a Vault request. 66 67!> If you have only one audit device enabled, and it is blocking (network 68block, etc.), then Vault will be _unresponsive_. Vault **will not** complete 69any requests until the audit device can write. 70 71If you have more than one audit device, then Vault will complete the request 72as long as one audit device persists the log. 73 74Vault will not respond to requests if audit devices are blocked because 75audit logs are critically important and ignoring blocked requests opens 76an avenue for attack. Be absolutely certain that your audit devices cannot 77block. 78 79## API 80 81Audit devices also have a full HTTP API. Please see the [Audit device API 82docs](/api/system/audit) for more details. 83