Logs d'audit Key Vault : qui a lu quel secret, et quand
Utiliser les logs d'audit Azure Key Vault (AuditEvent) pour savoir qui a lu quel secret : SecretGet, SecretList, stratégies d'accès, nouveaux principaux.
En bref. Les lectures de secrets ne sont visibles que dans le log Key Vault AuditEvent, et seulement si un paramètre de diagnostic l'envoyait quelque part avant l'incident. Cherchez des SecretGet / SecretList par un principal qui n'avait jamais touché le coffre, de nombreux secrets distincts lus par un même principal en moins d'une heure, et un VaultAccessPolicyChangedEventGridNotification ou un Microsoft.KeyVault/vaults/accessPolicies/write juste avant. Avec le modèle des stratégies d'accès, quiconque détient Contributor sur le coffre peut s'accorder l'accès aux données. Sans logs, faites tourner chaque secret accessible à l'identité.
Key Vault est l'endroit où les attaquants vont juste après avoir obtenu un point d'appui avec de vrais privilèges, parce que c'est là que vivent le mot de passe de la base, la clé d'API du prestataire de paiement et la phrase secrète de chiffrement des sauvegardes. La bonne nouvelle : quand la journalisation est active, le log d'audit Key Vault est l'une des sources les plus précises d'Azure. Chaque requête est enregistrée avec l'URI de l'objet, l'identité de l'appelant et l'IP.
Ce qu'enregistre le log AuditEvent
La référence sur la journalisation Key Vault documente le schéma. Les champs utiles en investigation :
| Champ | Contenu | Usage en investigation |
|---|---|---|
time | Horodatage UTC | Chronologie |
operationName | SecretGet, SecretList, KeyDecrypt, VaultGet… | Ce qui a été fait |
identity.claim | Object ID (…/objectidentifier), appid, UPN pour les utilisateurs, xms_mirid pour les identités managées | Qui |
callerIpAddress | IP du client | D'où |
properties.id | URI complet de l'objet, par ex. https://<vault>.vault.azure.net/secrets/<name>/<version> | Quel secret, quelle version |
properties.clientInfo | User agent (nom et version du SDK, curl, python…) | Comment |
resultSignature / httpStatusCode | Statut HTTP | Succès ou refus |
Les mêmes données arrivent dans la table AzureDiagnostics (avec des colonnes identity_claim_* aplaties) ou dans la table spécifique AZKVAuditLogs de Log Analytics. Dans un compte de stockage, elles sont écrites dans le conteneur insights-logs-auditevent. Microsoft indique que les entrées sont disponibles au plus dix minutes après l'opération.
Les noms d'opérations qui comptent
Les noms d'opérations suivent un modèle ObjetVerbe. Ceux qui comptent pour le vol d'identifiants :
| Opération | Signification | Poids forensique |
|---|---|---|
SecretGet | Lire la valeur d'un secret | La preuve centrale d'accès aux identifiants |
SecretList, SecretListVersions | Énumérer les noms, pas les valeurs | Reconnaissance avant une lecture en masse |
SecretBackup, KeyBackup | Exporter une sauvegarde chiffrée | Exfiltration de l'objet entier |
KeyDecrypt, KeyUnwrap | Utiliser une clé sans l'extraire | Déchiffrement par procuration |
CertificateGet | Lire les propriétés et la partie publique d'un certificat ; une clé privée exportable se lit via le secret associé au certificat, donc apparaît comme SecretGet | Accès aux identifiants |
SecretPurge, KeyPurge, CertificatePurge | Suppression définitive | Impact / anti-forensique |
VaultAccessPolicyChangedEventGridNotification | Stratégie d'accès modifiée | Journalisé même sans abonnement Event Grid |
Authentication | Authentification via l'endpoint Entra | Contexte |
Côté plan de contrôle, l'Activity Log enregistre Microsoft.KeyVault/vaults/accessPolicies/write (modification de stratégie d'accès), Microsoft.KeyVault/vaults/write (propriétés du coffre, dont la suppression réversible et la protection contre la purge) et Microsoft.KeyVault/locations/deletedVaults/purge/action.
L'élévation par stratégie d'accès
Key Vault propose deux modèles de permissions. Avec Azure RBAC, accorder l'accès aux données requiert Owner ou User Access Administrator. Avec l'ancien modèle des stratégies d'accès, Microsoft avertit que les utilisateurs disposant de Contributor, Key Vault Contributor ou de tout rôle incluant Microsoft.KeyVault/vaults/write peuvent s'accorder eux-mêmes l'accès au plan de données en modifiant la stratégie d'accès (Azure RBAC ou stratégies d'accès).
En pratique, la chaîne ressemble à ceci, en quelques minutes :
- Activity Log :
accessPolicies/writepar le principal X sur le coffre V. - Log Key Vault :
VaultAccessPolicyChangedEventGridNotificationsur V. - Log Key Vault :
SecretListpar X depuis la même IP. - Log Key Vault : une rafale de
SecretGetpar X, un par secret.
MITRE ATT&CK suit la lecture de coffres de secrets cloud sous T1555.006 Cloud Secrets Management Stores.
Ce que signale l'analyseur
| Règle | Détecte | Niveau |
|---|---|---|
AZ-KV-001 | Un principal lit des secrets, clés ou certificats dans un coffre jamais consulté pendant la période d'apprentissage de 72 heures | Haut |
AZ-KV-002 | Un principal lit au moins 8 secrets / clés / certificats distincts d'un même coffre en 60 minutes | Haut |
AZ-KV-003 | Stratégie d'accès modifiée (Activity Log ou log Key Vault) | Moyen |
AZ-KV-004 | Suppression réversible ou protection contre la purge désactivée, ou coffres / objets purgés | Haut |
AZ-ID-002 | Identité managée utilisée depuis une IP jamais vue : souvent un jeton volé sur une VM et rejoué contre Key Vault | Haut |
AZ-KV-002 compte des objets distincts, pas des requêtes : une application qui lit la même chaîne de connexion toutes les heures ne le déclenche jamais ; un script qui parcourt le coffre, si. Les chargeurs de configuration qui lisent tous les secrets au démarrage sont le faux positif connu.
Questions de tri
- La journalisation était-elle active ? Vérifiez le bloc de couverture de l'analyseur ou l'historique des paramètres de diagnostic du coffre dans l'Activity Log (
microsoft.insights/diagnosticSettings/writeet/delete). Un paramètre de diagnostic supprimé est en soi un constat (évasion de défense). - Le lecteur est-il nouveau ? Comparez avec la référence : quels principaux lisaient ce coffre la semaine précédente, depuis quelles IP, avec quel client ?
- Combien de secrets distincts ? Un secret lu par un nouveau principal peut être une mise en service. Douze en une minute depuis un SDK Python sur une IP résidentielle, non.
- Quel client ?
clientInfodistingue un SDK applicatif decurlou d'un script improvisé. Il peut être falsifié, mais un changement reste informatif. - Des requêtes refusées ? Une série de 403 avant un succès est typique d'un attaquant qui découvre ce que l'identité peut faire.
- Que déverrouillaient ces secrets ? Chaque secret lu élargit le périmètre de l'incident : la base de données, le prestataire de paiement, le partenaire SFTP.
Remédiation
- Faites tourner chaque secret, clé et certificat lu par le principal suspect, et mettez à jour les systèmes qui les consomment. Une rotation sans mise à jour des consommateurs provoque une panne : coordonnez.
- Supprimez les entrées de stratégie d'accès inattendues ; planifiez le passage au modèle de permissions Azure RBAC.
- Assurez-vous que la suppression réversible et la protection contre la purge sont activées.
- Activez dès maintenant le paramètre de diagnostic
AuditEvents'il était désactivé, et protégez-le avec Azure Policy.
FAQ
L'Activity Log montre-t-il les lectures de secrets Key Vault ?
Non. Lire un secret est une opération du plan de données. Elle n'apparaît que dans le log de ressource Key Vault AuditEvent, et seulement si un paramètre de diagnostic envoyait ce log quelque part avant la lecture.
Peut-on récupérer les logs d'accès Key Vault si la journalisation n'était pas activée ?
Non. Activer le paramètre de diagnostic maintenant n'enregistre que les opérations futures. Partez du principe que chaque secret lisible par l'identité compromise a été lu, et faites-les tourner.
En combien de temps les logs Key Vault apparaissent-ils ?
Microsoft indique que les informations de journalisation sont disponibles au plus 10 minutes après l'opération Key Vault, généralement moins.