SEC03-BP05 Définir des protections par autorisation 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 de la politique d’autorisation inclut vos barrières de protection pour déterminer les autorisations effectives d’un principal lors de la prise de décisions d’autorisation.  Vous pouvez définir des barrières de protection à 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 souhaité : vous disposez d’un isolement clair des environnements grâce à l’utilisation de Comptes AWS distincts.  Les politiques de contrôle des services (SCP) sont utilisées pour définir des barrières de protection 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 d’autorisation 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 de la mise en place de cette bonne pratique : les barrières de protection des autorisations permettent de s’assurer 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 établie : 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 relèvent de la même unité organisationnelle (UO).  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.  À cette fin, vous pouvez utiliser des politiques de contrôle des services (SCP), que vous pouvez appliquer à une unité organisationnelle 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.

Une autre étape consiste à utiliser les politiques de ressources IAM afin de définir les actions disponibles que vous pouvez entreprendre sur les ressources qu’elles régissent, ainsi que toutes les conditions que le principal doit remplir.  Vous pouvez aller jusqu’à autoriser toutes les actions tant que le principal fait partie de votre organisation (à l’aide de la clé de condition PrincipalOrgId), ou faire preuve de précision en n’autorisant que des actions spécifiques pour un rôle IAM spécifique uniquement.  Vous pouvez adopter une approche similaire avec des conditions dans les politiques d’approbation 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 capturer la portée maximale des autorisations que l’équipe est autorisée à accorder dans une limite d’autorisations IAM et associer ce document à un rôle IAM que l’équipe peut ensuite utiliser pour gérer ses rôles et ses autorisations IAM.  Cette approche peut lui donner la liberté de terminer son travail, tout en limitant les risques liés à un accès administratif IAM.

Une étape plus granulaire consiste à mettre en œuvre des techniques de gestion des accès avec privilèges (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 Configuring MFA-protected API access. 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, et à lever temporairement cette restriction pendant la fenêtre de temps approuvée. Pour en savoir plus sur les solutions validées par AWS et certains partenaires, consultez Temporary elevated access.

Étapes d’implémentation

Ressources

Documents connexes :

Exemples connexes :

Outils associés :