Forensique Cloud : Analyser les Logs CloudTrail, Azure

\\n\\n\\n

Architecture de CloudTrail

\\n\\n

AWS CloudTrail enregistre chaque appel API effectué dans un compte AWS, qu'il provienne de la console, du CLI, du SDK ou d'un service AWS. Chaque entrée CloudTrail contient l'identité de l'appelant (ARN de l'utilisateur ou du rôle), l'action effectuée (nom de l'API), les paramètres de la requête, la réponse, l'adresse IP source, l'User-Agent et un horodatage précis. CloudTrail distingue trois types d'événements : Guide de forensique cloud : analyse des logs AWS CloudTrail, Azure Activity/Sign-in Logs, GCP Audit Logs, investigation d'incidents et méthodologie. L'investigation numérique exige rigueur et méthodologie. Forensique Cloud : Analyser les Logs CloudTrail, Azure couvre les aspects pratiques que les analystes forensics rencontrent sur le terrain.

\\n\\n\\n\\n\\n\\n\\n\\n\\n\\n\\n

Type d'événement	Description	Exemples	Activation
Management Events	Actions sur les ressources AWS (plan de contrôle)	CreateUser, RunInstances, PutBucketPolicy	Activé par défaut
Data Events	Actions sur les données (plan de données)	GetObject (S3), Invoke (Lambda)	Désactivé par défaut (coût)
Insights Events	Détection automatique d'anomalies d'utilisation API	Pic d'appels DeleteObject	Optionnel (payant)

\\n\\n\\n\\n

Requêtage avec Amazon Athena

\\n\\n

Pour les investigations portant sur de grandes périodes ou des volumes importants de logs, Amazon Athena permet de requêter les fichiers CloudTrail stockés dans S3 avec du SQL standard. La première étape consiste à créer une table Athena pointant vers le bucket CloudTrail :

\\n\\n

-- Création de la table Athena pour CloudTrail\\nCREATE EXTERNAL TABLE cloudtrail_logs (\\n eventVersion STRING,\\n userIdentity STRUCT<\\n type: STRING,\\n principalId: STRING,\\n arn: STRING,\\n accountId: STRING,\\n invokedBy: STRING,\\n accessKeyId: STRING,\\n userName: STRING,\\n sessionContext: STRUCT<\\n attributes: STRUCT,\\n sessionIssuer: STRUCT\\n >\\n >,\\n eventTime STRING,\\n eventSource STRING,\\n eventName STRING,\\n awsRegion STRING,\\n sourceIPAddress STRING,\\n userAgent STRING,\\n errorCode STRING,\\n errorMessage STRING,\\n requestParameters STRING,\\n responseElements STRING,\\n resources ARRAY>\\n)\\nROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'\\nLOCATION 's3://mon-bucket-cloudtrail/AWSLogs/123456789012/CloudTrail/'\\n\\n-- Requête : toutes les actions d'un utilisateur compromis\\nSELECT eventTime, eventName, sourceIPAddress, userAgent, errorCode\\nFROM cloudtrail_logs\\nWHERE userIdentity.arn LIKE '%compromised-user%'\\nAND eventTime BETWEEN '2026-01-15T00:00:00Z' AND '2026-02-01T00:00:00Z'\\nORDER BY eventTime;\\n\\n-- Requête : connexions depuis des IPs inhabituelles\\nSELECT sourceIPAddress, COUNT(*) as nb_events,\\n MIN(eventTime) as first_seen, MAX(eventTime) as last_seen,\\n ARRAY_AGG(DISTINCT eventName) as actions\\nFROM cloudtrail_logs\\nWHERE userIdentity.arn LIKE '%admin%'\\nAND eventTime > '2026-01-01'\\nGROUP BY sourceIPAddress\\nORDER BY nb_events DESC;

\\n\\n

Sources complémentaires AWS

\\n

VPC Flow Logs capturent les métadonnées des flux réseau (IP source/destination, ports, protocole, bytes, action accept/reject) au niveau de l'interface réseau (ENI), du sous-réseau ou du VPC. Ils sont essentiels pour détecter les mouvements latéraux entre instances, les connexions vers des IP de C2 et l'exfiltration de données. Les Flow Logs peuvent être publiés vers CloudWatch Logs, S3 ou Kinesis Data Firehose.

\\n\\n

S3 Access Logs fournissent un détail des requêtes effectuées sur chaque bucket (méthode HTTP, clé d'objet, statut HTTP, bytes transférés). Ils complètent les Data Events de CloudTrail avec des métadonnées supplémentaires comme le referer et les headers HTTP.

\\n\\n

Amazon GuardDuty est un service de détection de menaces qui analyse automatiquement les logs CloudTrail, VPC Flow Logs et DNS pour identifier les comportements suspects. Les findings GuardDuty constituent un point de départ précieux pour l'investigation : chaque finding contient un type de menace, un score de sévérité, les ressources affectées et les détails techniques. Pour la forensique, les findings de type UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B, Exfiltration:S3/MaliciousIPCaller ou PrivilegeEscalation:IAMUser/AnomalousBehavior sont particulièrement pertinents.

\\n\\n\\n\\n

// Connexions suspectes : échecs suivis de succès (password spray réussi)\\nSigninLogs\\n| where TimeGenerated > ago(30d)\\n| summarize \\n FailedCount = countif(ResultType != "0"),\\n SuccessCount = countif(ResultType == "0"),\\n DistinctIPs = dcount(IPAddress),\\n IPList = make_set(IPAddress)\\n by UserPrincipalName\\n| where FailedCount > 50 and SuccessCount > 0\\n| sort by FailedCount desc\\n\\n// Détection de connexion impossible (impossible travel)\\nSigninLogs\\n| where ResultType == "0"\\n| project TimeGenerated, UserPrincipalName, IPAddress, Location\\n| sort by UserPrincipalName, TimeGenerated\\n| extend PrevTime = prev(TimeGenerated, 1), PrevLocation = prev(Location, 1), PrevUser = prev(UserPrincipalName, 1)\\n| where UserPrincipalName == PrevUser\\n| extend TimeDiffMinutes = datetime_diff('minute', TimeGenerated, PrevTime)\\n| where TimeDiffMinutes < 60 and Location != PrevLocation and PrevLocation != ""\\n| project TimeGenerated, UserPrincipalName, Location, PrevLocation, TimeDiffMinutes, IPAddress\\n\\n// Opérations sensibles sur les rôles RBAC\\nAzureActivity\\n| where OperationNameValue has_any ("Microsoft.Authorization/roleAssignments/write", \\n "Microsoft.Authorization/roleDefinitions/write")\\n| where ActivityStatusValue == "Success"\\n| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, Properties\\n| sort by TimeGenerated desc\\n\\n// Investigation Key Vault : accès aux secrets\\nAzureDiagnostics\\n| where ResourceType == "VAULTS"\\n| where OperationName in ("SecretGet", "SecretList", "KeyGet", "CertificateGet")\\n| project TimeGenerated, CallerIPAddress, identity_claim_upn_s, OperationName, id_s\\n| sort by TimeGenerated desc

\\n\\n

Microsoft Sentinel pour la forensique

\\n\\n

Microsoft Sentinel est le SIEM cloud-native d'Azure qui centralise les logs de l'ensemble de l'écosystème Microsoft (Azure, M365, Entra ID, Defender) et de sources tierces. Pour la forensique cloud, Sentinel offre plusieurs avantages : la corrélation automatique entre les logs Azure et les logs Microsoft 365 (Exchange Online, SharePoint, Teams), les workbooks de visualisation prêts à l'emploi, et les capacités de hunting avec les requêtes KQL. Les tables Sentinel les plus pertinentes pour la forensique sont SigninLogs, AuditLogs, AzureActivity, SecurityAlert et OfficeActivity.

\\n\\n

L'API Microsoft Graph complète les sources de logs en donnant accès programmatique aux audit logs d'Entra ID, aux sign-in logs et aux détections Identity Protection. Pour une investigation approfondie, l'API Graph permet de récupérer les détails des applications enregistrées (app registrations), des consentements OAuth accordés et des configurations de service principal -- des éléments essentiels pour comprendre les attaques par abus d'applications.

\\n\\n\\n\\n

La collecte rassemble toutes les données forensiques pertinentes dans un environnement d'analyse sécurisé. Pour la forensique cloud, la collecte couvre trois dimensions :

\\n\\n

Logs du cloud provider : exporter les logs CloudTrail, Activity Logs ou Cloud Audit Logs pour la période d'investigation (typiquement, 90 jours avant la détection). Pour AWS, les logs sont déjà dans S3 si un trail est configuré. Pour Azure, il faut exporter le Log Analytics Workspace. Pour GCP, utiliser gcloud logging read avec des filtres temporels ou configurer un sink vers BigQuery pour l'analyse.

\\n\\n

Artefacts système : à partir des snapshots préservés, créer un volume et le monter sur une instance d'analyse pour extraire les logs système, les configurations, les binaires suspects et les artefacts forensiques classiques (crontab, authorized_keys, bash_history, journalctl).

\\n\\n

Configuration et état : collecter l'état actuel de la configuration IAM (politiques, rôles, utilisateurs, clés d'accès), des Security Groups, des bucket policies, des VPC et de tous les éléments de configuration qui auraient pu être modifiés par l'attaquant.

\\n\\n\\n\\n

Cet article vous a été utile ? Partagez-le avec votre réseau professionnel !

\\n \\n \\n\\n \\n\\n \\n

\\n

Ressources & Références Officielles

\\n

Documentations officielles et outils de la communauté DFIR cloud

\\n

\\n \\n \\n

AWS CloudTrail Documentation

docs.aws.amazon.com

\\n \\n \\n \\n

Azure Monitor & Sentinel

learn.microsoft.com

\\n \\n \\n \\n

Prowler - Cloud Security Tool

github.com/prowler-cloud

\\n \\n

\\n

\\n\\n\\n\\n\\n\\n

Sources et références : SANS SIFT · MITRE ATT&CK

\\n\\n

FAQ

\\n

Qu'est-ce que Forensique Cloud ?

\\n

Forensique Cloud désigne l'ensemble des concepts, techniques et méthodologies abordés dans cet article. Les fondamentaux sont détaillés dans les premières sections du guide.

\\n

Pourquoi forensique cloud cloudtrail azure gcp est-il important ?

\\n

La maîtrise de forensique cloud cloudtrail azure gcp est devenue essentielle pour les équipes de sécurité. Les enjeux et le contexte opérationnel sont développés tout au long de l'article.

\\n

Comment appliquer ces recommandations en entreprise ?

\\n

Chaque section de cet article propose des méthodologies et des outils directement utilisables. Les recommandations tiennent compte des contraintes d'environnements de production réels.

\\n\\n\\n

Conclusion

Face à l'évolution constante des menaces, une posture de sécurité proactive est indispensable. Les techniques et recommandations présentées dans cet article constituent des fondations solides pour renforcer la résilience de votre infrastructure.

Analyse des impacts et recommandations

L'analyse des risques associés à cette problématique révèle des impacts potentiels significatifs sur la confidentialité, l'intégrité et la disponibilité des systèmes d'information. Les recommandations présentées s'appuient sur les référentiels de l'ANSSI et du NIST pour garantir une approche structurée de la remédiation.

Mise en œuvre opérationnelle

La mise en œuvre des mesures de sécurité décrites dans cet article nécessite une approche progressive, en commençant par les actions à gain rapide avant de déployer les contrôles plus complexes. Un plan d'action priorisé permet de maximiser la réduction du risque tout en respectant les contraintes opérationnelles de l'organisation.

Perspectives et évolutions

Le paysage des menaces évolue continuellement, rendant nécessaire une veille permanente et une adaptation régulière des stratégies de défense. Les tendances actuelles indiquent une sophistication croissante des techniques d'attaque et une nécessité d'automatisation accrue des processus de détection et de réponse.

Synthèse et points clés

Les éléments présentés dans cet article mettent en évidence l'importance d'une approche structurée et méthodique. La combinaison de contrôles techniques, de processus organisationnels et de formation continue constitue le socle d'une posture de sécurité mature et résiliente face aux menaces actuelles.

\\n\\n\n\n

Collecte de preuves forensiques dans AWS CloudTrail

\n

AWS CloudTrail est l'outil fondamental de la forensique cloud sur la plateforme Amazon Web Services : il journalise l'ensemble des appels d'API réalisés dans le compte AWS, constituant une piste d'audit complète de toutes les actions effectuées par les utilisateurs, les rôles IAM et les services AWS. Maîtriser son exploitation forensique est une compétence clé pour tout analyste cloud.

\n\n

La configuration forensique de CloudTrail doit être établie avant tout incident : trail activé sur toutes les régions (pas seulement la région principale), logs envoyés vers un bucket S3 dans un compte de log centralisé distinct du compte de production (éviter qu'un attaquant compromettant le compte de production puisse supprimer les logs), chiffrement des logs avec une clé KMS dédiée, et validation d'intégrité activée (log file validation) pour détecter les modifications ou suppressions de fichiers de logs. L'activation des CloudTrail Insights permet la détection automatique des appels d'API anormaux (volume inhabituel, actions rares).

\n\n

Lors d'un incident, l'analyse forensique CloudTrail commence par la reconstruction de la timeline des actions de l'attaquant : identification du premier appel d'API suspect (souvent une énumération des ressources), trace de la progression (création de backdoors, exfiltration de données, modification de configurations), et identification de toutes les ressources accédées ou modifiées. Les requêtes Athena sur les logs CloudTrail permettent une analyse à grande échelle : par exemple, identifier toutes les actions réalisées avec un rôle compromis, ou tous les appels vers des régions inhabituelles.

\n\n

Les preuves forensiques cloud doivent être collectées et préservées avec les mêmes exigences de chaîne de traçabilité que les preuves forensiques traditionnelles : export des logs CloudTrail pour la période concernée avec hash de vérification, snapshots EBS des instances compromises (non modifiées après la découverte), captures des configurations IAM, groupes de sécurité et VPC au moment de l'incident, et documentation des métadonnées (horodatage, source, hash). Ces preuves peuvent être requises lors de poursuites judiciaires ou d'audits réglementaires.

\n\n

Forensique Azure Activity Log et GCP Audit Logs

\n

Les plateformes Azure et GCP offrent des capacités de journalisation forensique comparables à CloudTrail, avec leurs propres outils et syntaxes d'interrogation. Une approche multi-cloud nécessite de maîtriser les spécificités de chaque plateforme.

\n\n

Sur Microsoft Azure, l'Activity Log enregistre toutes les opérations sur les ressources Azure (création, modification, suppression), tandis que les Azure AD Sign-in Logs et Audit Logs tracent les activités d'identité. Microsoft Sentinel, le SIEM cloud-native d'Azure, permet de corréler ces sources avec d'autres logs (Office 365, Defender) pour une vision unifiée des incidents. La requête KQL (Kusto Query Language) est le langage d'interrogation natif : AuditLogs | where OperationName == "Add member to role" | where TimeGenerated > ago(7d) identifie par exemple les attributions de rôles récentes. Les logs Azure sont conservés 90 jours dans le portail et doivent être exportés vers Log Analytics Workspace ou un storage account pour une rétention plus longue.

\n\n

Sur Google Cloud Platform, les Cloud Audit Logs (Admin Activity, Data Access, System Event, Policy Denied) constituent la source principale de forensique. Cloud Logging centralise ces logs et BigQuery permet des analyses à grande échelle avec SQL standard. La commande gcloud logging read 'logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"' --freshness=7d --format=json extrait les logs d'activité admin des 7 derniers jours. La fonctionnalité VPC Service Controls permet de restreindre l'accès aux APIs GCP par périmètre réseau, générant des logs de violation qui constituent des preuves forensiques précieuses en cas d'incident.

\n\n

Réponse aux incidents cloud : outils et procédures

\n

La réponse aux incidents dans un environnement cloud nécessite des outils et des procédures adaptés aux spécificités cloud : vitesse de propagation des actions (une clé compromis peut créer des centaines de ressources en quelques minutes), complexité des permissions (des droits excessifs dans une région peuvent donner accès à toutes les régions), et risque d'effacement des preuves (un attaquant peut supprimer des ressources et leurs logs associés).

\n\n

Les outils de réponse aux incidents cloud incluent : AWS GuardDuty (détection automatique des menaces avec playbooks de réponse intégrés), Prowler (audit de configuration de sécurité AWS/Azure/GCP en temps réel), CloudMapper (visualisation des relations entre ressources AWS pour identifier les expositions), et Stratus Red Team (simulation d'attaques cloud pour tester les capacités de détection). Pour la conteneurisation, Falco détecte les comportements anormaux dans les pods Kubernetes en temps réel.

\n\n

Le playbook de réponse à un incident cloud doit couvrir les actions immédiates (révocation des credentials compromis, isolation des ressources affectées via modification des security groups ou des ACLs réseau, activation de MFA sur tous les comptes persistants), la collecte de preuves (export des logs avant toute modification, snapshots des instances, capture de la configuration au moment de l'incident), l'analyse (reconstruction de la timeline, identification du blast radius, détermination du vecteur d'entrée initial), et la remédiation (réduction des droits IAM, rotation de tous les credentials, revue des backdoors créés). Ce playbook doit être testé au minimum annuellement via un exercice de table top.

\n\n

Conformité légale de la forensique cloud en Europe

La collecte et la préservation de preuves digitales dans les environnements cloud sont encadrées par un corpus juridique en évolution qui conditionne la recevabilité de ces preuves dans les procédures judiciaires et les exigences de notification réglementaire.

En droit français, la forensique cloud est encadrée par le Code de procédure pénale (perquisitions informatiques, saisies de données) et par la jurisprudence relative aux preuves électroniques. La chaîne de traçabilité des preuves (chain of custody) doit documenter : qui a collecté les preuves, quand, depuis quel système, avec quels outils et droits d'accès, et comment les preuves ont été préservées de toute modification (hash SHA-256 avant et après manipulation). Sans cette documentation, les preuves peuvent être invalidées en procédure judiciaire.

Les obligations RGPD dans la forensique cloud créent une tension entre la nécessité de collecter des logs contenant des données personnelles (adresses IP, identifiants, contenus de messages) et les principes de minimisation des données et de limitation des finalités. La finalité de sécurité et de réponse aux incidents constitue une base légale valable (article 6.1.f du RGPD - intérêt légitime), mais les logs collectés doivent être utilisés uniquement pour les finalités de sécurité déclarées, avec une durée de conservation limitée. La DPIA initiale du système de logs doit prévoir ces usages forensiques pour éviter des violations RGPD lors d'investigations.

La collaboration avec les autorités judiciaires dans les incidents cloud transfrontaliers (serveurs dans plusieurs pays UE ou hors UE) soulève des questions de compétence et d'entraide judiciaire. La Convention de Budapest sur la cybercriminalité facilite la coopération entre les 68 États signataires, mais les délais et les procédures restent complexes. Avoir établi des contacts préalables avec le service dédié de la gendarmerie nationale (C3N) ou de la police nationale (OCLCTIC) facilite la gestion des incidents nécessitant une coopération judiciaire internationale.