Détecter l'utilisation du compte racine

L’utilisateur Root est l’identité du propriétaire du compte, créée lors de l’ouverture d’un compte AWS, et dispose d’un accès illimité à chaque action et ressource. Il ne peut pas être restreint par des politiques IAM ou des SCP. En raison de ce pouvoir, toute utilisation de l’utilisateur Root constitue un événement de sécurité fortement révélateur qui mérite une alerte immédiate.

Les recommandations AWS préconisent d’utiliser l’utilisateur Root uniquement pour les quelques tâches qui l’exigent, puis de ne plus l’utiliser. Vous devez activer la MFA pour Root, supprimer entièrement ses clés d’accès et créer des identités IAM ou des utilisateurs d’Identity Center pour le travail quotidien. Une fois le verrouillage effectué, toute activité Root légitime doit être rare et planifiée.

Puisque Root ne devrait presque jamais se connecter, une connexion Root inattendue est un indicateur fort de compromission ou de violation d’une politique. Sa détection fait partie des contrôles de surveillance classiques du référentiel CIS et constitue un scénario fréquent d’examen : la réponse attendue est un filtre de métrique et une alarme alimentés par CloudTrail, et non une vérification manuelle.

La détection utilise trois éléments que vous connaissez déjà : CloudTrail enregistre les événements de connexion et d’API, journaux CloudWatch reçoit ces événements lorsque CloudTrail est configuré pour les transmettre à un groupe de journaux, et un filtre de métrique associé à une alarme transforme les événements Root en notification instantanée. Chaque élément doit être en place pour que la chaîne fonctionne.

Dans un événement CloudTrail, le champ userIdentity.type est égal à Root lorsque l’utilisateur Root exécute l’action. Un filtre de métrique peut rechercher ce champ. Pour éviter le bruit causé par les événements automatisés courants, les filtres excluent souvent aussi les événements de services AWS afin que seules les véritables actions humaines de Root déclenchent l’alerte.

Par défaut, CloudTrail écrit dans S3, et non dans les journaux CloudWatch. Pour déclencher une alarme presque en temps réel, vous devez également configurer le journal d’activité afin qu’il transmette les événements à un groupe de journaux CloudWatch. Cela nécessite un rôle IAM autorisant CloudTrail à écrire dans le groupe de journaux. Sans cette étape de transmission, le filtre de métrique n’a rien à rechercher.

Créez un filtre de métrique sur le groupe de journaux CloudTrail avec un modèle correspondant à userIdentity.type = Root. Associez chaque correspondance à une métrique telle que RootAccountUsageCount, avec une valeur de un. Chaque action Root incrémente alors une métrique que vous pouvez surveiller, transformant un champ JSON enfoui en signal mesurable.

Associez une alarme CloudWatch à la métrique, avec un seuil de un sur une seule période courte, afin qu’elle se déclenche dès le premier événement Root. Dirigez l’alarme vers une rubrique SNS à laquelle votre équipe de sécurité est abonnée. Vous obtenez ainsi une alerte presque instantanée dès que Root est utilisé.

Dans une organisation, chaque compte membre possède son propre utilisateur Root. Un journal d’activité d’organisation peut centraliser CloudTrail pour tous les comptes, et vous pouvez créer la détection une seule fois sur le groupe de journaux central. Ainsi, aucune activité Root d’un compte membre ne passe inaperçue, ce qui constitue une exigence essentielle de gouvernance.

Lorsque l’alarme se déclenche, traitez l’événement comme un incident jusqu’à preuve du contraire. Vérifiez si l’activité correspondait à une tâche planifiée et autorisée. Dans le cas contraire, sécurisez le compte : changez le mot de passe Root, vérifiez que la MFA est toujours active, examinez les actions Root récentes dans CloudTrail et recherchez les nouvelles identités IAM ou clés qu’un attaquant aurait pu créer.

La détection de l’utilisation de Root relie CloudTrail, les journaux CloudWatch, les filtres de métriques, les alarmes et SNS au sein d’un contrôle réaliste. Attendez-vous à des questions dont les mauvaises réponses proposent une vérification manuelle, des politiques IAM appliquées à Root ou des SCP. La bonne réponse est toujours une détection automatisée accompagnée d’une notification immédiate, car Root ne peut pas être restreint, seulement surveillé.

Testez le modèle de détection de l’utilisation de Root.

L’utilisateur Root dispose d’un accès illimité et doit être mis à l’écart avec la MFA, sans aucune clé d’accès. Toute utilisation constitue un événement fortement révélateur. Détectez-la en transmettant CloudTrail aux journaux CloudWatch, en ajoutant un filtre de métrique sur userIdentity.type = Root et en déclenchant une alarme CloudWatch vers une rubrique SNS. Dans les organisations, un journal d’activité d’organisation centralise cette détection pour chaque compte.