SCPévaluation

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'activezSCPs, AWS Organizations il associe une SCP politique AWS gérée nommée F ullAWSAccess 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 ou un service soit autorisé sur le compte B, une SCP autorisation ou un service doit être associé à Root, à l'unité d'organisation de production et au compte B lui-même.

SCPl'évaluation suit un deny-by-default modèle, ce qui signifie que toutes les autorisations non explicitement autorisées dans le 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 Allow instruction dans un SCP permet à l'Resourceélément de n'avoir qu'une "*" entrée.

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

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

Lorsqu'une autorisation est refusée pour un compte spécifique, toute personne SCP depuis la racine jusqu'à chaque unité d'organisation située sur le chemin direct vers le compte (y compris le compte cible lui-même) peut refuser cette autorisation.

Supposons, par exemple, qu'une Deny instruction explicite soit spécifiée pour un service donné dans une SCP pièce jointe à l'unité d'organisation de production. Il se trouve également qu'il y en a un autre SCP attaché à Root et au compte B qui 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 IAMpour les mettre à jour SCPs afin de restreindre l'accès aux seules données Services AWS dont vous avez besoin. Pour plus d'informations, consultez la section Visualisation des dernières données consultées par le service Organizations pour les organisations dans le guide de IAM l'utilisateur.

AWS Organizations attache un AWS gestionnaire SCP nommé F ullAWSAccess à chaque racine, unité d'organisation et compte lors de sa création. Cette politique autorise tous les services et actions. Vous pouvez ullAWSAccess remplacer F 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 à jourSCPs. 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 ullAWSAccess politique F 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 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	SCPchez Root	SCPchez Sandbox OU	SCPau 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 et 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	SCPchez Root	SCPchez Workloads OU	SCPchez Test OU	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 et 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 au service