Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Évaluation du SCP
Note
Les informations de cette section ne s'appliquent pas aux types de politiques déclaratives, y compris les politiques de sauvegarde, les politiques de balises, les politiques des applications de chat ou les politiques de désactivation des services d'IA. Pour de plus amples informations, veuillez consulter Comprendre l'héritage des politiques déclaratives.
Vous pouvez attacher plusieurs politiques de contrôle des services (SCP) à différents niveaux dans AWS Organizations. Comprendre comment les SCP sont évaluées peut ainsi vous aider à définir des SCP de sorte qu'elles produisent les résultats attendus.
Rubriques
Fonctionnement des SCP avec Allow
Pour qu'une autorisation soit accordée pour un compte spécifique, une instruction Allow explicite est nécessaire à chaque niveau, de la racine via chaque UO sur le chemin d'accès direct au compte (y compris le compte cible lui-même). C'est pourquoi, lorsque vous activez les SCP, AWS Organizations une politique SCP AWS gérée nommée FullawsAccess est associée,
Examinons le scénario des figures 1 et 2. Pour qu'une autorisation soit accordée ou qu'un service soit autorisé pour le compte B, une SCP accordant l'autorisation ou autorisant le service doit être attachée à la racine, à l'UO de production et au compte B.
L'évaluation des SCP obéit à un modèle de refus par défaut selon lequel toutes les autorisations non explicitement autorisées dans les SCP sont refusées. Si aucune instruction Allow n'est présente dans les SCP à quelque niveau que ce soit (à la racine ou au niveau de l'UO de production ou du compte B), l'accès est refusé.
Figure 1 : exemple de structure organisationnelle avec une instruction Allow attachée à la racine, à l'UO de production et au compte B
Figure 2 : exemple de structure organisationnelle avec une instruction Allow attachée à l'UO de production et impact sur le compte B
Fonctionnement des SCP avec Deny
N'importe quelle SCP de la racine via chaque UO sur le chemin d'accès direct au compte (y compris le compte cible lui-même) peut refuser une autorisation pour un compte spécifique.
Supposons, par exemple, qu'une SCP attachée à l'UO de production comporte une instruction Deny explicite spécifiée pour un service donné. Une autre SCP attachée à la racine et au compte B autorise explicitement l'accès à ce même service, comme le montre la figure 3. Par conséquent, le compte A et le compte B se verront refuser l'accès au service, car une politique de refus attachée à tous les niveaux de l'organisation est évaluée pour toutes les UO et tous les comptes membres sous-jacents.
Figure 3 : exemple de structure organisationnelle avec une instruction Deny attachée à l'UO de production et impact sur le compte B
Stratégie d'utilisation des SCP
Lorsque vous rédigez des SCP, vous pouvez utiliser une combinaison de Allow et d'Denyinstructions pour autoriser les actions et les services prévus dans votre organisation. Denyles relevés constituent un moyen efficace de mettre en œuvre des restrictions qui devraient s'appliquer à une plus grande partie de votre organisation ou à vos unités d'organisation, car lorsqu'elles sont appliquées à la racine ou OU-level qu'elles affectent tous les comptes qui la composent.
Astuce
Vous pouvez utiliser les données du dernier accès au service dans IAM pour mettre à jour vos SCP afin de limiter l'accès aux seules données Services AWS dont vous avez besoin. Pour de plus amples informations, consultez Affichage des dernière informations consultées pour Organizations dans le Guide de l'utilisateur IAM.
AWS Organizations attache un SCP AWS géré nommé FullawsAccess Allow pour n'autoriser que certains services. Vous pouvez choisir de remplacer FullLawsAccess à la racine ou à tous les niveaux. Si vous attachez une liste d'autorisations SCP spécifique à un service à la racine, elle s'applique automatiquement à toutes les unités d'organisation et à tous les comptes situés en dessous, ce qui signifie qu'une seule politique au niveau racine détermine la liste d'autorisation de service effective pour l'ensemble de l'organisation, comme indiqué dans le scénario 7. Vous pouvez également supprimer et remplacer FullLawsAccess au niveau de chaque unité d'organisation et de chaque compte, ce qui vous permet de mettre en œuvre des listes d'autorisation de services plus détaillées qui diffèrent selon les unités organisationnelles ou les comptes individuels.
Remarque : le fait de se fier uniquement aux instructions Allow et au modèle implicite de refus par défaut peut entraîner un accès involontaire, car des instructions Allow plus larges ou superposées peuvent remplacer des instructions plus restrictives.
L'exemple suivant montre une politique combinant les deux instructions, ce qui empêche les comptes membres de quitter l'organisation et autorise l'utilisation des services AWS souhaités. L'administrateur de l'organisation peut détacher la politique FullAWSAccess et attacher celle-ci à la place.
Pour démontrer comment plusieurs politiques de contrôle des services (SCP) peuvent être appliquées dans une AWS organisation, considérez la structure organisationnelle et les scénarios suivants.
Scénario 1 : Impact des politiques de refus
Ce scénario montre comment les politiques de refus aux niveaux supérieurs de l'organisation ont un impact sur tous les comptes ci-dessous. Lorsque l'unité d'organisation Sandbox applique à la fois des politiques « AWS Accès complet » et « Refuser l'accès S3 », et que le compte B a une politique « Refuser l'accès EC2 », il en résulte que le compte B ne peut pas accéder à S3 (à partir du OU-level refus) et à EC2 (à partir de son refus au niveau du compte). Le compte A ne dispose pas d'un accès S3 (depuis le OU-level refus).
Scénario 2 : les politiques d'autorisation doivent exister à tous les niveaux
Ce scénario montre comment les politiques d'autorisation fonctionnent dans les SCP. Pour qu'un service soit accessible, il doit y avoir une autorisation explicite à tous les niveaux, de la racine au compte. Dans ce cas, étant donné que l'unité d'organisation Sandbox a une politique « Autoriser l'accès à EC2 », qui n'autorise explicitement que l'accès au service EC2, les comptes A et B auront uniquement accès à EC2.
Scénario 3 : Impact de l'absence d'une instruction Allow au niveau de la racine
Lorsque le root ne dispose que d'une instruction Refy sans une instruction Allow « AWS Accès complet », tous les comptes membres n'ont aucun accès au service. Les SCP nécessitent une autorisation explicite à chaque niveau du chemin. Un Deny-only SCP à la racine bloque donc chaque service à moins qu'un Allow explicite ne le couvre.
Scénario 4 : instructions de refus en couches et autorisations qui en résultent
Ce scénario illustre une structure d'unité d'organisation profonde à deux niveaux. L'unité d'organisation Root et Workloads dispose d'un « AWS accès complet », l'unité d'organisation de test dispose d'un « AWS accès complet » avec « Interdire l'accès à EC2 » et l'unité d'organisation de production dispose d'un « AWS accès complet ». Par conséquent, le compte D dispose de tous les accès aux services sauf EC2 et les comptes E et F ont tous accès aux services.
Scénario 5 : Autoriser les politiques OU-level pour restreindre l'accès au service
Ce scénario montre comment les politiques d'autorisation peuvent être utilisées pour restreindre l'accès à des services spécifiques. L'unité d'organisation de test applique une politique « Autoriser l'accès à EC2 », ce qui signifie que seuls les services EC2 sont autorisés pour le compte D. L'unité d'organisation de production conserve un « AWS accès complet », de sorte que les comptes E et F ont accès à tous les services. Cela montre comment des politiques d'autorisation plus restrictives peuvent être mises en œuvre OU-level tout en maintenant une autorisation plus large au niveau racine.
Scénario 6 : le Root-level refus affecte tous les comptes, quel que soit le niveau d'autorisation inférieur
Ce scénario montre qu'une politique de refus au niveau racine affecte tous les comptes de l'organisation, quelles que soient les politiques d'autorisation aux niveaux inférieurs. La racine applique à la fois des politiques « AWS Accès complet » et « Refuser l'accès S3 ». Même si l'unité d'organisation de test applique une politique « Autoriser l'accès S3 », le refus S3 au niveau racine est prioritaire. Le compte D n'a aucun accès au service car l'unité d'organisation de test autorise uniquement l'accès S3, mais S3 est refusé au niveau racine. Les comptes E et F peuvent accéder à d'autres services à l'exception de S3 en raison du refus explicite au niveau root.
Scénario 7 : politiques d'autorisation personnalisées au niveau racine pour restreindre l' OU-level accès
Ce scénario montre comment les SCP dotés de listes d'autorisations de service explicites fonctionnent lorsqu'ils sont appliqués au niveau racine dans un AWS Organizations. Au niveau racine de l'organisation, deux SCP personnalisés « Service Allow » sont attachés pour autoriser explicitement l'accès à un ensemble limité de AWS services : SCP_1 autorise IAM et Amazon EC2, SCP_2 autorise Amazon S3 et Amazon. CloudWatch Au niveau de l'unité organisationnelle (OU), la politique FullLawsAccess par défaut reste attachée. Cependant, en raison du comportement d'intersection, les comptes A et B de ces unités d'organisation ne peuvent accéder qu'aux services explicitement autorisés par le SCP au niveau racine. La politique racine la plus restrictive prévaut, limitant ainsi l'accès uniquement à IAM, EC2, S3 et aux CloudWatch services, quelles que soient les autorisations plus étendues accordées aux niveaux organisationnels inférieurs.
