Accès centralisé aux comptes racine pour votre organisation AWS

Chaque responsable de landing zone AWS cherche à réduire la surface d'attaque pour protéger au mieux les systèmes d'information. Une des ressources critiques de la landing zone est le compte racine associé à chaque compte AWS.

Les comptes AWS, même intégrés dans une organisation, possèdent chacun un compte racine. Ces comptes racine étaient indispensables pour effectuer certaines opérations critiques, comme par exemple lors de la configuration initiale du compte et pour débloquer des buckets Amazon Amazon Simple Storage Service (Amazon S3), des queues Amazon Simple Queue Service (AmazonSQS).

Ces opérations, qui doivent rester le plus rare possible, nécessitaient l'utilisation du compte racine et la récupération du dispositif MFA physique dans le coffre de l'entreprise. Ces démarches fastidieuses pour se connecter au compte racine étaient nécessaires pour assurer la sécurité. Elles n'étaient pas suffisante pour totalement protéger le compte AWS, car un collaborateur utilisant le compte racine peut effectuer n'importe quel appel API de services AWS, ce qui représente un risque élevé.

Depuis mi-novembre 2024, AWS propose une nouvelle méthode pour simplifier ces opérations via l'accès racine centralisé. Il n'est plus nécessaire de récupérer le mot de passe du compte racine de chaque compte membre de l'organisation. Les opérations de déblocage de bucket S3 ou de file d'attente SQS peuvent être initiées par un utilisateur IAM ayant les autorisations nécessaires sur un compte membre. La gestion de la récupération du mot de passe racine est maintenant centralisée au niveau du compte payeur.

En utilisant cette méthode, nous pouvons réduire la surface d'attaque et simplifier le modèle opérationnel pour résoudre les erreurs liées à IAM, SQS et S3. Cette méthode permet également de réduire la charge de travail lors du départ d'un administrateur des comptes AWS.

Notre environnement pour cet article

Nous disposons d'une organisation existante avec plusieurs comptes membres pour lesquels nous avons configuré un mot de passe pour chaque compte racine ainsi que l'authentification multi-facteurs (MFA). Un nouveau compte Sandbox nommé Sandbox Sylvain a été créé, mais nous ne nous y sommes jamais connectés.

Nous avons également un compte Breaking Glass avec quelques utilisateurs IAM de secours nous permettant de nous connecter si AWS Identity Center ne fonctionne plus comme attendu.

Mise en place

La première étape est d'activer l'accès centralisé aux comptes racine au niveau du compte payeur de votre organisation. Cette fonctionnalité se trouve au niveau d'IAM si vous passez via la console, vous pouvez également faire cette opération via la CLI.

Pour effectuer cette première étape, vous devez avoir les autorisations suivantes :

  iam:EnableOrganizationsRootCredentialsManagement
  iam:EnableOrganizationsRootSessions
  organizations:RegisterDelegatedAdministrator
  organizations:EnableAwsServiceAccess

Via la CLI

 > aws iam enable-organizations-root-credentials-management
 > aws iam enable-organizations-root-sessions

Via la console

Nous allons dans le service IAM puis cliquer sur le menu de gauche sur le lien Root Access Management

Nous allons utiliser notre compte Breaking Glass comme compte administrateur délégué. Ainsi, nous pourrons non seulement intervenir sur les comptes membres en cas de problème avec nos comptes IAM Breaking Glass, mais en dernier recours, nous pourrons également recréer des identifiants pour le compte racine des comptes membres.

Pour maintenir une observabilité maximale sur ce compte Breaking Glass, nous ajouterons de nouvelles alarmes liées aux nouvelles possibilités offertes à nos utilisateurs IAM.

Nous voyons maintenant la section Centralized root access for member accounts activée.

En cliquant de nouveau sur Root Access Management, vous obtenez la liste des comptes, avec l'indication de la présence ou non d'accès racine. Dans notre cas, le compte Breaking Glass bénéficie de cette fonctionnalité, tandis que les autres comptes ont toujours les accès racine activés.

Validation de la mise en place

Nous n'avons pas encore récupéré le mot de passe pour le compte racine sur le compte Sandbox Sylvain. Nous allons maintenant vérifier que tout cela fonctionne comme attendu, c'est à dire avoir un message d'erreur lors du processus de récupération du mot de passe.

Essayons de faire un reset du mot de passe.

Rien ne change pour la demande d'oubli du mot de passe et l'envoi de l'email se fait sans problème.

Quand nous utilisons le lien, nous avons un message nous indiquant la désactivation de la fonctionnalité, comme attendu.

Il ne reste plus qu'à retirer les accès au compte racine sur tous les comptes membre de l'organisation. Vous pouvez le faire via la console ou la CLI.

Utilisation de assumeRoot et moindre privilège

Même si l'utilisation de l'API assumeRoot est limitée aux politiques IAM suivantes, il est nécessaire de restreindre son utilisation car avec IAMCreateRootUserPassword, nous pourrions réaliser une élévation de privilèges.

Liste des politiques disponibles :

 IAMAuditRootUserCredentials
 IAMCreateRootUserPassword
 IAMDeleteRootUserCredentials
 S3UnlockBucketPolicy
 SQSUnlockQueuePolicy

Nous allons donc répartir les droits entre deux profils d'utilisateurs :

Seuls les administrateurs d'Identity Center et de comptes AWS sont habilités à accorder les droits de connexion sur le compte racine. Ce sont eux également qui gèrent les comptes "breaking glass" et qui appliqueront les mêmes politiques sur ces comptes IAM de secours.

Nous allons créer un permset dédié aux opérateurs, que nous allons appeler UnlockS3SQS. Nous avons délégué la gestion de IAM identity center au compte breaking glass, nous allons donc utiliser celui-ci pour la connexion des Administrateurs et des Opérateurs.

Exemple de politique suivant le principe du moindre privilège pour permettre la gestion des comptes racines par les opérateurs via la console AWS et la CLI :

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "Statement1",
         "Effect": "Allow",
         "Action": [
           "organizations:DescribeOrganization",
           "organizations:ListAccounts",
           "organizations:ListChildren",
           "sts:AssumeRoot",
           "organizations:ListAWSServiceAccessForOrganization",
           "organizations:ListDelegatedAdministrators",
           "organizations:ListOrganizationalUnitsForParent",
           "organizations:ListParents",
           "organizations:ListRoots",
           "organizations:ListAccountsForParent",
           "organizations:DescribeAccount",
           "organizations:DescribeOrganizationalUnit",
           "iam:ListOrganizationsFeatures"
         ],
         "Resource": "*"
       }
     ]
   }

Nous allons interdire la réactivation du compte racine des comptes membres via une Service control Policy (SCP). Si un adminitrateur de compte AWS doit rétablir un compte racine, il devra donc desactiver la SCP sur le compte cible avant tout autre opération.

SCP pour bloquer la réactivation d'un compte racine :

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "Statement2",
               "Effect": "Deny",
               "Action": [
                   "iam:CreateLoginProfile"
               ],
               "Resource": "*",
               "Condition": {
                   "ForAnyValue:Bool": {
                       "aws:AssumedRoot": "true"
                   }
               }
           }
       ]
   }

Réflexions sur la gouvernance

Nous réduisons notre surface d'attaque grâce à la centralisation des accès aux comptes racine. Bien que les tentatives de force brute soient déjà compliquées avec les mécanismes de protection sur le formulaire de récupération de mot de passe, rien n'est plus efficace que la désactivation d'une fonctionnalité.

Le cycle de vie et la protection des mots de passe des comptes racines sont ainsi réduits à un seul élément à gérer. En cas de départ d'un gestionnaire de la landing zone, il suffit de modifier un seul mot de passe pour s'assurer que seules les personnes habilitées auront accès aux comptes racines. Cette première ligne de défense est donc maintenant plus facile à gérer, elle restera renforcée par le MFA physique stocké dans un coffre, dont les gestionnaires de la landing zone n'ont pas le code.

Il n'y a plus d'opérations courantes nécessitant l'utilisation du compte racine et la récupération du MFA associé. Un compte IAM supervisé est suffisant, et cette fonctionnalité ne permet qu'une liste FINIE d'actions strictement nécessaires.

Nous pouvons suivre l'utilisation aisément via CloudTrail, tout en maintenant le même niveau d'observabilité.

Conclusion

L'utilisation de cette méthode améliore la sécurité de votre landing zone. Vous pourriez constater une baisse transitoire de votre score sur certains frameworks de sécurité. Cette fonctionnalité étant assez récente, elle n'est pas encore prise en compte et pourrait être considérée comme un compte racine sans MFA pour le protéger. Par exemple, Scoutsuite considère qu'il n'y a pas de MFA associé au compte racine. Au moment de la rédaction de cet article, aucune pull request n'est ouverte pour corriger ce point.

Comme nous l'avons vu tout au long de cet article, l'accès au compte racine centralisé apporte une grande facilité de gestion, mais il faut rester prudent. L'API IAMCreateRootUserPassword pourrait permettre une élévation de privilèges. Une étude des impacts sur la sécurité est donc indispensable, et le respect de la séparation des responsabilités ainsi que du principe du moindre privilège est nécessaire pour réduire les risques.