Limites de la forensique des logs Azure : rétention, trous

En bref. Azure conserve l'Activity Log 90 jours, puis le supprime. Les logs de ressources (Key Vault, Storage et la plupart de l'activité du plan de données) sont désactivés par défaut et n'existent qu'à partir de la création d'un paramètre de diagnostic. Les flow logs doivent être activés NSG par NSG ou VNet par VNet. Les événements de niveau tenant comme elevateAccess ne figurent pas dans les exports d'abonnement. Les règles sont des heuristiques avec des seuils et des périodes d'apprentissage. Rien de tout cela ne rend la forensique Azure vaine ; cela impose d'écrire précisément ce dont on disposait, et de formuler les conclusions en conséquence.

Chaque rapport Azure que je rédige comporte une section « Périmètre et limites ». Ce n'est pas du remplissage. C'est là que le lecteur apprend si « aucune preuve d'accès aux données » veut dire « nous avons vérifié et rien ne s'est passé » ou « il n'y avait rien à vérifier ».

Rétention : le compte à rebours de 90 jours

Microsoft indique qu'Azure conserve les événements du journal d'activité 90 jours puis les supprime (journal d'activité dans Azure Monitor). L'API REST exige que les deux bornes de votre plage horaire se trouvent dans cette fenêtre. Conséquences :

Une intrusion découverte au jour 100 a perdu ses dix premiers jours d'historique du plan de contrôle, sauf si un paramètre de diagnostic a exporté l'Activity Log vers Log Analytics (rétention configurable, jusqu'à 12 ans selon Microsoft), un compte de stockage ou Event Hubs.
Le créateur d'une ressource n'est enregistré que dans l'Activity Log. Après 90 jours sans export, « qui a créé cette VM ? » peut rester sans réponse.
Exporter tôt est l'action la plus précieuse de la première heure (guide d'export).

Les logs de ressources n'ont aucune rétention côté plateforme : ils vivent là où le paramètre de diagnostic les envoie, avec la rétention de cette destination.

Sources manquantes : la journalisation jamais activée

Question	Log nécessaire	Actif par défaut ?	S'il était désactivé
Qui a modifié quoi dans Azure ?	Activity Log	Oui (90 jours)	—
Qui a lu quel secret Key Vault ?	Key Vault `AuditEvent`	Non	Sans réponse ; faire tourner tous les secrets accessibles
Quels blobs ont été téléchargés ?	`StorageRead` / `StorageBlobLogs`	Non	Sans réponse côté Azure ; considérer le contenu du compte comme exposé
Une VM a-t-elle parlé à l'attaquant ?	Flow logs NSG / VNet	Non	Examiner la VM elle-même, les logs de pare-feu ou de proxy
Comment l'identité a-t-elle été compromise ?	Journaux de connexion et d'audit Entra ID	Oui (rétention selon la licence)	Investigation séparée (m365forensics.com)
Qu'est-ce qui s'est exécuté sur la VM ?	Logs de l'OS invité, disque	Selon la VM	Forensique du disque

Le bloc de couverture de l'analyseur le rend explicite : sources « non fourni », règles qui « n'ont pas pu s'exécuter » et pourquoi. Recopiez-le dans votre rapport.

Les trous créés par l'attaquant

Des paramètres de diagnostic supprimés créent un trou à partir de l'horodatage de la suppression ; des plans Defender désactivés arrêtent les détections ; des blobs de logs supprimés effacent l'historique d'une archive. C'est différent de « jamais activé » : la suppression elle-même est une preuve, enregistrée dans l'Activity Log. Voir l'évasion de défense.

Les angles morts des logs eux-mêmes

Même avec tous les logs activés :

Le contenu des scripts Run Command ne figure généralement pas dans l'Activity Log (attaques Run Command).
La création d'un SAS signé côté client n'est journalisée nulle part ; Microsoft indique qu'il n'est pas possible d'auditer la génération de jetons SAS (vue d'ensemble des SAS).
Les flow logs ne contiennent pas de charges utiles et ne voient pas les clients Internet qui parlent directement aux endpoints PaaS (flow logs).
Les opérations de lecture sur le plan de contrôle (lister des ressources, lire une configuration) ne figurent généralement pas dans l'Activity Log : la reconnaissance est en grande partie invisible.
Les événements de niveau tenant, comme elevateAccess, sont dans le log de niveau tenant, pas dans les exports d'abonnement.
La latence. Microsoft annonce de 3 à 20 minutes pour la disponibilité de l'Activity Log et jusqu'à 10 minutes pour les logs Key Vault ; un export réalisé pendant un incident actif peut manquer les dernières minutes.
Les différences de casse dans Log Analytics. Microsoft signale que les valeurs de AzureActivity peuvent varier en casse ; les comparaisons de chaînes doivent être insensibles à la casse.

