Fédération IAM

Note

Si vous disposez déjà d'un annuaire d'utilisateurs central pour gérer les utilisateurs et les groupes, nous vous recommandons d'utiliser IAM Identity Center comme principal service d'accès au personnel. Si l'une des considérations de conception abordées plus loin dans cette section vous empêche d'utiliser IAM Identity Center, utilisez la fédération IAM au lieu de créer des utilisateurs IAM distincts au sein d'AWS.

La fédération IAM établit un système de confiance entre deux parties dans le but d'authentifier les utilisateurs et de partager les informations nécessaires pour autoriser leur accès aux ressources. Ce système nécessite un fournisseur d'identité (IdP) connecté à votre annuaire d'utilisateurs et un fournisseur de services (SP) géré dans IAM. L'IdP est chargé d'authentifier les utilisateurs et de fournir les données contextuelles d'autorisation pertinentes à IAM, et IAM contrôle l'accès aux ressources dans les comptes et les environnements AWS.

La fédération IAM prend en charge les normes couramment utilisées telles que SAML 2.0 et OpenID Connect (OIDC). La fédération basée sur le protocole SAML est prise en charge par de nombreuses personnes IdPs et permet aux utilisateurs de se connecter à l'AWS Management Console ou d'appeler une API AWS sans avoir à créer d'utilisateurs IAM. Vous pouvez créer des identités utilisateur dans AWS à l'aide d'IAM ou vous connecter à votre IdP existant (par exemple, Microsoft Active Directory, Okta, Ping Identity ou Microsoft Entra ID). Vous pouvez également utiliser un fournisseur d'identité IAM OIDC lorsque vous souhaitez établir un lien de confiance entre un IdP compatible OIDC et votre compte AWS.

Il existe deux modèles de conception pour la fédération IAM : la fédération multi-comptes ou la fédération monocompte.

Fédération IAM multi-comptes

Dans ce modèle IAM multi-comptes, vous établissez une relation de confiance SAML distincte entre l'IdP et tous les comptes AWS qui doivent être intégrés. Les autorisations sont mappées et allouées sur la base d'un compte individuel. Ce modèle de conception fournit une approche distribuée de la gestion des rôles et des politiques, et vous donne la flexibilité d'activer un IdP SAML ou OIDC distinct pour chaque compte et d'utiliser des attributs utilisateur fédérés pour le contrôle d'accès.

La fédération IAM multi-comptes offre les avantages suivants :

• Fournit un accès centralisé à tous vos comptes AWS et vous permet de gérer les autorisations de manière distribuée pour chaque compte AWS.

• Améliore l'évolutivité dans une configuration multi-comptes.

• Répond aux exigences de conformité.

• Vous permet de gérer les identités à partir d'un emplacement central.

La conception est particulièrement utile si vous souhaitez gérer les autorisations de manière distribuée, séparées par des comptes AWS. Cela est également utile dans les scénarios où vous ne disposez pas d'autorisations IAM répétables pour les utilisateurs d'Active Directory dans leurs comptes AWS. Par exemple, il prend en charge les administrateurs réseau qui peuvent fournir un accès aux ressources avec de légères variations selon les comptes.

Les fournisseurs SAML doivent être créés séparément dans chaque compte, de sorte que chaque compte AWS nécessite des processus pour gérer la création, la mise à jour et la suppression des rôles IAM et de leurs autorisations. Cela signifie que vous pouvez définir des autorisations de rôle IAM précises et distinctes pour les comptes AWS avec différents niveaux de sensibilité pour la même fonction.

Le schéma suivant illustre le modèle de fédération IAM multi-comptes.

Fédération IAM à compte unique (modèle) hub-and-spoke

Note

Utilisez ce modèle de conception pour les scénarios spécifiques décrits dans cette section. Dans la plupart des scénarios, la fédération basée sur IAM Identity Center ou la fédération IAM multi-comptes est l'approche recommandée. Pour toute question, contactez le support AWS.

