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à. # Tutorial IAM: definisci le autorizzazioni per accedere alle AWS risorse in base ai tag Il controllo degli accessi basato su attributi (ABAC) è una strategia di autorizzazione che definisce le autorizzazioni in base agli attributi. In AWS, questi attributi sono chiamati *tag*. Puoi allegare tag alle risorse IAM, incluse le entità IAM (utenti o ruoli) e alle AWS risorse. È possibile definire policy che utilizzano le chiavi condizionali sui tag per concedere autorizzazioni ai principali sulla base dei relativi tag. Quando usi i tag per controllare l'accesso alle tue AWS risorse, consenti ai team e alle risorse di crescere con meno modifiche alle AWS policy. Le politiche ABAC sono più flessibili delle AWS politiche tradizionali, che richiedono di elencare ogni singola risorsa. Per ulteriori informazioni su ABAC e i suoi vantaggi rispetto alle policy tradizionali, consulta [Definire le autorizzazioni basate su attributi con l'autorizzazione ABAC](introduction_attribute-based-access-control.md). **Nota** È necessario passare un singolo valore per ogni tag di sessione. AWS Security Token Service non supporta tag di sessione multivalore. **Topics** + [Panoramica del tutorial](#tutorial_attribute-based-access-control-overview) + [Prerequisiti](#tutorial_abac_prereqs) + [Fase 1: creazione degli utenti di test](#tutorial_abac_step1) + [Fase 2: creazione della policy ABAC](#tutorial_abac_step2) + [Fase 3: creazione di ruoli](#tutorial_abac_step3) + [Fase 4: verifica della creazione di segreti](#tutorial_abac_step4) + [Fase 5: verifica della visualizzazione dei segreti](#tutorial_abac_step5) + [Fase 6: verifica della scalabilità](#tutorial_abac_step6) + [Fase 7: verifica dell'aggiornamento e dell'eliminazione dei segreti](#tutorial_abac_step7) + [Riepilogo](#tutorial-abac-summary) + [Risorse correlate](#tutorial_abac_related) + [Tutorial IAM: Utilizzo dei tag di sessione SAML per ABAC](tutorial_abac-saml.md) ## Panoramica del tutorial Questo tutorial mostra come creare e testare una policy che consente ai ruoli IAM con tag del principale di accedere alle risorse con i tag corrispondenti. Quando un principale effettua una richiesta ad AWS, le autorizzazioni vengono concesse in base al fatto che i tag del principale e quelli della risorsa corrispondano. Questa strategia consente alle persone di visualizzare o modificare solo AWS le risorse necessarie per il proprio lavoro. **Scenario** Si supponga di essere uno sviluppatore responsabile in una grande azienda denominata Example Corporation e di essere un amministratore IAM esperto. Si ha familiarità con la creazione e la gestione di utenti, ruoli e policy IAM. Si desidera garantire che i gli ingegneri dedicati allo sviluppo e i membri del team di garanzia della qualità possano accedere alle risorse di cui hanno bisogno. C'è anche bisogno di una strategia in grado di ridimensionarsi man mano che l'azienda cresce. Scegli di utilizzare i tag AWS delle risorse e i tag principali dei ruoli IAM per implementare una strategia ABAC per i servizi che la supportano, a cominciare Gestione dei segreti AWS da. Per informazioni su quali servizi supportano l'autorizzazione basata sui tag, consulta [AWS servizi che funzionano con IAM](reference_aws-services-that-work-with-iam.md). Per scoprire quali chiavi di condizione di etichettatura puoi utilizzare in una policy con le azioni e le risorse di ciascun servizio, consulta [Azioni, risorse e chiavi di condizione per i AWS](reference_policies_actions-resources-contextkeys.html) servizi. È possibile configurare il provider di identità basato su SAML o web per passare [i tag di sessione](id_session-tags.md) ad AWS. Quando i dipendenti si uniscono AWS, i loro attributi vengono applicati al responsabile risultante. AWSÈ quindi possibile utilizzare ABAC per consentire o negare le autorizzazioni sulla base di tali attributi. Per informazioni su come l'utilizzo di tag di sessione con un'identità federata SAML differisce da questa esercitazione, consulta [Tutorial IAM: Utilizzo dei tag di sessione SAML per ABAC](tutorial_abac-saml.md). I membri dei team Engineering e Quality Assurance fanno parte del progetto **Pegasus** o **Unicorn** . È possibile scegliere i seguenti valori di tag lunghi 3 caratteri per progetto e team: + `access-project` = `peg` per il progetto **Pegasus** + `access-project` = `uni` per il progetto **Unicorn** + `access-team` = `eng` per il team di Engineering + `access-team` = `qas` per il team di Quality Assurance Inoltre, scegli di richiedere il tag di allocazione dei `cost-center` costi per abilitare i report di fatturazione personalizzati AWS . Per ulteriori informazioni, consulta la pagina sull'[utilizzo dei tag per l'allocazione dei costi](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) nella *Guida per l'utente di Gestione dei costi e fatturazione AWS *. **Riepilogo delle scelte principali** + I dipendenti eseguono l'accesso con le credenziali dell'utente IAM e quindi assumono il ruolo IAM associato ai relativi team e il progetto. Se l'azienda dispone di un proprio sistema di identità, puoi configurare la federazione per consentire ai dipendenti di assumere un ruolo senza dover passare attraverso gli utenti IAM. Per ulteriori informazioni, consulta [Tutorial IAM: Utilizzo dei tag di sessione SAML per ABAC](tutorial_abac-saml.md). + La stessa policy è collegata a tutti i ruoli. Le operazioni sono consentite o negate in base ai tag. + I dipendenti possono creare nuove risorse, ma solo se collegano alla risorsa gli stessi tag che sono applicati al loro ruolo. In questo modo i dipendenti possono visualizzare la risorsa dopo averla creata. Gli amministratori non sono più tenuti ad aggiornare le policy con l'ARN delle nuove risorse. + I dipendenti possono leggere le risorse di proprietà del loro team, indipendentemente dal progetto. + I dipendenti possono aggiornare ed eliminare le risorse di proprietà del proprio team e progetto. + Gli amministratori IAM possono aggiungere un nuovo ruolo per i nuovi progetti. Possono creare e associare tag a un nuovo utente IAM per consentire l'accesso al ruolo appropriato. Gli amministratori non sono tenuti a modificare una policy per supportare un nuovo progetto o membro del team. In questa esercitazione, verranno associati tag a tutte le risorse e ai ruoli del progetto e aggiunte policy ai ruoli per consentire il comportamento precedentemente descritto. La policy risultante consente ai ruoli `Create`, `Read`, `Update` e `Delete` l'accesso alle risorse contrassegnate con gli stessi tag di progetto e team. La policy consente inoltre l'accesso tra progetti in modalità `Read` per le risorse contrassegnate con lo stesso team. ![\[Il diagramma mostra due progetti in cui i ruoli sono limitati all'accesso in sola lettura all'esterno del progetto e dispongono delle autorizzazioni per creare, leggere, aggiornare ed eliminare risorse nel proprio progetto.\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/tutorial-abac-cross-project.png) ## Prerequisiti Per eseguire queste fasi in questo tutorial, è necessario quanto segue: + E a Account AWS cui puoi accedere come utente con autorizzazioni amministrative. + L'ID account a 12 cifre, che si utilizza per creare i ruoli nel passaggio 3. Per trovare il numero ID dell' AWS account utilizzando Console di gestione AWS, scegli **Supporto** nella barra di navigazione in alto a destra, quindi scegli **Support Center**. Il numero dell'account (ID) viene visualizzato nel riquadro di navigazione a sinistra. ![\[Supporto Pagina centrale che mostra il numero dell'account.\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/account-id-support-center.console.png) + Creazione e modifica di utenti, ruoli e policy IAM nella Console di gestione AWS. Tuttavia, se hai bisogno di aiuto per ricordare un processo di gestione IAM, questo tutorial fornisce collegamenti in cui puoi visualizzare step-by-step le istruzioni. ## Fase 1: creazione degli utenti di test A scopo di test, crea quattro utenti IAM con le autorizzazioni per assumere ruoli con gli stessi tag. In questo modo è più facile aggiungere più utenti ai team. Quando si associano i tag agli utenti, questi ottengono automaticamente l'accesso per assumere il ruolo corretto. Non è necessario aggiungere gli utenti alla policy di trust del ruolo se lavorano su un solo progetto e in un solo team. 1. Creare la seguente policy gestita dal cliente denominata `access-assume-role`. Per ulteriori informazioni sulla creazione della policy JSON, consulta [Creazione di policy IAM](access_policies_create-console.md#access_policies_create-start). **Policy ABAC: assumere qualsiasi ruolo ABAC, ma solo quando i tag utente e ruolo corrispondono** La policy seguente consente a un utente di assumere qualsiasi ruolo nell'account con il prefisso `access-` nel nome. Il ruolo deve inoltre essere taggato con gli stessi tag di progetto, team e centro di costi dell'utente. Per utilizzare questa policy, sostituisci il *testo segnaposto in corsivo* con le tue informazioni. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TutorialAssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/access-*", "Condition": { "StringEquals": { "iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}", "iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}", "iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}" } } } ] } ``` ------ Per ridimensionare questa esercitazione a un numero elevato di utenti, è possibile collegare la policy a un gruppo e aggiungere ogni utente al gruppo. Per ulteriori informazioni, consultare [Creare gruppi IAM](id_groups_create.md) e [Modificare gli utenti nei gruppi IAM](id_groups_manage_add-remove-users.md). 1. Creare i seguenti utenti IAM e collegare la policy di autorizzazione `access-assume-role`. Assicurarsi di selezionare **Fornire l'accesso agli utenti a Console di gestione AWS**, poi aggiungere i seguenti tag. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## Fase 2: creazione della policy ABAC Creare la seguente policy denominata **access-same-project-team**. Questa policy verrà aggiunta ai ruoli in un passaggio successivo. Per ulteriori informazioni sulla creazione della policy JSON, consulta [Creazione di policy IAM](access_policies_create-console.md#access_policies_create-start). Per ulteriori policy che è possibile adattare a questa esercitazione, vedere le pagine seguenti: + [Controllo dell'accesso per i principali IAM](access_iam-tags.md#access_iam-tags_control-principals) + [Amazon EC2: consente l'avvio o l'arresto di istanze EC2 che un utente ha contrassegnato, a livello programmatico e nella console](reference_policies_examples_ec2_tag-owner.md) + [EC2: avvio o arresto di istanze in base alla corrispondenza dei tag della risorsa e del principale](reference_policies_examples_ec2-start-stop-match-tags.md) + [EC2: avvia o interrompe le istanze in base ai tag](reference_policies_examples_ec2-start-stop-tags.md) + [IAM: assumere ruoli che dispongono di un tag specifico](reference_policies_examples_iam-assume-tagged-role.md) **Policy ABAC: accesso alle risorse di Secrets Manager solo quando il tag del principale e quello della risorsa corrispondono** La policy seguente consente ai principali di creare, leggere, modificare ed eliminare risorse, ma solo quando tali risorse sono contrassegnate con le stesse coppie chiave-valore del principale. Quando un principale crea una risorsa, deve aggiungere i tag `access-project`, `access-team` e `cost-center` con valori corrispondenti ai tag del principale. La policy consente anche l'aggiunta di tag facoltativi `Name` o `OwnedBy`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllActionsSecretsManagerSameProjectSameTeam", "Effect": "Allow", "Action": "secretsmanager:*", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}", "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}", "aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}" }, "ForAllValues:StringEquals": { "aws:TagKeys": [ "access-project", "access-team", "cost-center", "Name", "OwnedBy" ] }, "StringEqualsIfExists": { "aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}", "aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}", "aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}" } } }, { "Sid": "AllResourcesSecretsManagerNoTags", "Effect": "Allow", "Action": [ "secretsmanager:GetRandomPassword", "secretsmanager:ListSecrets" ], "Resource": "*" }, { "Sid": "ReadSecretsManagerSameTeam", "Effect": "Allow", "Action": [ "secretsmanager:Describe*", "secretsmanager:Get*", "secretsmanager:List*" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}" } } }, { "Sid": "DenyUntagSecretsManagerReservedTags", "Effect": "Deny", "Action": "secretsmanager:UntagResource", "Resource": "*", "Condition": { "ForAnyValue:StringLike": { "aws:TagKeys": "access-*" } } }, { "Sid": "DenyPermissionsManagement", "Effect": "Deny", "Action": "secretsmanager:*Policy", "Resource": "*" } ] } ``` ------ **Che cosa fa questa policy?** + L'istruzione `AllActionsSecretsManagerSameProjectSameTeam` consente tutte le operazioni relative a questo servizio su tutte le risorse correlate, ma solo se i tag di risorsa corrispondono ai tag del principale. Aggiungendo `"Action": "secretsmanager:*"` alla policy, la policy stessa cresce man mano che Secrets Manager cresce. Se Secrets Manager aggiunge una nuova operazione API, non è necessario aggiungere tale operazione all'istruzione. L'istruzione implementa ABAC utilizzando tre blocchi di condizione. La richiesta è consentita solo se tutti e tre i blocchi restituiscono true. + Il primo blocco di condizione di questa istruzione restituisce true se le chiavi tag specificate sono presenti nella risorsa e i loro valori corrispondono ai tag del principale. Questo blocco restituisce false per i tag non corrispondenti o per le operazioni che non supportano il tag delle risorse. Per sapere quali azioni non sono consentite da questo blocco, vedi [Azioni, risorse e chiavi di condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html) per. Gestione dei segreti AWS Questa pagina mostra che le operazioni eseguite sul [tipo di risorsa **Segreto**](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-resources-for-iam-policies) supportano la chiave di condizione `secretsmanager:ResourceTag/tag-key`. Alcune [azioni di Secrets Manager](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-actions-as-permissions) non supportano tale tipo di risorsa, inclusi `GetRandomPassword` e `ListSecrets`. Per consentire tali azioni, è necessario creare istruzioni aggiuntive. + Il secondo blocco di condizione restituisce true se ogni chiave del tag passata nella richiesta è incluso nell'elenco specificato. Questo viene fatto utilizzando `ForAllValues` con l'operatore condizionale `StringEquals`. Se non vengono passate chiavi o un sottoinsieme del set di chiavi, la condizione restituisce true. Ciò consente operazioni `Get*` che non consentono il passaggio di tag nella richiesta. Se il richiedente include una chiave del tag che non è nell'elenco, la condizione restituisce false. Ogni chiave dei tag passata nella richiesta deve corrispondere a un elemento di tale elenco. Per ulteriori informazioni, consulta [Operatori dell’insieme per le chiavi di contesto multivalore](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys). + Il terzo blocco di condizioni restituisce true se la richiesta supporta il passaggio dei tag, se tutti e tre i tag sono presenti e se corrispondono ai valori del tag del principale. Questo blocco restituisce true anche se la richiesta non supporta il passaggio di tag. Tale risultato è ottenuto tramite l'utilizzo di [`...IfExists`](reference_policies_elements_condition_operators.md#Conditions_IfExists) nell'operatore condizionale. Il blocco restituisce false se non vi è alcun tag passato durante un'operazione che li supporta o se le chiavi e i valori dei tag non corrispondono. + L'istruzione `AllResourcesSecretsManagerNoTags` permette le operazioni `GetRandomPassword` e `ListSecrets` che non sono consentite dalla prima istruzione. + L'istruzione `ReadSecretsManagerSameTeam` permette le operazioni di sola lettura se il principale è contrassegnato con lo stesso tag di team di accesso della risorsa. Ciò è consentito indipendentemente dal progetto o dal tag del centro di costi. + L'istruzione `DenyUntagSecretsManagerReservedTags` rifiuta le richieste di rimuovere da Secrets Manager i tag con chiavi che iniziano con il prefisso "access-". Questi tag vengono utilizzati per controllare l'accesso alle risorse, pertanto la rimozione dei tag potrebbe rimuovere le autorizzazioni. + L'istruzione `DenyPermissionsManagement` nega l'accesso per creare, modificare o eliminare policy basate sulle risorse di Secrets Manager. Queste policy possono essere utilizzate per modificare le autorizzazioni dei segreti. **Importante** Questa policy utilizza una strategia per consentire tutte le operazioni per un servizio, ma negando esplicitamente le operazioni di modifica delle autorizzazioni. Il rifiuto di un'operazione sostituisce qualsiasi altra policy che consente al principale di eseguire tale operazione. Ciò può avere risultati imprevisti. Come best practice, usare il rifiuto esplicito solo quando non vi è alcuna circostanza in cui debba essere consentita tale operazione. In caso contrario, consentire un elenco di singole operazioni in modo che le operazioni indesiderate vengano negate per impostazione predefinita. ## Fase 3: creazione di ruoli Crea i seguenti ruoli IAM e collega la policy **access-same-project-team** creata nella fase precedente. Per ulteriori informazioni sulla creazione dei ruoli IAM, consulta [Creazione di un ruolo per fornire le autorizzazioni a un utente IAM](id_roles_create_for-user.md). Se decidi di utilizzare la federazione anziché gli utenti e i ruoli IAM, consulta [Tutorial IAM: Utilizzo dei tag di sessione SAML per ABAC](tutorial_abac-saml.md). | Funzione processo | Nome ruolo | Tag di ruolo | Descrizione del ruolo | | --- | --- | --- | --- | | Progetto Pegasus Engineering | access-peg-engineering | access-project = `peg` access-team = `eng` cost-center = `987654` | Consente agli ingegneri di leggere tutte le risorse ingegneristiche e di creare e gestire le risorse ingegneristiche di Pegasus. | | Progetto Pegasus Quality Assurance | access-peg-quality-assurance | access-project = `peg` access-team = `qas` cost-center = `987654` | Consente al team QA di leggere tutte le risorse di QA e di creare e gestire tutte le risorse QA di Pegasus. | | Progetto Unicorn Engineering | access-uni-engineering | access-project= `uni` access-team = `eng` cost-center = `123456` | Consente agli ingegneri di leggere tutte le risorse ingegneristiche e creare e gestire le risorse ingegneristiche di Unicorn. | | Progetto Unicorn Quality Assurance | access-uni-quality-assurance | access-project = `uni` access-team = `qas` cost-center = `123456` | Consente al team QA di leggere tutte le risorse QA e di creare e gestire tutte le risorse QA di Unicorn. | ## Fase 4: verifica della creazione di segreti La policy di autorizzazione collegata ai ruoli consente ai dipendenti di creare segreti. Questo è consentito solo se il segreto è contrassegnato con il relativo progetto, team e centro di costi. Verifica che le autorizzazioni funzionino come previsto accedendo come i tuoi utenti, assumendo il ruolo corretto e testando l'attività in Secrets Manager. **Per testare la creazione di un segreto con e senza i tag richiesti** 1. Nella finestra principale del browser, resta connesso come utente amministratore in modo da poter esaminare utenti, ruoli e policy in IAM. Utilizzare una finestra di navigazione in incognito del browser o un browser separato per i test. Lì, accedi come utente `access-Arnav-peg-eng` IAM e apri la console Secrets Manager all'indirizzo [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/). 1. Provare a passare al ruolo `access-uni-engineering`. Questa operazione ha esito negativo perché i valori de tag `access-project` e `cost-center` non corrispondono all'utente `access-Arnav-peg-eng` e al ruolo `access-uni-engineering`. Per ulteriori informazioni sul cambio di ruolo in Console di gestione AWS, consulta [Passare da un utente a un ruolo IAM (console)](id_roles_use_switch-role-console.md) 1. Passare al ruolo `access-peg-engineering`. 1. Archiviare un nuovo segreto utilizzando le seguenti informazioni. Per informazioni su come archiviare un segreto, consulta [Creazione di un segreto di base](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) nella *Guida per l'utente di Gestione dei segreti AWS *. **Importante** Secrets Manager visualizza avvisi che segnalano che non disponi delle autorizzazioni per i servizi AWS aggiuntivi che funzionano con Secrets Manager. Ad esempio, per creare credenziali per un database Amazon RDS, è necessario disporre dell'autorizzazione per descrivere istanze RDS, cluster RDS e cluster Amazon Redshift. Puoi ignorare questi avvisi poiché non stai utilizzando questi AWS servizi specifici in questo tutorial. 1. Nella sezione **Seleziona tipo di segreto**, scegliere **Altro tipo di segreti**. Nelle due caselle di testo, inserire `test-access-key` e `test-access-secret`. 1. Nel campo **Nome segreto** inserire il valore `test-access-peg-eng`. 1. Aggiungere diverse combinazioni di tag dalla tabella seguente e visualizzare il comportamento previsto. 1. Scegliere **Memorizza** per provare a creare il segreto. Se l'archiviazione non riesce, torna alle pagine della console di Secrets Manager precedenti e utilizza il set di tag successivo dalla tabella seguente. L'ultimo set di tag è consentito e creerà con successo il segreto. La tabella seguente mostra le combinazioni di tag ABAC per il ruolo `test-access-peg-eng`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) 1. Disconnettersi e ripetere i primi tre passaggi di questa procedura per ciascuno dei seguenti ruoli e valori dei tag. Nel quarto passaggio di questa procedura, verificare tutti i set di tag mancanti, tag facoltativi, tag non consentiti e valori di tag non validi selezionati. Quindi utilizzare i tag richiesti per creare un segreto con i seguenti tag e nome. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## Fase 5: verifica della visualizzazione dei segreti La policy collegata a ciascun ruolo consente ai dipendenti di visualizzare eventuali segreti contrassegnati con il nome del team, indipendentemente dal progetto. Verifica che le autorizzazioni funzionino come previsto testando i ruoli in Secrets Manager. **Per testare la visualizzazione di un segreto con e senza i tag richiesti** 1. Accedi come uno dei seguenti utenti IAM: + `access-Arnav-peg-eng` + `access-Mary-peg-qas` + `access-Saanvi-uni-eng` + `access-Carlos-uni-qas` 1. Passa al ruolo corrispondente: + `access-peg-engineering` + `access-peg-quality-assurance` + `access-uni-engineering` + `access-uni-quality-assurance` Per ulteriori informazioni sul cambio di ruolo in Console di gestione AWS, vedere. [Passare da un utente a un ruolo IAM (console)](id_roles_use_switch-role-console.md) 1. Nel riquadro di navigazione a sinistra, scegli l'icona del menu per espanderlo, quindi scegliere **Segreti**. 1. Dovrebbero essere visualizzati tutti e quattro i segreti nella tabella, indipendentemente dal proprio ruolo attuale. Ciò accade perché la policy denominata `access-same-project-team` consente l'operazione `secretsmanager:ListSecrets` per tutte le risorse. 1. Scegli il nome di uno dei segreti. 1. Nella pagina dei dettagli del segreto, i tag del ruolo determinano se è possibile visualizzare il contenuto della pagina. Confrontare il nome del proprio ruolo con il nome del segreto. Se condividono lo stesso nome del team, i tag `access-team` corrispondono. Se non corrispondono, l'accesso viene negato. La tabella seguente mostra il comportamento di visualizzazione del segreto ABAC per ogni ruolo. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) 1. Nel percorso di navigazione nella parte superiore della pagina, scegliere **Segreti** per tornare all'elenco dei segreti. Ripetere i passaggi di questa procedura utilizzando ruoli diversi per verificare se è possibile visualizzare ciascuno dei segreti. ## Fase 6: verifica della scalabilità Un motivo importante per utilizzare il controllo degli accessi basato su attributi (ABAC) invece del controllo di accesso basato su ruoli (RBAC) è la scalabilità. Man mano che l'azienda aggiunge nuovi progetti, team o persone AWS, non è necessario aggiornare le politiche basate su ABAC. Ad esempio, si supponga che Example Company stia finanziando un nuovo progetto dal nome in codice **Centaur**. Un ingegnere di nome Saanvi Sarkar sarà l'ingegnere responsabile di **Centaur** continuando a lavorare al progetto **Unicorn** . Saanvi esaminerà anche i lavori per il progetto **Peg**. Ci sono anche diversi ingegneri appena assunti, tra cui Nikhil Jayashankar, che lavoreranno solo al progetto **Centaur** . **Per aggiungere il nuovo progetto a AWS** 1. Accedi come utente amministratore IAM e apri la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Nel pannello di navigazione sulla sinistra, scegli **Ruoli** e aggiungi un ruolo IAM denominato `access-cen-engineering`. Collega la policy delle autorizzazioni **access-same-project-team** al ruolo e aggiungere i seguenti tag di ruolo: + `access-project` = `cen` + `access-team` = `eng` + `cost-center` = `101010` 1. Nel riquadro di navigazione sinistro, scegli **Utenti**. 1. Aggiungi un nuovo utente denominato `access-Nikhil-cen-eng`, collega la policy denominata `access-assume-role` e aggiungi i seguenti tag utente. + `access-project` = `cen` + `access-team` = `eng` + `cost-center` = `101010` 1. Utilizza le procedure in [Fase 4: verifica della creazione di segreti](#tutorial_abac_step4) e [Fase 5: verifica della visualizzazione dei segreti](#tutorial_abac_step5). In un'altra finestra del browser, verifica che Nikhil possa creare segreti solo per il team di ingegneria di **Centaur** e che possa visualizzare tutti i segreti dei team di ingegneria. 1. Nella finestra principale del browser in cui hai effettuato l'accesso come amministratore, scegli l'utente `access-Saanvi-uni-eng`. 1. Nella scheda **Autorizzazioni**, rimuovi la politica delle **access-assume-role**autorizzazioni. 1. Aggiungi la seguente policy inline denominata `access-assume-specific-roles`. Per ulteriori informazioni sull'aggiunta di una policy inline a un utente, consulta [Per incorporare una policy inline per un utente o un ruolo (console)](access_policies_manage-attach-detach.md#embed-inline-policy-console). **Policy ABAC: assunzione dei soli ruoli specifici** Questa policy consente a Saanvi di assumere i ruoli ingegneristici per i progetti **Pegasus** e **Centaur**. È necessario creare questa policy personalizzata perché IAM non supporta tag multivalore. Non è possibile etichettare l'utente di Saanvi con `access-project` = `peg` e `access-project` = `cen`. Inoltre, il modello di AWS autorizzazione non può corrispondere a entrambi i valori. Per ulteriori informazioni, consulta [Regole per l'etichettatura in IAM e AWS STS](id_tags.md#id_tags_rules). È invece necessario specificare manualmente i due ruoli che può assumere. Per utilizzare questa policy, sostituisci il *testo segnaposto in corsivo* con le tue informazioni. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TutorialAssumeSpecificRoles", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::111122223333:role/access-peg-engineering", "arn:aws:iam::111122223333:role/access-cen-engineering" ] } ] } ``` ------ 1. Utilizza le procedure in [Fase 4: verifica della creazione di segreti](#tutorial_abac_step4) e [Fase 5: verifica della visualizzazione dei segreti](#tutorial_abac_step5). In un'altra finestra del browser, conferma che Saanvi possa assumere entrambi i ruoli. Verifica che sia in grado di creare segreti solo per i suoi progetto, team e centro di costo, a seconda dei tag del ruolo. Verifica anche che possa visualizzare i dettagli su eventuali segreti di proprietà del team di ingegneria, inclusi quelli che ha appena creato. ## Fase 7: verifica dell'aggiornamento e dell'eliminazione dei segreti La policy `access-same-project-team` collegata ai ruoli consente ai dipendenti di aggiornare ed eliminare eventuali segreti contrassegnati con il proprio progetto, team e centro costi. Verifica che le autorizzazioni funzionino come previsto testando i ruoli in Secrets Manager. **Per verificare l'aggiornamento e l'eliminazione di un segreto con e senza i tag richiesti** 1. Accedi come uno dei seguenti utenti IAM: + `access-Arnav-peg-eng` + `access-Mary-peg-qas` + `access-Saanvi-uni-eng` + `access-Carlos-uni-qas` + `access-Nikhil-cen-eng` 1. Passa al ruolo corrispondente: + `access-peg-engineering` + `access-peg-quality-assurance` + `access-uni-engineering` + `access-peg-quality-assurance` + `access-cen-engineering` Per ulteriori informazioni sul cambio di ruolo in Console di gestione AWS, vedere[Passare da un utente a un ruolo IAM (console)](id_roles_use_switch-role-console.md). 1. Per ogni ruolo, prova ad aggiornare la descrizione del segreto e quindi prova a eliminare i seguenti segreti. Per ulteriori informazioni, consulta [Modifica di un segreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html) ed [Eliminazione e ripristino di un segreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html) nella *Guida per l'utente di Gestione dei segreti AWS *. La seguente tabella riporta il comportamento di aggiornamento ed eliminazione dei segreti ABAC per ogni ruolo. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) ## Riepilogo Tutte le fasi necessarie per utilizzare i tag per il controllo degli accessi basato su attributi (ABAC) sono state completate correttamente. L'utente ha imparato a definire una strategia di tagging. Tale strategia è stata applicata alle proprie entità e risorse. È stata creata e applicata una policy che impone la strategia a Secrets Manager. L'utente ha anche imparato che ABAC è facilmente ridimensionabile nel momento in cui si aggiungono nuovi progetti e membri del team. Di conseguenza, sarai in grado di accedere alla console IAM con i ruoli di test e scoprire come utilizzare i tag per ABAC in AWS. **Nota** L'utente ha aggiunto policy che consentono operazioni solo in condizioni specifiche. Se si applica un criterio diverso agli utenti o ai ruoli con autorizzazioni più ampie, è possibile che le azioni non siano limitate a richiedere l'assegnazione di tag. Ad esempio, se concedi a un utente autorizzazioni amministrative complete utilizzando la politica `AdministratorAccess` AWS gestita, tali politiche non limiteranno tale accesso. Per ulteriori informazioni su come vengono determinate le autorizzazioni quando sono coinvolte più policy, vedere [In che modo la logica del codice di AWS applicazione valuta le richieste di consentire o negare l'accesso](reference_policies_evaluation-logic_policy-eval-denyallow.md). ## Risorse correlate Per informazioni correlate, consulta le seguenti risorse: + [Definire le autorizzazioni basate su attributi con l'autorizzazione ABAC](introduction_attribute-based-access-control.md) + [AWS chiavi di contesto della condizione globale](reference_policies_condition-keys.md) + [Creazione di un ruolo per fornire le autorizzazioni a un utente IAM](id_roles_create_for-user.md) + [Tag per AWS Identity and Access Management le risorse](id_tags.md) + [Controllo dell'accesso alle AWS risorse tramite tag](access_tags.md) + [Passare da un utente a un ruolo IAM (console)](id_roles_use_switch-role-console.md) + [Tutorial IAM: Utilizzo dei tag di sessione SAML per ABAC](tutorial_abac-saml.md) Per sapere come monitorare i tag nel tuo account, consulta [Monitorare le modifiche ai tag sulle AWS risorse con flussi di lavoro serverless e Amazon CloudWatch Events](https://aws.amazon.com/blogs/mt/monitor-tag-changes-on-aws-resources-with-serverless-workflows-and-amazon-cloudwatch-events/).