Évaluation du SCP

Note

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. Pour de plus amples informations, veuillez consulter Fonctionnement de l'héritage des politiques de gestion.

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 des SCP, AWS Organizations attache une politique SCP AWS gérée nommée FullAWSAccess qui autorise tous les services et toutes les 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 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é.

Remarques

• Une instruction Allow dans un SCP permet à l’élément Resource de ne posséder qu’une entrée "*".

• Une instruction Allow dans une SCP ne peut pas avoir d'élément Condition du tout.

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

Astuce

Vous pouvez utiliser les dernières informations consultées relatives aux services dans IAM pour mettre à jour vos politiques SCP afin d'en limiter l'accès uniquement aux 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 une SCP gérée par AWS nommée FullAWSAccess à chaque racine, UO et compte lors de sa création. Cette politique autorise tous les services et actions. Vous pouvez remplacer FullAWSAccess par une politique n'autorisant qu'un ensemble défini de services, de sorte que les nouveaux services AWS ne soient pas autorisés à moins d'être explicitement autorisés par une 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 politique FullAWSAccess et attacher 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.

Scénario	SCP attachée à la racine	SCP attachée à l'UO d'environnement de test	SCP attachée au compte A	Politique correspondante attachée au compte A	Politique correspondante attachée au compte B et au compte C
1	Accès complet à AWS	Accès complet à AWS + accès à S3 refusé	Accès complet à AWS + accès à EC2 refusé	Aucun accès à S3 ni EC2	Aucun accès à S3
2	Accès complet à AWS	Accès à Amazon Elastic Compute Cloud (Amazon EC2) autorisé	Accès à EC2 autorisé	Accès autorisé pour EC2 uniquement	Accès autorisé pour EC2 uniquement
3	Accès à S3 refusé	Accès à S3 autorisé	Accès complet à AWS	Aucun accès au service	Aucun accès au service

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

Scénario	SCP attachée à la racine	SCP attachée à l'UO de charge de travail	SCP attachée à l'UO de test	Politique correspondante attachée au compte D	Politiques correspondantes attachées à l'UO de production, au compte E et au compte F
1	Accès complet à AWS	Accès complet à AWS	Accès complet à AWS + accès à EC2 refusé	Aucun accès à EC2	Accès complet à AWS
2	Accès complet à AWS	Accès complet à AWS	Accès à EC2 autorisé	Accès à EC2 autorisé	Accès complet à AWS
3	Accès à S3 refusé	Accès complet à AWS	Accès à S3 autorisé	Aucun accès au service	Aucun accès au service