SEC03-BP05 Définir des garde-fous des autorisations pour votre organisation

Utilisez des barrières de protection pour réduire la portée des autorisations disponibles qui peuvent être accordées aux principaux. La chaîne d’évaluation des politiques d’autorisation inclut vos barrières de protection permettant de déterminer les autorisations effectives d’un principal lorsqu’il prend des décisions en matière d’autorisation.  Vous pouvez définir des garde-fous à l’aide d’une approche par couches. Appliquez certaines barrières de protection de manière générale à l’ensemble de votre organisation et appliquez-en d’autres de manière granulaire aux sessions d’accès temporaires.

Résultat escompté : vous isolez clairement les environnements en utilisant des Comptes AWS distincts.  Les politiques de contrôle des services (SCP) sont utilisées pour définir des garde-fous des autorisations à l’échelle de l’organisation. Des barrières de protection plus étendues sont définies aux niveaux hiérarchiques les plus proches de la racine de votre organisation, tandis que des barrières de protection plus strictes sont définies plus près du niveau des comptes individuels.

Lorsqu’elles sont prises en charge, les politiques de ressources définissent les conditions qu’un principal doit remplir pour accéder à une ressource. Les politiques relatives aux ressources définissent également l’ensemble des actions autorisées, le cas échéant. Les limites des autorisations sont placées sur les principaux qui gèrent les autorisations de charge de travail, en déléguant la gestion des autorisations aux propriétaires individuels de la charge de travail.

Anti-modèles courants :

Avantages du respect de cette bonne pratique : les barrières de protection des autorisations contribuent à garantir que des autorisations indésirables ne peuvent pas être accordées, même lorsqu’une politique d’autorisation tente de le faire.  Cela peut simplifier la définition et la gestion des autorisations en réduisant la portée maximale des autorisations à prendre en compte.

Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : moyen

Directives d’implémentation

Nous vous recommandons d’utiliser une approche par couches afin de définir les barrières de protection des autorisations pour votre organisation. Cette approche réduit systématiquement l’ensemble maximum d’autorisations possibles à mesure que des couches supplémentaires sont appliquées. Cela vous permet d’accorder l’accès sur la base du principe du moindre privilège, réduisant ainsi le risque d’accès involontaire dû à une mauvaise configuration des politiques.

La première étape pour établir des barrières de protection des autorisations consiste à isoler vos charges de travail et vos environnements dans des Comptes AWS séparés. Les principaux d’un compte ne peuvent pas accéder aux ressources d’un autre compte sans autorisation explicite, même lorsque les deux comptes appartiennent à la même organisation AWS ou à la même unité organisationnelle. Vous pouvez utiliser les unités organisationnelles pour regrouper les comptes que vous souhaitez administrer en tant qu’unité unique.   

L’étape suivante consiste à réduire le nombre maximum d’autorisations que vous pouvez accorder aux principaux au sein des comptes membres de votre organisation. Vous pouvez utiliser des politiques de contrôle des services (SCP) à cette fin, que vous pouvez appliquer à une unité d’organisation ou à un compte. Les SCP peuvent appliquer des contrôles d’accès courants, tels que la restriction de l’accès à des Régions AWS spécifiques, la protection contre la suppression des ressources ou la désactivation d’actions de service potentiellement risquées. Les SCP que vous appliquez à la racine de votre organisation n’affectent que ses comptes membres, pas le compte de gestion.  Les SCP régissent uniquement les principaux au sein de votre organisation. Vos SCP ne régissent pas les principaux extérieurs à votre organisation qui accèdent à vos ressources.

Si vous utilisez AWS Control Tower, vous pouvez tirer parti de ses contrôles et de ses zones de destination comme base de vos garde-fous d’autorisations et de votre environnement multi-compte. Les zones de destination fournissent un environnement de base sécurisé préconfiguré avec des comptes distincts pour différentes charges de travail et applications. Les garde-fous appliquent des contrôles obligatoires en matière de sécurité, d’exploitation et de conformité par le biais d’une combinaison de politiques de contrôle des services (SCP), de règles AWS Config et d’autres configurations. Toutefois, lorsque vous utilisez les garde-fous et les zones de destination Control Tower en plus des politiques SCP personnalisées de l’organisation, il est essentiel de suivre les bonnes pratiques décrites dans la documentation AWS afin d’éviter les conflits et de garantir une bonne gouvernance. Reportez-vous aux recommandations AWS Control Tower pour AWS Organizations afin d’obtenir des recommandations détaillées sur la gestion des politiques SCP, des comptes et des unités organisationnelles (OU) dans un environnement Control Tower.

En respectant ces directives, vous pouvez tirer parti efficacement des garde-fous, des zones de destination et des politiques SCP personnalisées de Control Tower tout en atténuant les conflits potentiels et en garantissant une gouvernance et un contrôle appropriés de votre environnement AWS multi-compte.

Une autre étape consiste à utiliser les politiques de ressources IAM pour définir les actions disponibles que vous pouvez entreprendre sur les ressources qu’elles régissent, ainsi que les conditions que le principal temporaire doit respecter. Cela peut être aussi large que d’autoriser toutes les actions tant que le principal fait partie de votre organisation (en utilisant la clé de condition PrincipalOrgID), ou aussi granulaire que de n’autoriser que des actions spécifiques par un rôle IAM spécifique. Vous pouvez adopter une approche similaire avec des conditions dans les politiques de confiance des rôles IAM.  Si une politique d’approbation en matière de ressources ou de rôles désigne explicitement un principal dans le même compte que le rôle ou la ressource qu’elle gère, ce principal n’a pas besoin de politique IAM associée qui accorde les mêmes autorisations.  Si le principal se trouve dans un compte différent de celui de la ressource, il a besoin d’une politique IAM associée qui accorde ces autorisations.

Souvent, une équipe responsable d’une charge de travail souhaite gérer les autorisations requises pour sa charge de travail.  Cela peut l’obliger à créer de nouveaux rôles et politiques d’autorisation IAM.  Vous pouvez saisir l’étendue maximale des autorisations que l’équipe est autorisée à accorder dans une limite des autorisations IAM, et associer ce document à un rôle IAM que l’équipe peut ensuite utiliser pour gérer ses rôles et autorisations IAM.  Cette approche peut lui donner la liberté de terminer son travail, tout en limitant les risques liés au fait de disposer d’un accès administratif IAM.

Une étape plus précise consiste à mettre en œuvre des techniques de gestion des accès privilégiés (PAM) et de gestion des accès élevés temporaires (TEAM).  Un exemple de PAM consiste à obliger les principaux à effectuer une authentification multifactorielle avant de réaliser des actions avec privilège.  Pour plus d’informations, consultez Configuration de l’accès aux API protégé par MFA. TEAM a besoin d’une solution qui gère l’approbation et le délai pendant lequel un principal est autorisé à bénéficier d’un accès élevé.  Une approche consiste à ajouter temporairement le principal à la politique d’approbation des rôles pour un rôle IAM dont l’accès est élevé.  Une autre approche consiste, dans le cadre d’un fonctionnement normal, à réduire les autorisations accordées à un principal par un rôle IAM à l’aide d’une politique de session, puis à lever temporairement cette restriction pendant la période approuvée. Pour en savoir plus sur les solutions validées par AWS et des partenaires sélectionnés, consultez la section Accès élevé temporaire.

Étapes d’implémentation

Ressources

Documents connexes :

Exemples connexes :

Outils associés :