Les limites de l'analyseur

Soyons honnêtes sur l'outil aussi :

Il ne voit que ce que vous chargez. Aucun accès API à votre tenant, par conception.
Les règles de première apparition exigent plus de 72 heures d'historique avant l'activité suspecte. Avec un export court, AZ-KV-001, AZ-ID-001, AZ-ID-002 et AZ-VM-004 ne peuvent pas s'exécuter.
Les seuils peuvent être contournés. Le téléchargement en masse exige 50 blobs distincts en une heure par une même identité et IP ; l'énumération de secrets exige 8 objets distincts en une heure. Un attaquant patient reste en dessous.
L'automatisation légitime déclenche des règles. Chaque règle documente ses faux positifs connus.
Les formats. Avro (Event Hubs Capture) et Parquet ne sont pas lus ; le CSV du portail est traité au mieux ; l'UTF-16 doit être converti.
Plafond d'affichage. Au-delà de 100 000 événements, le tableau cesse de les lister, mais chaque événement est tout de même analysé et compté.
Entra ID est hors périmètre. L'identité relève de m365forensics.com.

Rédiger la conclusion

Les formulations que j'utilise, selon ce qui était disponible :

Situation	Formulation défendable
Logs Key Vault présents sur toute la période, aucune lecture suspecte	« Aucune preuve d'accès aux secrets par l'identité compromise dans les logs d'audit Key Vault couvrant <période>. »
Logs Key Vault absents	« La journalisation d'audit Key Vault n'était pas activée ; l'accès aux secrets ne peut pas être déterminé. Tous les secrets accessibles à l'identité sont considérés comme exposés. »
Logs supprimés en cours d'incident	« La journalisation Key Vault a été désactivée par l'attaquant à <heure> ; l'activité postérieure ne peut pas être déterminée. »
Verdict Sain, couverture complète	« Aucune détection n'a correspondu dans <sources> sur <période>. Cela n'exclut pas une activité sous les seuils de détection. »

Le verdict d'un outil automatique est le début de ce paragraphe, pas sa conclusion.

FAQ

Combien de temps Azure conserve-t-il l'Activity Log ?

90 jours. Ensuite, Azure supprime les événements. Une rétention plus longue exige un paramètre de diagnostic qui envoie l'Activity Log vers un espace de travail Log Analytics, un compte de stockage ou Event Hubs.

Peut-on obtenir les logs d'accès Key Vault ou Storage d'une période où la journalisation était désactivée ?

Non. Les logs de ressources ne sont écrits que tant qu'un paramètre de diagnostic les envoie quelque part. En activer un maintenant ne comble pas le passé.

Un verdict Sain signifie-t-il que l'abonnement n'a pas été compromis ?

Non. Il signifie qu'aucune règle de détection n'a correspondu dans les logs fournis. Vérifiez quelles sources étaient présentes, quelles règles n'ont pas pu s'exécuter, et si la fenêtre de rétention couvre la période suspectée.