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
**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 relatives aux applications de chat ou les politiques de désactivation des services d'intelligence artificielle. Pour de plus amples informations, veuillez consulter [Fonctionnement de l'héritage des politiques de gestion](orgs_manage_policies_inheritance_mgmt.md).
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.
**Topics**
+ [Comment SCPs travailler avec Allow](#how_scps_allow)
+ [Comment SCPs travailler avec Deny](#how_scps_deny)
+ [Stratégie d'utilisation SCPs](#strategy_using_scps)
## 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](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess) 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 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
*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. `Deny`les déclarations 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 qui en dépendent.
**Astuce**
Vous pouvez utiliser les [données du dernier accès au service](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) dans [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html) dans le *Guide de l'utilisateur IAM.*
AWS Organizations attache un SCP AWS géré nommé [https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess) à 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. Vous pouvez choisir de remplacer **Full AWSAccess** à la racine ou à tous les niveaux. Si vous associez une liste d'autorisations (SCP) spécifique à un service à la racine, elle s'applique automatiquement à tous les comptes OUs et aux comptes situés en dessous, ce qui signifie qu'une seule politique au niveau de la racine détermine la liste d'autorisations de service effective dans l'ensemble de l'organisation, comme indiqué dans le scénario 7. Vous pouvez également supprimer et remplacer **Full AWSAccess** au niveau de chaque unité organisationnelle et de chaque compte, ce qui vous permet de mettre en œuvre des listes d'autorisation de service plus détaillées qui diffèrent selon les unités organisationnelles ou les comptes individuels.
Remarque : Le fait de s'appuyer uniquement sur les instructions d'autorisation et le deny-by-default modèle implicite peut entraîner un accès involontaire, car les instructions Allow plus larges ou qui se chevauchent peuvent remplacer les instructions plus restrictives.
------
#### [ JSON ]
****
```
{
"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.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"cloudwatch:*",
"organizations:*"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action":"organizations:LeaveOrganization",
"Resource": "*"
}
]
}
```
------
Pour démontrer comment plusieurs politiques de contrôle des services (SCPs) peuvent être appliquées dans une AWS organisation, considérez la structure organisationnelle et les scénarios suivants.
### Scénario 1 : Impact des politiques de refus
Ce scénario montre comment les politiques de refus appliquées aux niveaux supérieurs de l'organisation ont un impact sur tous les comptes ci-dessous. Lorsque l'unité d'organisation Sandbox possède à la fois des politiques « AWS accès complet » et « Refuser l'accès S3 », et que le compte B applique une politique « Refuser l'accès EC2 », le compte B ne peut pas accéder à S3 (depuis le refus au niveau de l'unité d'organisation) et à EC2 (depuis son refus au niveau du compte). Le compte A ne dispose pas d'un accès S3 (depuis le refus au niveau de l'unité d'organisation).
### Scénario 2 : les politiques d'autorisation doivent exister à tous les niveaux
Ce scénario montre comment les politiques d'autorisation fonctionnent dans les SCP. Pour qu'un service soit accessible, il doit y avoir une autorisation explicite à tous les niveaux, depuis le root jusqu'au compte. Dans ce cas, étant donné que l'unité d'organisation Sandbox applique une politique « Autoriser l'accès EC2 », qui n'autorise explicitement que l'accès au service EC2, les comptes A et B auront uniquement accès à EC2.
### Scénario 3 : impact de l'absence d'une instruction Allow au niveau de la racine
L'absence d'une instruction « Autoriser » au niveau de la racine dans un SCP constitue une erreur de configuration critique qui bloquera efficacement tout accès aux AWS services et aux actions pour tous les comptes membres de votre organisation.
### Scénario 4 : déclarations de refus en couches et autorisations qui en résultent
Ce scénario illustre une structure d'UO profonde à deux niveaux. L'unité d'organisation racine et l'unité d'organisation de charges de travail ont toutes deux un « AWS accès complet », l'unité d'organisation de test dispose d'un « AWS accès complet » avec « Refuser l'accès EC2 » et l'unité d'organisation de production dispose d'un « AWS accès complet ». Par conséquent, le compte D dispose de tous les accès aux services, à l'exception de l'EC2, et les comptes E et F ont tous les accès aux services.
### Scénario 5 : autoriser les politiques au niveau de l'unité d'organisation à restreindre l'accès aux services
Ce scénario montre comment les politiques d'autorisation peuvent être utilisées pour restreindre l'accès à des services spécifiques. L'UO de test applique une politique « Autoriser l'accès EC2 », ce qui signifie que seuls les services EC2 sont autorisés pour le compte D. L'UO de production maintient un « AWS accès complet », de sorte que les comptes E et F ont accès à tous les services. Cela montre comment des politiques d'autorisation plus restrictives peuvent être mises en œuvre au niveau de l'unité d'organisation tout en maintenant une autorisation plus large au niveau racine.
### Scénario 6 : le refus au niveau root affecte tous les comptes, quelles que soient les autorisations de niveau inférieur
Ce scénario montre qu'une politique de refus au niveau racine affecte tous les comptes de l'organisation, quelles que soient les politiques d'autorisation aux niveaux inférieurs. La racine applique à la fois des politiques « AWS Accès complet » et « Refuser l'accès S3 ». Même si l'unité d'organisation de test applique une politique « Autoriser l'accès au S3 », le refus du S3 au niveau racine a la priorité. Le compte D n'a aucun accès au service car l'unité d'organisation de test autorise uniquement l'accès à S3, mais S3 est refusé au niveau racine. Les comptes E et F peuvent accéder à d'autres services à l'exception de S3 en raison du refus explicite au niveau de la racine.
### Scénario 7 : politiques d'autorisation personnalisées au niveau de la racine pour restreindre l'accès au niveau de l'unité d'organisation
Ce scénario montre comment, SCPs avec un service explicite, les listes d'autorisations fonctionnent lorsqu'elles sont appliquées au niveau de la racine dans un AWS Organizations. Au niveau de la racine de l'organisation, deux « Autorisations de service » personnalisées SCPs sont associées qui autorisent explicitement l'accès à un ensemble limité de AWS services : SCP\_1 autorise IAM et Amazon EC2, SCP\_2 autorise Amazon S3 et Amazon. CloudWatch Au niveau de l'unité organisationnelle (UO), la AWSAccess politique complète par défaut reste attachée. Cependant, en raison du comportement des intersections, les comptes A et B de ces UO ne peuvent accéder qu'aux services explicitement autorisés par le SCP de niveau racine. La politique racine la plus restrictive a la priorité, limitant efficacement l'accès aux seuls IAM, EC2, S3 et CloudWatch aux services, indépendamment des autorisations plus larges accordées aux niveaux organisationnels inférieurs.
