Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Administration déléguée

L'administration déléguée permet aux utilisateurs assignés d'un compte de membre enregistré d'effectuer facilement la plupart des tâches administratives d'IAM Identity Center. Lorsque vous activez IAM Identity Center, votre instance IAM Identity Center est créée dans le compte de gestion AWS Organizations par défaut. Il a été initialement conçu de cette façon afin qu'IAM Identity Center puisse provisionner, déprovisionner et mettre à jour des rôles sur tous les comptes membres de votre organisation. Même si votre instance IAM Identity Center doit toujours résider dans le compte de gestion, vous pouvez choisir de déléguer l'administration d'IAM Identity Center à un compte de membre AWS Organizations, élargissant ainsi la capacité de gérer IAM Identity Center depuis l'extérieur du compte de gestion.

L'activation de l'administration déléguée présente les avantages suivants :

Pour plus d'informations sur la façon dont IAM Identity Center fonctionne avec AWS Organizations, consultezConfigurer l'accès à Comptes AWS. Pour plus d'informations et pour consulter un exemple de scénario d'entreprise montrant comment configurer l'administration déléguée, consultez la rubrique Démarrage avec l'administration déléguée d'IAM Identity Center dans le blog consacré à la AWS sécurité.

Bonnes pratiques

Voici quelques bonnes pratiques à prendre en compte avant de configurer l'administration déléguée :

Limiter les actions de la banque d'identités IAM Identity Center dans le compte d'administration déléguée avec des sources d'identité externes

Si vous utilisez une source d'identité externe telle qu'un IdP ou Directory Service, vous devez mettre en œuvre des politiques qui limitent les actions de la banque d'identités qu'un administrateur IAM Identity Center peut effectuer depuis le compte d'administration déléguée. Les opérations d'écriture et de suppression doivent être soigneusement prises en compte. En général, la source d'identité externe est la source de vérité pour les utilisateurs et leurs attributs, ainsi que pour les appartenances à des groupes. Si vous les modifiez à l'aide des API de la boutique d'identités ou de la console, vos modifications seront remplacées au cours des cycles de synchronisation normaux. Il est préférable de laisser ces opérations au contrôle exclusif de votre identité source de vérité. Cela évite également qu'un administrateur IAM Identity Center ne modifie l'appartenance à un groupe pour accorder l'accès à un ensemble d'autorisations ou à une application attribués au groupe, au lieu de laisser le contrôle de l'appartenance au groupe à votre administrateur IdP. Vous devez également vous demander qui peut créer des jetons porteurs SCIM à partir du compte d'administration délégué, car cela pourrait permettre à l'administrateur du compte d'un membre de modifier des groupes et des utilisateurs via un client SCIM.

Il peut arriver que des opérations d'écriture ou de suppression soient appropriées à partir du compte administrateur délégué. Par exemple, vous pouvez créer un groupe sans ajouter de membres, puis attribuer des autorisations à un ensemble d'autorisations sans avoir à attendre que l'administrateur de l'IdP crée le groupe. Personne n'aura accès à cette attribution tant que l'administrateur de l'IdP n'aura pas configuré le groupe et que le processus de synchronisation de l'IdP n'aura pas défini les membres du groupe. Il peut également être approprié de supprimer un utilisateur ou un groupe pour empêcher la connexion ou l'autorisation pendant une période où vous ne pouvez pas attendre que le processus de synchronisation IdP supprime l'accès de l'utilisateur ou du groupe. Cependant, une mauvaise utilisation de cette autorisation peut perturber les utilisateurs. Vous devez utiliser le principe du moindre privilège lorsque vous attribuez des autorisations de magasin d'identités. Vous pouvez contrôler quelles actions de la banque d'identités sont autorisées par les administrateurs de votre compte d'administration déléguée à l'aide d'une politique de contrôle des services (SCP).

L'exemple de SCP ci-dessous empêche d'affecter des utilisateurs à des groupes via l'API Identity Store et le Console de gestion AWS, ce qui est recommandé lorsque votre source d'identité est externe. Cela n'affecte pas la synchronisation des utilisateurs depuis Directory Service ou depuis un IdP externe (via SCIM).

{
  "Version": "2012-10-17", 
  "Statement": [
    { "Effect": "Deny",
      "Action": ["identitystore:CreateGroupMembership"],
      "Resource": [ "*" ] }
  ]
}

Si vous souhaitez empêcher l'ajout d'utilisateurs uniquement aux groupes qui accordent l'accès au compte de gestion, vous pouvez référencer ces groupes spécifiques à l'aide de l'ARN du groupe au format suivant :arn:${Partition}:identitystore:::group/${GroupId}. Ce type de ressource et les autres types disponibles dans l'Identity Store sont documentés dans la section Types de ressources définis par AWS Identity Store dans la référence d'autorisation de service. Vous pouvez également envisager d'inclure des API Identity Store supplémentaires dans le SCP. Pour plus d'informations, consultez la section Actions dans la référence de l'API Identity Store.

En ajoutant la déclaration de politique suivante à votre SCP, vous pouvez empêcher la création de jetons porteurs SCIM par l'administrateur délégué. Vous pouvez l'appliquer aux deux sources d'identité externes.

    { "Effect": "Deny",
      "Action": ["sso-directory:CreateBearerToken"],
      "Resource": [ "*" ]
    }

Limiter les actions de la banque d'identités IAM Identity Center dans le compte d'administration déléguée pour les utilisateurs gérés localement

Si vous créez vos utilisateurs et vos groupes directement dans IAM Identity Center, plutôt que d'utiliser un IdP externe Directory Service, vous devez prendre des précautions pour déterminer qui peut créer des utilisateurs, réinitialiser les mots de passe et contrôler l'appartenance aux groupes. Ces actions confèrent à l'administrateur de grands pouvoirs pour déterminer qui peut se connecter et qui peut y accéder en faisant partie de groupes. Il est préférable de mettre en œuvre ces politiques en tant que politiques en ligne au sein des ensembles d'autorisations que vous utilisez pour les administrateurs de votre IAM Identity Center, plutôt que comme des SCP. L'exemple de politique en ligne suivant poursuit deux objectifs. Tout d'abord, cela empêche l'ajout d'utilisateurs à des groupes spécifiques. Vous pouvez l'utiliser pour empêcher les administrateurs délégués d'ajouter des utilisateurs à des groupes qui accordent l'accès au compte de gestion. Deuxièmement, cela empêche l'émission de jetons au porteur SCIM.

{ 
  "Version": "2012-10-17", 
  "Statement": [ 
  { "Effect": "Deny", 
    "Action": ["identitystore:CreateGroupMembership"],
    "Resource": [ arn:${Partition}:identitystore:::group/${GroupId1}, 
                  arn:${Partition}:identitystore:::group/${GroupId2} 
                 ] 
   }
  ],
  { "Effect": "Deny", 
    "Action": ["sso-directory:CreateBearerToken"],
    "Resource": [ "*" ] }
  ]
}
                

Séparer la gestion de la configuration d'IAM Identity Center de la gestion PermissionSet

Séparez les tâches administratives, y compris la modification de la source d'identité externe, la gestion des jetons SCIM, la configuration du délai d'expiration des sessions, des tâches de création, de modification et d'attribution d'ensembles d'autorisations en créant des ensembles d'autorisations d'administrateur distincts à partir de votre compte de gestion.

Limiter l'émission de jetons au porteur SCIM

Les jetons porteurs SCIM permettent à une source d'identité externe de fournir des utilisateurs, des groupes et des appartenances à des groupes via le protocole SCIM lorsque la source d'identité de votre IAM Identity Center est un IdP externe tel qu'Okta ou Entra ID. Vous pouvez configurer le SCP suivant pour empêcher la création de jetons porteurs SCIM par les administrateurs délégués. Si votre administrateur délégué doit configurer le provisionnement des utilisateurs avec SCIM ou effectuer la rotation périodique des jetons porteurs SCIM, vous devrez autoriser temporairement l'accès à cette API pour permettre à l'administrateur délégué d'effectuer ces tâches.

    { "Effect": "Deny",
      "Action": ["sso-directory:CreateBearerToken"],
      "Resource": [ "*" ] 
}

Utilisez des balises d'ensembles d'autorisations et des listes de comptes pour déléguer l'administration de comptes spécifiques

Vous pouvez créer des ensembles d'autorisations que vous attribuez à vos administrateurs IAM Identity Center afin de déléguer qui peut créer des ensembles d'autorisations et qui peut attribuer quels ensembles d'autorisations à quels comptes. Cela se fait en balisant les ensembles d'autorisations et en utilisant des conditions de politique dans les ensembles d'autorisations que vous attribuez à vos administrateurs. Par exemple, vous pouvez créer des ensembles d'autorisations qui permettent à un utilisateur de créer des ensembles d'autorisations à condition qu'ils soient balisés d'une certaine manière. Vous pouvez également créer des politiques qui permettent à un administrateur d'attribuer des ensembles d'autorisations dotés d'une étiquette spécifique à des comptes spécifiques. Cela peut vous aider à déléguer la gestion des comptes sans donner à un administrateur les privilèges nécessaires pour modifier son accès et ses privilèges sur le compte d'administration délégué. Par exemple, en balisant les ensembles d'autorisations que vous utilisez uniquement dans le compte d'administration déléguée, vous pouvez spécifier une politique qui accorde uniquement à certaines personnes les autorisations nécessaires pour modifier les ensembles d'autorisations et les attributions qui affectent le compte d'administration déléguée. Vous pouvez également autoriser d'autres personnes à gérer une liste de comptes en dehors du compte d'administration déléguée. Pour en savoir plus, consultez la section Délégation de la gestion des ensembles d'autorisations et de l'attribution de comptes AWS IAM Identity Center dans le blog sur la AWS sécurité.

Conditions préalables

Avant de pouvoir enregistrer un compte en tant qu'administrateur délégué, vous devez d'abord déployer l'environnement suivant :