Héritage pour les politiques de contrôle des services - AWS Organizations

Héritage pour les politiques de contrôle des services

Important

Les informations de cette section ne s'appliquent pas aux types de politiques de gestion, y compris les politiques de désactivation des services AI, les politiques de sauvegarde ou les politiques de balises. Consultez la section suivante Syntaxe des politiques et héritage pour les types de politiques de gestion.

Politiques de contrôle des services (SCP)

L'héritage pour les politiques de contrôle des services fonctionne comme un filtre à travers lequel les autorisations sont acheminées vers toutes les parties de l'arborescence situées en dessous. Imaginez que l'arborescence inversée de l'organisation est composée de branches qui partent de la racine vers les UO et aboutissent aux comptes. Toutes les autorisations AWS coulent dans la racine de l'arborescence. Ces autorisations doivent ensuite s'écouler à travers les politiques SCP attachées à la racine, aux unités d'organisation et au compte pour arriver au mandataire (un rôle ou un utilisateur) qui fait une demande. Chaque SCP peut filtrer les autorisations qui passent par elle pour aller aux niveaux en dessous. Si une action est bloquée par une instruction Deny, toutes les unités d'organisation et tous les comptes concernés par cette SCP se voient refuser l'accès à cette action. Une SCP d'un niveau inférieur ne peut pas ajouter une autorisation qui a été bloquée par une SCP d'un niveau supérieur. Les SCP peuvent uniquement filtrer, jamais ajouter des autorisations.

Les SCP ne prennent pas en charge les opérateurs d'héritage qui modifient la façon dont les éléments de la politique sont hérités par les unités d'organisation et les comptes enfants.

L'illustration suivante présente le fonctionnement des politiques de contrôle des services.

Dans cette illustration, supposons que l'ovale à gauche représente une SCP attachée à la racine de l'organisation. Il accorde les autorisations A, B et C. La racine contient une unité d'organisation (UO) à laquelle est attachée une seconde SCP représentée par l'ovale à droite. Cette deuxième SCP octroie les autorisations C, D et E. Étant donné que la politique SCP attachée à la racine n'autorise pas D ni E, aucune unité ni aucun compte de l'organisation ne peut les utiliser. Même si la politique SCP attachée à l'unité d'organisation autorise explicitement D et E, ces autorisations sont bloquées par la SCP attachée à la racine. Comme la politique SCP de l'unité d'organisation n'autorise pas A et B, ces autorisations sont bloquées pour l'unité d'organisation et tous ses UO enfants et comptes. Cependant, les autres UO qui pourraient exister sous la racine peuvent toujours autoriser A et B.

À mesure que vous descendez à travers la hiérarchie des UO jusqu'au compte, le processus décrit dans le paragraphe précédent est répété à chaque unité d'organisation et enfin au niveau du compte. À chaque niveau, le résultat de l'évaluation au niveau du parent devient la politique à gauche du diagramme et est comparé aux SCP attachées à l'unité d'organisation enfant.

Par exemple, si vous deviez descendre l'arborescence jusqu'à une UO enfant appelée X, imaginez que l'ovale de gauche représente les autorisations effectives héritées autorisées par toutes les SCP au-dessus de l'UO X dans la hiérarchie. L'ovale de droite représente la SCP attachée à une unité d'organisation ou à un Compte AWS contenu dans l'unité d'organisation X. Encore une fois, l'intersection de ces autorisations est ce qui est disponible pour être utilisé par l'entité de droite. Si cette entité est un Compte AWS, l'intersection est l'ensemble des autorisations qui peuvent être accordées aux utilisateurs et aux rôles dans ce compte. Si l'entité est une unité d'organisation, l'intersection est l'ensemble des autorisations qui peuvent être héritées par les enfants de cette UO. Répétez le processus pour chaque niveau dans la hiérarchie des UO jusqu'à atteindre le compte lui-même. Cette politique effective finale est la liste des autorisations octroyées par toutes les SCP au-dessus de ce compte et celles attachées à celui-ci.

