# Gestion des identités et des accès
**Topics**
+ [SÉC 2. Comment gérer l’authentification des personnes et des machines ?](sec-02.md)
+ [SÉC 3. Comment gérer les autorisations des personnes et des machines ?](sec-03.md)
# SÉC 2. Comment gérer l’authentification des personnes et des machines ?
Il existe deux types d’identités que vous devez gérer dans le cadre de l’exploitation de charges de travail AWS sécurisées.
+ **Identités humaines :** les identités humaines qui nécessitent l’accès à vos environnements et applications AWS peuvent être classées en trois groupes : employés, tiers et utilisateurs.
Le groupe des *employés* comprend les administrateurs, les développeurs et les opérateurs qui font partie de votre organisation. Ils ont besoin d’un accès pour gérer, créer et exploiter vos ressources AWS.
Les *tiers* sont les collaborateurs externes, tels que les sous-traitants, les fournisseurs et les partenaires. Ils interagissent avec vos ressources AWS dans le cadre de leur engagement auprès de votre organisation.
Les *utilisateurs* sont les consommateurs de vos applications. Ils accèdent à vos ressources AWS via des navigateurs Web, des applications client, des applications mobiles ou des outils de ligne de commande interactifs.
+ **Identités des machines :** les applications, les outils opérationnels et les composants de votre charge de travail ont besoin d’une identité pour adresser des demandes aux services AWS, telles que la lecture de données. Ces identités incluent également les machines qui s’exécutent dans votre environnement AWS, comme les instances Amazon EC2 ou les fonctions AWS Lambda. Vous pouvez également gérer les identités des machines pour des parties externes ou des machines en dehors d’AWS, qui ont besoin d’accéder à votre environnement AWS.
**Topics**
+ [SEC02-BP01 Utiliser de solides mécanismes d’authentification](sec_identities_enforce_mechanisms.md)
+ [SEC02-BP02 Utiliser des informations d’identification temporaires](sec_identities_unique.md)
+ [SEC02-BP03 Stocker et utiliser des secrets en toute sécurité](sec_identities_secrets.md)
+ [SEC02-BP04 S’appuyer sur un fournisseur d’identité centralisé](sec_identities_identity_provider.md)
+ [SEC02-BP05 Contrôler et effectuer régulièrement une rotation des informations d’identification](sec_identities_audit.md)
+ [SEC02-BP06 Utiliser des groupes d’utilisateurs et des attributs](sec_identities_groups_attributes.md)
# SEC02-BP01 Utiliser de solides mécanismes d’authentification
Les connexions (authentification au moyen d’informations d’identification de connexion) peuvent présenter des risques lorsque l’on n’utilise pas des mécanismes tels que l’authentification multifactorielle (MFA), surtout dans les situations où les informations d’identification de connexion ont été divulguées par inadvertance ou peuvent être devinées facilement. Vous devez utiliser de solides mécanismes d’authentification pour réduire ces risques en exigeant l’authentification multifactorielle (MFA) et des politiques strictes de gestion des mots de passe.
**Résultat escompté :** réduisez les risques d’accès involontaire aux informations d’identification dans AWS en utilisant des mécanismes de connexion robustes pour les utilisateurs [Gestion des identités et des accès AWS (IAM)](https://aws.amazon.com/iam/), l’[utilisateur racine du Compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html), [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) et les fournisseurs d’identité tiers. Cela signifie que vous devez exiger une authentification multifactorielle (MFA), appliquer des politiques strictes de gestion des mots de passe et détecter les comportements de connexion anormaux.
**Anti-modèles courants :**
+ Ne pas appliquer de politique stricte de gestion de mots de passe pour vos identités, notamment des mots de passe complexes et l’authentification multifactorielle (MFA).
+ Utilisation des mêmes informations d’identification pour différents utilisateurs.
+ Ne pas utiliser de contrôles de détection pour les connexions suspectes.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Les identités humaines peuvent se connecter à AWS de plusieurs façons. Une bonne pratique AWS consiste à s’appuyer sur un fournisseur d’identité centralisé en utilisant la fédération (fédération SAML 2.0 directe entre AWS IAM et le fournisseur d’identité centralisé ou utilisant AWS IAM Identity Center) lors de l’authentification auprès d’AWS. Dans ce cas, établissez un processus de connexion sécurisée avec votre fournisseur d’identité ou Microsoft Active Directory.
Lorsque vous ouvrez pour la première fois un Compte AWS, vous commencez avec un utilisateur racine du Compte AWS. Vous ne devez utiliser l’utilisateur racine du compte que pour configurer l’accès de vos utilisateurs (et pour les [tâches nécessitant l’utilisateur racine](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)). Il est important d’activer l’authentification multifactorielle (MFA) pour l’utilisateur racine du compte immédiatement après l’ouverture de votre Compte AWS et de sécuriser l’utilisateur racine à l’aide du [guide des bonnes pratiques AWS](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_aws_account.html).
AWS IAM Identity Center est conçu pour les utilisateurs en interne et vous pouvez créer et gérer des identités utilisateur au sein du service et sécuriser le processus d’authentification avec la MFA. AWS Cognito, quant à lui, est conçu pour la gestion de l’identité et de l’accès des clients (CIAM), qui fournit des groupes d’utilisateurs et des fournisseurs d’identité pour les identités des utilisateurs externes dans vos applications.
Si vous créez des utilisateurs dans AWS IAM Identity Center, sécurisez le processus d’authentification dans ce service et [activez la MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html). Pour les identités des utilisateurs externes dans vos applications, vous pouvez utiliser les [groupes d’utilisateurs Amazon Cognito](https://docs.aws.amazon.com/cognito/index.html) et sécuriser le processus d’authentification dans ce service ou utiliser l’un des fournisseurs d’identité pris en charge dans les groupes d’utilisateurs Amazon Cognito.
En outre, pour les utilisateurs dans AWS IAM Identity Center, vous pouvez utiliser [Accès vérifié par AWS](https://docs.aws.amazon.com/verified-access/latest/ug/what-is-verified-access.html) pour fournir un niveau de sécurité supplémentaire en vérifiant l’identité de l’utilisateur et la position de l’appareil avant d’accorder l’accès aux ressources AWS.
Si vous utilisez des utilisateurs [Gestion des identités et des accès AWS (IAM)](https://aws.amazon.com/iam/), sécurisez le processus d’authentification à l’aide d’IAM.
Vous pouvez utiliser AWS IAM Identity Center et la fédération IAM directe simultanément pour gérer l’accès à AWS. Vous pouvez utiliser la fédération IAM pour gérer l’accès à la AWS Management Console et aux services et IAM Identity Center pour gérer l’accès aux applications professionnelles telles que Quick ou Amazon Q Business.
Quelle que soit la méthode de connexion, il est essentiel d’appliquer une politique de connexion rigoureuse.
### Étapes d’implémentation
Voici des recommandations générales pour la connexion. Les paramètres que vous configurez doivent être définis par la politique de votre entreprise ou suivre une norme telle que [NIST 800-63](https://pages.nist.gov/800-63-3/sp800-63b.html).
+ Require MFA (Demander l’authentification MFA). L’une des [bonnes pratiques IAM consiste à exiger l’authentification multifactorielle](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users) pour les identités humaines et les charges de travail. L’activation de l’authentification multifactorielle (MFA) fournit une couche de sécurité supplémentaire en exigeant que les utilisateurs fournissent des informations d’identification et un mot de passe unique (OTP) ou une chaîne de caractères générée et vérifiée cryptographiquement à partir d’un appareil physique.
+ Mettez en place une longueur de mot de passe minimale, il s’agit d’un facteur essentiel pour garantir la force du mot de passe.
+ Appliquez la complexité des mots de passe pour les rendre plus difficiles à deviner.
+ Autorisez les utilisateurs à modifier leurs propres mots de passe.
+ Créez des identités individuelles plutôt que des informations d’identification partagées. En créant des identités individuelles, vous pouvez attribuer à chaque utilisateur un ensemble unique d’informations d’identification de sécurité. Les utilisateurs individuels offrent la possibilité d’auditer l’activité de chaque utilisateur.
Recommandations pour IAM Identity Center :
+ IAM Identity Center fournit une [politique de gestion de mots de passe](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html) prédéfinie lors de l’utilisation du répertoire par défaut qui définit la longueur, la complexité et les exigences de réutilisation de mots de passe.
+ [Activez l’authentification multifactorielle (MFA)](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-enable-how-to.html) et configurez le paramètre contextuel ou permanent pour la MFA lorsque la source d’identité est le répertoire par défaut, AWS Managed Microsoft AD, ou AD Connector.
+ Permettez aux utilisateurs d’[enregistrer leurs propres appareils MFA](https://docs.aws.amazon.com/singlesignon/latest/userguide/how-to-allow-user-registration.html).
Recommandations pour le répertoire des groupes d’utilisateurs Amazon Cognito :
+ Configurez les paramètres de [sécurité du mot de passe](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html).
+ [Exiger l’authentification multifactorielle (MFA)](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html) pour les utilisateurs.
+ Utilisez les [paramètres de sécurité avancés](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-advanced-security.html) des groupes d’utilisateurs Amazon Cognito pour des fonctionnalités telles que l’[authentification adaptative](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-adaptive-authentication.html) qui permet de bloquer les connexions suspectes.
Recommandations pour les utilisateurs IAM :
+ Idéalement, vous utilisez IAM Identify Center ou la fédération directe. Cependant, vous aurez peut-être besoin des utilisateurs IAM. Dans ce cas, [définissez une politique de gestion de mots de passe](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) pour les utilisateurs IAM. Vous pouvez utiliser la politique de gestion de mots de passe pour définir des exigences telles que la longueur minimale ou la nécessité d’utiliser des caractères non alphabétiques.
+ Créez une politique IAM pour [appliquer la connexion l’authentification multifactorielle (MFA)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1) afin que les utilisateurs soient autorisés à gérer leurs propres mots de passe et appareils MFA.
## Ressources
**Bonnes pratiques associées :**
+ [SEC02-BP03 Stocker et utiliser des secrets en toute sécurité](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
+ [SEC02-BP04 S’appuyer sur un fournisseur d’identité centralisé](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP08 Partager des ressources en toute sécurité au sein de votre organisation](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**Documents connexes :**
+ [Politique de mot de passe AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html)
+ [Politique de mot de passe de l’utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [Définition du mot de passe de l’utilisateur racine du Compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
+ [Politique de mot de passe Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html)
+ [Informations d’identification AWS](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [Bonnes pratiques de sécurité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
**Vidéos connexes:**
+ [Gestion des autorisations des utilisateurs à grande échelle avec IAM Identity Center AWS](https://youtu.be/aEIqeFCcK7E)
+ [Maîtrise des identités dans chaque couche](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP02 Utiliser des informations d’identification temporaires
Lors de tout type d’authentification, il est préférable d’utiliser des informations d’identification temporaires plutôt que des informations d’identification à long terme afin de réduire ou d’éliminer les risques, tels que la divulgation, le partage ou le vol des informations d’identification par inadvertance.
**Résultat escompté :** pour réduire le risque d’informations d’identification à long terme, utilisez des informations d’identification temporaires dans la mesure du possible pour les identités humaines et les identités machine. Les informations d’identification à long terme créent de nombreux risques, tels que l’exposition par le biais de chargements dans des référentiels publics. En utilisant des informations d’identification temporaires, vous réduisez considérablement les risques de compromission de ces informations.
**Anti-modèles courants :**
+ Les développeurs utilisent des clés d’accès à long terme issues des utilisateur IAM au lieu d’obtenir des informations d’identification temporaires de la CLI à l’aide de la fédération.
+ Les développeurs intègrent des clés d’accès à long terme dans leur code et téléchargent ce code dans des référentiels Git publics.
+ Les développeurs intègrent des clés d’accès à long terme dans les applications mobiles qui sont ensuite disponibles dans les boutiques d’applications.
+ Les utilisateurs partagent des clés d’accès à long terme avec d’autres utilisateurs ou des employés quittent l’entreprise avec des clés d’accès à long terme toujours en leur possession.
+ Utilisation des clés d’accès à long terme pour les identités machine lorsque des informations d’identification temporaires peuvent être utilisées.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Utilisez des informations d’identification de sécurité temporaires plutôt que des informations d’identification à long terme pour toutes les demandes d’API et de CLI AWS. Les demandes d’API et de CLI adressées aux services AWS doivent, dans presque tous les cas, être signées à l’aide de [clés d’accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html). Ces demandes peuvent être signées avec des informations d’identification temporaires ou à long terme. Vous ne devez utiliser des informations d’identification à long terme, également appelées clés d’accès à long terme, que si vous utilisez un [utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) ou l’[utilisateur racine du Compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html). Lorsque vous vous fédérez vers AWS ou que vous assumez un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) par le biais d’autres méthodes, des informations d’identification temporaires sont générées. Même lorsque vous accédez à la AWS Management Console à l’aide des informations d’identification de connexion, des informations d’identification temporaires sont gérées pour vous permettre d’appeler les services AWS. Vous avez rarement besoin d’informations d’identification à long terme et vous pouvez accomplir presque toutes les tâches en utilisant des informations d’identification temporaires.
Privilégiez les informations d’identification temporaires plutôt que les informations d’identification à long terme et, parallèlement, mettez en place une stratégie de réduction des utilisateurs IAM au profit de la fédération et des rôles IAM. Bien que les utilisateurs IAM aient été employés pour les identités humaines et machine dans le passé, nous recommandons désormais de ne plus procéder ainsi afin d’éviter les risques liés à l’utilisation de clés d’accès à long terme.
### Étapes d’implémentation
#### Identités humaines
Pour les identités du personnel comme les employés, les administrateurs, les développeurs et les opérateurs :
+ Vous devez vous [compter sur un fournisseur d’identité](https://docs.aws.amazon.com//wellarchitected/latest/security-pillar/sec_identities_identity_provider.html) et [exiger des utilisateurs humains qu’ils utilisent la fédération avec un fournisseur d’identité pour accéder à AWS en utilisant des informations d’identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp). La fédération de vos utilisateurs peut se faire soit par une [fédération directe à chaque Compte AWS](https://aws.amazon.com/identity/federation/), soit en utilisant [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) et le fournisseur d’identité de votre choix. La fédération offre un certain nombre d’avantages par rapport aux utilisateurs IAM, outre l’élimination des informations d’identification à long terme. Vos utilisateurs peuvent également demander des informations d’identification temporaires depuis la ligne de commande pour une [fédération directe](https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/) ou en utilisant [IAM Identity Center](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html). Cela signifie que peu de cas d’utilisation nécessitent des utilisateurs IAM ou des informations d’identification à long terme pour vos utilisateurs.
Pour les identités tierces :
+ Lorsque vous accordez à des tiers, tels que des fournisseurs de logiciel en tant que service (SaaS), l’accès aux ressources de votre Compte AWS, vous pouvez utiliser des [rôles entre comptes](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) et des [politiques basées sur les ressources](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html). En outre, vous pouvez utiliser le flux d’informations d’identification client d’[octroi OAuth 2.0 Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/federation-endpoints-oauth-grants.html) pour les partenaires et clients SaaS B2B.
Pour les identités utilisateur qui accèdent à vos ressources AWS via des navigateurs Web, des applications client, des applications mobiles ou des outils de ligne de commande interactifs :
+ Si vous devez autoriser des demandes permettant aux consommateurs ou aux clients d’accéder à vos ressources AWS, vous pouvez utiliser les [groupes d’identités Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html) ou les [groupes d’utilisateurs Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) pour fournir des informations d’identification temporaires. Les autorisations pour ces informations d’identification sont configurées via des rôles IAM. Vous pouvez également définir un rôle IAM distinct avec des autorisations limitées pour les utilisateurs invités qui ne sont pas authentifiés.
#### Identités de machines
Pour les identités machine, vous devrez peut-être utiliser des informations d’identification à long terme. Dans ce cas, vous devez [exiger que les charges de travail utilisent des informations d’identification temporaires avec des rôles IAM pour accéder à AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles).
+ Pour [Amazon Elastic Compute Cloud](https://aws.amazon.com/pm/ec2/) (Amazon EC2), vous pouvez utiliser des [rôles pour Amazon EC2.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)
+ [AWS Lambda](https://aws.amazon.com/lambda/) vous permet de configurer un [rôle d’exécution Lambda pour accorder au service les autorisations nécessaires](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) pour effectuer des actions AWS à l’aide d’informations d’identification temporaires. Il existe de nombreux modèles similaires pour AWS permettre aux services d’octroyer des informations d’identification temporaires à l’aide des rôles IAM.
+ Pour les appareils IoT, vous pouvez utiliser le [fournisseur d’informations d’identification AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html) pour demander des informations d’identification temporaires.
+ Pour les systèmes sur site ou ceux qui s’exécutent en dehors d’AWS ces systèmes qui nécessitent un accès aux ressources AWS, vous pouvez utiliser [Rôles Anywhere IAM](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html).
Dans certains cas, les identifiants temporaires ne sont pas pris en charge et vous devez utiliser des informations d’identification à long terme. Dans ces cas, [contrôlez et effectuez régulièrement une rotation de ces informations d’identification](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html) et [effectuez régulièrement une rotation des clés d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials). Pour les clés d’accès d’utilisateurs IAM à l’accès très restreint, envisagez d’utiliser les mesures de sécurité supplémentaires suivantes :
+ Accordez des autorisations très restreintes :
+ Optez pour le principe du moindre privilège (soyez précis quant aux actions, aux ressources et aux conditions).
+ Envisagez d’accorder à l’utilisateur IAM uniquement l’opération AssumeRole pour un seul rôle spécifique. En fonction de l’architecture sur site, cette approche permet d’isoler et de sécuriser les informations d’identification IAM à long terme.
+ Limitez les sources réseau et les adresses IP autorisées dans la politique d’approbation de rôle IAM.
+ Surveillez l’utilisation et configurez des alertes pour des autorisations non utilisées ou abusives (à l’aide des filtres de métriques et des alarmes AWS CloudWatch Logs).
+ Appliquez des [limites d’autorisation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) (les politiques de contrôle des services (SCP) et les limites d’autorisation se complètent : les SCP sont grossières, tandis que les limites d’autorisation sont détaillées).
+ Mettez en œuvre un processus pour provisionner et stocker en toute sécurité (dans un coffre-fort sur site) les informations d’identification.
Autres options pour les scénarios nécessitant des informations d’identification à long terme :
+ Créez votre propre API de distribution de jetons (à l’aide d’Amazon API Gateway).
+ Dans les scénarios où vous devez utiliser des informations d’identification à long terme ou des informations d’identification autres que des clés d’accès AWS (telles que les connexions à la base de données), vous pouvez utiliser un service conçu pour gérer la gestion des secrets, tel qu’[AWS Secrets Manager](https://aws.amazon.com/secrets-manager/). Secrets Manager simplifie la gestion, la rotation et le stockage sécurisé des secrets chiffrés. De nombreux services AWS prennent en charge une [intégration directe](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html) avec Secrets Manager.
+ Pour les intégrations multicloud, vous pouvez utiliser la fédération d’identité en fonction des informations d’identification de votre fournisseur de services d’informations d’identification (CSP) source (voir [AWS STS AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)).
Pour plus d’informations sur la rotation des informations d’identification à long terme, veuillez consulter la rubrique [Rotation des clés d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey).
## Ressources
**Bonnes pratiques associées:**
+ [SEC02-BP03 Stocker et utiliser des secrets en toute sécurité](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
+ [SEC02-BP04 S’appuyer sur un fournisseur d’identité centralisé](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP08 Partager des ressources en toute sécurité au sein de votre organisation](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**Documents connexes:**
+ [Informations d’identification de sécurité temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [AWS Informations d’identification](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [Bonnes pratiques de sécurité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)
+ [IAM Identity Center](https://aws.amazon.com/iam/identity-center/)
+ [Fournisseurs d’identité et fédération](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Rotation des clés d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)
+ [Solutions partenaires de sécurité : accès et contrôle d’accès](https://aws.amazon.com/security/partner-solutions/#access-control)
+ [Utilisateur racine d’un compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
+ [Accès à AWS via une identité de charge de travail native de Google Cloud Platform](https://aws.amazon.com/blogs/security/access-aws-using-a-google-cloud-platform-native-workload-identity/)
+ [Comment accéder aux ressources AWS à partir de locataires Microsoft Entra ID à l’aide d’AWS Security Token Service](https://aws.amazon.com/blogs/security/how-to-access-aws-resources-from-microsoft-entra-id-tenants-using-aws-security-token-service/)
**Vidéos connexes:**
+ [Gestion des autorisations des utilisateurs à grande échelle avec IAM Identity Center AWS](https://youtu.be/aEIqeFCcK7E)
+ [Maîtrise des identités dans chaque couche](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP03 Stocker et utiliser des secrets en toute sécurité
Une charge de travail nécessite une capacité automatisée pour prouver son identité aux bases de données, aux ressources et aux services tiers. Cela se fait à l’aide d’informations d’identification d’accès secrets, tels que des clés d’accès à l’API, des mots de passe et des jetons OAuth. L’utilisation d’un service spécialement conçu pour stocker, gérer et faire tourner ces informations d’identification permet de réduire les risques de compromission de ces informations d’identification.
**Résultat escompté :** mise en œuvre d’un mécanisme de gestion sécurisée des informations d’identification des applications permettant d’atteindre les objectifs suivants :
+ Identification des secrets nécessaires pour la charge de travail.
+ Réduction du nombre d’informations d’identification à long terme requis, en les remplaçant par des informations d’identification à court terme dans la mesure du possible.
+ Établissement d’un stockage sécurisé et d’une rotation automatisée des informations d’identification à long terme restantes.
+ Audit de l’accès aux secrets qui existent dans la charge de travail.
+ Surveillance continue pour vérifier qu’aucun secret n’est intégré dans le code source pendant le processus de développement.
+ Réduction des risques de divulgation des informations d’identification par inadvertance.
**Anti-modèles courants :**
+ Aucune rotation des informations d’identification.
+ Stockage des informations d’identification à long terme dans le code source ou les fichiers de configuration.
+ Stockage des informations d’identification au repos non chiffrées.
**Avantages liés au respect de cette bonne pratique :**
+ Les secrets sont chiffrés au repos et en transit.
+ L’accès aux informations d’identification est bloqué par le biais d’une API (considérez-la comme un *distributeur automatique d’informations d’identification*).
+ L’accès à une information d’identification (en lecture et en écriture) est audité et consigné.
+ Séparation des préoccupations : la rotation des informations d’identification est effectuée par un composant distinct, qui peut être séparé du reste de l’architecture.
+ Les secrets sont distribués automatiquement à la demande aux composants logiciels et la rotation se produit dans un emplacement central.
+ L’accès aux informations d’identification peut être contrôlé de façon précise.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée** : élevé
## Directives d’implémentation
Dans le passé, les informations d’identification utilisées pour s’authentifier auprès des bases de données, des API tierces, des jetons et d’autres secrets pouvaient être intégrées dans du code source ou des fichiers d’environnement. AWS fournit plusieurs mécanismes pour stocker ces informations d’identification en toute sécurité, en effectuer la rotation automatiquement et vérifier leur utilisation.
Pour gérer les secrets de façon optimale, la meilleure solution consiste à suivre les directives de suppression, de remplacement et de rotation. Les informations d’identification les plus sûres sont celles que vous n’avez pas à stocker, gérer ou manipuler. Certaines informations d’identification qui ne sont plus nécessaires au fonctionnement de la charge de travail peuvent être supprimées en toute sécurité.
Pour les informations d’identification qui restent nécessaires au bon fonctionnement de la charge de travail, il peut être possible d’opter pour une solution temporaire ou à court terme au lieu d’utiliser des informations d’identification à long terme. Par exemple, au lieu du codage en dur une AWS clé d’accès secrète , envisagez de remplacer les informations d’identification à long terme par des informations d’identification temporaires à l’aide de rôles IAM.
Certains secrets de longue durée ne peuvent pas être supprimés ni remplacés. Ces secrets peuvent être stockés dans un service tel que [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html), où ils peuvent être stockés, gérés et subir une rotation de manière centralisée et régulière.
Un audit du code source et des fichiers de configuration de la charge de travail peut révéler de nombreux types d’informations d’identification. Le tableau suivant résume les stratégies de traitement des types courants d’informations d’identification :
| Type d’informations d’identification | Description | Stratégie suggérée |
| --- | --- | --- |
| Clés d’accès IAM | AWS Accès IAM et clés secrètes utilisés pour assumer des rôles IAM au sein d’une charge de travail | Remplacer : utilisez plutôt les [rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios.html) attribués aux instances de calcul (telles que [Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) ou [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)). Pour l’interopérabilité avec des tiers qui ont besoin d’accéder aux ressources de votre compteCompte AWS, demandez-leur s’ils proposent [AWS l’accès intercompte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html). Pour les applications mobiles, pensez à utiliser des informations d’identification temporaires via les groupes d’identités [Amazon Cognito (identités fédérées)](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html). Pour les charges de travail exécutées en dehors de AWS, pensez à [Rôles Anywhere IAM](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) ou à [AWS Systems Manager Hybrid Activations](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html). Pour les conteneurs, consultez le [rôle IAM de la tâche Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) ou le [rôle IAM du nœud Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html). |
| Clés SSH | Clés privées Secure shell utilisées pour se connecter aux instances Linux EC2, manuellement ou dans le cadre d’un processus automatisé | Remplacer : utilisez [AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) ou [EC2 Instance Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html) pour fournir un accès programmatique et humain aux instances EC2 à l’aide de rôles IAM. |
| Informations d’identification d’application et base de données | Mots de passe — chaîne de texte brut | Rotation : stockez les informations d’identification dans [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) et établissez une rotation automatique si possible. |
| Informations d’identification d’administration Amazon RDS et Amazon Aurora | Mots de passe — chaîne de texte brut | Remplacer : utilisez [l’intégration de Secrets Manager avec Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html) ou [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-secrets-manager.html). En outre, certains types de bases de données RDS peuvent utiliser des rôles IAM au lieu de mots de passe dans certains cas d’utilisation (pour plus de détails, voir [Authentification de base de données IAM](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html)). |
| Jetons OAuth | Jetons secrets — chaîne de texte brut | Rotation : stockez les jetons dans [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) et configurez la rotation automatique. |
| Jetons et clés API | Jetons secrets — chaîne de texte brut | Rotation : stockez dans [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) et établissez une rotation automatique si possible. |
Parmi les anti-modèles courants, citons l’intégration des clés d’accès IAM dans le code source, les fichiers de configuration ou les applications mobiles. Lorsqu’une clé d’accès IAM est requise pour communiquer avec un AWS service, utilisez des [informations d’identification de sécurité temporaires (à court terme)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html). Ces informations d’identification à court terme peuvent être fournies via [des rôles IAM pour les instances EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), des [rôles d’exécution](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) pour les fonctions Lambda, [des rôles IAM Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html) pour l’accès des utilisateurs mobiles et des [politiques IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policies.html) pour les appareils IoT. Lorsque vous interagissez avec des tiers, préférez la [délégation de l’accès à un rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) disposant de l’accès requis aux ressources de votre compte à la configuration d’un utilisateur IAM et à l’envoi au tiers de la clé d’accès secrète de cet utilisateur.
Dans de nombreux cas, la charge de travail nécessite le stockage des secrets nécessaires à l’interopérabilité avec d’autres services et ressources. [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) est spécialement conçu pour gérer en toute sécurité ces informations d’identification, ainsi que le stockage, l’utilisation et la rotation des jetons API, des mots de passe et d’autres informations d’identification.
AWS Secrets Manager fournit cinq fonctionnalités clés pour garantir le stockage et le traitement sécurisés des informations d’identification sensibles : [le chiffrement au repos](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html), [le chiffrement en transit](https://docs.aws.amazon.com/secretsmanager/latest/userguide/data-protection.html), [l’audit complet](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html), [le contrôle d’accès précis](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html) et [la rotation extensible des informations d’identification](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html). D’autres services de gestion des secrets créés par des AWS partenaires ou des solutions développées localement qui offrent des capacités et des assurances similaires sont également acceptables.
Lorsque vous récupérez un secret, vous pouvez utiliser les composants de mise en cache côté client de Secrets Manager pour le mettre en cache en vue d’une utilisation future. Il est plus rapide de récupérer un secret mis en cache que de le récupérer à partir de Secrets Manager. De plus, étant donné que l’appel des API Secrets Manager implique des coûts, l’utilisation d’un cache peut réduire vos coûts. Pour connaître toutes les manières dont vous pouvez récupérer des secrets, consultez [Obtenir des secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html).
**Note**
Certains langages peuvent vous obliger à implémenter votre propre chiffrement en mémoire pour la mise en cache côté client.
### Étapes d’implémentation
1. Identifiez les chemins de code contenant des informations d’identification codées en dur à l’aide d’outils automatisés tels qu’[Amazon CodeGuru](https://aws.amazon.com/codeguru/features/).
1. Utilisez Amazon CodeGuru pour analyser vos référentiels de code. Une fois l’examen terminé, filtrez sur Type=Secrets dans CodeGuru pour trouver les lignes de code problématiques.
1. Identifiez les informations d’identification qui peuvent être supprimées ou remplacées.
1. Identifiez les informations d’identification qui ne sont plus nécessaires et marquez-les en vue de leur suppression.
1. Pour les clés secrètes AWS qui sont intégrées au code source, remplacez-les par des rôles IAM associés aux ressources nécessaires. Si une partie de votre charge de travail est externe à AWS mais nécessite des informations d’identification IAM pour accéder aux ressources AWS, envisagez d’utiliser [Rôles Anywhere IAM](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/) ou des [activations hybrides AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html).
1. Pour les autres secrets tiers de longue durée qui nécessitent l’utilisation de la stratégie de rotation, intégrez Secrets Manager dans votre code afin d’extraire les secrets tiers au moment de l’exécution.
1. La console CodeGuru peut [créer automatiquement un secret dans Secrets Manager](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/) à l’aide des informations d’identification découvertes.
1. Intégrez l’extraction des secrets à partir de Secrets Manager dans votre code d’application.
1. Les fonctions Lambda sans serveur peuvent utiliser une [extension Lambda](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html) indépendante du langage.
1. Pour les instances ou les conteneurs EC2, AWS fournit un exemple de [code côté client permettant de récupérer des secrets à partir de Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) dans plusieurs langages de programmation courants.
1. Examinez régulièrement votre base de code et effectuez une nouvelle analyse afin de vérifier qu’aucun nouveau secret n’a été ajouté au code.
1. Envisagez l’utilisation d’un outil tel que [git-secrets](https://github.com/awslabs/git-secrets) pour éviter l’ajout de nouveaux secrets à votre dépôt de code source.
1. [Surveillez l’activité de Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html) pour détecter tout signe d’utilisation inattendue, d’accès secret inapproprié ou de tentative de suppression de secrets.
1. Réduisez l’exposition humaine aux informations d’identification. Limitez l’accès à la lecture, à l’écriture et à la modification des informations d’identification à un rôle IAM dédié à cette fin et fournissez un accès uniquement pour assumer le rôle à un petit sous-ensemble d’utilisateurs opérationnels.
## Ressources
**Bonnes pratiques associées :**
+ [SEC02-BP02 Utiliser des informations d’identification temporaires](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC02-BP05 Contrôler et effectuer régulièrement une rotation des informations d’identification](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html)
**Documents connexes :**
+ [Mise en route avec AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [Fournisseurs d’identité et fédération](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Amazon CodeGuru présente un détecteur de secrets](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/)
+ [Comment AWS Secrets Manager utilise-t-il AWS Key Management Service ?](https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html)
+ [Chiffrement et déchiffrement de secret dans Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)
+ [Entrées du journal de Secrets Manager](https://aws.amazon.com/blogs/security/tag/aws-secrets-manager/)
+ [Amazon RDS annonce l’intégration avec AWS Secrets Manager](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-rds-integration-aws-secrets-manager/)
**Vidéos connexes :**
+ [Bonnes pratiques de gestion, d’extraction et de renouvellement des secrets à grande échelle](https://youtu.be/qoxxRlwJKZ4)
+ [Trouvez des secrets codés en dur à l’aide du détecteur de secrets Amazon CodeGuru](https://www.youtube.com/watch?v=ryK3PN--oJs)
+ [Sécurisation des secrets des charges de travail hybrides à l’aide de AWS Secrets Manager](https://www.youtube.com/watch?v=k1YWhogGVF8)
**Ateliers connexes :**
+ [Stockez, récupérez et gérez les informations d’identification sensibles dans AWS Secrets Manager](https://catalog.us-east-1.prod.workshops.aws/workshops/92e466fd-bd95-4805-9f16-2df07450db42/en-US)
+ [Activations hybrides AWS Systems Manager](https://mng.workshop.aws/ssm/capability_hands-on_labs/hybridactivations.html)
# SEC02-BP04 S’appuyer sur un fournisseur d’identité centralisé
Pour les identités du personnel (employés et sous-traitants), faites confiance à un fournisseur d’identité qui vous permet de gérer les identités de manière centralisée. Cela facilite la gestion de l’accès entre plusieurs applications et systèmes, car vous créez, attribuez, gérez, révoquez et auditez l’accès depuis un seul emplacement.
**Résultat escompté :** vous disposez d’un fournisseur d’identité centralisé dans lequel vous gérez de manière centralisée les utilisateurs faisant partie du personnel, les politiques d’authentification (telles que l’exigence d’authentification multifactorielle (MFA)) et les autorisations accordées aux systèmes et aux applications (telles que l’attribution de l’accès en fonction de l’appartenance à un groupe ou des attributs d’un utilisateur). Les utilisateurs en interne se connectent au fournisseur d’identité central et se fédèrent (authentification unique) avec les applications internes et externes, ce qui leur évite d’avoir à mémoriser différentes informations d’identification. Votre fournisseur d’identité est intégré à vos systèmes de ressources humaines (RH) afin que les changements de personnel soient automatiquement synchronisés avec lui. Par exemple, si quelqu’un quitte votre organisation, vous pouvez automatiquement révoquer l’accès aux applications et systèmes fédérés (y compris AWS). Vous avez activé la journalisation détaillée des audits dans votre fournisseur d’identité et vous surveillez ces journaux pour détecter tout comportement inhabituel des utilisateurs.
**Anti-modèles courants :**
+ Vous n’utilisez pas la fédération ni l’authentification unique. Les utilisateurs en interne créent des comptes utilisateur et des informations d’identification distincts dans plusieurs applications et systèmes.
+ Vous n’avez pas automatisé le cycle de vie des identités pour les utilisateurs en interne, par exemple en intégrant votre fournisseur d’identité à vos systèmes RH. Lorsqu’un utilisateur quitte votre organisation ou change de rôle, vous suivez un processus manuel pour supprimer ou mettre à jour ses enregistrements dans plusieurs applications et systèmes.
**Avantages liés au respect de cette bonne pratique :** en utilisant un fournisseur d’identité centralisé, vous disposez d’un emplacement unique pour gérer les identités et les politiques des utilisateurs en interne, de la possibilité d’attribuer l’accès aux applications, aux utilisateurs et aux groupes, et de la capacité de surveiller l’activité de connexion des utilisateurs. Grâce à l’intégration du fournisseur d’identité dans vos systèmes de ressources humaines (RH), lorsqu’un utilisateur change de rôle, ces modifications sont synchronisées avec le fournisseur d’identité et mettent automatiquement à jour les applications et les autorisations qui lui ont été attribuées. Lorsqu’un utilisateur quitte votre organisation, son identité est automatiquement désactivée dans le fournisseur d’identité, révoquant ainsi son accès aux applications et systèmes fédérés.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée** : élevé
## Directives d’implémentation
**Conseils pour les utilisateurs en interne accédant à AWS** Les utilisateurs en interne, tels que les employés et les sous-traitants de votre organisation, peuvent avoir besoin d’accéder à AWS avec la AWS Management Console ou l’AWS Command Line Interface (AWS CLI) pour exécuter leurs tâches. Vous pouvez accorder l’accès AWS aux utilisateurs en interne en les fédérant avec AWS à deux niveaux à partir de votre fournisseur d’identité centralisé : fédération directe vers chaque Compte AWS ou fédération vers plusieurs comptes dans [ votre organisation AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html).
Pour fédérer les utilisateurs en interne directement avec chaque Compte AWS, vous pouvez utiliser un fournisseur d’identité centralisé afin de les fédérer à [Gestion des identités et des accès AWS](https://aws.amazon.com/iam/) dans ce compte. La flexibilité d’IAM vous permet d’activer un fournisseur d’identité [SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) ou [Open ID Connect (OIDC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) distinct pour chaque Compte AWS et d’utiliser des attributs d’utilisateur fédéré pour le contrôle d’accès. Les utilisateurs en interne utiliseront leur navigateur Web pour se connecter au fournisseur d’identité en indiquant leurs informations d’identification (telles que des mots de passe et des codes de jeton MFA). Le fournisseur d’identité enverra à son navigateur une assertion SAML soumise à l’URL de connexion de la AWS Management Console pour permettre à l’utilisateur de s’authentifier de manière unique auprès de la [AWS Management Console en assumant un rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html). Vos utilisateurs peuvent également obtenir des informations d’identification d’API AWS temporaires à utiliser dans le [AWS CLI](https://aws.amazon.com/cli/) ou [AWS les SDK](https://aws.amazon.com/developer/tools/) à partir de [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) en [assumant le rôle IAM à l’aide d’une assertion SAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) du fournisseur d’identité.
Pour fédérer vos utilisateurs en interne avec plusieurs comptes dans votre organisation AWS, vous pouvez utiliser [https://aws.amazon.com/single-sign-on/](https://aws.amazon.com/single-sign-on/) pour gérer de manière centralisée l’accès des utilisateurs en interne aux Comptes AWS et aux applications. Vous activez Identity Center pour votre organisation et configurez votre source d’identité. IAM Identity Center fournit un répertoire de sources d’identité par défaut que vous pouvez utiliser pour gérer vos utilisateurs et vos groupes. Vous pouvez également choisir une source d’identité externe en vous [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) à l’aide de SAML 2.0 et en [provisionnant automatiquement](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html) les utilisateurs et les groupes à l’aide de SCIM, ou en [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html) à l’aide de [Directory Service](https://aws.amazon.com/directoryservice/). Une fois qu’une source d’identité est configurée, vous pouvez attribuer aux utilisateurs et aux groupes l’accès aux Comptes AWS en définissant des politiques de moindre privilège dans vos [ensembles d’autorisation](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html). Les utilisateurs de votre personnel peuvent s’authentifier par l’intermédiaire de votre fournisseur d’identité central pour se connecter au [portail d’accès AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-the-portal.html) et ouvrir une session unique dans le Comptes AWS et les applications cloud qui leur sont attribuées. Vos utilisateurs peuvent configurer la [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) pour s’authentifier auprès d’Identity Center et obtenir des informations d’identification pour exécuter des commandes AWS CLI. Identity Center permet également l’accès par authentification unique aux applications AWS telles qu'[Amazon SageMaker AI Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/onboard-sso-users.html) et [les portails AWS IoT Sitewise Monitor](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/monitor-getting-started.html).
Une fois que vous aurez suivi les instructions précédentes, vos utilisateurs en interne n’auront plus besoin d’utiliser des utilisateur IAM et des groupes pour les opérations normales lors de la gestion des charges de travail sur AWS. Au lieu de cela, vos utilisateurs et vos groupes sont gérés en dehors de AWS et les utilisateurs peuvent accéder aux ressources AWS sous la forme d’une *identité fédérée*. Les identités fédérées utilisent les groupes définis par votre fournisseur d’identité centralisé. Vous devez identifier et supprimer les groupes IAM, les utilisateur IAM et les informations d’identification utilisateur de longue durée (mots de passe et clés d’accès) dont vous n’avez plus besoin dans vos Comptes AWS. Vous pouvez [trouver les informations d’identification non utilisées](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) à l’aide de [rapports d’informations d’identification IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html), [supprimer les utilisateurs IAM correspondants](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html) et [supprimer les groupes IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html). Vous pouvez appliquer une [Politique de contrôle des services (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) à votre organisation afin d’empêcher la création de nouveaux utilisateurs IAM et groupes, en renforçant cet accès à AWS via des identités fédérées.
**Note**
Vous êtes responsable de la gestion de la rotation des jetons d’accès SCIM, comme décrit dans la documentation relative au [provisionnement automatique](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html). En outre, vous êtes responsable de la rotation des certificats prenant en charge votre fédération d’identité.
**Conseils pour les utilisateurs de vos applications** Vous pouvez gérer les identités des utilisateurs de vos applications, telles qu’une application mobile, en utilisant [https://aws.amazon.com/cognito/](https://aws.amazon.com/cognito/) comme fournisseur d’identité centralisé. Amazon Cognito assure l’authentification, l’autorisation et la gestion des utilisateurs pour vos applications Web et mobiles. Amazon Cognito fournit une banque d’identités adaptée à des millions d’utilisateurs, prend en charge la fédération d’identité sociale de l’entreprise et propose des fonctionnalités de sécurité avancées pour protéger vos utilisateurs et votre entreprise. Vous pouvez intégrer votre application Web ou mobile personnalisée avec Amazon Cognito pour ajouter l’authentification des utilisateurs et le contrôle d’accès à vos applications en quelques minutes. Fondé sur des normes d’identité ouvertes telles que SAML et OpenID Connect (OIDC), Amazon Cognito prend en charge diverses réglementations de conformité et s’intègre aux ressources de développement front-end et dorsal.
### Étapes d’implémentation
**Étapes à suivre pour permettre aux utilisateurs en interne d’accéder à AWS**
+ Fédérez les utilisateurs en interne à AWS à l’aide d’un fournisseur d’identité centralisé en utilisant l’une des approches suivantes :
+ Utilisez IAM Identity Center pour activer l’authentification unique à plusieurs Comptes AWS dans votre organisation AWS en vous fédérant avec votre fournisseur d’identité.
+ Utilisez IAM pour connecter votre fournisseur d’identité directement à chaque Compte AWS, afin de permettre un accès fédéré précis.
+ Identifiez et supprimez les utilisateurs IAM et les groupes qui seront remplacés par des identités fédérées.
**Étapes à suivre pour les utilisateurs de vos applications**
+ Utilisez Amazon Cognito comme fournisseur d’identité centralisé pour vos applications.
+ Intégrez vos applications personnalisées à Amazon Cognito à l’aide d’OpenID Connect et d’OAuth. Vous pouvez développer vos applications personnalisées à l’aide des bibliothèques Amplify qui fournissent des interfaces simples à intégrer à divers services AWS, tels que Amazon Cognito pour l’authentification.
## Ressources
**Bonnes pratiques associées :**
+ [SEC02-BP06 Utiliser des groupes d’utilisateurs et des attributs](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_groups_attributes.html)
+ [SEC03-BP02 Accorder un accès selon le principe du moindre privilège](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)
+ [SEC03-BP06 Gérer l’accès en fonction du cycle de vie](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
**Documents connexes :**
+ [Fédération d’identité dans AWS](https://aws.amazon.com/identity/federation/)
+ [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [ Bonnes pratiques Gestion des identités et des accès AWS](https://aws.amazon.com/iam/resources/best-practices/)
+ [Mise en route avec l’administration déléguée d’IAM Identity Center](https://aws.amazon.com/blogs/security/getting-started-with-aws-sso-delegated-administration/)
+ [Comment utiliser les politiques gérées par le client dans IAM Identity Center pour les cas d’utilisation avancés](https://aws.amazon.com/blogs/security/how-to-use-customer-managed-policies-in-aws-single-sign-on-for-advanced-use-cases/)
+ [AWS CLI v2 : fournisseur d’informations d’identification IAM Identity Center](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sso-credentials.html)
**Vidéos connexes :**
+ [AWS re:Inforce 2022 - Gestion des identités et des accès AWS (IAM) deep dive](https://youtu.be/YMj33ToS8cI)
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Invent 2018: Mastering Identity at Every Layer of the Cake](https://youtu.be/vbjFjMNVEpc)
**Exemples connexes :**
+ [Atelier : utilisation d’AWS IAM Identity Center pour assurer une gestion forte des identités](https://catalog.us-east-1.prod.workshops.aws/workshops/590f8439-42c7-46a1-8e70-28ee41498b3a/en-US)
**Outils associés :**
+ [AWS Partenaires disposant de la compétence Sécurité : gestion des identités et des accès](https://aws.amazon.com/security/partner-solutions/)
+ [saml2aws](https://github.com/Versent/saml2aws)
# SEC02-BP05 Contrôler et effectuer régulièrement une rotation des informations d’identification
Contrôlez et effectuez régulièrement une rotation des informations d’identification afin de limiter leur durée d’utilisation pour accéder à vos ressources. Les informations d’identification à long terme créent de nombreux risques, et ces risques peuvent être réduits par une rotation régulière de ces informations.
**Résultat souhaité :** mettez en œuvre la rotation des informations d’identification afin de réduire les risques associés à l’utilisation à long terme des informations d’identification. Auditez et corrigez régulièrement toute non-conformité avec les politiques de rotation des informations d’identification.
**Anti-modèles courants :**
+ Ne pas auditer l’utilisation des informations d’identification.
+ Utiliser inutilement des informations d’identification à long terme.
+ Utiliser des informations d’identification à long terme et ne pas effectuer de rotation régulièrement.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Lorsque vous ne pouvez pas compter sur des informations d’identification temporaires et que vous avez besoin d’informations d’identification à long terme, auditez les informations d’identification pour vous assurer que les contrôles définis tels que [l’authentification multifactorielle](https://aws.amazon.com/iam/features/mfa/) (MFA) sont appliqués, qu’ils font l’objet d’une rotation régulière et qu’ils ont le niveau d’accès approprié.
La validation régulière, de préférence via un outil automatisé, est nécessaire pour vérifier que les contrôles corrects sont appliqués. Pour les identités humaines, vous devez obliger les utilisateurs à modifier leurs mots de passe régulièrement et à mettre hors service les clés d’accès au profit d’informations d’identification temporaires. Lorsque vous passez des utilisateurs Gestion des identités et des accès AWS (IAM) aux identités centralisées, vous pouvez [générer un rapport d’informations d’identification](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) pour auditer vos utilisateurs.
Nous vous recommandons également d’appliquer les paramètres d’authentification multifactorielle dans votre fournisseur d’identité. Vous pouvez configurer [AWS Config Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) ou utiliser des [normes de sécurité AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-iam-3) pour vérifier si les utilisateurs ont configuré l’authentification multifactorielle. Envisagez d’utiliser [Rôles Anywhere IAM](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) afin de fournir des informations d’identification temporaires pour les identités des machines. Lorsque l’utilisation de rôles IAM et d’informations d’identification temporaires n’est pas possible, il est nécessaire de réaliser fréquemment des audits et la rotation des clés d’accès.
### Étapes d’implémentation
+ **Audit fréquent des informations d’identification :** l’audit des identités configurées dans votre fournisseur d’identités et dans IAM aide à garantir que seules les identités autorisées ont accès à votre charge de travail. Ces identités peuvent inclure, sans s’y limiter, des utilisateurs IAM, des utilisateurs AWS IAM Identity Center, des utilisateurs Active Directory ou des utilisateurs dans un autre fournisseur d’identité en amont. Par exemple, supprimez les personnes qui quittent l’organisation et supprimez les rôles inter-comptes qui ne sont plus requis. Mettez en place un processus pour auditer périodiquement les autorisations aux services auxquels accède une entité IAM. Cela vous permet d’identifier les politiques à modifier afin de supprimer les autorisations inutilisées. Utilisez les rapports d’informations d’identification et [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) pour auditer les informations d’identification et les autorisations IAM. Vous pouvez utiliser [Amazon CloudWatch pour configurer des alarmes pour des appels d’API spécifiques](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html) appelés dans votre environnement AWS. [Amazon GuardDuty peut également vous avertir en cas d’activité inattendue](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html), qui peut indiquer un accès trop permissif ou un accès involontaire aux informations d’identification IAM.
+ **Rotation régulière des informations d’identification :** lorsque vous ne pouvez pas utiliser d’informations d’identification temporaires, alternez régulièrement les clés d’accès IAM à long terme (au maximum tous les 90 jours). Si une clé d’accès est divulguée involontairement à votre insu, cela limite la durée pendant laquelle les informations d’identification peuvent être utilisées pour accéder à vos ressources. Pour plus d’informations sur la rotation des clés d’accès pour les utilisateurs IAM, consultez la rubrique [Rotation des clés d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey).
+ **Examiner les permissions IAM :** pour améliorer la sécurité de votre Compte AWS, examinez et surveillez régulièrement chacune de vos politiques IAM. Vérifiez que les politiques respectent le principe du moindre privilège.
+ **Envisagez d’automatiser la création et la mise à jour des ressources IAM :** [IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) automatise de nombreuses tâches IAM, telles que la gestion des rôles et des politiques. Sinon, AWS CloudFormation peut être utilisé afin d’automatiser le déploiement des ressources IAM, y compris les rôles et les politiques, afin de réduire le risque d’erreur humaine, car les modèles peuvent être vérifiés et la version contrôlée.
+ **Utilisez Rôles Anywhere IAM pour remplacer les utilisateurs IAM par des identités de machines :** [Rôles Anywhere IAM](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) vous permet d’utiliser des rôles dans des domaines que vous ne pouviez pas utiliser auparavant, tels que les serveurs sur site. Rôles Anywhere IAM utilise un [certificat X.509](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/trust-model.html#signature-verification) approuvé afin de s’authentifier auprès d’AWS et de recevoir des informations d’identification temporaires. L’utilisation de Rôles Anywhere IAM vous évite d’avoir à effectuer des rotations de ces informations d’identification, car les informations d’identification à long terme ne sont plus stockées dans votre environnement sur site. Veuillez noter que vous devrez surveiller et faire tourner le certificat X.509 à l’approche de son expiration.
## Ressources
**Bonnes pratiques associées :**
+ [SEC02-BP02 Utiliser des informations d’identification temporaires](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC02-BP03 Stocker et utiliser des secrets en toute sécurité](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
**Documents connexes :**
+ [Mise en route avec AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [Bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Fournisseurs d’identité et fédération](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Solutions partenaires de sécurité : accès et contrôle d’accès](https://aws.amazon.com/security/partner-solutions/#access-control)
+ [Informations d’identification de sécurité temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [Obtention de rapports d’informations d’identification pour votre Compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)
**Vidéos connexes :**
+ [Bonnes pratiques de gestion, d’extraction et de renouvellement des secrets à grande échelle](https://youtu.be/qoxxRlwJKZ4)
+ [Gestion des autorisations des utilisateurs à grande échelle avec IAM Identity Center AWS](https://youtu.be/aEIqeFCcK7E)
+ [Maîtrise des identités dans chaque couche](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP06 Utiliser des groupes d’utilisateurs et des attributs
La définition des autorisations en fonction des groupes d’utilisateurs et des attributs contribue à réduire le nombre et la complexité des politiques, ce qui simplifie la mise en œuvre du principe du moindre privilège. Vous pouvez utiliser des groupes d’utilisateurs pour gérer les autorisations de nombreuses personnes en un seul endroit selon la fonction qu’elles occupent au sein de votre organisation. Les attributs, tels que le service, le projet ou l’emplacement, peuvent fournir une couche supplémentaire de portée des autorisations lorsque des personnes occupent une fonction similaire, mais pour des sous-ensembles de ressources différents.
**Résultat escompté :** vous pouvez appliquer des modifications aux autorisations selon la fonction de tous les utilisateurs qui exécutent cette fonction. L’appartenance aux groupes et les attributs régissent les autorisations des utilisateurs, ce qui réduit la nécessité de gérer les autorisations au niveau de chaque utilisateur. Les groupes et les attributs que vous définissez dans votre fournisseur d’identité (IdP) sont propagés automatiquement à vos environnements AWS.
**Anti-modèles courants :**
+ Gestion des autorisations pour les utilisateurs individuels et duplication entre de nombreux utilisateurs.
+ Définition de groupes à un niveau trop élevé, autorisations trop étendues accordées.
+ Définition de groupes à un niveau trop détaillé, ce qui crée des duplications et de la confusion quant à l’appartenance.
+ Utilisation de groupes avec des autorisations dupliquées sur des sous-ensembles de ressources lorsque des attributs peuvent être utilisés à la place.
+ Aucune gestion de groupes, d’attributs et d’appartenances par le biais d’un fournisseur d’identité standardisé intégré à vos environnements AWS.
+ Utilisation du chaînage des rôles lors de l’utilisation de sessions AWS IAM Identity Center
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Les autorisations AWS sont définies dans des documents appelés *politiques*, qui sont associés à un principal, tel qu’un utilisateur, un groupe, un rôle ou une ressource. Vous pouvez mettre à l’échelle la gestion des autorisations en organisant les attributions d’autorisations (groupe, autorisations, compte) en fonction de la fonction, de la charge de travail et de l’environnement SDLC. En ce qui concerne le personnel, cela vous permet de définir des groupes selon la fonction occupée par les utilisateurs au sein de votre organisation, plutôt que selon les ressources auxquelles ils accèdent. Par exemple, un groupe WebAppDeveloper peut être associé à une politique pour configurer des services tels qu’Amazon CloudFront au sein d’un compte de développement. Un groupe `AutomationDeveloper` peut avoir des autorisations qui se chevauchent avec le groupe `WebAppDeveloper`. Ces autorisations communes peuvent être saisies dans une politique distincte et associées aux deux groupes, au lieu de faire en sorte que les utilisateurs des deux fonctions appartiennent à un groupe `CloudFrontAccess`.
Outre les groupes, vous pouvez utiliser des *attributs* pour élargir l’accès. Par exemple, vous pouvez avoir un attribut de projet permettant aux utilisateurs de votre groupe `WebAppDeveloper` de définir l’accès aux ressources spécifiques à leur projet. L’utilisation de cette technique élimine la nécessité de créer différents groupes pour les développeurs d’applications qui travaillent sur différents projets si leurs autorisations sont par ailleurs les mêmes. La façon dont vous faites référence aux attributs dans les politiques d’autorisation dépend de leur source, qu’ils soient définis dans le cadre de votre protocole de fédération (tel que SAML, OIDC ou SCIM), en tant qu’assertions SAML personnalisées ou définis dans le cadre d’IAM Identity Center.
### Étapes d’implémentation
1. Déterminez où vous allez définir les groupes et les attributs :
1. En suivant les instructions fournies dans [SEC02-BP04 S’appuyer sur un fournisseur d’identité centralisé](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html), vous pouvez déterminer si vous devez définir des groupes et des attributs au sein de votre fournisseur d’identité, dans IAM Identity Center ou utiliser des groupes d’utilisateurs IAM dans un compte spécifique.
1. Définissez des groupes :
1. Déterminez vos groupes selon la fonction et la portée de l’accès requis. Envisagez d’utiliser une structure hiérarchique ou des conventions de dénomination pour organiser efficacement les groupes.
1. Si vous optez pour une définition au sein d’IAM Identity Center, créez des groupes et associez le niveau d’accès souhaité à l’aide d’ensembles d’autorisations.
1. Si vous optez pour une définition au sein d’un fournisseur d’identité externe, déterminez si le fournisseur prend en charge le protocole SCIM et envisagez d’activer le provisionnement automatique au sein d’IAM Identity Center. Cette capacité synchronise la création, l’appartenance et la suppression de groupes entre votre fournisseur et IAM Identity Center.
1. Définissez des attributs :
1. Si vous utilisez un fournisseur d’identité externe, les protocoles SCIM et SAML 2.0 fournissent certains attributs par défaut. Des attributs supplémentaires peuvent être définis et transmis à l’aide d’assertions SAML utilisant le nom de l’attribut `https://aws.amazon.com/SAML/Attributes/PrincipalTag`. Consultez la documentation de votre fournisseur d’identité pour obtenir des recommandations quant à la définition et la configuration d’attributs personnalisés.
1. Si vous définissez des rôles dans IAM Identity Center, activez la fonctionnalité de contrôle d’accès par attributs (ABAC) et définissez les attributs comme vous le souhaitez. Tenez compte des attributs qui correspondent à la stratégie de balisage des ressources ou à la structure de votre organisation.
Si vous avez besoin d’un chaînage des rôles IAM à partir des rôles IAM assumés via IAM Identity Center, les valeurs telles que `source-identity` et `principal-tags` ne se propagent pas. Pour plus de détails, consultez [Activer et configurer les attributs pour le contrôle d’accès](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html).
1. Déterminez la portée des autorisations en fonction des groupes et des attributs :
1. Envisagez d’inclure dans vos politiques d’autorisation des conditions qui comparent les attributs de votre principal à ceux des ressources auxquelles vous accédez. Par exemple, vous pouvez définir une condition pour autoriser l’accès à une ressource uniquement si la valeur d’une clé de condition `PrincipalTag` correspond à la valeur d’une clé `ResourceTag` du même nom.
1. Lorsque vous définissez des politiques ABAC, suivez les instructions figurant dans les bonnes pratiques et les exemples relatifs à l’[autorisation ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html).
1. Passez régulièrement en revue et mettez à jour la structure de votre groupe et de vos attributs au fur et à mesure de l’évolution des besoins de votre organisation afin de garantir une gestion optimale des autorisations.
## Ressources
**Bonnes pratiques associées :**
+ [SEC02-BP04 S’appuyer sur un fournisseur d’identité centralisé](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP02 Accorder un accès selon le principe du moindre privilège](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)
+ [COST02-BP04 Mettre en œuvre des groupes et des rôles](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_groups_roles.html)
**Documents connexes :**
+ [Bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Gestion des identités dans IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [Qu’est-ce que le contrôle d’accès par attributs (ABAC) pour AWS ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [Contrôle d’accès par attributs (ABAC) dans IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)
+ [Exemples de politique ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_abac.html)
**Vidéos connexes :**
+ [Gestion des autorisations des utilisateurs à grande échelle avec IAM Identity Center AWS](https://youtu.be/aEIqeFCcK7E)
+ [Maîtrise des identités dans chaque couche](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SÉC 3. Comment gérer les autorisations des personnes et des machines ?
Gérez les autorisations des identités humaines et machines qui nécessitent un accès à AWS ainsi qu’à votre charge de travail. Les autorisations vous permettent de contrôler qui peut accéder à quoi et dans quelles conditions. En définissant des autorisations pour des identités humaines et des identités de machines spécifiques, vous leur donnez accès à des actions de service spécifiques sur des ressources spécifiques. En outre, vous pouvez spécifier les conditions qui doivent être remplies pour que l’accès soit accordé.
**Topics**
+ [SEC03-BP01 Définir les conditions d’accès](sec_permissions_define.md)
+ [SEC03-BP02 Accorder un accès selon le principe du moindre privilège](sec_permissions_least_privileges.md)
+ [SEC03-BP03 Établir un processus d’accès d’urgence](sec_permissions_emergency_process.md)
+ [SEC03-BP04 Limiter les autorisations au minimum requis en permanence](sec_permissions_continuous_reduction.md)
+ [SEC03-BP05 Définir des barrières de protection des autorisations de votre organisation](sec_permissions_define_guardrails.md)
+ [SEC03-BP06 Gérer l’accès en fonction du cycle de vie](sec_permissions_lifecycle.md)
+ [SEC03-BP07 Analyser l’accès public et intercompte](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP08 Partager des ressources en toute sécurité au sein de votre organisation](sec_permissions_share_securely.md)
+ [SEC03-BP09 Partager des ressources en toute sécurité avec un tiers](sec_permissions_share_securely_third_party.md)
# SEC03-BP01 Définir les conditions d’accès
Chaque composant ou ressource de votre charge de travail doit être accessible aux administrateurs, aux utilisateurs finaux ou à d’autres composants. Définissez clairement qui ou quoi doit avoir accès à chaque composant, choisissez le type d’identité approprié et la méthode d’authentification et d’autorisation.
**Anti-modèles courants :**
+ Codage en dur ou stockage de secrets dans votre application.
+ Octroi d’autorisations personnalisées à chaque utilisateur.
+ Utilisation d’informations d’identification durables.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Chaque composant ou ressource de votre charge de travail doit être accessible aux administrateurs, aux utilisateurs finaux ou à d’autres composants. Définissez clairement qui ou quoi doit avoir accès à chaque composant, choisissez le type d’identité approprié et la méthode d’authentification et d’autorisation.
L’accès régulier à Comptes AWS au sein d’une organisation doit être assuré par un [accès fédéré](https://aws.amazon.com/identity/federation/) ou un fournisseur d’identité centralisé. Vous devez également centraliser la gestion des identités et vous assurer qu’il existe une pratique établie pour intégrer l’accès à AWS au cycle de vie de l’accès des employés. Par exemple, lorsqu’un employé change de poste et de niveau d’accès, son appartenance à un groupe doit également évoluer de façon à refléter les nouvelles conditions d’accès qui lui sont associées.
Lorsque vous définissez des conditions d’accès pour des identités non humaines, déterminez quels applications et composants ont besoin d’un accès et comment les autorisations sont accordées. Dans cette optique, il est recommandé d’utiliser les rôles IAM créés avec le modèle d’accès du moindre privilège. [AWS Les stratégies gérées](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) établissent des politiques IAM prédéfinies qui couvrent les cas d’utilisation les plus courants.
Les services AWS, tels que [AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) et [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html), peuvent aider à dissocier les secrets de l’application ou de la charge de travail en toute sécurité. Dans Secrets Manager, vous pouvez établir une rotation automatique de vos informations d’identification. Vous pouvez utiliser Systems Manager de façon à référencer les paramètres dans vos scripts, commandes, documents SSM, configuration et flux de travail d’automatisation en utilisant le nom unique que vous avez spécifié lors de la création du paramètre.
Vous pouvez utiliser [Rôles Anywhere AWS IAM](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) pour obtenir des [informations d’identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) pour les charges de travail qui s’exécutent en dehors d’AWS. Vos charges de travail peuvent utiliser les mêmes [politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) et [rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que ceux que vous utilisez avec les applications AWS pour accéder aux ressources AWS.
Dans la mesure du possible, privilégiez les informations d’identification temporaires à court terme plutôt que les informations d’identification statiques à long terme. Pour les scénarios dans lesquels vous avez besoin d’utilisateurs qui disposent d’un accès par programmation et d’informations d’identification à long terme, utilisez les [informations les plus récentes de la clé d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) pour faire pivoter et supprimer les clés d’accès.
Les utilisateurs ont besoin d’un accès programmatique s’ils souhaitent interagir avec AWS en dehors de la AWS Management Console. La manière d’octroyer un accès par programmation dépend du type d’utilisateur qui accède à AWS.
Pour accorder aux utilisateurs un accès programmatique, choisissez l’une des options suivantes.
****
| Quel utilisateur a besoin d’un accès programmatique ? | Pour | Méthode |
| --- | --- | --- |
| IAM | (Recommandé) Utilisez des informations d’identification de la console temporaires pour signer des demandes par programmation destinées à la AWS CLI, aux kits AWS SDK ou aux API AWS. | Suivez les instructions de l’interface que vous souhaitez utiliser. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/framework/sec_permissions_define.html) |
| Identité de la main-d’œuvre (Utilisateurs gérés dans IAM Identity Center) | Utilisez des informations d’identification temporaires pour signer des demandes par programmation destinées à la AWS CLI, aux AWS SDK ou aux API AWS. | Suivez les instructions de l’interface que vous souhaitez utiliser. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/framework/sec_permissions_define.html) |
| IAM | Utilisez des informations d’identification temporaires pour signer des demandes par programmation destinées à la AWS CLI, aux AWS SDK ou aux API AWS. | Suivez les instructions de la section [Utilisation d’informations d’identification temporaires avec des ressources AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html) dans le Guide de l’utilisateur IAM. |
| IAM | (Non recommandé)Utilisez des informations d’identification à long terme pour signer des demandes par programmation destinées à la AWS CLI, aux AWS SDK ou aux API AWS. | Suivez les instructions de l’interface que vous souhaitez utiliser. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/framework/sec_permissions_define.html) |
## Ressources
**Documents connexes:**
+ [Contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/)
+ [Rôles Anywhere IAM](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)
+ [AWS Politiques gérées par pour IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)
+ [AWS Conditions des politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)
+ [Cas d’utilisation de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html)
+ [Supprimer les informations d’identification inutiles](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [Utilisation des stratégies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [Comment contrôler l’accès aux ressources AWS basées sur Compte AWS, OU, ou l’organisation](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/)
+ [Identifiez, organisez, et gérez les secrets de manière simple au travers de la recherche avancée dans AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/)
**Vidéos connexes:**
+ [Become an IAM Policy Master in 60 Minutes or Less](https://youtu.be/YQsK4MtsELU)
+ [Separation of Duties, Least Privilege, Delegation, and CI/CD](https://youtu.be/3H0i7VyTu70)
+ [Streamlining identity and access management for innovation](https://www.youtube.com/watch?v=3qK0b1UkaE8)
# SEC03-BP02 Accorder un accès selon le principe du moindre privilège
Accordez uniquement l’accès dont les utilisateurs ont besoin pour effectuer des actions spécifiques sur des ressources spécifiques dans des conditions spécifiques. Faites appel à des groupes et des attributs d’identité pour définir de façon dynamique des autorisations à grande échelle, plutôt que pour des utilisateurs individuels. Par exemple, vous pouvez autoriser un groupe de développeurs à gérer uniquement les ressources de leur projet. Ainsi, si un développeur quitte le projet, son accès est automatiquement révoqué sans que les stratégies d’accès sous-jacentes soient modifiées.
**Résultat escompté :** les utilisateurs ne disposent que des autorisations minimales requises pour leurs fonctions professionnelles spécifiques. Vous utilisez des Comptes AWS séparés pour isoler les développeurs des environnements de production. Lorsque les développeurs ont besoin d’accéder à des environnements de production pour des tâches spécifiques, un accès limité et contrôlé leur est accordé seulement pour la durée de ces tâches. Leur accès en production est immédiatement révoqué une fois qu’ils ont terminé les travaux nécessaires. Vous révisez régulièrement les autorisations et vous les révoquez rapidement lorsqu’elles ne sont plus nécessaires, par exemple lorsqu’un utilisateur change de rôle ou quitte l’organisation. Vous limitez les privilèges d’administrateur à un petit groupe de confiance afin de réduire l’exposition aux risques. Vous accordez aux comptes de machines ou de systèmes uniquement les autorisations minimales requises pour effectuer les tâches prévues.
**Anti-modèles courants :**
+ Par défaut, vous accordez des autorisations d’administrateur aux utilisateurs.
+ Vous utilisez le compte d’utilisateur racine pour les activités quotidiennes.
+ Vous créez des politiques trop permissives sans les délimiter correctement.
+ Vos révisions d’autorisations sont peu fréquentes, ce qui entraîne des dérives.
+ Vous vous appuyez uniquement sur un contrôle d’accès basé sur les attributs pour l’isolation de l’environnement ou la gestion des autorisations.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Le principe du [moindre privilège](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) stipule que les identités ne devraient être autorisées à effectuer que le plus petit ensemble d’actions nécessaires pour accomplir une tâche spécifique. Il permet d’atteindre un équilibre entre la convivialité, l’efficacité et la sécurité. Le respect de ce principe permet de limiter l’accès non intentionnel et de déterminer qui a accès aux ressources. Les utilisateurs et les rôles IAM ne disposent d’aucune autorisation. L’utilisateur racine dispose d’un accès complet par défaut et doit être étroitement contrôlé, surveillé et utilisé uniquement pour les [tâches nécessitant un accès racine](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html).
Les politiques IAM sont utilisées pour octroyer explicitement des autorisations aux rôles IAM ou à des ressources spécifiques. Par exemple, les politiques basées sur l’identité peuvent être attachées à des groupes IAM, tandis que les compartiments S3 peuvent être contrôlés par des politiques basées sur les ressources.
Lorsque vous créez une politique IAM, vous pouvez spécifier les actions de service, les ressources et les conditions qui doivent être remplies pour qu’AWS autorise ou refuse l’accès. AWS prend en charge diverses conditions pour vous aider à limiter l’accès. Par exemple, en utilisant la [clé de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) PrincipalOrgID, vous pouvez refuser des actions si le demandeur ne fait pas partie de votre organisation AWS.
Vous pouvez également contrôler les demandes que les services AWS effectuent en votre nom, comme AWS CloudFormation qui crée une fonction AWS Lambda, à l’aide de la clé de condition CalledVia. Vous pouvez superposer différents types de politiques pour établir une défense en profondeur et limiter les autorisations globales de vos utilisateurs. Vous pouvez également limiter les autorisations qui peuvent être accordées et sous quelles conditions. Par exemple, vous pouvez autoriser vos équipes responsables de la charge de travail à créer leurs propres politiques IAM pour les systèmes qu’elles créent, mais seulement si elles appliquent une [limite des autorisations](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) afin de limiter le nombre maximal d’autorisations qu’elles peuvent accorder.
### Étapes d’implémentation
+ **Implémentez des politiques de moindre privilège** : attribuez des stratégies d’accès avec le moindre privilège aux groupes et rôles IAM pour rester cohérent avec le rôle ou la fonction de l’utilisateur que vous avez défini.
+ **Isolez les environnements de développement et de production via des Comptes AWS séparés** : utilisez des Comptes AWS séparés pour les environnements de développement et de production, et contrôlez l’accès entre eux à l’aide de [politiques de contrôle des services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), de politiques de ressources et de politiques d’identité.
+ **Politiques de base relatives à l’utilisation de l’API** : l’un des moyens de déterminer les autorisations nécessaires consiste à consulter les journaux AWS CloudTrail. Vous pouvez utiliser cette révision pour créer des autorisations adaptées aux actions effectivement réalisées par l’utilisateur dans AWS. [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) peut [générer automatiquement](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) une politique IAM basée sur l’activité d’accès. Vous pouvez utiliser IAM Access Advisor au niveau de l’organisation ou du compte pour [suivre les dernières informations consultées pour une stratégie donnée](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html).
+ **Envisagez d’utiliser des [politiques gérées par AWS pour les fonctions professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)** : lorsque vous commencez à créer des politiques d’autorisations détaillées, il peut être utile d’utiliser des politiques gérées par AWS pour les rôles professionnels courants, tels que la facturation, les administrateurs de base de données et les scientifiques des données. Ces politiques peuvent permettre de restreindre l’accès des utilisateurs en déterminant comment mettre en œuvre les politiques de moindre privilège.
+ **Supprimez les autorisations inutiles :** détectez et supprimez les entités, les informations d’identification et les autorisations IAM inutilisées afin d’appliquer le principe du moindre privilège. Vous pouvez utiliser l’[Analyseur d’accès IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html) pour identifier les accès externes et non utilisés, et la [génération de politiques de l’Analyseur d’accès IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) peut aider à optimiser les politiques d’autorisation.
+ **Assurez-vous que les utilisateurs ont un accès limité aux environnements de production :** les utilisateurs ne doivent avoir accès qu’aux environnements de production présentant un cas d’utilisation valide. Une fois que l’utilisateur a effectué les tâches précises qui nécessitent un accès en production, cet accès doit être révoqué. Le fait de limiter l’accès aux environnements de production permet de prévenir les événements imprévus ayant une incidence sur la production et réduit la portée des répercussions de l’accès involontaire.
+ **Envisagez les limites des autorisations :** une [limite des autorisations](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) est une fonctionnalité permettant d’utiliser une politique gérée qui définit les autorisations maximales qu’une politique basée sur l’identité peut accorder à une entité IAM. La limite d’autorisations d’une entité lui permet d’effectuer uniquement les actions autorisées à la fois par ses politiques basées sur l’identité et ses limites d’autorisations.
+ **Affinez l’accès à l’aide du contrôle d’accès basé sur les attributs et des balises de ressources :** un [contrôle d’accès basé sur les attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) utilisant des balises de ressources peut être utilisé pour affiner les autorisations lorsqu’il est pris en charge. Vous pouvez utiliser un modèle ABAC qui compare les balises principales aux balises de ressources pour affiner l’accès en fonction des dimensions personnalisées que vous définissez. Cette approche permet de simplifier et de réduire le nombre de politiques d’autorisation au sein de votre organisation.
+ Il est recommandé d’utiliser uniquement ABAC pour le contrôle d’accès lorsque les principaux et les ressources appartiennent à votre organisation AWS. Les parties externes peuvent utiliser les mêmes noms de balises et les mêmes valeurs que votre organisation pour leurs propres principaux et ressources. Si vous vous appuyez uniquement sur ces paires nom-valeur pour accorder l’accès à des principaux ou à des ressources externes, vous pouvez fournir des autorisations involontaires.
+ **Utilisez des politiques de contrôle des services pour AWS Organizations :** les [politiques de contrôle des services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) contrôlent de façon centralisée les autorisations disponibles maximales pour les comptes membres de votre organisation. Il est important de noter que vous pouvez utiliser les politiques de contrôle des services pour limiter les autorisations des utilisateurs racine dans les comptes membres. Envisagez également d’utiliser AWS Control Tower, qui fournit des contrôles gérés normatifs permettant d’enrichir AWS Organizations. Vous pouvez également définir vos propres contrôles dans Control Tower.
+ **Mettez en place une politique de cycle de vie des utilisateurs pour votre organisation :** les politiques de cycle de vie des utilisateurs définissent les tâches à effectuer lorsque les utilisateurs sont intégrés dans AWS, changent de rôle ou de champ d’activité, ou n’ont plus besoin d’accéder à AWS. Examinez les autorisations à chaque étape du cycle de vie d’un utilisateur pour vous assurer qu’elles sont suffisamment restrictives et éviter les dérives.
+ **Établissez un calendrier régulier pour vérifier les autorisations et supprimer les autorisations inutiles :** vous devez régulièrement vérifier l’accès des utilisateurs pour vérifier qu’il n’est pas trop permissif. [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) et l’Analyseur d’accès IAM peuvent aider lors des audits des autorisations des utilisateurs.
+ **Établissez une matrice des rôles professionnels :** une matrice des rôles professionnels permet de visualiser les différents rôles et niveaux d’accès requis au sein de votre empreinte AWS. À l’aide d’une matrice des fonctions professionnelles, vous pouvez définir et séparer les autorisations en fonction des responsabilités des utilisateurs au sein de votre organisation. Utilisez des groupes au lieu d’appliquer des autorisations directement à des utilisateurs ou à des rôles individuels.
## Ressources
**Documents connexes :**
+ [Accorder le moindre privilège](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [Limites des autorisations pour les entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
+ [Techniques d’écriture de politiques IAM selon le principe de moindre privilège](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)
+ [IAM Access Analyzer facilite la mise en œuvre d’autorisations de moindre privilège en générant des politiques IAM en fonction de l’activité d’accès](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/)
+ [Déléguez la gestion des autorisations aux développeurs en utilisant les limites des autorisations IAM](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)
+ [Ajustement des autorisations à l’aide des dernières informations consultées](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [Types de politiques IAM et leur utilisation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)
+ [Test des politiques IAM avec le simulateur de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)
+ [Barrières de protection dans AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [Architectures Zero Trust : Une perspective AWS](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)
+ [Comment implémenter le principe du moindre privilège avec CloudFormation StackSets](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/)
+ [Contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [Réduction de la portée de la stratégie en affichant l’activité des utilisateurs](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [Afficher l’accès au rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html)
+ [Use Tagging to Organize Your Environment and Drive Accountability](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html)
+ [Stratégies de balisage AWS](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)
+ [Balisage de ressources AWS](https://aws.amazon.com/premiumsupport/knowledge-center/tagging-resources/)
**Vidéos connexes :**
+ [Gestion des autorisations de prochaine génération](https://www.youtube.com/watch?v=8vsD_aTtuTo)
+ [Zero Trust : Une perspective AWS](https://www.youtube.com/watch?v=1p5G1-4s1r0)
# SEC03-BP03 Établir un processus d’accès d’urgence
Élaborez un processus permettant un accès d’urgence à vos charges de travail dans le cas, peu probable, où un problème avec votre fournisseur d’identité centralisé surviendrait.
Vous devez concevoir des processus pour les différents modes de défaillance susceptibles de provoquer un événement d’urgence. Par exemple, dans des circonstances normales, les utilisateurs en interne se fédèrent au cloud à l’aide d’un fournisseur d’identité centralisé ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)) pour gérer leurs charges de travail. Toutefois, si votre fournisseur d’identité centralisé échoue ou si la configuration de la fédération dans le cloud est modifiée, les utilisateurs en interne risquent de ne pas parvenir à se fédérer dans le cloud. Un processus d’accès d’urgence permet aux administrateurs autorisés d’accéder à vos ressources cloud par d’autres moyens (tels qu’une autre forme de fédération ou un accès utilisateur direct) afin de résoudre les problèmes liés à la configuration de la fédération ou à vos charges de travail. Le processus d’accès d’urgence est utilisé jusqu’à ce que le mécanisme de fédération normal soit rétabli.
**Résultat escompté :**
+ Vous avez défini et documenté les modes de défaillance considérés comme une urgence : envisagez les circonstances habituelles et les systèmes dont dépendent vos utilisateurs pour gérer leurs charges de travail. Réfléchissez à la façon dont chacune de ces dépendances peut échouer et provoquer une situation d’urgence. Les questions ainsi que les bonnes pratiques sont disponibles dans le [pilier Fiabilité](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html). Ils servent à identifier les modes de défaillance et à concevoir des systèmes plus résilients afin de minimiser le risque de défaillance.
+ Vous avez documenté les étapes à suivre pour confirmer qu’une défaillance est une urgence. Par exemple, vous pouvez demander aux administrateurs d’identité de vérifier l’état des fournisseurs d’identité principal et secondaire et, si les deux ne sont pas disponibles, de déclarer un événement d’urgence pour cause de défaillance du fournisseur d’identité.
+ Vous avez défini un processus d’accès d’urgence spécifique à chaque type d’urgence ou de mode de défaillance. En étant aussi précis que possible, vous éviterez que les utilisateurs abusent d’un processus général pour tous les types d’urgence. Vos processus d’accès d’urgence décrivent les circonstances dans lesquelles chaque processus doit être utilisé, et inversement, les situations dans lesquelles le processus ne doit pas être utilisé et renvoie à d’autres processus qui peuvent s’appliquer.
+ Vos processus sont bien documentés avec des instructions détaillées et des playbooks qui peuvent être suivis rapidement et efficacement. N’oubliez pas qu’un événement d’urgence peut être stressant pour vos utilisateurs et qu’ils peuvent être soumis à des contraintes de temps extrêmes. Concevez donc votre processus de manière à ce qu’il soit aussi simple que possible.
**Anti-modèles courants :**
+ Vous ne disposez pas de processus d’accès d’urgence bien documentés et bien testés. Vos utilisateurs ne sont pas préparés à une situation d’urgence et suivent des processus improvisés lorsqu’une situation d’urgence survient.
+ Vos processus d’accès d’urgence dépendent des mêmes systèmes (tels qu’un fournisseur d’identité centralisé) que vos mécanismes d’accès habituels. Autrement dit, la défaillance d’un système de ce type peut avoir un impact à la fois sur vos mécanismes d’accès habituels et sur les mécanismes d’accès d’urgence, et nuire à votre capacité à vous remettre de la panne.
+ Vos processus d’accès d’urgence sont utilisés dans des situations non urgentes. Par exemple, vos utilisateurs utilisent fréquemment à mauvais escient les processus d’accès d’urgence, car ils trouvent qu’il est plus facile d’apporter des modifications directement que de les soumettre par le biais d’un pipeline.
+ Vos processus d’accès d’urgence ne génèrent pas suffisamment de journaux pour auditer les processus, ou les journaux ne sont pas surveillés pour signaler une éventuelle utilisation inappropriée des processus.
**Avantages liés au respect de cette bonne pratique :**
+ En disposant de processus d’accès d’urgence bien documentés et bien testés, vous réduisez le temps nécessaire à vos utilisateurs pour répondre à un événement d’urgence et le résoudre. Cela peut se traduire par une réduction des temps d’arrêt et une meilleure disponibilité des services que vous offrez à vos clients.
+ Vous pouvez suivre chaque demande d’accès d’urgence, détecter les tentatives non autorisées d’utilisation abusive du processus pour des événements non urgents et les signaler.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée** : moyen
## Directives d’implémentation
Cette section fournit des conseils pour créer des processus d’accès d’urgence pour plusieurs modes de défaillance liés aux charges de travail déployées sur AWS, en commençant par des conseils communs applicables à tous les modes de défaillance, suivies de directives spécifiques basées sur le type de mode de défaillance.
**Conseils communs pour tous les modes de défaillance**
Envisagez les points suivants lorsque vous concevez un processus d’accès d’urgence pour un mode de défaillance :
+ Documentez les conditions préalables et les hypothèses du processus : situations dans lesquelles le processus doit être utilisé et situations dans lesquelles il ne doit pas être utilisé. Il est utile de détailler le mode de défaillance et de documenter les hypothèses, telles que l’état d’autres systèmes connexes. Par exemple, le processus du mode de défaillance 2 suppose que le fournisseur d’identité est disponible, mais que la configuration sur AWS est modifiée ou a expiré.
+ Créez au préalable les ressources nécessaires au processus d’accès d’urgence ([SEC10-BP05](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_pre_provision_access.html)). Par exemple, créez au préalable le Compte AWS d’accès d’urgence avec les utilisateurs et les rôles IAM, ainsi que les rôles IAM intercompte dans tous les comptes de la charge de travail. Vous pourrez ainsi vérifier que ces ressources sont prêtes et disponibles en cas d’urgence. En pré-créant des ressources, vous n’êtes pas tributaire des API du [plan de contrôle](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) AWS (utilisées pour créer et modifier des ressources AWS) qui peuvent ne pas être disponibles en cas d’urgence. Par ailleurs, en créant au préalable les ressources IAM, vous n’avez pas besoin de prendre en compte les [retards potentiels dus à une éventuelle cohérence.](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency)
+ Incluez les processus d’accès d’urgence dans vos plans de gestion des incidents ([SEC10-BP02](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_develop_management_plans.html)). Documentez la manière dont les événements d’urgence sont suivis et communiqués aux autres membres de votre organisation (tels que vos pairs et la direction) et, le cas échéant, à vos clients et partenaires commerciaux.
+ Définissez le processus de demande d’accès d’urgence dans votre système de flux de travail des demandes de service existant, si vous en avez un. Généralement, ces systèmes de flux de travail vous permettent de créer des formulaires de réception pour collecter des informations sur la demande, de suivre la demande à chaque étape du flux de travail et d’ajouter des étapes d’approbation automatisées et manuelles. Associez chaque demande à un événement d’urgence correspondant suivi dans votre système de gestion des incidents. Le fait de disposer d’un système uniforme pour les accès d’urgence vous permet de suivre ces demandes dans un seul système, d’analyser les tendances d’utilisation et d’améliorer vos processus.
+ Vérifiez que vos processus d’accès d’urgence ne peuvent être initiés que par des utilisateurs autorisés et nécessitent l’approbation de pairs ou de la direction de l’utilisateur, le cas échéant. Le processus d’approbation doit fonctionner efficacement pendant les heures de bureau et au-delà. Définissez comment les demandes d’approbation autorisent les approbateurs secondaires si les approbateurs principaux ne sont pas disponibles et comment elles remontent dans la chaîne de gestion jusqu’à ce qu’elles soient approuvées.
+ Mettez en œuvre des mécanismes robustes de journalisation, de surveillance et d’alerte pour le processus et les mécanismes d’accès d’urgence. Générez des journaux d’audit détaillés pour toutes les tentatives réussies et échouées d’obtenir un accès d’urgence. Établissez une corrélation entre l’activité et les événements d’urgence en cours à partir de votre système de gestion des incidents, et lancez des alertes lorsque des actions se produisent en dehors des périodes prévues ou lorsque le compte d’accès d’urgence est utilisé pendant les opérations normales. Le compte d’accès d’urgence ne doit être accessible qu’en cas d’urgence, car les procédures de bris de glace peuvent être considérées comme une porte dérobée. Intégrez-le à votre outil de gestion des informations et des événements de sécurité (SIEM) ou à [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)pour signaler et auditer toutes les activités pendant la période d’accès d’urgence. À la reprise des activités normales, effectuez une rotation automatique des informations d’identification d’accès d’urgence et informez les équipes concernées.
+ Testez régulièrement les processus d’accès d’urgence pour vérifier que les étapes sont claires et accorder le niveau d’accès approprié rapidement et efficacement. Vos processus d’accès d’urgence doivent être testés dans le cadre de simulations de réponse aux incidents ([SEC10-BP07](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)) et de tests de reprise après sinistre ([REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)).
**Mode de défaillance 1 : le fournisseur d’identité utilisé pour la fédération à AWS n’est pas disponible**
Comme décrit dans [SEC02-BP04 S’appuyer sur un fournisseur d’identité centralisé](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html), nous vous recommandons de faire appel à un fournisseur d’identité centralisé pour fédérer les utilisateurs en interne et accorder l’accès aux Comptes AWS. Vous pouvez fédérer les utilisateurs à plusieurs Comptes AWS au sein de votre organisation AWS à l’aide de IAM Identity Center, ou vous pouvez les fédérer à des Comptes AWS individuels en utilisant IAM. Dans les deux cas, les utilisateurs en interne s’authentifient auprès de votre fournisseur d’identité centralisé avant d’être redirigés vers un point de terminaison de connexion AWS pour l’authentification unique.
Dans le cas peu probable où votre fournisseur d’identité centralisé ne serait pas disponible, les utilisateurs en interne ne pourraient pas se fédérer aux Comptes AWS ni gérer leurs charges de travail. Dans ce cas d’urgence, vous pouvez fournir un processus d’accès d’urgence permettant à un petit groupe d’administrateurs d’accéder aux Comptes AWS pour effectuer des tâches critiques qui ne peuvent pas attendre que vos fournisseurs d’identité centralisés soient de nouveau disponibles. Par exemple, votre fournisseur d’identité n’est pas disponible pendant 4 heures et, durant cette période, vous devez modifier les limites supérieures d’un groupe Amazon EC2 Auto Scaling dans un compte de production pour faire face à un pic inattendu du trafic client. Vos administrateurs d’urgence doivent suivre le processus d’accès d’urgence pour accéder au Compte AWS de production spécifique et apporter les modifications nécessaires.
Le processus d’accès d’urgence repose sur un Compte AWS d’accès d’urgence créé au préalable, qui est utilisé uniquement pour l’accès d’urgence et dispose de ressources AWS (comme les rôles IAM et les utilisateurs IAM) pour soutenir le processus d’accès d’urgence. Pendant les opérations normales, personne ne doit accéder au compte d’accès d’urgence et vous devez surveiller et signaler tout cas d’utilisation abusive de ce compte (pour plus de détails, consultez la section précédente consacrée aux conseils communs).
Le compte d’accès d’urgence possède des rôles IAM d’accès d’urgence autorisés à endosser des rôles intercomptes dans les Comptes AWS nécessitant un accès d’urgence. Ces rôles IAM sont créés au préalable et configurés avec des politiques d’approbation qui assurent la validité des rôles IAM du compte d’urgence.
Le processus d’accès d’urgence peut utiliser l’une des approches suivantes :
+ Vous pouvez pré-créer un ensemble d’[utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) pour vos administrateurs d’urgence dans le compte d’accès d’urgence avec des mots de passe robustes et des jetons MFA associés. Ces utilisateurs IAM seront autorisés à endosser les rôles IAM qui autoriseront ensuite l’accès intercompte au Compte AWS où un accès d’urgence est requis. Nous vous recommandons de créer le moins d’utilisateurs possible et d’affecter chaque utilisateur à un seul administrateur d’urgence. En cas d’urgence, un utilisateur administrateur d’urgence se connecte au compte d’accès d’urgence à l’aide de son mot de passe et de son code de jeton MFA, passe au rôle IAM d’accès d’urgence dans le compte d’urgence, puis passe au rôle IAM d’accès d’urgence dans le compte de la charge de travail pour effectuer l’action de modification d’urgence. L’avantage de cette approche est que chaque utilisateur IAM est associé à un seul administrateur d’urgence et que vous pouvez savoir quel utilisateur s’est connecté en consultant les événements CloudTrail. L’inconvénient est que vous devez gérer plusieurs utilisateurs IAM avec leurs mots de passe de longue durée de vie et leurs jetons MFA associés.
+ Vous pouvez utiliser [l’utilisateur racine Compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) d’accès d’urgence pour vous connecter au compte d’accès d’urgence, endosser le rôle IAM d’accès d’urgence et endosser le rôle entre comptes dans le compte de la charge de travail. Nous recommandons de définir un mot de passe robuste et plusieurs jetons MFA pour l’utilisateur racine. Nous conseillons également de stocker le mot de passe et les jetons MFA dans un coffre-fort d’informations d’identification d’entreprise sécurisé, qui applique des mécanismes solides d’authentification et d’autorisation. Vous devez sécuriser les facteurs de réinitialisation de mots de passe et des jetons MFA : configurez l’adresse e-mail du compte sur une liste de distribution surveillée par vos administrateurs de sécurité cloud, et le numéro de téléphone du compte doit être un numéro partagé également surveillé par ces administrateurs. L’avantage de cette approche est qu’il n’existe qu’un seul ensemble d’informations d’identification d’utilisateur racine à gérer. L’inconvénient est qu’étant donné qu’il s’agit d’un utilisateur partagé, plusieurs administrateurs ont la possibilité de se connecter en tant qu’utilisateur racine. Vous devez auditer les événements du journal de votre coffre-fort d’entreprise pour identifier quel administrateur a extrait le mot de passe de l’utilisateur racine.
**Mode de défaillance 2 : la configuration du fournisseur d’identité sur AWS est modifiée ou a expiré**
Pour permettre aux utilisateurs en interne de se fédérer aux Comptes AWS, vous pouvez configurer le IAM Identity Center auprès d’un fournisseur d’identité externe ou créer un fournisseur d’identité ([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)). Généralement, vous les configurez en important un document XML de métadonnées SAML fourni par votre fournisseur d’identité. Ce document XML de métadonnées inclut un certificat X.509 correspondant à une clé privée que le fournisseur d’identité utilise pour signer ses assertions SAML.
Ces configurations côté AWS peuvent être modifiées ou supprimées par erreur par un administrateur. Dans un autre scénario, le certificat X.509 importé dans AWS peut expirer, et aucun nouveau fichier XML de métadonnées contenant un nouveau certificat n’a encore été importé dans AWS. Ces deux scénarios peuvent désactiver la fédération des utilisateurs en interne à AWS, ce qui peut entraîner une situation d’urgence.
Dans un tel cas d’urgence, vous pouvez fournir à vos administrateurs d’identité un accès à AWS pour résoudre les problèmes de fédération. Par exemple, votre administrateur d’identité utilisera le processus d’accès d’urgence pour se connecter au Compte AWS d’accès d’urgence, passera à un rôle dans le compte administrateur d’Identity Center et mettra à jour la configuration du fournisseur d’identité externe en important le dernier document XML de métadonnées SAML de votre fournisseur d’identité afin de réactiver la fédération. Une fois la fédération rétablie, les utilisateurs en interne pourront continuer à utiliser le processus d’exploitation habituel pour se fédérer aux comptes de leur charge de travail.
Vous pouvez suivre les approches détaillées dans le précédent mode de défaillance 1 pour créer un processus d’accès d’urgence. Vous pouvez accorder des autorisations de moindre privilège aux administrateurs d’identité pour qu’ils ne puissent accéder qu’au compte administrateur d’Identity Center et effectuer des actions sur Identity Center dans ce compte uniquement.
**Mode de défaillance 3 : interruption d’Identity Center**
Dans le cas, peu probable, où IAM Identity Center ou Région AWS serait interrompue, nous vous recommandons de créer une configuration que vous pourrez utiliser pour assurer un accès temporaire à la AWS Management Console.
Le processus d’accès d’urgence utilise une fédération directe entre votre fournisseur d’identité et IAM dans un compte d’urgence. Pour plus de détails sur le processus et les considérations de conception, voir [Configurer l’accès d’urgence à la AWS Management Console](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html).
### Étapes d’implémentation
**Étapes communes pour tous les modes de défaillance**
+ Créez un Compte AWS dédié aux processus d’accès d’urgence. Créez au préalable les ressources IAM nécessaires dans le compte, telles que les rôles IAM ou les utilisateurs IAM et, éventuellement, les fournisseurs d’identité IAM. En outre, créez au préalable des rôles IAM intercomptes dans les Comptes AWS de la charge de travail et établir des relations d’approbation avec les rôles IAM correspondants dans le compte d’accès d’urgence. Vous pouvez utiliser [CloudFormation StackSets avec AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) pour créer ces ressources dans les comptes membres de votre organisation.
+ Créez les [politiques de contrôle des services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) AWS Organizations pour refuser la suppression et la modification des rôles IAM intercomptes dans les Comptes AWS membres.
+ Activez CloudTrail pour le Compte AWS d’accès d’urgence et envoyez les événements de suivi vers un compartiment S3 central de votre Compte AWS de collecte de journaux. Si vous utilisez AWS Control Tower pour configurer et gérer votre environnement AWS multi-comptes, chaque compte que vous créez avec AWS Control Tower ou que vous inscrivez dans AWS Control Tower est activé pour CloudTrail par défaut et envoyé vers un compartiment S3 dans un Compte AWS d’archive de journal dédié.
+ Surveillez l’activité du compte d’accès d’urgence en créant des règles EventBridge qui correspondent lors de la connexion à la console et de l’activité de l’API en fonction des rôles IAM d’urgence. Envoyez des notifications à votre centre des opérations de sécurité lorsque des activités se produisent en dehors d’un événement d’urgence en cours, suivi dans votre système de gestion des incidents.
**Étapes supplémentaires pour le mode de défaillance 1 : le fournisseur d’identité utilisé pour la fédération à AWS n’est pas disponible et pour le mode de défaillance 2 : la configuration du fournisseur d’identité sur AWS est modifiée ou a expiré**
+ Créez des ressources au préalable en fonction du mécanisme que vous avez choisi pour l’accès d’urgence :
+ **Avec les utilisateurs IAM :** créez au préalable les utilisateurs IAM avec des mots de passe robustes et les dispositifs MFA associés.
+ **Avec l’utilisateur racine du compte d’urgence :** configurez l’utilisateur racine avec un mot de passe robuste et stockez ce mot de passe dans le coffre-fort d’informations d’identification de votre entreprise. Associez plusieurs appareils MFA physiques à l’utilisateur racine et stockez-les à des emplacements auxquels les membres de votre équipe d’administrateurs d’urgence peuvent accéder rapidement.
**Étapes supplémentaires pour le mode de défaillance 3 : interruption d’Identity Center**
+ Comme indiqué dans la rubrique [Configurez l’accès d’urgence à AWS Management Console](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html), dans le Compte AWS d’accès d’urgence, créez un fournisseur d’identité IAM pour activer la fédération SAML directe à partir de votre fournisseur d’identité.
+ Créez des groupes d’opérations d’urgence dans votre fournisseur d’identité (IdP) sans aucun membre.
+ Créez des rôles IAM correspondant aux groupes d’opérations d’urgence dans le compte d’accès d’urgence.
## Ressources
**Bonnes pratiques Well-Architected connexes:**
+ [SEC02-BP04 S’appuyer sur un fournisseur d’identité centralisé](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
+ [SEC03-BP02 Accorder un accès selon le principe du moindre privilège](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html)
+ [SEC10-BP02 Développer des plans de gestion des incidents](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
+ [SEC10-BP07 Organiser des jeux de rôle](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html)
**Documents connexes:**
+ [Configurer un accès d’urgence à la AWS Management Console](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)
+ [Activation de l’accès des utilisateurs fédérés SAML 2.0 à la AWS Management Console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html)
+ [Accès en mode « bris de glace](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**Vidéos connexes:**
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Inforce 2022 - Gestion des identités et des accès AWS (IAM) deep dive](https://youtu.be/YMj33ToS8cI)
**Exemples connexes:**
+ [AWS Break Glass Role](https://github.com/awslabs/aws-break-glass-role)
+ [AWS Cadre de playbook client](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Modèles de playbooks de réponse aux incidents](https://github.com/aws-samples/aws-incident-response-playbooks)
# SEC03-BP04 Limiter les autorisations au minimum requis en permanence
Au fur et à mesure que vos équipes déterminent les accès nécessaires, supprimez les autorisations inutiles et mettez en place des processus de révision afin d’obtenir des autorisations de moindre privilège. Surveillez et supprimez en permanence les identités ainsi que les autorisations inutilisées pour les accès humains et machines.
**Résultat escompté :** les politiques d’autorisation doivent respecter le principe de moindre privilège. Au fur et à mesure que les tâches et les rôles sont mieux définis, vos politiques d’autorisation doivent être revues de façon à supprimer les autorisations inutiles. Cette approche réduit l’impact si les informations d’identification sont exposées par inadvertance ou autrement consultées sans autorisation.
**Anti-modèles courants :**
+ Octroi par défaut des autorisations d’administrateur aux utilisateurs.
+ Création de politiques trop permissives sans tous les privilèges d’administrateur.
+ Maintien des politiques d’autorisation une fois qu’elles ne sont plus nécessaires.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Lorsque les équipes et les projets sont à leur début, des politiques d’autorisation permissives peuvent être utilisées pour favoriser l’innovation et l’agilité. Par exemple, dans un environnement de développement ou de test, les développeurs peuvent se voir octroyer un accès à un large éventail de services AWS. Nous vous recommandons d’évaluer l’accès en continu et de restreindre l’accès aux services et aux actions de service nécessaires pour effectuer le travail en cours. Nous recommandons cette évaluation pour les identités humaines et machine. Les identités machine, parfois appelées comptes de système ou de service, donnent un accès AWS aux applications ou aux serveurs. Cet accès est particulièrement important dans un environnement de production, où des autorisations trop permissives peuvent avoir un impact important et exposer les données des clients.
AWS fournit plusieurs méthodes pour identifier les utilisateurs, les rôles, les autorisations et les informations d’identification non utilisés. AWS peut également faciliter l’analyse de l’activité d’accès des utilisateurs et rôles IAM, notamment des clés d’accès, ainsi que l’accès aux ressources AWS telles que les objets dans les compartiments Amazon S3. La génération de politiques AWS Identity and Access Management Access Analyzer peut vous aider à créer des politiques d’autorisations restrictives basées sur les services et les actions réels avec lesquels un principal interagit. Le [contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) peut contribuer à simplifier la gestion des autorisations, car vous pouvez fournir des autorisations aux utilisateurs en utilisant leurs attributs au lieu d’associer des politiques d’autorisations directement à chaque utilisateur.
### Étapes d’implémentation
+ **Utilisez [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) :** l’analyseur d’accès IAM vous aide à identifier les ressources de votre organisation et de vos comptes comme les compartiments Amazon Simple Storage Service (Amazon S3) ou les rôles IAM, qui sont [partagées avec une entité externe](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html).
+ **Utilisez la [génération de politiques de l’Analyseur d’accès IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) :** la génération de politiques de l’Analyseur d’accès IAM vous permet de [créer des politiques d’autorisation précises reposant sur l’activité d’accès d’un utilisateur ou d’un rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks).
+ **Testez les autorisations dans les environnements inférieurs avant la production :** commencez par utiliser les [environnements de développement et de test (sandbox) les moins critiques](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/understanding-the-devops-environments.html) pour tester les autorisations requises pour les différentes fonctions professionnelles à l’aide de l’Analyseur d’accès IAM. Ensuite, renforcez progressivement et validez ces autorisations dans les environnements de test, d’assurance qualité et intermédiaires avant de les appliquer en production. Les environnements inférieurs peuvent avoir des autorisations plus souples au départ, car les politiques de contrôle des services (SCP) constituent un garde-fou en limitant le nombre maximal d’autorisations accordées.
+ **Déterminez un délai et une politique d’utilisation acceptables pour les utilisateurs et les rôles IAM :** utilisez [l’horodatage du dernier accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html) pour [identifier les utilisateurs et les rôles non utilisés](https://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/) et les supprimer. Consultez les informations relatives aux services et actions consultées en dernier afin d’identifier et de [restreindre les autorisations à des utilisateurs et des rôles spécifiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html). Par exemple, vous pouvez utiliser les dernières informations consultées pour identifier les actions spécifiques d’Amazon S3 dont votre rôle d’application a besoin et limiter l’accès du rôle à celles-ci uniquement. Les fonctionnalités relatives aux informations sur les derniers accès sont disponibles dans la AWS Management Console et par programmation pour vous permettre de les intégrer dans vos flux de travail d’infrastructure et vos outils automatisés.
+ **Envisagez de [consigner les événements de données dans AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html) :** par défaut, CloudTrail n’enregistre pas les événements de données tels que l’activité au niveau des objets Amazon S3 (par exemple, `GetObject` et `DeleteObject`) ou les activités de tables Amazon DynamoDB (par exemple, `PutItem` et `DeleteItem`). Envisagez d’autoriser la journalisation de ces événements afin de déterminer quels utilisateurs et rôles ont besoin d’accéder à des objets Amazon S3 ou des éléments de table DynamoDB spécifiques.
## Ressources
**Documents connexes:**
+ [Accorder le moindre privilège](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [Supprimer les informations d’identification inutiles](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [ Présentation de AWS CloudTrail? ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [Utilisation des stratégies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [ Journalisation et surveillance dans DynamoDB ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/MonitoringDynamoDB.html)
+ [ Utilisation de la journalisation des événements CloudTrail pour vos compartiments et objets Amazon S ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)
+ [ Obtenir des rapports d’informations d’identification pour votre Compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)
**Vidéos connexes:**
+ [Become an IAM Policy Master in 60 Minutes or Less](https://youtu.be/YQsK4MtsELU)
+ [Separation of Duties, Least Privilege, Delegation, and CI/CD](https://youtu.be/3H0i7VyTu70)
+ [AWS re:Inforce 2022 - Gestion des identités et des accès AWS (IAM) deep dive ](https://www.youtube.com/watch?v=YMj33ToS8cI)
# SEC03-BP05 Définir des barrières de protection des autorisations de votre organisation
Utilisez des barrières de protection pour réduire la portée des autorisations disponibles qui peuvent être accordées aux principaux. La chaîne d’évaluation des politiques d’autorisation inclut vos barrières de protection pour déterminer les *autorisations effectives* d’un principal lorsqu’il prend des décisions d’autorisation. Vous pouvez définir des barrières de protection à l’aide d’une approche par couches. Appliquez certaines barrières de protection de manière générale à l’ensemble de votre organisation et appliquez-en d’autres de manière granulaire aux sessions d’accès temporaires.
**Résultat escompté :** garantir une séparation claire des environnements en utilisant les Comptes AWS distincts. Les politiques de contrôle des services (SCP) sont utilisées pour définir des barrières de protection des autorisations à l’échelle de l’organisation. Des barrières de protection plus étendues sont définies aux niveaux hiérarchiques les plus proches de la racine de votre organisation, tandis que des barrières de protection plus strictes sont définies plus près du niveau des comptes individuels.
Lorsqu’elles sont prises en charge, les politiques de ressources définissent les conditions qu’un principal doit remplir pour accéder à une ressource. Les politiques relatives aux ressources définissent également l’ensemble des actions autorisées, le cas échéant. Les limites d’autorisation sont placées sur les principaux qui gèrent les autorisations de charge de travail, en déléguant la gestion des autorisations aux propriétaires individuels de la charge de travail.
**Anti-modèles courants :**
+ Création d’un Comptes AWS membre au sein d’une [ organisation AWS](https://aws.amazon.com/organizations/), sans utiliser les SCP pour restreindre l’utilisation et les autorisations accordées à leurs informations d’identification racine.
+ Attribution des autorisations en fonction du principe de moindre privilège, sans placer de barrières de protection sur l’ensemble maximum d’autorisations pouvant être accordées.
+ S’appuyer sur le principe de *refus implicite* d’IAM AWS pour restreindre les autorisations, en étant sûr que les politiques n’accorderont pas d’autorisation *explicite* indésirable.
+ Exécuter plusieurs environnements de charge de travail dans le même Compte AWS, puis s’appuyer sur des mécanismes tels que des VPC, des balises ou des politiques de ressources pour appliquer les limites d’autorisation.
**Avantages de l’adoption de cette bonne pratique :** les barrières de protection des autorisations contribuent à garantir le refus des autorisations indésirables, même lorsqu’une politique d’autorisation tente de le faire. Cette mesure peut simplifier la définition et la gestion des autorisations en réduisant la portée maximale des autorisations à prendre en compte.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Nous vous recommandons d’utiliser une approche par couches afin de définir les barrières de protection des autorisations de votre organisation. Cette approche réduit systématiquement l’ensemble maximum d’autorisations possibles à mesure que des couches supplémentaires sont appliquées. Cela vous permet d’accorder l’accès sur la base du principe de moindre privilège, réduisant ainsi le risque d’accès involontaire dû à une mauvaise configuration des politiques.
La première étape pour établir des barrières de protection des autorisations consiste à isoler vos charges de travail et vos environnements dans des Comptes AWS distincts. Les principaux d’un compte ne peuvent pas accéder aux ressources d’un autre sans autorisation explicite, même lorsque les deux comptes appartiennent à la même organisation AWS ou à la même [unité organisationnelle (OU)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html). Vous pouvez utiliser les unités organisationnelles pour regrouper les comptes que vous souhaitez administrer en tant qu’unité unique.
L’étape suivante consiste à réduire le nombre maximum d’autorisations que vous pouvez accorder aux principaux au sein des comptes membres de votre organisation. Pour ce faire, vous pouvez utiliser des [politiques de contrôle des services (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), que vous pouvez appliquer soit à une unité d’organisation, soit à un compte. Les SCP peuvent appliquer des contrôles d’accès courants, tels que la restriction de l’accès à des Régions AWS spécifiques, la protection contre la suppression des ressources ou la désactivation d’actions de service potentiellement risquées. Les SCP que vous appliquez à la racine de votre organisation n’affectent que ses comptes membres, et non le compte de gestion. Les SCP régissent uniquement les principaux au sein de votre organisation. Vos SCP ne régissent pas les principaux, extérieurs à votre organisation, qui accèdent à vos ressources.
Si vous utilisez [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html), vous pouvez tirer parti de ses [contrôles](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-controls-work) et de ses [zones de destination](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) comme base de vos garde-fous d’autorisations et de votre environnement multi-compte. Les zones de destination fournissent un environnement de base sécurisé préconfiguré avec des comptes distincts pour différentes charges de travail et applications. Les garde-fous appliquent des contrôles obligatoires en matière de sécurité, d’exploitation et de conformité par le biais d’une combinaison de politiques de contrôle des services (SCP), de règles AWS Config et d’autres configurations. Toutefois, lorsque vous utilisez les garde-fous et les zones de destination Control Tower en plus des politiques SCP personnalisées de l’organisation, il est essentiel de suivre les bonnes pratiques décrites dans la documentation AWS afin d’éviter les conflits et de garantir une bonne gouvernance. Reportez-vous aux [recommandations AWS Control Tower pour AWS Organizations](https://docs.aws.amazon.com/controltower/latest/userguide/orgs-guidance.html) afin d’obtenir des recommandations détaillées sur la gestion des politiques SCP, des comptes et des unités organisationnelles (OU) dans un environnement Control Tower.
En respectant ces directives, vous pouvez tirer parti efficacement des garde-fous, des zones de destination et des politiques SCP personnalisées de Control Tower tout en atténuant les conflits potentiels et en garantissant une gouvernance et un contrôle appropriés de votre environnement AWS multi-compte.
Une autre étape consiste à utiliser les [politiques de ressources IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based) pour définir les actions disponibles que vous pouvez effectuées sur les ressources qu’elles régissent, ainsi que les conditions que le principal par intérim doit respecter. Vous pouvez donc autoriser toutes les actions pour le principal faisant partie de votre organisation (en utilisant la [clé de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) PrincipalOrgId), ou restreindre les permissions à certaines actions spécifiques pour un rôle IAM particulier. Vous pouvez adopter une approche similaire avec des conditions dans les politiques d’approbation des rôles IAM. Si une politique d’approbation en matière de ressources ou de rôles désigne explicitement un principal dans le même compte que le rôle ou la ressource qu’elle gère, ce principal n’a pas besoin de politique IAM associée qui accorde les mêmes autorisations. Si le principal se trouve dans un compte différent de celui de la ressource, il a besoin d’une politique IAM associée qui accorde ces autorisations.
La plupart du temps, une équipe responsable d’une charge de travail souhaite gérer les autorisations requises pour sa charge de travail. Cette situation peut nécessiter la création de nouveaux rôles IAM et de nouvelles politiques d’autorisation. Vous pouvez saisir la portée maximale des autorisations que l’équipe peut accorder dans une [limite d’autorisations IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html), puis associer ce document à un rôle IAM que l’équipe pourra utiliser pour gérer ses rôles et autorisations IAM. Cette approche peut lui donner la liberté de terminer son travail, tout en limitant les risques liés au fait de disposer d’un accès administratif IAM.
Une étape plus précise consiste à implémenter des techniques de *gestion des accès privilégiés* (PAM) et de *gestion d’accès élevés temporaires* (TEAM). Un exemple de PAM consiste à demander aux principaux de procéder à une authentification multifactorielle avant d’entreprendre des actions privilégiées. Pour plus d’informations, consultez la section [Configuration de l’accès aux API protégé par MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html). TEAM a besoin d’une solution qui gère l’approbation et le délai pendant lequel un principal est autorisé à bénéficier d’un accès élevé. Une approche consiste à ajouter temporairement le principal à la politique d’approbation des rôles pour un rôle IAM dont l’accès est élevé. Une autre approche consiste, dans le cadre d’un fonctionnement normal, à réduire les autorisations accordées à un principal par un rôle IAM à l’aide d’une [politique de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session), puis à lever temporairement cette restriction pendant la période approuvée. Pour en savoir plus sur les solutions que AWS et validées par certains partenaires, consultez la section [Accès élevé temporaire](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html).
### Étapes d’implémentation
1. Isolez vos charges de travail et vos environnements dans des Comptes AWS distincts.
1. Utilisez les SCP pour réduire le nombre maximum d’autorisations pouvant être accordées aux principaux sur les comptes membres de votre organisation.
1. Lorsque vous définissez des politiques SCP pour réduire le nombre maximal d’autorisations pouvant être accordées aux principaux sur les comptes membres de votre organisation, vous pouvez choisir entre une approche avec *liste d’autorisations* ou *liste de refus*. La stratégie avec liste d’autorisations spécifie explicitement les accès autorisés et bloque implicitement tous les autres accès. La stratégie avec liste de refus spécifie explicitement les accès qui sont refusés et autorise par défaut tous les autres accès. Ces deux stratégies ont leurs avantages et leurs inconvénients, et le choix approprié dépend des exigences spécifiques et du modèle de risque de votre organisation. Pour plus de détails, consultez [Stratégie d’utilisation des politiques SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html).
1. En outre, passez en revue les [exemples de politiques de contrôle des services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) pour comprendre comment élaborer efficacement des politiques SCP.
1. Utilisez les politiques relatives aux ressources IAM pour réduire la portée et spécifier les conditions des actions autorisées sur les ressources. Utilisez les conditions des politiques d’approbation relatives aux rôles IAM pour créer des restrictions quant à l’attribution des rôles.
1. Attribuez des limites d’autorisation IAM aux rôles IAM que les équipes de la charge de travail peuvent ensuite utiliser afin de gérer leurs propres rôles et autorisations IAM en matière de charge de travail.
1. Évaluez les solutions PAM et TEAM en fonction de vos besoins.
## Ressources
**Documents connexes:**
+ [Périmètres de données sur AWS](https://aws.amazon.com/identity/data-perimeters-on-aws/)
+ [Mettez en place des barrières de protection des autorisations à l’aide de périmètres de données](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_data-perimeters.html)
+ [Logique d’évaluation de stratégies](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)
**Exemples associés:**
+ [Exemples de politiques de contrôle des services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
**Outils associés:**
+ [AWS Solution : gestion des accès élevés temporaires (TEAM](https://aws-samples.github.io/iam-identity-center-team/)
+ [Solutions validées de partenaires en matière de sécurité pour TEAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html#validatedpartners)
# SEC03-BP06 Gérer l’accès en fonction du cycle de vie
Surveillez et ajustez les autorisations accordées à vos principaux (utilisateurs, rôles et groupes) tout au long de leur cycle de vie au sein de votre organisation. Ajustez les appartenances aux groupes lorsque les utilisateurs changent de rôle et supprimez l’accès lorsqu’un utilisateur quitte l’organisation.
**Résultat escompté :** vous surveillez et ajustez les autorisations tout au long du cycle de vie des principaux au sein de l’organisation, réduisant ainsi le risque de privilèges inutiles. Vous accordez l’accès approprié lorsque vous créez un utilisateur. Vous modifiez l’accès en fonction de l’évolution des responsabilités de l’utilisateur et vous supprimez l’accès lorsque l’utilisateur n’est plus actif ou s’il a quitté l’organisation. Vous gérez de manière centralisée les modifications apportées à vos utilisateurs, rôles et groupes. Vous utilisez l’automatisation pour propager les modifications à vos environnements AWS.
**Anti-modèles courants :**
+ Accorder en amont des privilèges d’accès excessifs ou étendus aux identités, au-delà de ce qui est initialement requis.
+ Ne pas examiner et ne pas ajuster les privilèges d’accès au fur et à mesure de l’évolution des rôles et des responsabilités des identités.
+ Laisser des identités inactives ou résiliées avec des privilèges d’accès actifs. Cela augmente le risque d’accès non autorisé.
+ Ne pas tirer parti de l’automatisation pour gérer le cycle de vie des identités.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Gérez et ajustez avec soin les privilèges d’accès que vous accordez aux identités (telles que les utilisateurs, les rôles, les groupes) tout au long de leur cycle de vie. Ce cycle de vie comprend la phase initiale d’intégration, les changements continus des rôles et des responsabilités, et le départ ou la résiliation éventuels. Gérez l’accès de manière proactive en fonction de l’étape du cycle de vie afin de maintenir un niveau d’accès approprié. Optez pour le principe du moindre privilège afin de réduire le risque de privilèges d’accès excessifs ou inutiles.
Vous pouvez gérer le cycle de vie des utilisateurs IAM directement dans le Compte AWS ou par le biais d’une fédération entre le fournisseur d’identité de votre personnel et [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/). Pour les utilisateurs IAM, vous pouvez créer, modifier et supprimer des utilisateurs et leurs autorisations associées dans le Compte AWS. Pour les utilisateurs fédérés, vous pouvez utiliser IAM Identity Center afin de gérer leur cycle de vie en synchronisant les informations relatives aux utilisateurs et aux groupes provenant du fournisseur d’identité de votre organisation à l’aide du protocole [System for Cross-domain Identity Management](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) (SCIM).
SCIM est un protocole standard ouvert pour le provisionnement et le déprovisionnement automatisés des identités des utilisateurs sur différents systèmes. En intégrant votre fournisseur d’identité avec IAM Identity Center à l’aide de SCIM, vous pouvez synchroniser automatiquement les informations des utilisateurs et des groupes, ce qui aide à valider que les privilèges d’accès sont accordés, modifiés ou révoqués en fonction des modifications apportées à la source d’identité officielle de votre organisation.
Ajustez les privilèges en fonction de l’évolution des rôles et responsabilités des employés au sein de votre organisation. Vous pouvez utiliser les ensembles d’autorisations d’IAM Identity Center pour définir différents rôles ou responsabilités professionnels et les associer aux politiques et autorisations IAM Identity Center appropriées. Lorsque le rôle d’un employé change, vous pouvez mettre à jour l’ensemble d’autorisations qui lui a été attribué de façon à refléter ses nouvelles responsabilités. Vérifiez qu’il dispose de l’accès nécessaire tout en respectant le principe du moindre privilège.
### Étapes d’implémentation
1. Définissez et documentez un processus de gestion des accès tout au long du cycle de vie, y compris les procédures relatives à l’octroi de l’accès initial, aux révisions périodiques et à la révocation de l’accès.
1. Mettez en œuvre les [rôles, groupes et limites des autorisations IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) pour gérer l’accès collectivement et appliquer des niveaux d’accès maximaux autorisés.
1. Intégrez un [fournisseur d’identité fédéré](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) (tel que Microsoft Active Directory, Okta, Ping Identity) en tant que source officielle d’informations sur les utilisateurs et les groupes utilisant IAM Identity Center.
1. Utilisez le protocole [SCIM](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) pour synchroniser les informations sur les utilisateurs et les groupes provenant du fournisseur d’identité dans l’Identity Store d’IAM Identity Center.
1. Dans IAM Identity Center, créez des [ensembles d’autorisations](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) qui représentent les différents rôles ou responsabilités au sein de votre organisation. Définissez les politiques et les autorisations IAM appropriées pour chaque ensemble d’autorisations.
1. Mettez en œuvre des contrôles d’accès réguliers, une révocation rapide des accès et une amélioration continue du processus de gestion du cycle de vie des accès.
1. Formez et sensibilisez les employés aux bonnes pratiques de gestion des accès.
## Ressources
**Bonnes pratiques associées :**
+ [SEC02-BP04 S’appuyer sur un fournisseur d’identité centralisé](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
**Documents connexes :**
+ [Gérer votre source d’identité ](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html)
+ [Gestion des identités dans IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [Utilisation de AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ [Génération d’une politique de l’Analyseur d’accès IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)
**Vidéos connexes :**
+ [AWS re:Inforce 2023 - Manage temporary elevated access with AWS IAM Identity Center](https://www.youtube.com/watch?v=a1Na2G7TTQ0)
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://www.youtube.com/watch?v=TvQN4OdR_0Y&t=444s)
+ [AWS re:Invent 2022 - Harness power of IAM policies & rein in permissions w/Access Analyzer](https://www.youtube.com/watch?v=x-Kh8hKVX74&list=PL2yQDdvlhXf8bvQJuSP1DQ8vu75jdttlM&index=11)
# SEC03-BP07 Analyser l’accès public et intercompte
Surveillez continuellement les résultats qui mettent en évidence l’accès public et intercompte. Limitez l’accès public et l’accès intercompte aux seules ressources spécifiques qui nécessitent cet accès.
**Résultat escompté :** connaitre quelles de vos ressources AWS sont partagées et avec qui. Surveillez et auditez continuellement vos ressources partagées afin de vérifier qu’elles ne sont partagées qu’avec les principaux autorisés.
**Anti-modèles courants :**
+ Ne pas tenir un inventaire des ressources partagées.
+ Ne pas suivre de processus pour régir l’accès intercompte et public aux ressources.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** bas
## Directives d’implémentation
Si votre compte est dans AWS Organizations, vous pouvez accorder l’accès aux ressources à l’ensemble de l’organisation, à des unités d’organisation spécifiques ou à des comptes individuels. Si votre compte n’est pas membre d’une organisation, vous pouvez partager des ressources avec des comptes individuels. Vous pouvez accorder un accès direct intercompte à l’aide de politiques basées sur les ressources, par exemple les [politiques de compartiment Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html), ou en autorisant le principal d’un autre compte à assumer un rôle IAM dans votre compte. Lorsque vous utilisez des politiques de ressources, vérifiez que l’accès n’est accordé qu’aux principaux autorisés. Définir un processus d’approbation de toutes les ressources qui doivent être accessibles au public.
[AWS Identity and Access Management Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) utilise la [sécurité prouvable](https://aws.amazon.com/security/provable-security/) pour identifier tous les chemins d’accès à une ressource en dehors de son compte. Il passe en revue les politiques de ressources en continu et présente les résultats d’accès public et intercompte pour permettre d’analyser facilement un accès potentiellement étendu. Envisagez de configurer l’analyseur d’accès IAM avec AWS Organizations afin de vérifier que vous avez une visibilité sur tous vos comptes. L’analyseur d’accès IAM vous permet également de [prévisualiser les résultats](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html) avant de déployer les autorisations relatives aux ressources. Vous pouvez ainsi vérifier que vos modifications de politique n’accordent que l’accès public et intercompte prévu à vos ressources. En établissant un accès multicompte, vous pouvez utiliser des [politiques d’approbation](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/) pour vérifier dans quels cas un rôle peut être assumé. Par exemple, vous pourriez utiliser la [clé de condition `PrincipalOrgId` pour refuser une tentative d’assumer un rôle en dehors de votre AWS Organizations](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/).
[AWS Config peut signaler les ressources](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html) mal configurées et, par le biais de vérifications des politiques AWS Config, détecter les ressources dont l’accès public est configuré. Les services tels que [AWS Control Tower](https://aws.amazon.com/controltower/) et [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) simplifient le déploiement des contrôles de détection et des barrières de protection sur AWS Organizations afin d’identifier et de corriger les ressources exposées au public. Par exemple, AWS Control Tower dispose d’une barrière de protection gérée qui peut détecter si des [instantanés d’Amazon EBS sont restaurés par Comptes AWS](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html).
### Étapes d’implémentation
+ **Envisagez d’utiliser [AWS Config for AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html) :** AWS Config vous permet d’agréger les résultats de plusieurs comptes d’un AWS Organizations vers un compte d’administrateur délégué. Cela fournit une vue complète et vous permet de [déployer AWS Config Rules sur plusieurs comptes afin de détecter les ressources accessibles au public](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html).
+ **Configurez AWS Identity and Access Management Access Analyzer :** l’Analyseur d’accès IAM vous aide à identifier les ressources dans votre organisation et vos comptes, telles que les compartiments Amazon S3 ou les rôles IAM, qui sont [partagés avec une entité externe](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html).
+ **Utilisez la correction automatique AWS Config pour effectuer les modifications de la configuration de l’accès public des compartiments Amazon S3 :** [vous pouvez activer automatiquement les paramètres de blocage de l’accès public pour les compartiments Amazon S3](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/).
+ **Implémentez la surveillance et les alertes pour déterminer si les compartiments Amazon S3 sont devenus publics :** vous devez mettre en place un système de [surveillance et d’alerte](https://aws.amazon.com/blogs/aws/amazon-s3-update-cloudtrail-integration/) pour détecter si le blocage de l’accès public Amazon S3 est désactivé et si les compartiments Amazon S3 deviennent publics. En outre, si vous utilisez AWS Organizations, vous pouvez créer une [politique de contrôle de services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) qui empêche toute modification des stratégies d’accès public d’Amazon S3. [AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html) vérifie les compartiments Amazon S3 dont les autorisations permettent un accès libre. Les autorisations de compartiment qui accordent à tous un accès au chargement ou à la suppression créent des problèmes de sécurité potentiels, en permettant à quiconque d’ajouter, de modifier ou de supprimer les éléments d’un compartiment. La vérification Trusted Advisor examine les autorisations explicites de compartiment et les politiques associées de compartiment susceptibles de remplacer les autorisations de compartiment. Vous pouvez également utiliser AWS Config pour surveiller l’accès public de vos compartiments Amazon S3. Pour plus d’informations, consultez la section [Comment utiliser AWS Config pour surveiller et gérer les compartiments Amazon S3 autorisant l’accès public](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/).
Lorsque vous examinez les contrôles d’accès pour les compartiments Amazon S3, il est important de prendre en compte la nature des données qui y sont stockées. [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html) est un service conçu pour vous aider à découvrir et à protéger les données sensibles, telles que les données d’identification personnelle (PII), les informations protégées sur la santé (PHI) et les informations d’identification telles que les clés privées ou les clés d’accès AWS.
## Ressources
**Documents connexes :**
+ [Utilisation de AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected)
+ [Bibliothèque de contrôles AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/controls-reference.html)
+ [ Norme concernant les bonnes pratiques de sécurité de base AWS](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html)
+ [AWS Config Règles gérées](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html)
+ [Référence de la vérification AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html)
+ [Surveillance des résultats des vérifications AWS Trusted Advisor avec Amazon EventBridge](https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-ta.html)
+ [Gestion des règles AWS Config pour tous les comptes de votre organisation](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)
+ [AWS Config and AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)
+ [ Mise à disposition de votre AMI au public pour son utilisation dans Amazon EC2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-intro.html#block-public-access-to-amis)
**Vidéos connexes :**
+ [Best Practices for securing your multi-account environment](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [Dive Deep into IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0)
# SEC03-BP08 Partager des ressources en toute sécurité au sein de votre organisation
À mesure que le nombre de charges de travail augmente, vous devrez peut-être partager l’accès aux ressources de ces charges de travail ou fournir les ressources plusieurs fois pour plusieurs comptes. Vous pouvez utiliser des constructions pour compartimenter votre environnement, par exemple des environnements de développement, de test et de production. Cependant, le fait d’avoir des constructions distinctes ne vous empêche pas de partager en toute sécurité. En partageant des composants qui se chevauchent, vous pouvez réduire les frais d’exploitation et offrir une expérience cohérente sans avoir à deviner ce que vous avez pu manquer en créant la même ressource plusieurs fois.
**Résultat escompté :** minimisez les accès involontaires en utilisant des méthodes sécurisées pour partager les ressources au sein de votre organisation et contribuer à votre initiative de prévention des pertes de données. Réduisez vos frais généraux opérationnels par rapport à la gestion de composants individuels, réduisez les erreurs liées à la création manuelle du même composant plusieurs fois et augmentez la capacité de mise à l’échelle de vos charges de travail. Vous pouvez bénéficier d’une réduction du délai de résolution dans les scénarios de défaillance multipoints et augmenter votre confiance dans l’évaluation du moment où un composant n’est plus nécessaire. Pour obtenir des conseils prescriptifs sur l’analyse des ressources partagées en externe, voir [SEC03-BP07 Analyser l’accès public et intercompte](sec_permissions_analyze_cross_account.md).
**Anti-modèles courants :**
+ Manque de processus pour surveiller continuellement et alerter automatiquement sur un partage externe inattendu.
+ Manque de référence sur ce qui doit être partagé et ce qui ne doit pas l’être.
+ Adoption par défaut d’une politique largement ouverte au lieu de la partager explicitement lorsque c’est nécessaire.
+ Création manuelle des ressources de base qui se chevauchent si nécessaire.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Concevez vos contrôles et modèles d’accès de façon à régir la consommation de ressources partagées en toute sécurité et uniquement avec des entités approuvées. Surveillez les ressources partagées et examinez l’accès aux ressources partagées en permanence, et soyez alerté sur les partages inappropriés ou inattendus. Consultez [Analyser l’accès public et intercompte](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html) pour vous aider à établir une gouvernance visant à réduire l’accès externe aux seules ressources qui en ont besoin, et à établir un processus de surveillance continue et d’alerte automatique.
Le partage entre comptes au sein de AWS Organizations est pris en charge par [un certain nombre de services AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html), tels que [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html), [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html) et [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html). Ces services permettent de partager les données vers un compte central, de rendre les données accessibles à partir d’un compte central ou de gérer les ressources et les données à partir d’un compte central. Par exemple, AWS Security Hub CSPM peut transférer les résultats des comptes individuels vers un compte central où vous pouvez voir tous ces résultats. AWS Backup peut prendre une sauvegarde pour une ressource et la partager entre les comptes. Vous pouvez utiliser [AWS Resource Access Manager](https://aws.amazon.com/ram/) (AWS RAM) pour partager d’autres ressources communes, telles que des [sous-réseaux VPC et des attachements de la passerelle de transit](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc), [AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall) ou des [pipelines d'IA Amazon SageMaker](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker).
Pour empêcher votre compte de partager uniquement les ressources au sein de votre organisation, utilisez des [politiques de contrôle des services (SCP)](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) pour empêcher l’accès aux principaux externes. Lorsque vous partagez des ressources, combinez les contrôles basés sur l’identité et les contrôles réseau pour [créer un périmètre de données pour votre organisation](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) afin de la protéger contre tout accès non intentionnel. Un périmètre de données est un ensemble de barrières de protection préventives qui vous permettent de vous assurer que seules les identités approuvées accèdent aux ressources approuvées à partir des réseaux attendus. Ces contrôles doivent placer des limites appropriées pour les ressources susceptibles d’être partagées et empêcher le partage ou l’exposition de ressources qui ne doivent pas être autorisées. Par exemple, dans le cadre de votre périmètre de données, vous pouvez utiliser les politiques de point de terminaison d’un VPC et la condition `AWS:PrincipalOrgId` pour garantir que les identités accédant à vos compartiments Amazon S3 appartiennent à votre organisation. Il est important de noter que les [SCP ne s’appliquent pas aux rôles liés aux services ou aux principaux de service AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions).
Lorsque vous utilisez Amazon S3, [désactivez les ACL pour votre compartiment Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) et utilisez les politiques IAM pour définir le contrôle d’accès. Pour [restreindre l’accès à une origine Amazon S3](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) à partir d’[Amazon CloudFront](https://aws.amazon.com/cloudfront/), migrez l’identité d’accès d’origine (OAI) vers le contrôle d’accès d’origine (OAC) qui prend en charge des fonctionnalités supplémentaires, dont le chiffrement côté serveur avec [AWS Key Management Service](https://aws.amazon.com/kms/).
Dans certains cas, vous pouvez autoriser le partage des ressources à l’extérieur de votre organisation ou accorder à un tiers l’accès à vos ressources. Pour obtenir des conseils prescriptifs sur la gestion des autorisations de partage de ressources en externe, consultez la section [Gestion des autorisations](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html).
### Étapes d’implémentation
1. **Utilisez AWS Organizations :** AWS Organizations est un service de gestion de comptes qui vous permet de consolider plusieurs Comptes AWS en une organisation que vous créez et gérez de façon centralisée. Vous pouvez regrouper vos comptes en unités d’organisation (OU) et joindre différentes politiques à chacune d’entre elles afin de vous aider à répondre à vos besoins en matière de budget, de sécurité et de conformité. Vous pouvez également contrôler la façon dont l’intelligence artificielle (IA) et le machine learning (ML) d’AWS peuvent collecter et stocker des données, et utiliser la gestion multicompte des services AWS intégrés à Organizations.
1. **Intégrez AWS Organizations aux services AWS :** lorsque vous utilisez un service AWS pour exécuter des tâches en votre nom dans les comptes membres de votre organisation, AWS Organizations crée un rôle lié à un service IAM (SLR) pour ce service dans chaque compte membre. Gérez l’accès approuvé à l’aide de la AWS Management Console, des API AWS ou de la AWS CLI. Pour obtenir des conseils prescriptifs sur l’activation de l’accès sécurisé, voir [Utilisation d’AWS Organizations avec d’autres services AWS](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html) et [services AWS que vous pouvez utiliser avec Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html).
1. **Établissez un périmètre de données :** un périmètre de données fournit une délimitation claire de la confiance et de la propriété. Sur AWS, il est généralement représenté comme votre organisation AWS gérée par AWS Organizations, ainsi que par tous les réseaux ou systèmes sur site qui accèdent à vos ressources AWS. L’objectif du périmètre de données est de vérifier que l’accès est autorisé si l’identité est approuvée, si la ressource est approuvée et si le réseau est attendu. Toutefois, l’établissement d’un périmètre de données n’est pas une approche universelle. Évaluez et adoptez les objectifs de contrôle décrits dans le [livre blanc Construire un périmètre sur AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/welcome.html) sur la base de vos modèles de risques de sécurité et de vos exigences spécifiques. Vous devez examiner attentivement votre position unique en matière de risque et mettre en œuvre les contrôles périmétriques adaptés à vos besoins en matière de sécurité.
1. **Utilisez le partage des ressources dans les services AWS et limitez en conséquence :** de nombreux services AWS vous permettent de partager des ressources avec un autre compte ou de cibler une ressource d’un autre compte, comme [Amazon Machine Images (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) et [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html). Limitez l’API `ModifyImageAttribute` pour spécifier les comptes fiables avec lesquels partager l’AMI. Spécifiez la condition `ram:RequestedAllowsExternalPrincipals` lors de l’utilisation de AWS RAM pour limiter le partage à votre organisation uniquement, afin d’empêcher l’accès par des identités non fiables. Pour des conseils et des considérations prescriptifs, voir [Partage des ressources et cibles externes](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html).
1. **Utilisez AWS RAM pour partager en toute sécurité dans un compte ou avec d’autres Comptes AWS :** [AWS RAM](https://aws.amazon.com/ram/) vous aide à partager en toute sécurité les ressources que vous avez créées avec les rôles et les utilisateurs de votre compte et avec d’autres Comptes AWS. Dans un environnement multicompte, AWS RAM vous permet de créer une ressource une fois et de la partager avec d’autres comptes. Cette approche permet de réduire vos frais généraux opérationnels tout en assurant la cohérence, la visibilité et l’auditabilité grâce à des intégrations avec Amazon CloudWatch et AWS CloudTrail, que vous ne recevez pas lorsque vous utilisez l’accès intercompte.
Si vous avez déjà partagé des ressources à l’aide d’une politique basée sur les ressources, vous pouvez utiliser l’[API `PromoteResourceShareCreatedFromPolicy`](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) ou un équivalent pour transformer le partage de ressources en partage de ressources AWS RAM complet.
Dans certains cas, vous devrez peut-être prendre des mesures supplémentaires pour partager les ressources. Par exemple, pour partager un instantané chiffré, vous devez [partager une clé AWS KMS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-kms-key).
## Ressources
**Bonnes pratiques associées :**
+ [SEC03-BP07 Analyser l’accès public et intercompte](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP09 Partager des ressources en toute sécurité avec un tiers](sec_permissions_share_securely_third_party.md)
+ [SEC05-BP01 Créer des couches réseau](sec_network_protection_create_layers.md)
**Documents connexes :**
+ [Propriétaire d’un compartiment accordant des autorisations entre comptes à des objets qu’il ne possède pas](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [How to use Trust Policies with IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Building Data Perimeter on AWS](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)
+ [Procédure d’utilisation d’un ID externe lorsque vous accordez l’accès à vos ressources AWS à un tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [Services AWS que vous pouvez utiliser avec AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [ Établissement d’un périmètre de données sur AWS : autoriser uniquement les identités fiables à accéder aux données de l’entreprise](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/)
**Vidéos connexes :**
+ [Granular Access with AWS Resource Access Manager](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [Securing your data perimeter with VPC endpoints](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [ Establishing a data perimeter on AWS](https://www.youtube.com/watch?v=SMi5OBjp1fI)
**Outils associés :**
+ [ Exemples de stratégies relatives au périmètre des données ](https://github.com/aws-samples/data-perimeter-policy-examples)
# SEC03-BP09 Partager des ressources en toute sécurité avec un tiers
La sécurité de votre environnement cloud ne s’arrête pas à votre organisation. Votre organisation peut faire appel à un tiers pour gérer une partie de vos données. La gestion des autorisations du système administré par un tiers doit suivre la pratique de l’accès à la demande en appliquant le principe de moindre privilège avec des informations d’identification temporaires. En travaillant en étroite collaboration avec un tiers, vous pouvez réduire l’étendue de l’impact et du risque d’accès involontaire.
**Résultat escompté :** vous évitez d’utiliser des informations d’identification à long terme Gestion des identités et des accès AWS (IAM) telles que des clés d’accès et des clés secrètes, car elles présentent un risque de sécurité en cas d’utilisation abusive. Vous utilisez plutôt des rôles IAM et des informations d’identification temporaires pour améliorer votre niveau de sécurité et minimiser les frais opérationnels liés à la gestion des informations d’identification à long terme. Lorsque vous accordez l’accès à un tiers, vous utilisez un identifiant unique universel (UUID) comme ID externe dans la politique d’approbation IAM et vous maintenez sous votre contrôle les politiques IAM attachées au rôle afin de garantir un accès sur la base du moindre privilège. Pour obtenir des conseils prescriptifs sur l’analyse des ressources partagées en externe, consultez [SEC03-BP07 Analyser l’accès public et intercompte](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html).
**Anti-modèles courants :**
+ Utilisation de la politique d’approbation IAM sans aucune condition.
+ Utilisation des informations d’identification IAM et de clés d’accès à long terme.
+ Réutilisation des ID externes.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Vous pouvez autoriser le partage des ressources en dehors d’AWS Organizations ou accorder un accès tiers à votre compte. Par exemple, un tiers peut fournir une solution de surveillance qui doit accéder aux ressources de votre compte. Dans ces cas de figure, vous devez créer un rôle intercompte IAM en lui attribuant uniquement les privilèges requis par le tiers. Définissez également une politique d’approbation à l’aide de la [condition d’ID externe](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html). Lorsque vous utilisez un identifiant externe, vous pouvez (ou le tiers peut) générer un identifiant unique pour chaque client, tiers ou location. L’ID unique ne doit être contrôlé que par vous après sa création. Le tiers doit implémenter un processus pour relier l’ID externe au client de manière sécurisée, auditable et reproductible.
Vous pouvez également utiliser les [Rôles Anywhere IAM](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) afin de gérer les rôles IAM pour des applications autres que AWS qui utilisent des API AWS.
Si le tiers n’a plus besoin d’accéder à votre environnement, supprimez le rôle. Évitez de fournir à des tiers des informations d’identification à long terme. Gardez un œil sur les autres services AWS qui prennent en charge le partage, comme l’AWS Well-Architected Tool qui permet le [partage d’une charge de travail](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html) avec d’autres Comptes AWS et [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) qui vous aide à partager en toute sécurité une ressource AWS que vous possédez avec d’autres comptes.
### Étapes d’implémentation
1. **Utilisez des rôles intercomptes pour accéder aux comptes externes.** Les [rôles intercomptes](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) réduisent la quantité d’informations sensibles stockées par les comptes externes et les tiers pour servir leurs clients. Les rôles intercomptes vous permettent d’accorder l’accès aux ressources AWS de votre compte en toute sécurité à un tiers, par exemple aux partenaires AWS ou à d’autres comptes de votre organisation, tout en préservant la capacité de gérer et d’auditer cet accès. Il se peut que le tiers vous fournisse des services à partir d’une infrastructure hybride ou qu’il extraie des données vers un emplacement externe. [Rôles Anywhere IAM](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) vous permet d’autoriser des charges de travail tierces à interagir en toute sécurité avec vos charges de travail AWS et de réduire encore le besoin d’informations d’identification à long terme.
Vous ne devez pas utiliser d’informations d’identification à long terme ni de clés d’accès associées aux utilisateurs pour fournir un accès à un compte externe. Utilisez plutôt les rôles intercomptes pour fournir l’accès intercompte.
1. **Faites preuve d’une diligence raisonnable et garantissez un accès sécurisé aux fournisseurs SaaS tiers.** Lorsque vous partagez des ressources avec des fournisseurs SaaS tiers, faites preuve de toute la diligence appropriée pour vous assurer qu’ils adoptent une approche sûre et responsable de l’accès à vos ressources AWS. Évaluez leur modèle de responsabilité partagée pour comprendre les mesures de sécurité qu’ils fournissent et celles qui relèvent de votre responsabilité. Assurez-vous que le fournisseur SaaS dispose d’un processus sécurisé et auditable pour accéder à vos ressources, y compris l’utilisation d’[identifiants externes](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) et les principes d’accès sur la base du moindre privilège. L’utilisation d’identifiants externes permet de résoudre le [problème de l’adjoint confus](https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/).
Mettez en œuvre des contrôles de sécurité pour garantir un accès sécurisé et le respect du principe du moindre privilège lorsque vous accordez l’accès à des fournisseurs SaaS tiers. Cela peut inclure l’utilisation d’identifiants externes, d’identifiants uniques universels (UUID) et de politiques d’approbation IAM qui limitent l’accès au strict nécessaire. Travaillez en étroite collaboration avec le fournisseur SaaS pour établir des mécanismes d’accès sécurisés, passez régulièrement en revue son accès à vos ressources AWS et effectuez des audits pour garantir le respect de vos exigences de sécurité.
1. **Rendez obsolètes les informations d’identification à long terme fournies par le client.** Rendez obsolète l’utilisation d’informations d’identification à long terme et utilisez des rôles intercomptes ou Rôles Anywhere IAM. Si vous devez utiliser des informations d’identification à long terme, élaborez un plan pour migrer vers un accès basé sur les rôles. Pour plus de détails sur la gestion des clés, consultez [Gestion des identités](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-management.html). Collaborez également avec votre équipe Compte AWS et le tiers pour établir un dossier d¦exploitation d’atténuation des risques. Pour obtenir des conseils prescriptifs sur la réponse à un incident de sécurité et l’atténuation de son impact potentiel, consultez [Réponse aux incidents](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html).
1. **Vérifiez que la configuration est guidée par des instructions prescriptives ou qu’elle est automatisée.** L’ID externe n’est pas considéré comme un secret, mais il ne doit pas être facile à deviner, comme un numéro de téléphone, un nom ou un numéro de compte. Faites de l’ID externe un champ en lecture seule afin qu’il ne puisse pas être modifié dans le but d’usurper la configuration.
Vous ou le tiers pouvez générer l’ID externe. Définissez un processus pour déterminer qui est responsable de la génération de l’ID. Quelle que soit l’entité qui crée l’ID externe, le tiers applique l’unicité et les formats de façon uniforme parmi les clients.
La politique créée pour l’accès intercompte à vos comptes doit respecter le [principe de moindre privilège.](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) Le tiers doit fournir un document de politique de rôle ou un mécanisme de configuration automatisé qui utilise un modèle AWS CloudFormation ou un équivalent pour vous. Cela réduit le risque d’erreurs associées à la création manuelle de politiques et offre une piste auditable. Pour plus d’informations sur l’utilisation d’un modèle AWS CloudFormation pour créer des rôles intercomptes, consultez [Rôles intercomptes](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/).
Le tiers doit fournir un mécanisme de configuration automatisé et auditable. Cependant, si vous utilisez le document de politique de rôle décrivant l’accès nécessaire, vous devez automatiser la configuration du rôle. Si vous utilisez un modèle AWS CloudFormation ou un équivalent, vous devez surveiller les changements via une détection des dérives dans le cadre de la pratique d’audit.
1. **Tenez compte des modifications.** Votre structure de compte, la nécessité de faire appel à un tiers, ou son offre de service peuvent changer. Vous devez anticiper les changements et les défaillances, et planifier en conséquence avec les personnes, processus et technologies appropriés. Auditez régulièrement le niveau d’accès que vous fournissez et implémentez des méthodes de détection de changements imprévus. Surveillez et auditez l’utilisation du rôle et de l’entrepôt de données des ID externes. Vous devez être prêt à révoquer l’accès tiers, de façon temporaire ou permanente, en raison de changements ou de tendances d’accès imprévus. De plus, mesurez l’impact sur votre opération de révocation, y compris le temps nécessaire pour l’exécution, les personnes impliquées, le coût et l’impact sur d’autres ressources.
Pour obtenir des conseils prescriptifs sur les méthodes de détection, consultez la section [Bonnes pratiques en matière de détection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html).
## Ressources
**Bonnes pratiques associées :**
+ [SEC02-BP02 Utiliser des informations d’identification temporaires](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC03-BP05 Définir des garde-fous des autorisations pour votre organisation](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_define_guardrails.html)
+ [SEC03-BP06 Gérer l’accès en fonction du cycle de vie](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
+ [SEC03-BP07 Analyser l’accès public et intercompte](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC04 Détection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**Documents connexes :**
+ [Le propriétaire du compartiment accorde une autorisation multicompte à des objets qu’il ne possède pas](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [Comment utiliser des politiques d’approbation avec les rôles IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Déléguer l’accès entre des Comptes AWS à l’aide des rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ [Comment accéder aux ressources d’un autre Compte AWS à l’aide d’IAM ?](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/)
+ [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Logique d’évaluation des politiques intercomptes](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)
+ [Procédure d’utilisation d’un ID externe lorsque vous accordez l’accès à vos ressources AWS à un tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [Collecte d’informations à partir de ressources AWS CloudFormation créées dans des comptes externes avec des ressources personnalisées](https://aws.amazon.com/blogs/apn/collecting-information-from-aws-cloudformation-resources-created-in-external-accounts-with-custom-resources/)
+ [Utilisation sécurisée d’identifiants externes pour accéder à des comptes AWS détenus par d’autres](https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)
+ [Extension des rôles IAM à des charges de travail situées en dehors d’IAM avec Rôles Anywhere IAM](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/)
**Vidéos connexes :**
+ [Comment accorder à des utilisateurs ou des rôles situés dans un Compte AWS distinct l’accès à mon Compte AWS ?](https://www.youtube.com/watch?v=20tr9gUY4i0)
+ [AWS re:Invent 2018: Become an IAM Policy Master in 60 Minutes or Less](https://www.youtube.com/watch?v=YQsK4MtsELU)
+ [AWS Knowledge Center Live : Bonnes pratiques IAM et décisions de conception](https://www.youtube.com/watch?v=xzDFPIQy4Ks)
**Exemples connexes :**
+ [Configuration de l'accès intercompte à Amazon DynamoDB](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)
+ [Outil de requête réseau AWS STS](https://github.com/aws-samples/aws-sts-network-query-tool)