Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Amministrazione delegata

L'amministrazione delegata offre agli utenti assegnati in un account membro registrato un modo pratico per eseguire la maggior parte delle attività amministrative di IAM Identity Center. Quando abiliti IAM Identity Center, per impostazione predefinita, l'istanza IAM Identity Center viene AWS Organizations creata nell'account di gestione. Originariamente è stato progettato in questo modo per consentire a IAM Identity Center di effettuare il provisioning, il de-provisioning e l'aggiornamento dei ruoli in tutti gli account dei membri dell'organizzazione. Anche se l'istanza IAM Identity Center deve sempre risiedere nell'account di gestione, puoi scegliere di delegare l'amministrazione di IAM Identity Center a un account membro in AWS Organizations, estendendo così la capacità di gestire IAM Identity Center dall'esterno dell'account di gestione.

L'abilitazione dell'amministrazione delegata offre i seguenti vantaggi:

Per ulteriori informazioni su come funziona IAM Identity Center AWS Organizations, consulta. Account AWS accesso Per ulteriori informazioni e per esaminare uno scenario aziendale di esempio che mostra come configurare l'amministrazione delegata, consulta Guida introduttiva all'amministrazione delegata di IAM Identity Center nel AWS Security Blog.

Best practice

Ecco alcune best practice da considerare prima di configurare l'amministrazione delegata:

Limita le azioni di archiviazione delle identità di IAM Identity Center nell'account di amministrazione delegato con fonti di identità esterne

Se utilizzi una fonte di identità esterna come un IdP o AWS Directory Service, dovresti implementare politiche che limitino le azioni di archiviazione delle identità che un amministratore di IAM Identity Center può eseguire dall'interno dell'account di amministrazione delegato. Le operazioni di scrittura ed eliminazione devono essere considerate con attenzione. In genere, la fonte di identità esterna è la fonte di verità per gli utenti e i relativi attributi e per l'appartenenza ai gruppi. Se li modifichi utilizzando l'archivio di identità APIs o la console, le modifiche verranno sovrascritte durante i normali cicli di sincronizzazione. È meglio lasciare queste operazioni al controllo esclusivo della fonte di verità della propria identità. Ciò impedisce inoltre che un amministratore di IAM Identity Center modifichi le appartenenze ai gruppi per concedere l'accesso a un set di autorizzazioni o a un'applicazione assegnati dal gruppo, anziché lasciare il controllo dell'appartenenza al gruppo all'amministratore IdP. È inoltre necessario evitare chi può creare token SCIM bearer dall'account di amministrazione delegato, in quanto questi potrebbero consentire a un amministratore dell'account membro di modificare gruppi e utenti tramite un client SCIM.

Ci possono essere momenti in cui le operazioni di scrittura o cancellazione dall'account amministratore delegato sono appropriate. Ad esempio, puoi creare un gruppo senza aggiungere membri, quindi assegnare assegnazioni a un set di autorizzazioni senza dover attendere che l'amministratore IdP crei il gruppo. Nessuno avrà accesso a quell'assegnazione finché l'amministratore IdP non provvede al gruppo e il processo di sincronizzazione IdP non stabilisce i membri del gruppo. Potrebbe anche essere opportuno eliminare un utente o un gruppo per impedire l'accesso o l'autorizzazione durante un periodo in cui non è possibile attendere il processo di sincronizzazione IdP per rimuovere l'accesso dell'utente o del gruppo. Tuttavia, l'uso improprio di questa autorizzazione può causare problemi agli utenti. È necessario utilizzare il principio del privilegio minimo quando si assegnano le autorizzazioni dell'archivio di identità. È possibile controllare quali azioni di archiviazione delle identità sono consentite dagli amministratori degli account di amministrazione delegati utilizzando una policy di controllo del servizio (SCP).

L'esempio SCP riportato di seguito impedisce l'assegnazione di utenti a gruppi tramite l'API Identity Store e la AWS Management Console, operazione consigliata quando la fonte di identità è esterna. Ciò non influisce sulla sincronizzazione degli utenti da AWS Directory Service o verso un IdP esterno (tramite SCIM).

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

