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

Comme vous pouvez associer plusieurs politiques de contrôle des services (SCPs) à différents niveaux AWS Organizations, comprendre comment SCPs elles sont évaluées peut vous aider à rédiger des politiques SCPs qui donneront le bon résultat.

Comment SCPs travailler 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 l'activez SCPs, AWS Organizations elle associe une politique SCP AWS gérée nommée Full AWSAccess qui autorise tous les services et actions. Si cette politique est supprimée et qu'elle n'est remplacée à aucun niveau de l'organisation, tous OUs les comptes inférieurs à ce niveau seront empêchés d'effectuer des actions.

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 du SCP suit un deny-by-default modèle, ce qui signifie que toutes les autorisations non explicitement autorisées SCPs sont refusées. Si aucune instruction d'autorisation n'est présente dans aucun des niveaux tels que Root, Production OU ou Account B, l'accès est refusé. SCPs

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

Comment SCPs travailler 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 tous les comptes OUs et 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 SCPs

Lorsque SCPs vous rédigez, vous pouvez utiliser une combinaison de Deny déclarations Allow et de déclarations pour autoriser les actions et les services prévus dans votre organisation. Denyles déclarations constituent un moyen efficace de mettre en œuvre des restrictions qui devraient s'appliquer à une plus grande partie de votre organisation ou OUs parce que lorsqu'elles sont appliquées à la racine ou au niveau de l'unité d'organisation, elles affectent tous les comptes qui en dépendent.

Par exemple, vous pouvez mettre en œuvre une politique utilisant Deny des instructions Empêcher les comptes membres de quitter l'organisation au niveau de la racine, qui sera effective pour tous les comptes de l'organisation. Les instructions Deny prennent également en charge un élément de condition qui peut être utile pour définir des exceptions.

AWS Organizations attache un SCP AWS géré nommé Full AWSAccess à chaque racine, unité d'organisation et compte lors de sa création. Cette politique autorise tous les services et actions. Vous pouvez AWSAccess remplacer Full par une politique n'autorisant qu'un ensemble de services, de sorte que les nouveaux services ne Services AWS sont pas autorisés, sauf s'ils sont explicitement autorisés par le biais d'une mise à jour SCPs. Par exemple, si votre organisation souhaite uniquement autoriser l'utilisation d'un sous-ensemble de services dans votre environnement, vous pouvez utiliser une instruction Allow pour n'autoriser que certains services.

JSON

{
"Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*",
                "organizations:*"
            ],
            "Resource": "*"
        }
    ]
}

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 AWSAccess politique complète et joindre celle-ci à la place.

JSON

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*",
                "organizations:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Deny", 
            "Action":"organizations:LeaveOrganization",
            "Resource": "*" 
        }
    ]
}

Pour démontrer comment plusieurs politiques de contrôle des services (SCPs) 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 appliquées aux niveaux supérieurs de l'organisation ont un impact sur tous les comptes ci-dessous. Lorsque l'unité d'organisation Sandbox possède à la fois des politiques d' «  AWS  accès complet » et de « refus d'accès à S3 », et que le compte B possède une politique de « refus d' EC2 accès », le compte B ne peut pas accéder à S3 (depuis le refus au niveau de l'unité d'organisation) et EC2 (depuis son refus au niveau du compte). Le compte A ne dispose pas d'un accès S3 (depuis le refus au niveau de l'unité d'organisation).

Scénario 2 : les politiques d'autorisation doivent exister à tous les niveaux

Ce scénario montre comment fonctionnent les politiques d'autorisation SCPs. Pour qu'un service soit accessible, il doit y avoir une autorisation explicite à tous les niveaux, depuis le root jusqu'au compte. Dans ce cas, étant donné que l'unité d'organisation Sandbox applique une politique « Autoriser l' EC2 accès », qui n'autorise explicitement que l'accès au EC2 service, seuls les comptes A et B y auront EC2 accès.

Scénario 3 : impact de l'absence d'une instruction Allow au niveau de la racine

L'absence d'une instruction « Autoriser » au niveau de la racine dans un SCP constitue une erreur de configuration critique qui bloquera efficacement tout accès aux AWS services et aux actions pour tous les comptes membres de votre organisation.

Scénario 4 : déclarations de refus en couches et autorisations qui en résultent

Ce scénario illustre une structure d'UO profonde à deux niveaux. L'unité d'organisation racine et l'unité d'organisation de travail disposent toutes deux d'un «  AWS  accès complet », l'unité d'organisation de test dispose d'un «  AWS  accès complet » avec « Refuser l' EC2 accès » et l'unité d'organisation de production d'un «  AWS  accès complet ». Par conséquent, le compte D a accès à tous les services, à l'exception EC2 des comptes E et F qui ont tous les accès aux services.

Scénario 5 : autoriser les politiques au niveau de l'unité d'organisation à restreindre l'accès aux services

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 d' « autorisation d' EC2 accès », ce qui signifie que seuls les EC2 services sont autorisés pour le compte D. L'unité d'organisation de production maintient 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 au niveau de l'unité d'organisation tout en maintenant une autorisation plus large au niveau racine.

Scénario 6 : le refus au niveau racine affecte tous les comptes, quelles que soient les autorisations de niveau 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 au S3 », le refus du S3 au niveau racine a la priorité. 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 de la racine.