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

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.

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, vous AWS Organizations associez 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 n'est remplacée à aucun niveau de l'organisation, aucune action ne sera possible pour les UO ou les comptes sous-jacents.

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 suit un deny-by-default modèle, ce qui signifie que 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 définissez des SCP, vous pouvez utiliser une combinaison d'instructions Allow et Deny pour autoriser certaines actions et certains services dans votre organisation. Les instructions Deny constituent un moyen efficace de mettre en œuvre des restrictions qui s'appliquent à une plus grande partie de votre organisation ou de vos UO, car lorsqu'elles sont appliquées à la racine ou au niveau de l'UO, elles affectent tous les comptes sous-jacents.

Par exemple, vous pouvez mettre en œuvre une politique utilisant Deny des instructions Empêcher les comptes membres de quitter l'organisation à 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 AWS services ne sont pas autorisés, sauf s'ils sont explicitement autorisés par la mise à jour des SCP. 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.

{
"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.

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

Examinons à présent l'exemple de structure organisationnelle suivant pour comprendre comment vous pouvez appliquer plusieurs SCP à différents niveaux d'une organisation.

Le tableau suivant présente les politiques effectives dans l'UO d'environnement de test.

Le tableau suivant présente les politiques effectives dans l'UO de charge de travail.