Rôles intercomptes et politiques de ressources

Les architectures réelles s’étendent sur plusieurs comptes : un compte de production, un compte de journalisation et un compte de services partagés. Les charges de travail et les personnes doivent souvent accéder à des ressources entre ces limites.

La méthode sécurisée ne consiste jamais à copier des informations d’identification entre les comptes. Accordez plutôt un accès limité au moyen de rôles entre comptes ou de politiques fondées sur les ressources.

Le schéma le plus courant consiste à créer un rôle dans le compte cible, qu’assume un principal du compte source.

• La politique de confiance du rôle désigne le compte source ou le principal.
• Le principal source appelle AssumeRole et reçoit des informations d’identification temporaires.
• Il agit ensuite dans le compte cible selon les autorisations du rôle.

L’adoption d’un rôle entre comptes exige que les deux parties l’autorisent :

• La politique de confiance du rôle cible autorise le principal source.
• La politique d’identité du principal source autorise sts:AssumeRole sur ce rôle.

Si l’une des deux fait défaut, l’adoption échoue. Cette double vérification est un point fréquent des examens.

Certains services prennent en charge des politiques fondées sur les ressources, directement attachées à la ressource, comme une politique de compartiment S3, une politique de clé KMS ou une politique de file d’attente SQS.

Elles peuvent accorder un accès à un principal d’un autre compte sans que ce principal assume un rôle. Le compte externe utilise sa propre identité et la politique de la ressource l’autorise.

Choisissez le mécanisme en fonction du service :

• Pour les services sans politique de ressource (EC2, la plupart des API), utilisez un rôle entre comptes.
• Pour S3, KMS, SNS, SQS, Lambda et d’autres services, une politique de ressource peut accorder un accès direct entre comptes.

Les politiques de ressources évitent un appel AssumeRole supplémentaire.

Lorsque vous accordez à un tiers (par exemple un fournisseur SaaS) un accès entre comptes, ajoutez une condition d’identifiant externe à la politique de confiance.

Le fournisseur doit transmettre une valeur secrète unique lorsqu’il assume le rôle. Cela bloque le problème du mandataire confus, dans lequel un attaquant incite le fournisseur à accéder au compte d’un autre client.

Les rôles entre comptes doivent accorder le minimum nécessaire, en limitant l’accès à des ressources et à des actions précises.

Une erreur courante consiste à accorder une confiance étendue à un compte externe entier, tout en lui attribuant des autorisations d’administrateur. Limitez la confiance à un rôle ou à un utilisateur précis, et les autorisations à la tâche exacte.

Une conception fréquente consiste à centraliser une fonction dans un compte auquel les autres accèdent par des rôles, par exemple un compte de sécurité qui assume des rôles en lecture seule dans chaque compte de charge de travail.

Chaque compte de charge de travail héberge un rôle portant le même nom et faisant confiance au compte de sécurité, afin que les outils puissent analyser tous les comptes de manière uniforme.

AWS Resource Access Manager (RAM) partage des ressources précises, comme des sous-réseaux ou des passerelles de transit, entre les comptes d’une organisation.

RAM sert à partager la ressource elle-même, plutôt qu’à accorder des autorisations d’API permettant d’agir dessus. Il complète les rôles et les politiques de ressources pour le partage du réseau et de l’infrastructure.

L’accès entre comptes élargit votre surface de confiance : vous devez donc l’auditer régulièrement.

• CloudTrail enregistre chaque appel AssumeRole et chaque appel d’API entre comptes.
• IAM Access Analyzer signale les politiques de ressources qui accordent un accès en dehors de votre compte.

Examinez ces éléments pour détecter rapidement les partages involontaires.

Pour connecter des comptes en toute sécurité, privilégiez les rôles pour le calcul et les API, les politiques de ressources pour les services de stockage et de messagerie, et appliquez toujours le moindre privilège avec un identifiant externe pour les tiers.

Ne partagez jamais de clés à long terme entre les comptes.

Analysez l’accès entre comptes.

Vous avez appris à connecter des comptes en toute sécurité.

• Les rôles entre comptes nécessitent à la fois une politique de confiance et une politique d’identité source.
• Les politiques fondées sur les ressources accordent un accès direct pour des services comme S3 et KMS.
• Utilisez un identifiant externe pour les tiers et auditez avec Access Analyzer et CloudTrail.