Logs de auditoría de Key Vault: quién leyó qué secreto
Usa los logs de auditoría de Azure Key Vault (AuditEvent) para saber quién leyó qué secreto: SecretGet y SecretList, directivas de acceso y enumeración masiva.
En resumen. Las lecturas de secretos solo se ven en el log AuditEvent de Key Vault, y solo si una configuración de diagnóstico lo enviaba a algún sitio antes del incidente. Busca SecretGet / SecretList de una entidad que nunca había tocado el almacén, muchos secretos distintos leídos por una misma entidad en menos de una hora, y un VaultAccessPolicyChangedEventGridNotification o un Microsoft.KeyVault/vaults/accessPolicies/write justo antes. Con el modelo de directivas de acceso, cualquiera con Contributor en el almacén puede concederse acceso a los datos. Si no hay logs, rota todos los secretos a los que llegaba la identidad.
Key Vault es adonde van los atacantes justo después de hacerse con un punto de apoyo con privilegios reales, porque ahí están la contraseña de la base de datos, la clave de la API de pagos y la frase de cifrado de las copias de seguridad. La buena noticia: cuando el registro está activo, el log de auditoría de Key Vault es una de las fuentes más precisas de Azure. Cada solicitud queda registrada con el URI del objeto, la identidad del autor y la IP.
Qué registra el log AuditEvent
La referencia de registro de Key Vault documenta el esquema. Los campos que usarás en una investigación:
| Campo | Contenido | Uso en la investigación |
|---|---|---|
time | Marca de tiempo UTC | Cronología |
operationName | SecretGet, SecretList, KeyDecrypt, VaultGet… | Qué se hizo |
identity.claim | Object ID (…/objectidentifier), appid, UPN para usuarios, xms_mirid para identidades administradas | Quién |
callerIpAddress | IP del cliente | Desde dónde |
properties.id | URI completo del objeto, p. ej. https://<vault>.vault.azure.net/secrets/<name>/<version> | Qué secreto, qué versión |
properties.clientInfo | User agent (nombre y versión del SDK, curl, python…) | Cómo |
resultSignature / httpStatusCode | Estado HTTP | Éxito o denegación |
Los mismos datos llegan a la tabla AzureDiagnostics (con columnas identity_claim_* aplanadas) o a la tabla específica AZKVAuditLogs de Log Analytics. En una cuenta de almacenamiento se escriben en el contenedor insights-logs-auditevent. Microsoft indica que las entradas están disponibles como máximo diez minutos después de la operación.
Los nombres de operación que importan
Los nombres de operación siguen el patrón ObjetoVerbo. Los relevantes para el robo de credenciales:
| Operación | Significado | Peso forense |
|---|---|---|
SecretGet | Leer el valor de un secreto | La prueba central de acceso a credenciales |
SecretList, SecretListVersions | Enumerar nombres, no valores | Reconocimiento antes de lecturas masivas |
SecretBackup, KeyBackup | Exportar una copia de seguridad cifrada | Exfiltración del objeto completo |
KeyDecrypt, KeyUnwrap | Usar una clave sin extraerla | Descifrado por delegación |
CertificateGet | Leer las propiedades y la parte pública de un certificado; una clave privada exportable se lee a través del secreto asociado al certificado, así que aparece como SecretGet | Acceso a credenciales |
SecretPurge, KeyPurge, CertificatePurge | Eliminación permanente | Impacto / antiforense |
VaultAccessPolicyChangedEventGridNotification | Directiva de acceso modificada | Se registra aunque no exista suscripción de Event Grid |
Authentication | Autenticación mediante el endpoint de Entra | Contexto |
En el plano de control, el Activity Log registra Microsoft.KeyVault/vaults/accessPolicies/write (cambio de directiva de acceso), Microsoft.KeyVault/vaults/write (propiedades del almacén, incluida la eliminación temporal y la protección de purga) y Microsoft.KeyVault/locations/deletedVaults/purge/action.
La escalada mediante directivas de acceso
Key Vault tiene dos modelos de permisos. Con Azure RBAC, conceder acceso al plano de datos requiere Owner o User Access Administrator. Con el modelo heredado de directivas de acceso, Microsoft advierte de que los usuarios con Contributor, Key Vault Contributor o cualquier rol que incluya Microsoft.KeyVault/vaults/write pueden concederse acceso al plano de datos configurando una directiva de acceso (Azure RBAC frente a directivas de acceso).
En la práctica, la cadena es esta, en pocos minutos:
- Activity Log:
accessPolicies/writepor la entidad X en el almacén V. - Log de Key Vault:
VaultAccessPolicyChangedEventGridNotificationen V. - Log de Key Vault:
SecretListpor X desde la misma IP. - Log de Key Vault: una ráfaga de
SecretGetpor X, uno por secreto.
MITRE ATT&CK registra la lectura de almacenes de secretos en la nube como T1555.006 Cloud Secrets Management Stores.
Qué marca el analizador
| Regla | Detecta | Nivel |
|---|---|---|
AZ-KV-001 | Una entidad lee secretos, claves o certificados de un almacén al que no accedió durante el periodo de aprendizaje de 72 horas | Alto |
AZ-KV-002 | Una entidad lee al menos 8 secretos / claves / certificados distintos de un almacén en 60 minutos | Alto |
AZ-KV-003 | Directiva de acceso modificada (Activity Log o log de Key Vault) | Medio |
AZ-KV-004 | Eliminación temporal o protección de purga desactivadas, o almacenes / objetos purgados | Alto |
AZ-ID-002 | Identidad administrada usada desde una IP nunca vista: a menudo un token robado en una VM y reutilizado contra Key Vault | Alto |
AZ-KV-002 cuenta objetos distintos, no solicitudes: una aplicación que lee la misma cadena de conexión cada hora nunca lo dispara; un script que recorre el almacén, sí. Los cargadores de configuración que leen todos los secretos al arrancar son el falso positivo conocido.
Preguntas de triaje
- ¿Estaba activo el registro? Revisa el bloque de cobertura del analizador o el historial de configuraciones de diagnóstico del almacén en el Activity Log (
microsoft.insights/diagnosticSettings/writey/delete). Una configuración de diagnóstico eliminada es en sí misma un hallazgo (evasión de defensas). - ¿El lector es nuevo? Compara con la referencia: qué entidades leían este almacén la semana anterior, desde qué IP y con qué cliente.
- ¿Cuántos secretos distintos? Un secreto leído por una entidad nueva puede ser una incorporación. Doce en un minuto desde un SDK de Python en una IP residencial, no.
- ¿Qué cliente?
clientInfodistingue un SDK de aplicación decurlo de un script improvisado. Se puede falsificar, pero un cambio sigue siendo informativo. - ¿Solicitudes denegadas? Una serie de 403 antes del éxito es típica de un atacante que descubre qué puede hacer la identidad.
- ¿Qué desbloqueaban los secretos? Cada secreto leído amplía el alcance del incidente: la base de datos, el proveedor de pagos, el socio SFTP.
Remediación
- Rota todos los secretos, claves y certificados leídos por la entidad sospechosa, y actualiza los sistemas que los consumen. Rotar sin actualizar a los consumidores provoca una caída, así que coordínalo.
- Elimina las entradas inesperadas de las directivas de acceso; planifica el paso al modelo de permisos Azure RBAC.
- Asegúrate de que la eliminación temporal y la protección de purga están activadas.
- Activa ya la configuración de diagnóstico
AuditEventsi estaba desactivada y protégela con Azure Policy.
FAQ
¿El Activity Log muestra las lecturas de secretos de Key Vault?
No. Leer un secreto es una operación del plano de datos. Solo aparece en el log de recursos AuditEvent de Key Vault, y solo si una configuración de diagnóstico enviaba ese log a algún sitio antes de la lectura.
¿Puedo recuperar los logs de acceso de Key Vault si el registro no estaba activado?
No. Activar ahora la configuración de diagnóstico solo registra operaciones futuras. Da por hecho que se leyó cada secreto al que tenía acceso la identidad comprometida y rótalos.
¿Cuánto tardan en aparecer los logs de Key Vault?
Microsoft indica que la información de registro está disponible como máximo 10 minutos después de la operación de Key Vault, normalmente antes.