Évaluation du SCP

Note

Les informations contenues dans cette section ne s'appliquent pas aux types de politiques de gestion, y compris les politiques de sauvegarde, les politiques de balises, les politiques de chatbot ou les politiques de désinscription des services d'intelligence artificielle. Pour de plus amples informations, veuillez consulter Fonctionnement de l'héritage des politiques de gestion.

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

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

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 instructions 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 concernés.

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.

Astuce

Vous pouvez utiliser les données du dernier accès au service dans IAM pour les mettre à jour SCPs afin de restreindre 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é 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.

{
"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 maintenant l'exemple de structure d'organisation suivant pour comprendre comment vous pouvez en appliquer plusieurs SCPs à différents niveaux au sein 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	AWS Accès complet	AWS Accès complet + refus de l'accès S3	AWS Accès complet + refus EC2 d'accès	Pas de S3, pas EC2 d'accès	Aucun accès à S3
2	AWS Accès complet	Autoriser EC2 l'accès	Autoriser EC2 l'accès	Autoriser EC2 l'accès	Autoriser EC2 l'accès
3	Accès à S3 refusé	Accès à S3 autorisé	AWS Accès complet	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	AWS Accès complet	AWS Accès complet	AWS Accès complet + refus EC2 d'accès	Pas EC2 d'accès	AWS Accès complet
2	AWS Accès complet	AWS Accès complet	Autoriser EC2 l'accès	Autoriser EC2 l'accès	AWS Accès complet
3	Accès à S3 refusé	AWS Accès complet	Accès à S3 autorisé	Aucun accès au service	Aucun accès à S3