Se desideri evitare di aggiungere utenti solo ai gruppi che concedono l'accesso all'account di gestione, puoi fare riferimento a quei gruppi specifici utilizzando l'ARN del gruppo nel seguente formato:. arn:${Partition}:identitystore:::group/${GroupId} Questo e altri tipi di risorse disponibili in Identity Store sono documentati in Tipi di risorse definiti da AWS Identity Store nel Service Authorization Reference. Puoi anche considerare di includere un Identity Store aggiuntivo APIs in SCP. Per ulteriori informazioni, consulta Actions in the Identity Store API Reference.

Aggiungendo la seguente dichiarazione politica al tuo SCP, puoi impedire la creazione di token portatori SCIM da parte dell'amministratore delegato. Puoi applicarlo a entrambe le fonti di identità esterne.

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

Limita le azioni di archiviazione delle identità di IAM Identity Center nell'account di amministrazione delegato per gli utenti gestiti localmente

Se crei utenti e gruppi direttamente in IAM Identity Center, anziché utilizzare un IdP esterno o AWS Directory Service, dovresti prendere precauzioni per chi può creare utenti, reimpostare le password e controllare l'appartenenza ai gruppi. Queste azioni conferiscono all'amministratore ampi poteri su chi può accedere e chi può accedervi tramite l'appartenenza a gruppi. È meglio implementarle come politiche in linea all'interno dei set di autorizzazioni utilizzati per gli amministratori di IAM Identity Center, anziché come. SCPs L'esempio seguente di politica in linea ha due obiettivi. Innanzitutto, impedisce l'aggiunta di utenti a gruppi specifici. Puoi usarlo per impedire agli amministratori delegati di aggiungere utenti ai gruppi che concedono l'accesso all'account di gestione. In secondo luogo, impedisce l'emissione di token al portatore 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": [ "*" ] }
  ]
}
                

Separa la gestione della configurazione di IAM Identity Center dalla gestione PermissionSet

Separa le attività amministrative, tra cui la modifica dell'origine dell'identità esterna, la gestione dei token SCIM, la configurazione del timeout della sessione, dalle attività di creazione, modifica e assegnazione dei set di autorizzazioni creando set di autorizzazioni di amministrazione distinti dal tuo account di gestione.

Limita l'emissione di token portatori SCIM

I token portatori SCIM consentono a una fonte di identità esterna di fornire utenti, gruppi e appartenenze ai gruppi tramite il protocollo SCIM quando la fonte di identità del tuo IAM Identity Center è un IdP esterno come Okta o Entra ID. È possibile configurare il seguente SCP per impedire la creazione di token portatori SCIM da parte degli amministratori delegati. Se l'amministratore delegato deve configurare il provisioning degli utenti con SCIM o eseguire la rotazione periodica dei token SCIM bearer, sarà necessario consentire temporaneamente l'accesso a questa API per consentire all'amministratore delegato di completare tali attività.

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

Utilizzate i tag dei set di autorizzazioni e gli elenchi di account per delegare l'amministrazione di account specifici

Puoi creare set di autorizzazioni da assegnare agli amministratori del tuo IAM Identity Center per delegare chi può creare set di autorizzazioni e chi può assegnare quali set di autorizzazioni in quali account. Questo viene fatto etichettando i set di autorizzazioni e utilizzando le condizioni delle policy nei set di autorizzazioni assegnati agli amministratori. Ad esempio, è possibile creare set di autorizzazioni che consentono a un utente di creare set di autorizzazioni a condizione che venga etichettato in un determinato modo. È inoltre possibile creare politiche che consentano a un amministratore di assegnare set di autorizzazioni con un tag specifico in determinati account. In questo modo è possibile delegare la gestione degli account senza concedere a un amministratore i privilegi per modificare il proprio accesso e i privilegi sull'account di amministrazione delegato. Ad esempio, etichettando i set di autorizzazioni utilizzati solo nell'account di amministrazione delegato, è possibile specificare una politica che conceda solo a determinate persone le autorizzazioni per modificare i set di autorizzazioni e le assegnazioni che influiscono sull'account di amministrazione delegato. È inoltre possibile concedere ad altre persone le autorizzazioni per gestire un elenco di account esterni all'account di amministrazione delegato. Per ulteriori informazioni, consulta la sezione Delega della gestione dei set di autorizzazioni e dell'assegnazione degli account AWS IAM Identity Center nel Security Blog.AWS

Prerequisiti

Prima di poter registrare un account come amministratore delegato, devi prima aver distribuito il seguente ambiente: