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.
# Politiques de contrôle des services (SCPs)
Les politiques de contrôle des services (SCPs) sont un type de politique d'organisation que vous pouvez utiliser pour gérer les autorisations au sein de votre organisation. SCPs offrent un contrôle centralisé des autorisations maximales disponibles pour les utilisateurs IAM et les rôles IAM au sein de votre organisation. SCPs vous aider à garantir que vos comptes respectent les directives de contrôle d'accès de votre organisation. SCPsne sont disponibles que dans une organisation dont [toutes les fonctionnalités sont activées](orgs_manage_org_support-all-features.md). SCPs ne sont pas disponibles si votre organisation a activé uniquement les fonctionnalités de facturation consolidée. Pour obtenir des instructions sur l'activation SCPs, consultez[Désactivation d'un type de politique](enable-policy-type.md).
SCPs n'accordez pas d'autorisations aux utilisateurs IAM et aux rôles IAM au sein de votre organisation. Aucune autorisation n'est accordée par une SCP. Un SCP définit une barrière d'autorisation, ou fixe des limites, aux actions que les utilisateurs IAM et les rôles IAM de votre organisation peuvent effectuer. Pour accorder des autorisations, l'administrateur doit associer des politiques pour contrôler l'accès, telles que des politiques basées sur l'identité associées aux utilisateurs IAM et aux rôles IAM, et des politiques basées sur les ressources associées aux ressources de vos comptes. *Pour plus d'informations, consultez les sections Politiques basées sur l'[identité et politiques basées sur les ressources dans le Guide de l'](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)utilisateur IAM.*
Les [autorisations effectives](#scp-effects-on-permissions) sont l'intersection logique entre ce qui est autorisé par le SCP et les [politiques de contrôle des ressources (RCPs)](orgs_manage_policies_rcps.md) et ce qui est autorisé par les politiques basées sur l'identité et les ressources.
**SCPs n'affectent pas les utilisateurs ou les rôles dans le compte de gestion**
SCPs n'affectent pas les utilisateurs ni les rôles dans le compte de gestion. Elles affectent uniquement les comptes membres de votre organisation. Cela signifie également que cela SCPs s'applique aux comptes de membres désignés comme administrateurs délégués.
****Rubriques dans cette page****
+ [Tester les effets de SCPs](#scp-warning-testing-effect)
+ [Taille maximale de SCPs](#scp-size-limit)
+ [SCPs Attachement aux différents niveaux de l'organisation](#scp-about-inheritance)
+ [Effets des SCP sur les autorisations](#scp-effects-on-permissions)
+ [Utiliser les données d'accès pour améliorer SCPs](#data-from-iam)
+ [Tâches et entités non limitées par SCPs](#not-restricted-by-scp)
+ [Évaluation du SCP](orgs_manage_policies_scps_evaluation.md)
+ [Syntaxe d’une stratégie de contrôle de service](orgs_manage_policies_scps_syntax.md)
+ [Exemples de politiques de contrôle des services](orgs_manage_policies_scps_examples.md)
+ [Résolution des problèmes liés aux politiques de contrôle des services (SCPs) avec AWS Organizations](org_troubleshoot_policies.md)
## Tester les effets de SCPs
AWS vous recommande vivement de ne pas vous attacher SCPs à la racine de votre organisation sans avoir testé de manière approfondie l'impact de la politique sur les comptes. À la place, créez une unité d'organisation dans laquelle vous pouvez déplacer vos comptes un par un, ou au moins en petits nombres, afin de veiller à ne pas accidentellement empêcher des utilisateurs d'accéder à des services clés. Pour déterminer si un service est utilisé par un compte, vous pouvez examiner les [Dernières informations consultées relatives aux services dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html). Une autre méthode consiste [AWS CloudTrail à enregistrer l'utilisation du service au niveau de l'API](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html).
**Note**
Vous ne devez pas supprimer la AWSAccess politique **complète** à moins de la modifier ou de la remplacer par une politique distincte avec des actions autorisées, sinon toutes les AWS actions des comptes membres échoueront.
## Taille maximale de SCPs
Tous les caractères de votre SCP sont pris en compte dans le calcul de sa [taille maximale](orgs_reference_limits.md#min-max-values). Les exemples de ce guide montrent les SCPs formats avec des espaces blancs supplémentaires pour améliorer leur lisibilité. Toutefois, pour économiser de l'espace si la taille de votre politique approche de la taille maximale, vous pouvez supprimer les espaces, comme les espacements et les sauts de ligne qui ne figurent pas entre guillemets.
**Astuce**
Utilisez l'éditeur visuel pour créer votre politique de contrôle des services. Il supprime automatiquement les espaces superflus.
## SCPs Attachement aux différents niveaux de l'organisation
Pour une explication détaillée du SCPs fonctionnement, voir[Évaluation du SCP](orgs_manage_policies_scps_evaluation.md).
## Effets des SCP sur les autorisations
SCPs sont similaires aux politiques Gestion des identités et des accès AWS d'autorisation et utilisent presque la même syntaxe. Toutefois, une politique de contrôle des services n'accorde jamais d'autorisations. SCPs Il s'agit plutôt de contrôles d'accès qui spécifient les autorisations maximales disponibles pour les utilisateurs IAM et les rôles IAM au sein de votre organisation. Pour de plus amples informations, consultez [Logique d'évaluation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) dans le *Guide de l'utilisateur IAM*.
+ SCPs ***concernent uniquement les utilisateurs et les rôles IAM*** gérés par des comptes faisant partie de l'organisation. SCPs n'affectent pas directement les politiques basées sur les ressources. Elles n'affectent pas les utilisateurs ni les rôles de comptes extérieurs à l'organisation. Par exemple, considérons un compartiment Amazon S3 détenu par le compte A d'une organisation. La politique du compartiment (politique basée sur une ressource) accorde l'accès aux utilisateurs du compte B qui est extérieur à l'organisation. Une politique SCP est attachée au compte A. Cette politique de contrôle des services ne s'applique pas aux utilisateurs externes du compte B. La politique de contrôle des services s'applique uniquement aux utilisateurs gérés par le compte A dans l'organisation.
+ Une SCP limite les autorisations des utilisateurs et des rôles IAM dans les comptes membres, y compris l'utilisateur racine du compte membre. Chaque compte ne dispose que des autorisations octroyées par ***chaque*** parent au-dessus de lui. Si une autorisation est bloquée à n'importe quel niveau au-dessus du compte, implicitement (en n'étant pas incluse dans une instruction de politique `Allow`) ou explicitement (en étant incluse dans une instruction de politique `Deny`), un utilisateur ou un rôle figurant dans le compte concerné ne peut pas utiliser cette autorisation, même si l'administrateur du compte attache à l'utilisateur la politique IAM `AdministratorAccess` avec des autorisations \$1/\$1.
+ SCPs concernent uniquement ***les comptes des membres*** de l'organisation. Elles n'ont aucun effet sur les utilisateurs ou les rôles du compte de gestion. Cela signifie également que cela SCPs s'applique aux comptes de membres désignés comme administrateurs délégués. Pour de plus amples informations, veuillez consulter [Bonnes pratiques relatives au compte de gestion](orgs_best-practices_mgmt-acct.md).
+ Les utilisateurs et les rôles doivent toujours se voir attribuer des autorisations avec les politiques d'autorisation IAM appropriées. Un utilisateur ne disposant d'aucune politique d'autorisation IAM n'a aucun accès, même si les règles applicables SCPs autorisent tous les services et toutes les actions.
+ Si un utilisateur ou un rôle dispose d'une politique d'autorisation IAM qui accorde l'accès à une action également autorisée par l'autorité applicable SCPs, l'utilisateur ou le rôle peut effectuer cette action.
+ Si un utilisateur ou un rôle dispose d'une politique d'autorisation IAM qui accorde l'accès à une action non autorisée ou explicitement refusée par l'autorité applicable SCPs, l'utilisateur ou le rôle ne peut pas effectuer cette action.
+ SCPs affectent tous les utilisateurs et rôles des comptes attachés, ***y compris l'utilisateur root***. Les seules exceptions sont celles décrites dans [Tâches et entités non limitées par SCPs](#not-restricted-by-scp).
+ SCPs ***n'***affectent aucun rôle lié à un service. Les rôles liés aux services permettent Services AWS aux autres de s'intégrer AWS Organizations et ne peuvent pas être limités par. SCPs
+ Lorsque vous désactivez le type de politique SCP dans une racine, toutes SCPs sont automatiquement détachées de toutes les AWS Organizations entités de cette racine. AWS Organizations les entités incluent les unités organisationnelles, les organisations et les comptes. Si vous le réactivez SCPs dans une racine, cette racine revient uniquement à la `FullAWSAccess` politique par défaut automatiquement attachée à toutes les entités de la racine. Toutes les pièces jointes d' AWS Organizations entités antérieures SCPs à la désactivation SCPs sont perdues et ne sont pas automatiquement récupérables, bien que vous puissiez les rattacher manuellement.
+ Si une limite d'autorisations (une fonctionnalité IAM avancée) et une politique de contrôle des services sont présentes, la limite, la politique de contrôle des services et la politique basée sur l'identité doivent toutes autoriser l'action.
## Utiliser les données d'accès pour améliorer SCPs
Lorsque vous êtes connecté avec les informations d'identification du compte de gestion, vous pouvez consulter les [données du dernier accès au service](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) pour une AWS Organizations entité ou une politique dans la **AWS Organizations**section de la console IAM. Vous pouvez également utiliser le AWS Command Line Interface (AWS CLI) ou l' AWS API dans IAM pour récupérer les dernières données du service auxquelles vous avez accédé. Ces données incluent des informations sur les services autorisés auxquels les utilisateurs et les rôles IAM d'un AWS Organizations compte ont tenté d'accéder pour la dernière fois et à quel moment. Vous pouvez utiliser ces informations pour identifier les autorisations non utilisées afin d'affiner les SCPs vôtres afin de mieux respecter le principe du [moindre privilège](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege).
Par exemple, vous pouvez avoir une [liste de refus SCP](orgs_manage_policies_scps_evaluation.md#how_scps_deny) qui interdit l'accès à trois Services AWS d'entre eux. Tous les services qui ne sont pas répertoriés dans l’instruction `Deny` de la SCP sont autorisés. Les données du dernier accès au service dans IAM vous indiquent celles qui Services AWS sont autorisées par le SCP mais qui ne sont jamais utilisées. Ces informations vous permettent de mettre à jour la SCP pour refuser l'accès aux services dont vous n'avez pas besoin.
Pour plus d'informations, consultez les rubriques suivantes dans le *Guide de l'utilisateur IAM* :
+ [Affichage des dernières informations relatives aux services pour Organizations](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html)
+ [ Using Data to Refine Permissions for an Organizational Unit (Utilisation des données pour affiner les autorisations d’une unité d’organisation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-example-scenarios.html#access_policies_access-advisor-reduce-permissions-orgs)
## Tâches et entités non limitées par SCPs
Vous ***ne pouvez pas*** utiliser SCPs pour restreindre les tâches suivantes :
+ Toute action effectuée par le compte de gestion
+ Toute action réalisée à l'aide des autorisations attachées à un rôle lié à un service.
+ Enregistrement pour le plan Enterprise Support en tant qu'utilisateur racine
+ Fournir des fonctionnalités de signature fiables pour le contenu CloudFront privé
+ Configuration de DNS inverse pour un serveur de messagerie Amazon Lightsail et une instance Amazon EC2 en tant qu'utilisateur racine
+ Tâches AWS relatives à certains services connexes :
+ Alexa Top Sites
+ Alexa Web Information Service
+ Amazon Mechanical Turk
+ API Amazon Product Marketing
# É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
![\[Exemple de structure organisationnelle avec une instruction Allow attachée à la racine, à l'unité d'organisation de production et au compte B\]](http://docs.aws.amazon.com/fr_fr/organizations/latest/userguide/images/scp_allow_1.png)
*Figure 1 : exemple de structure organisationnelle avec une instruction `Allow` attachée à la racine, à l'UO de production et au compte B*
![\[Exemple de structure organisationnelle avec une instruction Allow manquante à l'unité de production et son impact sur le compte B\]](http://docs.aws.amazon.com/fr_fr/organizations/latest/userguide/images/scp_allow_2.png)
*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.
![\[Exemple de structure organisationnelle avec une déclaration de refus jointe à l'unité de production et son impact sur le compte B\]](http://docs.aws.amazon.com/fr_fr/organizations/latest/userguide/images/scp_deny_1.png)
*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 1 : Impact des politiques de refus\]](http://docs.aws.amazon.com/fr_fr/organizations/latest/userguide/images/scp_scenario_1.png)
### 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 2 : les politiques d'autorisation doivent exister à tous les niveaux\]](http://docs.aws.amazon.com/fr_fr/organizations/latest/userguide/images/scp_scenario_2.png)
### 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 3 : impact de l'absence d'une instruction Allow au niveau de la racine\]](http://docs.aws.amazon.com/fr_fr/organizations/latest/userguide/images/scp_scenario_3.png)
### 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 4 : déclarations de refus en couches et autorisations qui en résultent\]](http://docs.aws.amazon.com/fr_fr/organizations/latest/userguide/images/scp_scenario_4.png)
### 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 5 : autoriser les politiques au niveau de l'unité d'organisation à restreindre l'accès aux services\]](http://docs.aws.amazon.com/fr_fr/organizations/latest/userguide/images/scp_scenario_5.png)
### 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 6 : le refus au niveau root affecte tous les comptes, quelles que soient les autorisations de niveau inférieur\]](http://docs.aws.amazon.com/fr_fr/organizations/latest/userguide/images/scp_scenario_6.png)
### 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\$11 autorise IAM et Amazon EC2, SCP\$12 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.
![\[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\]](http://docs.aws.amazon.com/fr_fr/organizations/latest/userguide/images/scp_scenario_7.png)
# Syntaxe d’une stratégie de contrôle de service
Les politiques de contrôle des services (SCPs) utilisent une syntaxe similaire à celle utilisée par les politiques d'autorisation Gestion des identités et des accès AWS (IAM) et les politiques [basées sur les ressources (comme les politiques relatives](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based) aux compartiments Amazon S3). Pour plus d'informations sur les politiques IAM et leur syntaxe, consultez [Présentation des politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l'utilisateur IAM*.
Une politique SCP est un fichier texte brut qui est structuré conformément aux règles de [JSON](http://json.org). Elle utilise les éléments qui sont décrits dans cette rubrique.
**Note**
Tous les caractères de votre SCP sont pris en compte dans le calcul de sa [taille maximale](orgs_reference_limits.md#min-max-values). Les exemples présentés dans ce guide montrent les SCPs fichiers formatés avec des espaces blancs supplémentaires pour améliorer leur lisibilité. Toutefois, pour économiser de l'espace si la taille de votre politique approche de la taille maximale, vous pouvez supprimer les espaces, comme les espacements et les sauts de ligne qui ne figurent pas entre guillemets.
Pour des informations générales sur SCPs, voir[Politiques de contrôle des services (SCPs)](orgs_manage_policies_scps.md).
## Récapitulatif des éléments
Le tableau suivant récapitule les éléments de stratégie que vous pouvez utiliser dans SCPs. Certains éléments de politique ne sont disponibles SCPs que dans les cas où les actions sont interdites. La colonne **Effets pris en charge** répertorie le type d'effet que vous pouvez utiliser avec chaque élément de politique SCPs.
| Element | Objectif | Effets pris en charge |
| --- | --- | --- |
| [Action](#scp-syntax-action) | Spécifie le AWS service et les actions que le SCP autorise ou refuse. | `Allow`, `Deny` |
| [Effet](#scp-syntax-effect) | Définit si l'instruction SCP [autorise](orgs_manage_policies_scps_evaluation.md#how_scps_allow) ou [refuse](orgs_manage_policies_scps_evaluation.md#how_scps_deny) l'accès aux utilisateurs et rôles IAM d'un compte. | `Allow`, `Deny` |
| [Instruction](#scp-syntax-statement) | Sert de conteneur pour les éléments de politique. Vous pouvez avoir plusieurs instructions dans SCPs. | `Allow`, `Deny` |
| [ID d’instruction (Sid)](#scp-syntax-sid) | (Facultatif) Fournit un nom simple pour l'instruction. | `Allow`, `Deny` |
| [Version](#scp-syntax-version) | Spécifie les règles de syntaxe du langage à utiliser pour le traitement de la politique. | `Allow`, `Deny` |
| [Condition](#scp-syntax-condition) | Spécifie les conditions lorsque l’instruction est vigueur. | `Allow,``Deny` |
| [NotAction](#scp-syntax-action) | Spécifie le AWS service et les actions exemptés du SCP. Utilisé au lieu de l'élément `Action`. | `Allow,``Deny` |
| [Ressource](#scp-syntax-resource) | Spécifie les AWS ressources auxquelles le SCP s'applique. | `Allow,``Deny` |
| [NotResource](#scp-syntax-resource) | Spécifie les AWS ressources exemptées du SCP. Utilisé au lieu de l'élément Resource. | `Allow`, `Deny` |
Les sections suivantes fournissent des informations supplémentaires et des exemples de la manière dont les éléments de politique sont utilisés dans SCPs.
**Topics**
+ [Récapitulatif des éléments](#scp-elements-table)
+ [Éléments `Action` et `NotAction`](#scp-syntax-action)
+ [Élément `Condition`](#scp-syntax-condition)
+ [Élément `Effect`](#scp-syntax-effect)
+ [`Resource`et `NotResource` élément](#scp-syntax-resource)
+ [Élément `Statement`](#scp-syntax-statement)
+ [Élément ID d'instruction (`Sid`)](#scp-syntax-sid)
+ [Élément `Version`](#scp-syntax-version)
+ [Élément non pris en charge](#scp-syntax-unsupported)
## Éléments `Action` et `NotAction`
La valeur de l'`NotAction`élément `Action` or est une liste (un tableau JSON) de chaînes identifiant les AWS services et les actions autorisés ou refusés par l'instruction.
Chaque chaîne est constituée de l'abréviation du service (par exemple, « s3 », « ec2 », « iam » ou « organizations »), en minuscules, suivie de deux points, puis d'une action de ce service. Les actions et les notactions ne font pas la distinction majuscules/majuscules. En général, ils sont tous saisis avec chaque mot commençant par une lettre majuscule et le reste par une minuscule. Par exemple : `"s3:ListAllMyBuckets"`.
Vous pouvez également utiliser des caractères génériques comme un astérisque (\$1) ou un point d'interrogation (?) dans une SCP :
+ Utilisez un astérisque (\$1) en tant que caractère générique pour faire correspondre plusieurs actions partageant une partie d'un nom. La valeur `"s3:*"` signifie toutes les actions dans le service Amazon S3. La valeur `"ec2:Describe*"` correspond uniquement aux actions EC2 commençant par « Describe ».
+ Utilisez le caractère générique point d'interrogation (?) pour faire correspondre un seul caractère.
Pour obtenir une liste de tous les services et des actions qu'ils prennent en charge dans les politiques d'autorisation IAM AWS Organizations SCPs et dans les politiques d'autorisation IAM, consultez la section [Actions, ressources et clés de condition pour les AWS services](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actionsconditions.html) dans le guide de l'*utilisateur IAM*.
Pour plus d'informations, consultez les sections Éléments de [stratégie IAM JSON : action et Éléments](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_action.html) de [stratégie IAM JSON : NotAction](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notaction.html) dans le guide de l'utilisateur *IAM*.
### Exemple d'élément `Action`
L'exemple suivant montre une politique de contrôle des services dans une instruction qui permet aux administrateurs de compte de déléguer les autorisations décrire, démarrer, arrêter et résilier pour les instances EC2 dans le compte. Il s'agit d'un exemple de [liste d'autorisations](orgs_manage_policies_scps_evaluation.md#how_scps_allow), qui est utile lorsque les politiques `Allow *` par défaut ne sont ***pas attachées*** afin que, par défaut, les autorisations soient implicitement refusées. Si la politique `Allow *` par défaut est encore attachée à la racine, à l'unité d'organisation ou au compte auquel la politique suivante est attachée, cette politique n'a aucun effet.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeKeyPairs",
"ec2:DescribeSecurityGroups", "ec2:DescribeAvailabilityZones", "ec2:RunInstances",
"ec2:TerminateInstances", "ec2:StopInstances", "ec2:StartInstances"
],
"Resource": "*"
}
}
```
------
L'exemple suivant montre comment vous pouvez [refuser l’accès](orgs_manage_policies_scps_evaluation.md#how_scps_deny) à des services qui ne doivent pas être utilisés dans les comptes attachés. Il suppose que les politiques de contrôle des services `"Allow *"` par défaut sont encore attachées à toutes les unités d'organisation et à la racine. Cet exemple de politique empêche les administrateurs de compte dans les comptes attachés de déléguer des autorisations pour les services IAM, Amazon EC2 et Amazon RDS. Les actions d'autres services peuvent être déléguées dans la mesure où aucune autre politique attachée ne les refuse :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": [ "iam:*", "ec2:*", "rds:*" ],
"Resource": "*"
}
}
```
------
### Exemple d'élément `NotAction`
L'exemple suivant montre comment utiliser un `NotAction` élément pour exclure AWS des services de l'effet de la politique.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "LimitActionsInRegion",
"Effect": "Deny",
"NotAction": "iam:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": "us-west-1"
}
}
}
]
}
```
------
Avec cette instruction, les comptes concernés sont limités à l'exécution des actions spécifiées Région AWS, sauf lorsqu'ils utilisent des actions IAM.
## Élément `Condition`
Vous pouvez spécifier un `Condition` élément dans les instructions d'autorisation et de refus d'un SCP.
L'exemple suivant montre comment utiliser un élément de condition avec une instruction allow dans un SCP pour autoriser des principaux spécifiques à accéder AWS aux services.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowServicesForSpecificPrincipal",
"Effect":"Allow",
"Action":[
"ec2:*",
"s3:*",
"rds:*",
"lambda:*",
"cloudformation:*",
"iam:*",
"cloudwatch:*"
],
"Resource":"*",
"Condition":{
"StringEquals":{
"aws:PrincipalArn":[
"arn:aws:iam::123456789012:role/specific-role"
]
}
}
}
]
}
```
L'exemple suivant montre comment utiliser un élément de condition avec une déclaration de refus dans un SCP pour restreindre l'accès à toutes les opérations en dehors des `eu-west-1` régions `eu-central-1` et, à l'exception des actions dans les services spécifiés.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideEU",
"Effect": "Deny",
"NotAction": [
"cloudfront:*",
"iam:*",
"route53:*",
"support:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"eu-central-1",
"eu-west-1"
]
}
}
}
]
}
```
------
Pour plus d'informations, consultez [Éléments de politique JSON IAM : Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
## Élément `Effect`
Chaque instruction doit contenir un élément `Effect`. La valeur peut être `Allow` ou `Deny`. Cet élément affecte toutes les actions répertoriées dans la même instruction.
Pour plus d'informations, consultez [Éléments de politique JSON IAM : Effet](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_effect.html) dans le *Guide de l'utilisateur IAM*.
### `"Effect": "Allow"`
L'exemple suivant montre une politique de contrôle des services avec une instruction qui contient un élément `Effect` avec une valeur `Allow` qui permet aux utilisateurs de compte d'effectuer des actions pour le service Amazon S3. Cet exemple est utile dans une organisation qui utilise la [stratégie de liste d'autorisations](orgs_manage_policies_scps_evaluation.md#how_scps_allow) (où les politiques `FullAWSAccess` par défaut sont toutes détachées, de sorte que les autorisations sont implicitement refusées par défaut). Le résultat est que l'instruction [permet](orgs_manage_policies_scps_evaluation.md#how_scps_allow) les autorisations Amazon S3 pour les comptes attachés :
```
{
"Statement": {
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
}
```
Même si cette instruction utilise le même mot clé de valeur `Allow` qu'une politique d'autorisation IAM, dans une politique SCP, cela n'autorise pas réellement un utilisateur à effectuer une action. SCPs Agissez plutôt comme des filtres qui spécifient les autorisations maximales pour les comptes d'une organisation, d'une unité organisationnelle (UO) ou d'un compte. Dans l'exemple précédent, même si une politique gérée `AdministratorAccess` est attachée à un utilisateur du compte, la politique de contrôle des services limite ***tous*** les utilisateurs des comptes concernés aux seules actions Amazon S3.
### `"Effect": "Deny"`
Dans une instruction dont la valeur de l'`Effect`élément est égale à`Deny`, vous pouvez également restreindre l'accès à des ressources spécifiques ou définir les conditions d'entrée en vigueur. SCPs
L'exemple suivant montre la façon d'utiliser une clé de condition dans une instruction de refus.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringNotEquals": {
"ec2:InstanceType": "t2.micro"
}
}
}
}
```
------
Cette instruction dans une politique de contrôle des services définit une protection pour empêcher les comptes concernés (dans lesquels la politique de contrôle des services est attachée au compte lui-même ou à la racine de l'organisation ou à l'unité d'organisation qui contient le compte), de lancer des instances Amazon EC2 si l'instance Amazon EC2 n'est pas définie sur `t2.micro`. Même si une politique IAM qui permet cette action est attachée au compte, la protection créée par la politique de contrôle des services empêche cette action.
## `Resource`et `NotResource` élément
Dans les instructions où l'élément `Effect` a une valeur `Allow`, vous pouvez spécifier uniquement «\$1 » dans l'élément `Resource` d'une politique de contrôle des services (SCP). Vous ne pouvez pas spécifier de ressource Amazon Resource Names (ARNs) individuelle.
Vous pouvez utiliser des caractères génériques tels que l'astérisque (\$1) ou le point d'interrogation (?) dans l'élément ressource :
+ Utilisez un astérisque (\$1) en tant que caractère générique pour faire correspondre plusieurs actions partageant une partie d'un nom.
+ Utilisez le caractère générique point d'interrogation (?) pour faire correspondre un seul caractère.
Dans les instructions où l'`Effect`élément a une valeur égale à`Deny`, vous *pouvez* spécifier un élément individuel ARNs, comme indiqué dans l'exemple suivant.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAccessToAdminRole",
"Effect": "Deny",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRole",
"iam:DeleteRolePermissionsBoundary",
"iam:DeleteRolePolicy",
"iam:DetachRolePolicy",
"iam:PutRolePermissionsBoundary",
"iam:PutRolePolicy",
"iam:UpdateAssumeRolePolicy",
"iam:UpdateRole",
"iam:UpdateRoleDescription"
],
"Resource": [
"arn:aws:iam::*:role/role-to-deny"
]
}
]
}
```
------
Cette politique de contrôle des services empêche les utilisateurs et les rôles IAM des comptes concernés de modifier un rôle IAM d'administration commun créé dans tous les comptes de votre organisation.
L'exemple suivant montre comment utiliser un `NotResource` élément pour exclure des modèles Amazon Bedrock spécifiques de l'effet de la politique.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"Statement1",
"Effect":"Deny",
"Action":[
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"NotResource":[
"arn:aws:bedrock:*::foundation-model/model-to-permit"
]
}
]
}
```
Pour plus d'informations, consultez [Éléments de politique JSON IAM : Ressource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html) dans le *Guide de l'utilisateur IAM*.
## Élément `Statement`
Une politique de contrôle des services est constituée d'un ou plusieurs éléments `Statement`. Vous ne pouvez avoir qu'un mot clé `Statement` dans une politique, mais la valeur peut être un tableau d'instructions JSON (encadré par des caractères [ ]).
L'exemple suivant montre une instruction unique qui se compose d'éléments `Effect`, `Action` et `Resource` uniques.
```
"Statement": {
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
```
L'exemple suivant inclut deux instructions sous la forme d'un tableau à l'intérieur d'un élément `Statement`. La première instruction autorise toutes les actions, tandis que la deuxième refuse toutes les actions EC2. Le résultat est un qu'administrateur du compte peut déléguer n'importe quelle autorisation, *à l'exception* de celles provenant d'Amazon Elastic Compute Cloud (Amazon EC2).
```
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*"
}
]
```
Pour plus d'informations, consultez [Éléments de politique JSON IAM : Instruction](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_statement.html) dans le *Guide de l'utilisateur IAM*.
## Élément ID d'instruction (`Sid`)
L'élément `Sid` est un identifiant facultatif que vous pouvez fournir pour l'instruction de politique. Vous pouvez affecter une valeur `Sid` à chaque instruction d'un tableau d'instructions. L'exemple suivant de politique de contrôle des services présente un exemple d'instruction `Sid`.
```
{
"Statement": {
"Sid": "AllowsAllActions",
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
}
```
Pour plus d'informations, consultez [Éléments de politique JSON IAM : Id](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_id.html) dans le *Guide de l'utilisateur IAM*.
## Élément `Version`
Chaque politique de contrôle des services doit inclure un élément `Version` avec la valeur `"2012-10-17"`. Il s'agit de la même valeur de version que la version la plus récente des politiques d'autorisation IAM.
Pour plus d'informations, consultez [Éléments de politique JSON IAM : Version](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_version.html) dans le *Guide de l'utilisateur IAM*.
## Élément non pris en charge
Les éléments suivants ne sont pas pris en charge dans SCPs :
+ `NotPrincipal`
+ `Principal`
# Exemples de politiques de contrôle des services
Les exemples [de politiques de contrôle des services (SCPs)](orgs_manage_policies_scps.md) présentés dans cette rubrique sont fournis à titre informatif uniquement.
**Avant d'utiliser ces exemples**
Avant d'utiliser ces exemples SCPs dans votre organisation, tenez compte des points suivants :
Les [politiques de contrôle des services (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) sont destinées à être utilisées comme des barrières de sécurité grossières et n'accordent pas directement l'accès. L'administrateur doit toujours associer des [politiques basées sur l'identité ou les ressources](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) aux principaux IAM ou aux ressources de vos comptes pour réellement accorder des autorisations. Les autorisations effectives sont l'intersection logique entre la politique de policy/Resource contrôle des services et une politique d'identité ou entre la politique de policy/Resource contrôle des services et une politique des ressources. Vous pouvez obtenir plus de détails sur les effets du SCP sur les autorisations [ici](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions).
Lorsqu'elle est associée à une organisation, à une unité organisationnelle ou à un compte, une [politique de contrôle des services (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) permet de contrôler de manière centralisée les autorisations maximales disponibles pour tous les comptes de votre organisation, de votre unité organisationnelle ou d'un compte. Comme un SCP peut être appliqué à plusieurs niveaux dans une organisation, comprendre comment [SCPs sont évalués](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html) peut vous aider à rédiger des articles SCPs qui donnent le bon résultat.
Les politiques de contrôle des services de ce référentiel sont présentées à titre d'exemples. Vous ne devez pas joindre une SCPs pièce jointe sans avoir testé de manière approfondie l'impact de la politique sur les comptes. Une fois que vous avez une politique prête à mettre en œuvre, nous vous recommandons de la tester dans une organisation ou une unité d'organisation distincte pouvant représenter votre environnement de production. Une fois le test effectué, vous devez déployer les modifications de manière plus spécifique, OUs puis les déployer progressivement de manière plus large OUs au fil du temps.
Les exemples de SCP de ce référentiel utilisent une [stratégie de liste de refus](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html#strategy_using_scps), ce qui signifie que vous avez également besoin d'une AWSAccess politique [complète](https://console.aws.amazon.com/organizations/?#/policies/p-FullAWSAccess) ou d'une autre politique autorisant l'accès attaché aux entités de votre organisation pour autoriser les actions. Vous devez également accorder les autorisations appropriées à vos principaux en utilisant des politiques basées sur l'identité ou les ressources.
**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.*
## GitHub référentiel
+ [Exemples de politiques de contrôle des services](https://github.com/aws-samples/service-control-policy-examples) - Ce GitHub référentiel contient des exemples de politiques pour démarrer ou affiner votre utilisation de AWS SCPs
# Résolution des problèmes liés aux politiques de contrôle des services (SCPs) avec AWS Organizations
Utilisez les informations fournies ici pour vous aider à diagnostiquer et à corriger les erreurs courantes détectées dans les politiques de contrôle des services (SCPs).
Les politiques de contrôle des services (SCPs) AWS Organizations sont similaires aux politiques IAM et partagent une syntaxe commune. Cette syntaxe commence par les règles de la [notation d'JavaScript objet](http://www.json.org) (JSON). JSON décrit un *objet* avec des paires nom-valeur qui constituent l'objet. La [grammaire des politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies-grammar.html) s'appuie sur cela en définissant les noms et les valeurs qui ont une signification et sont compris par ceux Services AWS qui utilisent des politiques pour accorder des autorisations.
AWS Organizations utilise un sous-ensemble de la syntaxe et de la grammaire IAM. Pour en savoir plus, consultez [Syntaxe d’une stratégie de contrôle de service](orgs_manage_policies_scps_syntax.md).
**Topics**
+ [Plus d'un objet de politique](#morethanonepolicyblock)
+ [Plusieurs éléments d'instruction](#morethanonestatement)
+ [La taille du document de politique dépasse la taille maximale autorisée](#scptoolong)
## Plus d'un objet de politique
Une politique SCP doit inclure un et un seul objet JSON. Vous désignez un objet en le plaçant entre accolades \$1 \$1. S'il est possible d'imbriquer d'autres objets au sein d'un objet JSON en incorporant des parenthèses \$1 \$1 supplémentaires dans la paire extérieure, une politique peut uniquement comporter une paire de parenthèses \$1 \$1 extérieure. L'exemple suivant est ***incorrect*** car il contient deux objets au niveau supérieur (appelés dans*red*) :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*"
}
]
}
```
------
Toutefois, il est possible de réaliser ce que voulait faire l'exemple précédent en utilisant une grammaire correcte. Au lieu d'utiliser deux objets de politique complets, avec chacun son propre élément `Statement`, vous pouvez combiner les deux blocs en un seul élément `Statement`. La valeur de l'élément `Statement` est un tableau de deux objets, comme illustré dans l'exemple suivant :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*"
}
]
}
```
Cet exemple ne peut pas être davantage compressé en une `Statement` ne comportant qu‘un seul élément car les deux éléments ont des effets différents. En général, vous pouvez combiner des instructions uniquement lorsque les éléments `Effect` et `Resource` de chaque instruction sont identiques.
## Plusieurs éléments d'instruction
Au premier abord, cette erreur peut sembler être une variante de l'erreur de la section précédente. Toutefois, d'un point de vue syntaxique, il s'agit d'un type d'erreur différent. L'exemple suivant comporte un seul objet de politique, comme indiqué par la paire de parenthèses \$1 \$1 unique au niveau supérieur. Toutefois, cet objet contient deux éléments `Statement`.
Une politique SCP ne peut comporter qu'un seul élément `Statement`, composé du nom (`Statement`) suivi de deux points, eux-mêmes suivis de sa valeur à droite. La valeur d'un élément `Statement` doit être un objet, indiqué par des accolades \$1 \$1, contenant un élément `Effect`, un élément `Action` et un élément `Resource`. L'exemple suivant est ***incorrect*** car il contient deux éléments `Statement` dans l'objet de politique :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*"
}
]
}
```
------
Dans la mesure où un objet de valeur peut être un tableau de plusieurs objets de valeur, vous pouvez résoudre ce problème en combinant les deux éléments `Statement` en un seul élément avec un tableau d'objets, comme illustré dans l'exemple suivant :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource":"*"
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*"
}
]
}
```
------
La valeur de l'élément `Statement` est un tableau d'objets. Dans l'exemple, le tableau se compose de deux objets, chaque objet étant une valeur correcte pour un élément `Statement` Les objets du tableau sont séparés par des virgules.
## La taille du document de politique dépasse la taille maximale autorisée
La taille maximale d'un document SCP est de 5 120 octets. Cette taille maximale inclut tous les caractères, y compris les espaces blancs. Pour réduire la taille de votre politique SCP, vous pouvez supprimer tous les espaces (comme les espacements et les sauts de ligne) qui ne figurent pas entre guillemets.
**Note**
Si vous enregistrez la politique en utilisant le AWS Management Console, les espaces blancs supplémentaires entre les éléments JSON et en dehors des guillemets sont supprimés et ne sont pas pris en compte. Si vous enregistrez la politique à l'aide d'une opération du SDK ou du AWS CLI, elle est enregistrée exactement comme vous l'avez indiqué et aucun caractère n'est automatiquement supprimé.