Mise en place des accès root centralisé pour votre organisation AWS

Pourquoi mettre cela en place ?

Les comptes AWS, bien qu'intégrés dans une organisation, possèdent chacun un compte root. Ces comptes root étaient indispensables pour effectuer certaines opérations critiques, principalement lors de la configuration initiale du compte et pour résoudre des erreurs de configuration (IAM, S3 et SQS).

Bien que rares, ces opérations nécessitaient l'utilisation du compte root et la récupération du dispositif MFA physique dans le coffre de l'entreprise. Ces démarches, bien que lourdes, étaient nécessaires pour résoudre rapidement des problèmes simples. De plus, un collaborateur utilisant le compte root peut effectuer n'importe quel appel API, ce qui représente un risque supplémentaire.

Depuis mi-novembre, AWS propose une nouvelle méthode pour simplifier ces opérations via l'accès root centralisé (https://aws.amazon.com/fr/about-aws/whats-new/2024/11/manage-root-access-aws-identity-access-management/). Il n'est plus nécessaire de récupérer le mot de passe root de chaque compte membre de l'organisation. Désormais, 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 pour assumer le rôle root sur un compte membre. La gestion de la récupération du mot de passe root 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 root 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 nos permettant de nous connecter si AWS Identity Center ne fonctionne plus comme attendu.

Mise en place

La première étape est d'activer cette fonctionnalité au niveau du compte payer 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

Via la console

Nous allons aller 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 root pour les 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 actif la section Centralized root access for member accounts.

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 root. Dans notre cas, le compte Breaking Glass bénéficie de cette fonctionnalité, tandis que les autres comptes ont toujours les accès root activés.

Validation de la mise en place

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. Nous n'avons pas mis en place de mot de passe root sur le compte Sandbox Sylvain.

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'a retirer les accès root sur tous les comptes 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 assume root 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 :

• Les administrateurs de comptes AWS qui auront accès aux APIs IAMAuditRootUserCredentials, IAMCreateRootUserPassword et IAMDeleteRootUserCredentials.
• Les opérateurs qui pourront débloquer les buckets S3 et les queues SQS via les APIs S3UnlockBucketPolicy et SQSUnlockQueuePolicy. Pour plus de lisibilité, nous allons créer un permset dédié à cette fonction, que nous pourrions appeler UnlockS3SQS.

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

Pour aller plus loin, nous pouvons ajouter une IAM boundary à tous les permsets, pour s'assurer qu'aucun autre permset ne puisse utiliser l'API assumeRoot. Il faudra donc déployer cette policy sur tous les comptes AWS de l'organisation.

Réflexions sur la gouvernance

Nous réduisons notre surface d'attaque grâce à la centralisation des comptes root. 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 root 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 ont accès à une partie du secret (renforcé par le MFA physique stocké dans un coffre).

Il n'y a plus d'opérations courantes nécessitant l'utilisation du compte root 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é.

Selon le modèle opérationnel, nous pouvons également adopter un fonctionnement décentralisé, en permettant par exemple aux responsables d'une BU de débloquer un bucket S3 ou une queue SQS via le permset UnlockS3SQS. La réactivation du compte root sur leur compte ne sera bien sûr pas permise.

Conclusion

Bien que 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 root sans MFA pour le protéger.

Comme nous l'avons vu tout au long de cet article, l'accès root 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.