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 conveniente per eseguire la maggior parte delle attività amministrative di IAM Identity Center. Quando abiliti IAM Identity Center, l'istanza di IAM Identity Center viene creata per impostazione AWS Organizations predefinita nell'account di gestione. È stato originariamente progettato in questo modo in modo che IAM Identity Center possa fornire, annullare il provisioning e aggiornare i ruoli in tutti gli account membri dell'organizzazione. Anche se la tua istanza di 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, consultaConfigurare l'accesso a Account AWS. Per ulteriori informazioni e per esaminare un esempio di scenario aziendale 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 prendere in considerazione prima di configurare l'amministrazione delegata:

Limita le azioni dell'archivio di identità di IAM Identity Center nell'account di amministrazione delegata con fonti di identità esterne

Se utilizzi una fonte di identità esterna come un IdP o Servizio di directory, dovresti implementare politiche che limitino le azioni dell'archivio di 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 attentamente. In genere, la fonte di identità esterna è la fonte di verità per gli utenti e i loro attributi e per le appartenenze ai gruppi. Se li modifichi utilizzando le API dell'archivio di identità 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à. In questo modo si evita anche 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 dell'IdP. È inoltre opportuno fare attenzione a chi può creare token SCIM bearer dall'account di amministrazione delegato, in quanto questi potrebbero consentire all'amministratore di un account membro di modificare gruppi e utenti tramite un client SCIM.

A volte le operazioni di scrittura o eliminazione dall'account amministratore delegato sono appropriate. Ad esempio, puoi creare un gruppo senza aggiungere membri, quindi assegnare un set di autorizzazioni senza dover attendere che l'amministratore IdP crei il gruppo. Nessuno avrà accesso a tale assegnazione finché l'amministratore dell'IdP non effettuerà il provisioning del gruppo e il processo di sincronizzazione dell'IdP non stabilirà i membri del gruppo. Potrebbe anche essere opportuno eliminare un utente o un gruppo per impedire l'accesso o l'autorizzazione in un momento in cui non è possibile attendere che il processo di sincronizzazione IdP rimuova l'accesso da parte dell'utente o del gruppo. Tuttavia, l'uso improprio di questa autorizzazione può essere dannoso per gli utenti. È necessario utilizzare il principio del privilegio minimo per l'assegnazione delle autorizzazioni all'archivio di identità. È possibile controllare quali azioni relative all'archivio di 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 degli utenti ai gruppi tramite l'API Identity Store e il Console di gestione AWS, opzione consigliata quando la fonte di identità è esterna. Ciò non influisce sulla sincronizzazione degli utenti da Servizio di directory o verso un IdP esterno (tramite SCIM).

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

Se desideri impedire l'aggiunta di 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 prendere in considerazione l'inclusione di ulteriori API di Identity Store nell'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 al portatore 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 dell'archivio di 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 Servizio di directory, dovresti prendere precauzioni per stabilire chi può creare utenti, reimpostare le password e controllare l'appartenenza ai gruppi. Queste azioni conferiscono all'amministratore grandi poteri su chi può accedere e chi può accedervi tramite l'appartenenza a gruppi. È meglio implementare queste politiche come politiche in linea all'interno dei set di autorizzazioni utilizzati per gli amministratori del tuo IAM Identity Center, piuttosto che come SCP. Il seguente esempio di policy in linea ha due obiettivi. Innanzitutto, impedisce l'aggiunta di utenti a gruppi specifici. È possibile utilizzarlo 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 della fonte di 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 amministratore distinti dal tuo account di gestione.

Limita l'emissione di token al portatore SCIM

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

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

Utilizza 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 taggando 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 siano contrassegnati in un determinato modo. È inoltre possibile creare politiche che consentano a un amministratore di assegnare set di autorizzazioni con un tag specifico in account specifici. In questo modo è possibile delegare la gestione degli account senza concedere all'amministratore i privilegi necessari per modificare l'accesso e i privilegi sull'account di amministrazione delegato. Ad esempio, etichettando i set di autorizzazioni utilizzati solo nell'account di amministrazione delegata, è 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 delegata. È inoltre possibile concedere ad altre persone le autorizzazioni per gestire un elenco di account al di fuori dell'account di amministrazione delegato. Per saperne di più, vedi Delegare la gestione dei set di autorizzazioni e l'assegnazione degli account Centro identità AWS IAM nel Security Blog. AWS

Prerequisiti

Prima di poter registrare un account come amministratore delegato, è necessario installare il seguente ambiente: