Stratégies d'utilisation des stratégies de contrôle de service

Vous pouvez configurer les stratégies de contrôle des services (SCP) dans votre organisation pour qu'elles fonctionnent comme l'un des éléments suivants :

• AListe des refus— Les actions sont autorisées par défaut et vous spécifiez les services et actions interdits.

• UnListe des autorisations— Les actions sont interdites par défaut et vous spécifiez les services et actions autorisés.

Astuce

Vous pouvez utiliserdernières données de service consultéesinIAMPour mettre à jour vos stratégies de contrôle de service afin d'en limiter l'accès uniquement auxAWSservices dont vous avez besoin. Pour de plus amples informations, veuillez consulterAffichage Organizations données relatives aux derniers services consultés pour les organisationsdans leGuide de l'utilisateur IAM

Utilisation des stratégies de contrôle de service en tant que liste de refus

La configuration par défaut de AWS Organizations prend en charge l'utilisation des stratégies de contrôle de service en tant que listes de refus. Grâce à une stratégie de liste de refus, les administrateurs de compte peuvent déléguer tous les services et actions jusqu'à la création ou l'attachement d'une stratégie qui refuse un service spécifique ou un ensemble d'actions. Les instructions de refus demandent moins de maintenance, car vous n'avez pas besoin de les mettre à jour lorsqu'AWS ajoute de nouveaux services. Les instructions de refus utilisent généralement moins d'espace, ce qui permet de respecter plus facilement les tailles maximales pour les stratégies de contrôle de service. Dans une instruction dans laquelle l'élément Effect a une valeur de Deny, vous pouvez également limiter l'accès à des ressources spécifiques ou définir des conditions pour le moment où les stratégies de contrôle de service sont en vigueur.

Pour prendre en charge cela, AWS Organizations attache une stratégie de contrôle de service gérée par AWS et appelée FullWASAccess à chaque racine et unité d'organisation lors de sa création. Cette stratégie autorise tous les services et actions. Vous pouvez toujours l'attacher ou la détacher des entités de votre organisation si nécessaire. La stratégie étant une stratégie de contrôle de service AWS gérée, vous ne pouvez pas la modifier ou la supprimer. Une stratégie ressemble à ce qui suit :

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

Cette stratégie permet aux administrateurs de compte de déléguer des autorisations pour n'importe quel service ou opération jusqu'à ce que vous créiez et attachiez une stratégie SCP qui refuse un accès. Vous pouvez attacher une stratégie de contrôle de service qui interdit explicitement les actions que vous ne voulez pas que les utilisateurs et rôles de certains comptes effectuent.

Cette politique peut ressembler à l'exemple suivant, ce qui empêche les utilisateurs des comptes concernés d'exécuter les actions pour le service Amazon DynamoDB. L'administrateur de l'organisation peut détacher la stratégie FullAWSAccess et attacher celle-ci à la place. Cette stratégie de contrôle de service autorise toujours tous les autres services et leurs actions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowsAllActions",
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        },
        {
            "Sid": "DenyDynamoDB", 
            "Effect": "Deny",
            "Action": "dynamodb:*",
            "Resource": "*"
        }
    ]
}

Les utilisateurs des comptes concernés ne peuvent pas exécuter d'actions DynamoDB, car la stratégie expliciteDenydans la deuxième instruction remplace l'élément expliciteAllowDans la première. Vous pouvez également configurer cela en conservant la stratégie FullAWSAccess et en attachant une deuxième stratégie qui ne possède que l'instruction Deny, comme illustré ci-dessous :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "dynamodb:*",
            "Resource": "*"
        }
    ]
}

La combinaison de laFullAWSAccesset la stratégieDenyDans la stratégie DynamoDB précédente, appliquée à une racine ou à une unité d'organisation, a le même effet que la stratégie individuelle qui contient les deux instructions. Toutes les stratégies qui s'appliquent à un niveau spécifié sont combinées. Chaque déclaration, quelle que soit la stratégie à l'origine, est évaluée conformément aux règles décrites précédemment (c'est-à-dire un élément de contrôle de service est évalué conformément aux règles décrites précédemment (c'est-à-direexplicite DenyRemplacements sur uneexpliciteAllow, qui remplace la valeur par défautimpliciteDeny).

Utilisation des stratégies de contrôle de service en tant que liste d’autorisations

Pour utiliser des stratégies SCP en tant que liste d’autorisations, vous devez remplacer la stratégie SCP FullAWSAccess gérée par AWS par une stratégie SCP qui n'autorise explicitement que les services et actions que vous souhaitez autoriser. En supprimant la stratégie de contrôle de service FullAWSAccess par défaut, toutes les actions de tous les services sont désormais implicitement refusées. Votre stratégie de contrôle de service personnalisée remplace l'élément Deny implicite par un élément Allow explicite uniquement pour les actions que vous souhaitez autoriser. Pour qu'une autorisation soit activée pour un compte spécifique, chaque stratégie de contrôle de service depuis la racine via chaque unité d'organisation sur le chemin d'accès direct vers le compte, et même attachée au compte lui-même, doit autoriser cette autorisation.

Notes

• UnAllowdans un SCP ne peut pas avoir unResourceélément avec n'importe quoi, sauf un"*".

• UnAllowdans un SCP ne peut pas avoir unConditionélément du tout.

Une stratégie de liste d'autorisations peut ressembler à l'exemple suivant, qui permet aux utilisateurs de compte d'exécuter une opération pour Amazon Elastic Compute Cloud (Amazon EC2) et Amazon CloudWatch, mais aucun autre service. Toutes les stratégies de contrôle de service dans les unités d'organisation parents ou la racine doivent également autoriser explicitement ces autorisations.

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