Dans le modèle de fédération à compte unique, la relation de confiance SAML est établie entre l'IdP et un seul compte AWS (le compte d'identité). Les autorisations sont mappées et allouées via le compte d'identité centralisé. Ce modèle de conception apporte simplicité et efficacité. Le fournisseur d'identité fournit des assertions SAML mappées à des rôles (et autorisations) IAM spécifiques dans le compte d'identité. Les utilisateurs fédérés peuvent alors supposer d'accéder cross-account-roles à d'autres comptes AWS à partir du compte d'identité.

Le schéma suivant illustre le modèle de fédération IAM à compte unique.

Cas d'utilisation : 

• Entreprises disposant d'un seul compte AWS, mais qui ont parfois besoin de créer des comptes AWS de courte durée pour effectuer des tests ou des sandbox isolés.

• Établissements d'enseignement qui maintiennent leurs services de production dans un compte principal mais fournissent des comptes étudiants temporaires basés sur des projets. 

Note

Ces cas d'utilisation nécessitent une gouvernance solide et des processus de recyclage limités dans le temps afin de garantir que les données de production ne soient pas transmises aux comptes fédérés et d'éliminer les risques de sécurité potentiels. Le processus d'audit est également difficile dans ces scénarios.

Considérations relatives à la conception pour choisir entre la fédération IAM et l'IAM Identity Center

• IAM Identity Center prend en charge la connexion des comptes à un seul répertoire à la fois. Si vous utilisez plusieurs annuaires ou si vous souhaitez gérer les autorisations en fonction des attributs utilisateur, envisagez d'utiliser la fédération IAM comme alternative de conception. Vous devez disposer d'un IdP compatible avec le protocole SAML 2.0, tel que Microsoft Active Directory Federation Service (AD FS), Okta ou Microsoft Entra ID. Vous pouvez établir une confiance bidirectionnelle en échangeant des métadonnées IdP et SP, et en configurant des assertions SAML pour mapper les rôles IAM aux groupes d'annuaires d'entreprise et aux utilisateurs.

• Si vous utilisez un fournisseur d'identité IAM OIDC pour établir un lien de confiance entre un IdP compatible OIDC et votre compte AWS, pensez à utiliser la fédération IAM. Lorsque vous utilisez la console IAM pour créer un fournisseur d'identité OIDC, la console tente de récupérer l'empreinte numérique pour vous. Nous vous recommandons d'obtenir également l'empreinte de votre IdP OIDC manuellement et de vérifier que la console a récupéré la bonne empreinte. Pour plus d'informations, consultez la section Création d'un fournisseur d'identité OIDC dans IAM dans la documentation IAM.

• Utilisez la fédération IAM si les utilisateurs de votre annuaire d'entreprise ne disposent pas d'autorisations répétables pour une fonction professionnelle. Par exemple, différents administrateurs de réseau ou de base de données peuvent avoir besoin d'autorisations de rôle IAM personnalisées dans les comptes AWS. Pour ce faire, dans IAM Identity Center, vous pouvez créer des politiques distinctes gérées par le client et les référencer dans vos ensembles d'autorisations. Pour plus d'informations, consultez le billet de blog AWS How to use customer managed policies in AWS IAM Identity Center pour des cas d'utilisation avancés.

• Si vous utilisez un modèle d'autorisations distribuées, dans lequel chaque compte gère ses propres autorisations, ou un modèle d'autorisations centralisé via AWS CloudFormation StackSets, envisagez d'utiliser la fédération IAM. Si vous utilisez un modèle hybride qui implique à la fois des autorisations centralisées et distribuées, pensez à utiliser IAM Identity Center. Pour plus d'informations, consultez la section Fournisseurs d'identité et fédération dans la documentation IAM.

• Les services et fonctionnalités tels qu'Amazon Q Developer Professional et la version 2 de l'interface de ligne de commande AWS sont compatibles avec AWS Identity Center. Cependant, certaines de ces fonctionnalités ne sont pas prises en charge par la fédération IAM.

• IAM Access Analyzer ne prend actuellement pas en charge l'analyse des actions des utilisateurs d'IAM Identity Center.