La surveillance des logs cloud est, selon moi, l'une des meilleures lignes de défense pour détecter une fuite de données tôt — parfois avant même que quelqu'un ne s'en aperçoive. Dans cet article je partage des requêtes et patterns concrets, prêts à exécuter, pour AWS et GCP. Mon objectif : vous donner des outils pratiques pour repérer des comportements anormaux dans CloudTrail, CloudWatch, S3, VPC Flow Logs, Cloud Audit Logs et BigQuery/Cloud Logging. Je décris aussi les signaux faibles auxquels prêter attention et quelques règles simples pour prioriser les alertes.
Pourquoi analyser les logs pour repérer une fuite ?
Les fuites de données prennent souvent la forme d'accès légitimes détournés (comptes compromis, clés exposées) ou d'erreurs de configuration (buckets S3 publics, règles IAM trop permissives). Les logs conservent la trace de ces événements : qui a accédé à quoi, depuis où, à quel moment et avec quelle méthode. En creusant ces traces on peut reconstituer une chaîne d'accès et déceler des patterns répétitifs ou anormaux.
Signaux faibles à surveiller
- Tailles d'export ou de GET anormalement élevées sur des objets S3 / Cloud Storage.
- Accès massifs en peu de temps (burst) depuis une même IP ou un même compte de service.
- Accès à des endpoints sensibles (export de tables BigQuery, téléchargement d'objets d'archives).
- Utilisation d'API inhabituelles pour un compte (ex. : ListBuckets puis GetObject en paginant rapidement).
- Présence d'opérations via l'API console manuelle depuis des IP géolocalisées hors des zones habituelles.
- Erreurs d'authentification suivies d'une réussite (brute-force + succès) ou usages de tokens courts.
Pratiques recommandées avant d'exécuter les requêtes
- Centralisez vos logs (CloudWatch Logs / Logs Insights pour AWS, Cloud Logging / BigQuery export pour GCP).
- Normalisez les champs importants : principal, sourceIPAddress, userAgent, resourceName, requestPayloadSize, responseSize.
- Définissez des fenêtres temporelles raisonnables : les fuites peuvent se produire en quelques minutes ou étalées sur des jours.
- Priorisez les assets sensibles (buckets contenant PII, tables BigQuery, endpoints API publiques).
Requêtes & patterns pour AWS
Je me concentre ici sur CloudTrail + CloudWatch Logs Insights, Athena pour S3 access logs et VPC Flow Logs. Adaptez les temps et les noms de champs selon vos schémas.
CloudWatch Logs Insights (CloudTrail logs)
Objectif : détecter accès GET/Download massifs et téléchargements inhabituels.
Requête ready-to-run :
fields @timestamp, eventName, userIdentity.principalId, sourceIPAddress, awsRegion, requestParameters.bucketName, requestParameters.key| filter eventSource="s3.amazonaws.com" and (eventName="GetObject" or eventName="GetObjectAcl" or eventName="GetObjectTorrent")| stats count() as hits, sum(to_number(responseElements.ContentLength)) as total_bytes by userIdentity.principalId, sourceIPAddress| sort total_bytes desc| limit 50
Interprétation : triez par total_bytes pour faire remonter les téléchargements lourds. Si un principal inconnu ou une IP inconnue apparaît en tête, investiguez.
CloudTrail : activités d'énumération puis téléchargement
Pattern : ListBucket suivi de multiples GetObject. Requête :
fields @timestamp, eventName, userIdentity.principalId, sourceIPAddress, requestParameters.bucketName, requestParameters.key| filter eventSource="s3.amazonaws.com" and (eventName="ListObjects" or eventName="ListObjectsV2" or eventName="GetObject")| sort @timestamp desc| limit 200
Recherchez des séquences par principalId où ListObjects précède un grand nombre de GetObject dans un court laps de temps.
Athena / S3 Access Logs (SQL)
Objectif : trouver downloads massifs depuis une même IP :
SELECT requester, COUNT(*) as hits, SUM(object_size) as total_bytesFROM s3_access_logsWHERE operation LIKE 'REST.GET.OBJECT%'AND parse_datetime(request_datetime, 'dd/MMM/yyyy:HH:mm:ss Z') BETWEEN timestamp '2025-01-01 00:00:00' AND timestamp '2025-01-02 00:00:00'GROUP BY requesterORDER BY total_bytes DESCLIMIT 50;
VPC Flow Logs — sorties anormales
Objectif : connexions sortantes massives vers IP externes sur ports atypiques :
# Exemple CloudWatch Logs Insights pour VPC Flow Logsfields @timestamp, srcaddr, dstaddr, dstport, bytes, action| filter action="ACCEPT" and dstaddr not like /^10\./ and dstaddr not like /^172\.(1[6-9]|2[0-9]|3[0-1])\./ and dstaddr not like /^192\.168\./| stats sum(bytes) as total_bytes, count(*) as flows by srcaddr, dstaddr, dstport| sort total_bytes desc| limit 100
Un poste ou instance avec beaucoup de bytes sortants vers une IP publique inconnue est suspect.
Requêtes & patterns pour GCP
Ici j'utilise Cloud Logging (filtre) et BigQuery pour logs exportés.
Cloud Logging (advanced filter)
Objectif : téléchargements massifs depuis Cloud Storage. Filtre prêt à l'emploi :
resource.type="gcs_bucket"protoPayload.methodName="storage.objects.get"jsonPayload.size>10000000
Affinez jsonPayload.size selon vos seuils (ici >10MB). Vous pouvez agréger via Logs Explorer pour lister les comptes et IP.
BigQuery (pour logs exportés)
Détecter export massif de tables BigQuery :
SELECT protopayload_auditlog.authenticationInfo.principalEmail as principal, protopayload_auditlog.requestMetadata.callerIp as ip, COUNT(*) as operations, SUM(IFNULL(JSON_EXTRACT_SCALAR(protopayload_auditlog.request, '$.jobReference.jobId') IS NOT NULL, 1, 0)) as jobsFROM `project.logs_audit_YYYYMMDD*`WHERE protopayload_auditlog.methodName IN ( "google.cloud.bigquery.v2.JobService.Insert", "google.cloud.bigquery.v2.TableService.List", "google.cloud.bigquery.v2.TableService.Get")AND protopayload_auditlog.serviceName = "bigquery.googleapis.com"GROUP BY principal, ipORDER BY operations DESCLIMIT 50;
Regardez les principals qui lancent beaucoup de jobs d'extraction ou d'export.
Filtres Cloud Logging : séquences login échoué puis succès
resource.type="gce_instance"protoPayload.methodName="authorize"protoPayload.status.code=0
Combinez avec filtres d'erreurs pour voir les tentatives précédentes (status.code != 0).
Regex et patterns utiles
- IP suspicious: IPs géolocalisées en dehors des pays usuels pour vos opérations : /^((?!FR|CH|BE).)*$/ (à adapter selon vos besoins).
- Fichiers volumineux: size >= threshold (ex. 10MB).
- Rythme d'accès: pattern timestamp delta < 1s entre requêtes consécutives depuis même principal.
- User-agent suspect: /(curl|wget|python-requests|libwww-perl|Go-http-client)/i — souvent signe d'automatisation.
Comment prioriser les alertes
- Priorité haute : téléchargement massif d'objets contenant des PII/PI/financiers, exfiltration vers IPs externes non répertoriées.
- Moyenne : activités anormales mais venant d'un compte de service connu — vérifier si c'est un job d'export légitime.
- Faible : tentatives échouées répétées sans succès ou accès à des ressources non sensibles.
Mes bons réflexes d'investigation
- Reconstituer la timeline : ListObjects → GetObject × N, jobs BigQuery créés puis exports.
- Corréler logs réseau (VPC Flow) et logs applicatifs pour confirmer exfiltration.
- Zoom sur les credentials : rotation récente, utilisation de clés à large scope, accès via Console vs API.
- Isoler la ressource (retirer accès public, bloquer l'IP, révoquer la clé compromise) tout en conservant les logs pour l'investigation.
Quelques outils complémentaires
- AWS GuardDuty / GCP Security Command Center : détections prêtes à l'emploi mais à compléter par vos requêtes personnalisées.
- Splunk, ELK/Opensearch : pour corrélation et tableaux de bord interactifs.
- Soluces d'analyse comportementale (UEBA) pour repérer des déviations d'usage.
J'espère que ces requêtes et patterns vous permettront de monter rapidement en capacité pour détecter une fuite de données. Si vous voulez, je peux adapter ces requêtes à votre schéma de logs, vos noms de champs et vos seuils, ou produire des alertes CloudWatch / Logs-Based Metrics ou des règles d'alerting GCP correspondantes. N'hésitez pas à me dire sur quel cloud et quelles ressources vous voulez commencer — je vous aide à transformer ces patterns en détection opérationnelle.