Cela signifie que pour autoriser une API de service AWS au niveau du compte membre, vous devez autoriser cette API à chaque niveau entre le compte membre et la racine de votre organisation. Vous devez attacher des SCP à tous les niveaux, depuis la racine de votre organisation jusqu'au compte membre qui autorise l'API de service AWS considérée (comme ec2:RunInstances). Pour ce faire, utilisez l'une des stratégies suivantes :

  • Une politique de liste de refus utilise la SCP FullAWSAccess qui est attachée par défaut à chaque unité d'organisation et compte. Cette SCP remplace le refus implicite par défaut et autorise explicitement toutes les autorisations à se diffuser de la racine vers chaque compte, sauf si vous refusez explicitement une autorisation avec une SCP supplémentaire que vous créez et attachez à l'unité d'organisation ou au compte approprié. Cette stratégie fonctionne parce qu'un deny dans une politique remplace toujours tout type d'allow. Aucun compte inférieur au niveau de l'UO possédant la politique de refus ne peut utiliser l'API refusée, et il n'y a aucun moyen de rajouter l'autorisation plus bas dans la hiérarchie. Pour de plus amples informations, consultez Utilisation de politiques SCP comme une liste de refus.

  • Une politique de liste d'autorisations fait supprimer la SCP FullAWSAccess qui est attachée par défaut à chaque unité d'organisation et compte. Cela signifie qu'aucune API n'est autorisée nulle part sauf si vous les autorisez explicitement. Pour autoriser une API de service à fonctionner dans un Compte AWS, vous devez créer vos propres SCP et les attacher au compte et à chaque unité d'organisation supérieure, jusqu'à la racine incluse. Chaque SCP dans la hiérarchie, en commençant par la racine, doit explicitement autoriser les API que vous souhaitez pouvoir utiliser dans les unités d'organisation et les comptes situés en dessous. Cette politique fonctionne parce qu'un allow explicite dans une SCP remplace un deny implicite. Pour de plus amples informations, consultez Utilisation de politiques SCP comme une liste d'autorisations.

Pour examiner la façon dont les politiques sont évaluées en termes d'autorisations et de refus implicites ou explicites, et ce qui prend le pas sur quoi, consultez Déterminer si une demande est autorisée ou refusée dans un compte.

Les utilisateurs et rôles doivent tout de même se voir accorder des autorisations à l'aide des politiques d'autorisation AWS Identity and Access Management (IAM) qui leur sont attachées ou qui sont attachées aux groupes. Les SCP déterminent uniquement quelles autorisations sont disponibles pour être accordées par ces politiques. L'utilisateur ne peut pas effectuer les actions qui ne sont pas autorisées par les politiques SCP applicables. Les actions autorisées par les politiques de contrôle des services peuvent être utilisées si elles sont accordées à l'utilisateur ou au rôle par une ou plusieurs politiques d'autorisations IAM.

Lorsque vous attachez des politiques SCP à la racine de l'organisation, à des unités d'organisation ou directement à des comptes, toutes les politiques qui concernent un compte donné sont évaluées ensemble avec les mêmes règles que celles qui régissent les politiques d'autorisations IAM  :

  • Les utilisateurs et les rôles dans les comptes concernés ne peuvent effectuer aucune action répertoriée dans l'instruction Deny de la SCP. Une instruction Deny explicite remplace toutes les instructions Allow que d'autres politiques SCP peuvent accorder.

  • Toutes les actions avec une instruction Allow explicite dans une SCP (comme la SCP « * » par défaut ou une autre SCP qui appelle un service ou une action spécifique) peuvent être déléguées à des utilisateurs et rôles des comptes concernés.

  • Toute action qui n'est pas explicitement autorisée par une politique SCP est implicitement refusée et ne peut pas être déléguée aux utilisateurs ou rôles figurant dans les comptes concernés.

Par défaut, une politique SCP nommée FullAWSAccess est attachée à chaque racine, unité d'organisation et compte de l'organisation. Cette politique de contrôle des services par défaut autorise toutes les actions et tous les services. Ainsi, dans une nouvelle organisation, jusqu'à ce que vous commenciez à créer ou à utiliser les politiques de contrôle des services, toutes les autorisations IAM existantes continuent de fonctionner comme auparavant. Dès que vous appliquez une politique SCP nouvelle ou modifiée à la racine d'une organisation ou à une unité d'organisation contenant un compte, les autorisations dont vos utilisateurs disposent dans ce compte sont filtrées par cette politique. Les autorisations qui fonctionnaient peuvent désormais être refusées si elles ne sont pas autorisées par la politique de contrôle des services à chaque niveau de la hiérarchie jusqu'au compte spécifié.

Si vous désactivez le type de politique SCP au niveau de la racine de l'organisation, toutes les politiques SCP sont automatiquement détachées de toutes les entités liées à la racine de l'organisation. Si vous activez de nouveau des politiques SCP dans cette racine, toutes les associations d'origine sont perdues. Toutes les entités sont réinitialisées et ne sont donc attachées qu'à la politique SCP FullAWSAccess par défaut.

Pour en savoir plus sur la syntaxe des politiques de contrôle des services, consultez Syntaxe d'une politique de contrôle des services.

Vous pouvez afficher une liste de toutes les politiques appliquées à un compte et voir d'où provient cette politique. Pour ce faire, choisissez un compte dans la console AWS Organizations. Dans la page de détails du compte, choisissez Politiques, puis Politiques de contrôle des services dans le panneau d'informations de droite. La même politique peut s'appliquer au compte plusieurs fois, car elle peut être attachée à l'un ou à l'ensemble des conteneurs parents du compte. La politique effective qui s'applique au compte correspond à l'intersection des autorisations permises par toutes les politiques applicables.

Pour de plus amples informations sur l'utilisation des SCP, consultez Politiques de contrôle de service (SCP).