# 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)