Comment savoir qui a fait quoi dans votre compte AWS (CloudTrail expliqué)

« Qui a arrêté le serveur ? » « Ce n'est pas moi. » Quand plusieurs personnes touchent au même compte AWS, tôt ou tard quelqu'un fait quelque chose que personne ne reconnaît. La bonne nouvelle, c'est qu'AWS note tout : chaque action faite depuis la console, depuis un programme ou depuis un outil externe est enregistrée avec qui, quand, depuis quelle adresse et sur quoi. Ce journal s'appelle CloudTrail et il est activé d'office, sans que vous ayez rien fait.

Ce qui est moins simple, c'est de trouver ce que vous cherchez, parce que les noms sont techniques et que tout n'est conservé que 90 jours. Ce guide apprend à chercher et à conserver l'historique.

Pas à pas

1. Ouvrez l'historique des événements

   Dans la console AWS, cherchez CloudTrail et entrez dans Historique des événements. Vous verrez une liste des actions les plus récentes : heure, nom de l'événement, qui et sur quoi. En haut se trouve le sélecteur de région : choisissez la région où s'est produit ce que vous cherchez. Certaines actions globales (d'IAM, par exemple) apparaissent dans la région principale du compte.

2. Cherchez à partir de ce que vous savez

   Au-dessus de la liste, il y a un filtre avec une liste déroulante. Les recherches les plus utiles :

   • Nom de la ressource : collez l'identifiant de la machine (i-0abc...), le nom du bucket ou de la machine Lightsail. Tout ce qui lui a été fait apparaît.
   • Nom de l'événement : si vous savez ce qui s'est passé. Arrêter une machine EC2, c'est StopInstances ; dans Lightsail, StopInstance ; supprimer un fichier S3, DeleteObject ; changer un enregistrement DNS, ChangeResourceRecordSets ; supprimer un instantané, DeleteSnapshot.
   • Nom d'utilisateur : pour voir tout ce qu'a fait une personne précise.

   Ajustez la plage de dates au jour en question pour ne pas vous perdre dans la liste.

3. Lisez le détail de l'événement

   Cliquez sur l'événement. Dans la fiche, vous verrez l'utilisateur exact (et si c'était via un rôle, lequel), l'adresse IP source, l'agent (si c'était depuis la console web, la ligne de commande ou un outil externe) et, dans le bloc JSON en bas, les détails techniques. Avec l'heure, l'IP et l'utilisateur, on sait normalement qui c'était et depuis où, même si c'était sans le vouloir.

4. Déterminez si c'était une personne ou un programme

   Si l'utilisateur est quelqu'un de l'équipe et que l'IP est celle du bureau, c'est cette personne depuis la console. Si l'utilisateur est un compte créé pour un outil (un panneau, un système de sauvegarde) ou un rôle assumé, c'est cet outil : regardez ce qui était programmé à cette heure-là. Si l'utilisateur est le compte racine ou si l'IP vient d'un pays où vous n'avez personne, traitez cela comme une intrusion possible : changez les mots de passe et les clés et relisez le guide sur la protection du compte.

5. Conservez l'historique plus de 90 jours

   L'historique des événements ne garde que trois mois. Pour une entreprise, c'est peu : la question « qui a supprimé ceci » peut arriver l'année suivante. Dans CloudTrail, menu Journaux de suivi, Créer un journal de suivi : donnez-lui un nom, laissez-le créer un nouveau bucket S3 pour le stocker, cochez l'application à toutes les régions et créez. Dès lors, chaque événement est enregistré sous forme de fichiers dans ce bucket ; le premier journal de suivi d'événements de gestion n'a pas de coût CloudTrail, mais il y a le petit coût de l'espace S3.

6. Cherchez dans l'historique quand c'est nécessaire

   Les fichiers du bucket sont du JSON compressé, peu pratiques à lire à la main. Pour y chercher, CloudTrail propose des magasins de données d'événements avec des requêtes de type SQL (payant), ou vous pouvez télécharger le jour précis et l'ouvrir avec un éditeur en cherchant l'identifiant de la ressource. Pour la plupart des gens, savoir qu'ils sont là et pouvoir les récupérer suffit.

Ce qui peut mal tourner