Enquêter sur les incidents avec des requêtes SQL

Une fois CloudTrail et les journaux de flux catalogués, une investigation devient une série d'interrogations SQL qui réduisent des milliards d'événements à quelques-uns réellement importants. La compétence consiste à savoir quoi demander : qui a fait quoi, depuis où et quand. Cette leçon présente les modèles d'interrogation sur lesquels les enquêteurs s'appuient.

Lorsqu'un identifiant est soupçonné d'avoir été compromis, vous interrogez toutes les actions de ce principal. Filtrer CloudTrail sur userIdentity.arn ou sur l'ID de clé d'accès révèle chaque appel d'API effectué, dans l'ordre. Cette chronologie des actions de l'attaquant constitue souvent le résultat le plus précieux d'une investigation.

Filtrer sur sourceIPAddress affiche tout ce qui a été effectué depuis une adresse donnée. Si vous disposez d'une adresse IP suspecte issue d'une détection GuardDuty, cela fait apparaître chaque appel effectué sur l'ensemble des services, ce qui vous aide à déterminer l'ampleur de l'impact et à repérer les ressources touchées par l'attaquant.

Rechercher les événements dont errorCode est AccessDenied ou UnauthorizedOperation révèle une phase de reconnaissance : l'attaquant teste ce qu'un identifiant volé lui permet de faire. Une série de refus provenant d'un même principal, suivie d'un appel réussi, montre qu'il a trouvé une autorisation fonctionnelle, ce qui constitue un signal clair d'escalade.

Surveillez les événements IAM sensibles tels que CreateUser, AttachUserPolicy, CreateAccessKey ou PutUserPolicy. Un attaquant tente souvent d'établir une persistance en créant de nouvelles identités ou clés. Rechercher ces noms d'événements révèle rapidement les tentatives visant à renforcer son accès au-delà de l'entrée initiale.

Les investigations efficaces associent des sources de données : comparez les actions d'un principal CloudTrail aux journaux de flux VPC de la même instance, ou aux journaux ALB correspondant aux requêtes qu'elle a traitées. Mettre en corrélation l'activité du plan de contrôle et l'activité réseau permet de reconstituer l'ensemble de l'attaque plutôt que des fragments isolés.

Limitez toujours les interrogations à une fenêtre temporelle à l'aide de l'horodatage de l'événement. Cela concentre l'investigation sur la période pertinente et, avec les partitions, réduit considérablement la quantité de données analysées et le coût. Commencer avec une période large, puis la réduire, est une progression naturelle à mesure que la situation se précise.

Les agrégations font ressortir les tendances : utilisez GROUP BY sur l'adresse IP source pour trouver les plus actives, comptez les noms d'événements distincts par principal pour évaluer l'étendue de l'activité, ou totalisez les erreurs au fil du temps pour repérer un pic. Ces synthèses transforment les lignes brutes en tendances qui vous orientent vers l'incident réel.

La même approche SQL s'applique aux journaux de flux stockés dans S3 : recherchez les transferts sortants importants, comptez les ports rejetés par source ou répertoriez les adresses IP externes contactées par une instance. Associer CloudTrail (ce qui a été fait dans l'API) aux journaux de flux (ce qui a circulé sur le réseau) donne les deux aspects de l'incident.

Enregistrez les interrogations d'investigation éprouvées comme interrogations nommées ou sous forme de vues afin que votre équipe puisse les relancer rapidement lors du prochain incident. Une bibliothèque d'interrogations vérifiées, comme « toutes les actions d'une clé d'accès » ou « les appels refusés au cours de la dernière heure », transforme un travail ponctuel en capacité de réponse reproductible.

Les interrogations produisent des éléments probants ; ces éléments orientent la réponse : révoquer la clé, isoler l'instance, supprimer l'utilisateur IAM malveillant. Une démarche d'interrogation rigoureuse — d'abord le principal, puis l'adresse IP, ensuite les événements d'escalade, puis la corrélation — vous donne la compréhension complète et fiable nécessaire pour contenir correctement un incident.

Les investigations sont des interrogations SQL portant sur des journaux catalogués. Commencez par un principal ou une adresse IP source, recherchez les appels refusés pour la reconnaissance, surveillez les événements IAM comme CreateAccessKey pour détecter une escalade et limitez tout dans le temps. Regroupez et comptez pour trouver des tendances, mettez en corrélation CloudTrail et les journaux de flux, puis enregistrez des interrogations nommées vérifiées afin que la collecte d'éléments probants devienne une capacité de réponse reproductible.