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.
# Gestion des autorisations et des accès pour une architecture à comptes multiples
**Topics**
+ [Considérations culturelles en matière d'ingénierie](engineering-cultural-considerations.md)
+ [Création d'ensembles d'autorisations](creating-permission-sets.md)
+ [Création d'une limite des autorisations](creating-a-permissions-boundary.md)
+ [Gestion des autorisations pour les personnes](managing-permissions-for-individuals.md)
# Considérations culturelles en matière d'ingénierie
L'un des piliers du AWS Well-Architected Framework est l'excellence opérationnelle. Les équipes doivent comprendre le [modèle d'exploitation](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html) et le rôle qu'elles jouent pour atteindre vos résultats métier. Les équipes peuvent se concentrer sur la réalisation d'objectifs communs lorsqu'elles comprennent leurs responsabilités, les assument et qu'elles savent comment les décisions sont prises.
Dans les entreprises débutantes qui se développent rapidement, chaque membre de l'équipe joue plusieurs rôles. Il n'est pas rare que ces utilisateurs disposent d'un accès hautement privilégié à l'ensemble de l' Compte AWS. Au fur et à mesure que les entreprises se développent, elles souhaitent souvent suivre le principe de *moindre privilège* et n'accordent que les autorisations nécessaires pour que l'utilisateur puisse effectuer son travail. Pour vous aider à limiter la portée, vous pouvez utiliser [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) afin de voir quelles autorisations un utilisateur ou un rôle IAM utilise réellement, ce qui vous permet de supprimer les autorisations excédentaires.
Il peut être difficile de déterminer qui, au sein de votre entreprise, est autorisé à créer des rôles IAM. Il s'agit généralement d'un vecteur d'escalade des privilèges. L'escalade des privilèges se produit lorsqu'un utilisateur peut étendre ses propres autorisations ou la portée de son accès. Par exemple, si un utilisateur dispose d'autorisations limitées, mais peut créer des rôles IAM, il peut escalader ses privilèges en créant et en endossant un nouveau rôle IAM, auquel la politique gérée par `AdministratorAccess` est appliquée.
Certaines entreprises limitent l'attribution des rôles IAM à une équipe centralisée de personnes de confiance. L'inconvénient de cette approche est que cette équipe peut rapidement devenir un goulot d'étranglement, car presque toutes Services AWS ont besoin d'un rôle IAM pour fonctionner. Comme alternative, vous pouvez recourir aux [limites des autorisations](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) pour déléguer l'accès IAM uniquement aux utilisateurs qui développent, testent, lancent et gèrent votre infrastructure cloud. Pour des exemples de politiques, voir [Example Permission Boundaries](https://github.com/aws-samples/example-permissions-boundary) (GitHub).
Les équipes chargées des opérations de développement (DevOps), également appelées équipes de *plateforme*, doivent souvent trouver un équilibre entre les capacités de libre-service de plusieurs équipes de développement internes et la stabilité opérationnelle des applications. Favoriser une culture d'ingénierie qui prône l'autonomie, la maîtrise et la détermination au travail peut contribuer à motiver les équipes. Les ingénieurs veulent faire leur travail de manière autonome, sans compter sur les autres pour faire les choses à leur place. Si DevOps les équipes peuvent mettre en œuvre des solutions en libre-service, cela réduit également le temps que les autres personnes comptent sur elles pour accomplir leurs tâches.
# Création d'ensembles d'autorisations
Vous pouvez gérer Compte AWS l'accès à l'aide des [ensembles d'autorisations](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) intégrés AWS IAM Identity Center. Un *ensemble d'autorisations* est un modèle qui vous permet de déployer une ou plusieurs politiques IAM sur plusieurs Comptes AWS. Lorsque vous attribuez un ensemble d'autorisations à un Compte AWS, IAM Identity Center crée un rôle IAM et lui associe vos politiques IAM. Pour plus d'informations, veuillez consulter la rubrique [Create and manage permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsets.html) (documentation IAM Identity Center).
AWS recommande de créer des ensembles d'autorisations correspondant aux différentes personnes de votre entreprise.
**Topics**
+ [Ensemble d'autorisations de facturation](#billing-permission-set)
+ [Ensemble d'autorisations pour les développeurs](#developer-permission-set)
+ [Ensemble d'autorisations de production](#production-permission-set)
Les ensembles d'autorisations suivants sont des extraits d'un AWS CloudFormation modèle. Vous devez utiliser ce code comme point de départ et le personnaliser pour votre entreprise. Pour plus d'informations sur les CloudFormation modèles, voir [Apprendre les bases des modèles](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/gettingstarted.templatebasics.html) (CloudFormation documentation).
## Ensemble d'autorisations de facturation
L'équipe financière a l'habitude **BillingAccessPermissionSet**de consulter le tableau de bord de la AWS Billing console et AWS Cost Explorer de chaque compte.
```
BillingAccessPermissionSet:
Type: "AWS::SSO::PermissionSet"
Properties:
Description: Access to Billing and Cost Explorer
InstanceArn: !Sub "arn:${AWS::Partition}:sso:::instance/ssoins-instanceId"
ManagedPolicies:
- !Sub "arn:${AWS::Partition}:iam::aws:policy/job-function/Billing"
Name: BillingAccess
SessionDuration: PT8H
RelayStateType: https://console.aws.amazon.com/billing/home
```
## Ensemble d'autorisations pour les développeurs
L'équipe d'ingénierie a l'habitude d'accéder **DeveloperAccessPermissionSet**à des comptes non liés à la production.
```
DeveloperAccessPermissionSet:
Type: "AWS::SSO::PermissionSet"
Properties:
Description: Access to provision resources through CloudFormation
InlinePolicy: !Sub |-
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:${AWS::Partition}:iam::*:role/CloudFormationRole",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${!aws:PrincipalAccount}",
"iam:PassedToService": "cloudformation.${AWS::URLSuffix}"
}
}
},
{
"Effect": "Allow",
"Action": [
"cloudformation:ContinueUpdateRollback",
"cloudformation:CreateChangeSet",
"cloudformation:CreateStack",
"cloudformation:DeleteStack",
"cloudformation:RollbackStack",
"cloudformation:UpdateStack"
],
"Resource": "arn:${AWS::Partition}:cloudformation:*:*:stack/app-*",
"Condition": {
"ArnLike": {
"cloudformation:RoleArn": "arn:${AWS::Partition}:iam::${!aws:PrincipalAccount}:role/CloudFormationRole"
},
"Null": {
"cloudformation:ImportResourceTypes": true
}
}
},
{
"Effect": "Allow",
"Action": [
"cloudformation:CancelUpdateStack",
"cloudformation:DeleteChangeSet",
"cloudformation:DetectStackDrift",
"cloudformation:DetectStackResourceDrift",
"cloudformation:ExecuteChangeSet",
"cloudformation:TagResource",
"cloudformation:UntagResource",
"cloudformation:UpdateTerminationProtection"
],
"Resource": "arn:${AWS::Partition}:cloudformation:*:*:stack/app-*"
},
{
"Effect": "Allow",
"Action": [
"cloudformation:CreateUploadBucket",
"cloudformation:ValidateTemplate",
"cloudformation:EstimateTemplateCost"
],
"Resource": "*"
}
]
}
InstanceArn: !Sub "arn:${AWS::Partition}:sso:::instance/ssoins-instanceId"
ManagedPolicies:
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AWSServiceCatalogEndUserFullAccess"
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AWSBillingReadOnlyAccess"
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AWSSupportAccess"
- !Sub "arn:${AWS::Partition}:iam::aws:policy/ReadOnlyAccess"
Name: DeveloperAccess
SessionDuration: PT8H
```
## Ensemble d'autorisations de production
L'équipe d'ingénierie a l'habitude **ProductionPermissionSet**d'accéder aux comptes de production. Cet ensemble d'autorisations dispose d'un accès limité en lecture seule.
```
ProductionPermissionSet:
Type: "AWS::SSO::PermissionSet"
Properties:
Description: Access to production accounts
InlinePolicy: !Sub |-
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:${AWS::Partition}:iam::*:role/CloudFormationRole",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${!aws:PrincipalAccount}",
"iam:PassedToService": "cloudformation.${AWS::URLSuffix}"
}
}
},
{
"Effect": "Allow",
"Action": "cloudformation:ContinueUpdateRollback",
"Resource": "arn:${AWS::Partition}:cloudformation:*:*:stack/app-*",
"Condition": {
"ArnLike": {
"cloudformation:RoleArn": "arn:${AWS::Partition}:iam::${!aws:PrincipalAccount}:role/CloudFormationRole"
}
}
},
{
"Effect": "Allow",
"Action": "cloudformation:CancelUpdateStack",
"Resource": "arn:${AWS::Partition}:cloudformation:*:*:stack/app-*"
}
]
}
InstanceArn: !Sub "arn:${AWS::Partition}:sso:::instance/ssoins-instanceId"
ManagedPolicies:
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AWSBillingReadOnlyAccess"
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AWSSupportAccess"
- !Sub "arn:${AWS::Partition}:iam::aws:policy/job-function/ViewOnlyAccess"
Name: ProductionAccess
SessionDuration: PT2H
```
# Création d'une limite des autorisations
Après avoir déployé les ensembles d'autorisations, vous définissez une limite des autorisations. Cette *limite des autorisations* est un mécanisme permettant de déléguer l'accès IAM uniquement aux utilisateurs qui développent, testent, lancent et gèrent votre infrastructure cloud. Ces utilisateurs ne peuvent effectuer que les actions autorisées par la politique et les limites des autorisations.
Vous pouvez définir la limite des autorisations dans un AWS CloudFormation modèle, puis l'utiliser CloudFormation StackSets pour déployer le modèle sur plusieurs comptes. Cela vous permet d'établir et de maintenir des politiques normalisées au sein de votre organisation en une seule opération. Pour plus d'informations et d'instructions, consultez la section [Travailler avec AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) (CloudFormation documentation).
Le CloudFormation modèle suivant fournit un rôle IAM et crée une politique IAM qui sert de limite d'autorisation. À l'aide d'un ensemble de piles, vous pouvez déployer ce modèle sur tous les comptes membres de votre organisation.
```
CloudFormationRole:
Type: "AWS::IAM::Role"
Properties:
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
Effect: Allow
Principal:
Service: !Sub "cloudformation.${AWS::URLSuffix}"
Action: "sts:AssumeRole"
Condition:
StringEquals:
"aws:SourceAccount": !Ref "AWS::AccountId"
Description: !Sub "DO NOT DELETE - Used by CloudFormation. Created by CloudFormation ${AWS::StackId}"
ManagedPolicyArns:
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AdministratorAccess"
PermissionsBoundary: !Ref DeveloperBoundary
RoleName: CloudFormationRole
DeveloperBoundary:
Type: "AWS::IAM::ManagedPolicy"
Properties:
Description: Permission boundary for developers
ManagedPolicyName: PermissionsBoundary
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: AllowModifyIamRolesWithBoundary
Effect: Allow
Action:
- "iam:AttachRolePolicy"
- "iam:CreateRole"
- "iam:DeleteRolePolicy"
- "iam:DetachRolePolicy"
- "iam:PutRolePermissionsBoundary"
- "iam:PutRolePolicy"
Resource: !Sub "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/app/*"
Condition:
ArnEquals:
"iam:PermissionsBoundary": !Sub "arn:${AWS::Partition}:iam::${AWS::AccountId}:policy/PermissionsBoundary"
- Sid: AllowModifyIamRoles
Effect: Allow
Action:
- "iam:DeleteRole"
- "iam:TagRole"
- "iam:UntagRole"
- "iam:UpdateAssumeRolePolicy"
- "iam:UpdateRole"
- "iam:UpdateRoleDescription"
Resource: !Sub "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/app/*"
- Sid: OverlyPermissiveAllowedServices
Effect: Allow
Action:
- "lambda:*"
- "apigateway:*"
- "events:*"
- "s3:*"
- "logs:*"
Resource: "*"
```
Le **CloudFormationRole**rôle, la **PermissionsBoundary**politique et l'ensemble **DeveloperAccess**d'autorisations fonctionnent ensemble pour accorder les autorisations suivantes :
+ Les utilisateurs ont un accès en lecture seule à la plupart Services AWS, via la politique **ReadOnlyAccess** AWS gérée.
+ Les utilisateurs ont accès aux dossiers de support ouverts, par le biais de la politique de AWS gestion des **AWSSupportaccès**.
+ Les utilisateurs ont un accès en lecture seule au tableau de bord de la AWS Billing console, via la politique **AWSBillingReadOnlyAccess** AWS gérée.
+ Les utilisateurs peuvent approvisionner des produits à partir de Service Catalog, via la politique **AWSServiceCatalogEndUserFullAccess** AWS gérée.
+ Les utilisateurs peuvent valider et estimer le coût de n'importe quel CloudFormation modèle, grâce à la politique en ligne.
+ En utilisant le rôle **CloudFormationRole**IAM, les utilisateurs peuvent créer, mettre à jour ou supprimer toute CloudFormation pile commençant par **app/**.
+ Les utilisateurs peuvent l'utiliser CloudFormation pour créer, mettre à jour ou supprimer des rôles IAM commençant par **app/**. La politique **PermissionsBoundary**IAM empêche les utilisateurs d'augmenter leurs privilèges.
+ Les utilisateurs peuvent AWS Lambda approvisionner les ressources Amazon EventBridge CloudWatch, Amazon, Amazon Simple Storage Service (Amazon S3) et Amazon API Gateway uniquement en utilisant. CloudFormation
L'image suivante montre comment un utilisateur autorisé, tel qu'un développeur, peut créer un rôle IAM dans un compte membre en utilisant les ensembles d'autorisations, les rôles IAM et les limites des autorisations décrits dans ce guide :
1. L'utilisateur s'authentifie dans le centre d'identité IAM et assume le rôle **DeveloperAccess**IAM.
1. L'utilisateur lance l'`cloudformation:CreateStack`action et assume le rôle **CloudFormationRole**IAM.
1. L'utilisateur lance l'`iam:CreateRole`action et l'utilise CloudFormation pour créer un nouveau rôle IAM.
1. La politique **PermissionsBoundary**IAM est appliquée au nouveau rôle IAM.
![\[Utilisateur créant un rôle IAM soumis à la limite des autorisations du compte membre\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/2_create-iam-role.png)
La politique [AdministratorAccess](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator)gérée est attachée au **CloudFormationRole**rôle, mais en raison de la stratégie **PermissionsBoundary**IAM, les autorisations effectives du **CloudFormationRole**rôle deviennent égales à la **PermissionsBoundary**politique. La **PermissionsBoundary**politique se référence elle-même lorsqu'elle autorise l'`iam:CreateRole`action, ce qui garantit que les rôles ne peuvent être créés que si la limite des autorisations est appliquée.
# Gestion des autorisations pour les personnes
En utilisant les ensembles d'autorisations, la limite des autorisations et le rôle **CloudFormationRole**IAM, vous pouvez limiter le nombre d'autorisations que vous devez attribuer directement aux principaux individuels. Cela vous permet de gérer l'accès au fur et à mesure que votre entreprise se développe et d'appliquer les bonnes pratiques de sécurité qui consistent à accorder le moindre privilège.
Vous pouvez également utiliser des *rôles liés à un service*, qui accordent des autorisations à un service AWS afin d'allouer des ressources en votre nom. Au lieu d'accorder des autorisations au principal IAM (utilisateur, groupe d'utilisateurs ou rôle), vous pouvez accorder les autorisations au service. Par exemple, le rôle lié à un service pour vous [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html)permet de fournir vos propres modèles, ressources et environnements, sans attribuer d'autorisations au principal IAM. Pour plus d'informations, veuillez consulter les rubriques [Services AWS qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et [Utilisation des rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) (documentation IAM).
Une autre bonne pratique consiste à limiter le niveau d'accès dont disposent les personnes à la AWS Management Console. [En limitant l'accès à la console, vous pouvez obliger les utilisateurs à provisionner des ressources en utilisant des technologies d'infrastructure sous forme de code (IaC) [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html), telles que [HashiCorp Terraform](https://www.terraform.io/) ou Pulumi.](https://www.pulumi.com/) La gestion de l'infrastructure via iAC vous permet de suivre l'évolution des ressources au fil du temps et d'introduire des mécanismes d'approbation des modifications, tels que les GitHub pull requests.