ערוך

שתף באמצעות

Azure Key Vault logging

  • מאמר

After you create one or more key vaults, you'll likely want to monitor how and when your key vaults are accessed, and by whom. Enabling logging for Azure Key Vault saves this information in an Azure storage account that you provide. For step by step guidance, see How to enable Key Vault logging.

You can access your logging information 10 minutes (at most) after the key vault operation. In most cases, it will be quicker. It's up to you to manage your logs in your storage account:

  • Use standard Azure access control methods in your storage account to secure your logs by restricting who can access them.
  • Delete logs that you no longer want to keep in your storage account.

For overview information about Key Vault, see What is Azure Key Vault?. For information about where Key Vault is available, see the pricing page. For information about using Azure Monitor for Key Vault.

Interpret your Key Vault logs

When you enable logging, a new container called insights-logs-auditevent is automatically created for your specified storage account. You can use this same storage account for collecting logs for multiple key vaults.

Individual blobs are stored as text, formatted as a JSON blob. Let's look at an example log entry.

    {
        "records":
        [
            {
                "time": "2016-01-05T01:32:01.2691226Z",
                "resourceId": "/SUBSCRIPTIONS/361DA5D4-A47A-4C79-AFDD-XXXXXXXXXXXX/RESOURCEGROUPS/CONTOSOGROUP/PROVIDERS/MICROSOFT.KEYVAULT/VAULTS/CONTOSOKEYVAULT",
                "operationName": "VaultGet",
                "operationVersion": "2015-06-01",
                "category": "AuditEvent",
                "resultType": "Success",
                "resultSignature": "OK",
                "resultDescription": "",
                "durationMs": "78",
                "callerIpAddress": "104.40.82.76",
                "correlationId": "",
                "identity": {"claim":{"http://schemas.microsoft.com/identity/claims/objectidentifier":"d9da5048-2737-4770-bd64-XXXXXXXXXXXX","http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn":"live.com#username@outlook.com","appid":"1950a258-227b-4e31-a9cf-XXXXXXXXXXXX"}},
                "properties": {"clientInfo":"azure-resource-manager/2.0","requestUri":"https://control-prod-wus.vaultcore.azure.net/subscriptions/361da5d4-a47a-4c79-afdd-XXXXXXXXXXXX/resourcegroups/contosoresourcegroup/providers/Microsoft.KeyVault/vaults/contosokeyvault?api-version=2015-06-01","id":"https://contosokeyvault.vault.azure.net/","httpStatusCode":200}
            }
        ]
    }

The following table lists the field names and descriptions:

Field name Description
time Date and time in UTC.
resourceId Azure Resource Manager resource ID. For Key Vault logs, it is always the Key Vault resource ID.
operationName Name of the operation, as documented in the next table.
operationVersion REST API version requested by the client.
category Type of result. For Key Vault logs, AuditEvent is the single, available value.
resultType Result of the REST API request.
resultSignature HTTP status.
resultDescription More description about the result, when available.
durationMs Time it took to service the REST API request, in milliseconds. The time does not include the network latency, so the time you measure on the client side might not match this time.
callerIpAddress IP address of the client that made the request.
correlationId An optional GUID that the client can pass to correlate client-side logs with service-side (Key Vault) logs.
identity Identity from the token that was presented in the REST API request. Usually a "user," a "service principal," or the combination "user+appId", for instance when the request comes from an Azure PowerShell cmdlet.
properties Information that varies based on the operation (operationName). In most cases, this field contains client information (the user agent string passed by the client), the exact REST API request URI, and the HTTP status code. In addition, when an object is returned as a result of a request (for example, KeyCreate or VaultGet), it also contains the key URI (as id), vault URI, or secret URI.

The operationName field values are in ObjectVerb format. For example:

  • All key vault operations have the Vault<action> format, such as VaultGet and VaultCreate.
  • All key operations have the Key<action> format, such as KeySign and KeyList.
  • All secret operations have the Secret<action> format, such as SecretGet and SecretListVersions.

The following table lists the operationName values and corresponding REST API commands:

Operation names table

operationName REST API command
Authentication Authenticate via Microsoft Entra endpoint
VaultGet Get information about a key vault
VaultPut Create or update a key vault
VaultDelete Delete a key vault
VaultPatch Update a key vault
VaultList List all key vaults in a resource group
VaultPurge Purge deleted vault
VaultRecover Recover deleted vault
VaultGetDeleted Get deleted vault
VaultListDeleted List deleted vaults
VaultAccessPolicyChangedEventGridNotification Vault access policy changed event published. It is logged regardless if an Event Grid subscription exists.

Use Azure Monitor logs

You can use the Key Vault solution in Azure Monitor logs to review Key Vault AuditEvent logs. In Azure Monitor logs, you use log queries to analyze data and get the information you need.

For more information, including how to set it up, see Azure Key Vault in Azure Monitor.

For understanding how to analyze logs, see Sample Kusto log queries

Next steps