Panoramica del tutorial Prerequisiti Fase 1: creazione degli utenti di test Fase 2: creazione della policy ABAC Fase 3: creazione di ruoli Fase 4: verifica della creazione di segreti Fase 5: verifica della visualizzazione dei segreti Fase 6: verifica della scalabilità Fase 7: verifica dell'aggiornamento e dell'eliminazione dei segreti Riepilogo Risorse correlate

Tutorial IAM: Definizione delle autorizzazioni per accedere alle risorse AWS 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, tali attributi sono denominati tag. Puoi collegare i tag alle risorse IAM, tra cui le entità IAM (utenti o ruoli), e alle risorse AWS. È possibile definire policy che utilizzano le chiavi condizionali sui tag per concedere autorizzazioni ai principali sulla base dei relativi tag. Quando si utilizzano i tag per controllare l'accesso alle risorse AWS, si consente ai team e alle risorse di crescere con la necessità di un minor numero di modifiche alle policy AWS. Le policy ABAC sono più flessibili rispetto alle policy tradizionali di AWS, 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.

Nota

È necessario passare un singolo valore per ogni tag di sessione. AWS Security Token Service non supporta i tag di sessione multivalore.

Argomenti

Panoramica del tutorial
Prerequisiti
Fase 1: creazione degli utenti di test
Fase 2: creazione della policy ABAC
Fase 3: creazione di ruoli
Fase 4: verifica della creazione di segreti
Fase 5: verifica della visualizzazione dei segreti
Fase 6: verifica della scalabilità
Fase 7: verifica dell'aggiornamento e dell'eliminazione dei segreti
Riepilogo
Risorse correlate
Tutorial IAM: Utilizzo dei tag di sessione SAML per ABAC

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 agli individui di visualizzare o modificare solo le risorse AWS richieste per i propri processi.

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.

Si sceglie di utilizzare i tag delle risorse AWS e i tag del principale dei ruoli IAM per implementare una strategia ABAC per i servizi che lo supportano, a cominciare da AWS Secrets Manager. Per informazioni su quali servizi supportano l'autorizzazione basata sui tag, consulta AWS servizi che funzionano con IAM. Per informazioni sulle chiavi di condizione di tagging che è possibile utilizzare in una policy con le operazioni e le risorse di ciascun servizio, consulta Operazioni, risorse e chiavi di condizione per i servizi AWS. È possibile configurare il provider di identità basato su SAML o web per passare i tag di sessione ad AWS. Quando i dipendenti si federano in AWS, i loro attributi vengono applicati alla rispettiva entità risultante in 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.

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, si sceglie di richiedere che il tag di allocazione dei costi cost-center abiliti la generazione di rendiconti di fatturazione di AWS personalizzati. Per ulteriori informazioni, consulta la pagina sull'utilizzo dei tag per l'allocazione dei costi nella Guida per l'utente di AWS Billing and Cost Management.

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.
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.

Prerequisiti

Per eseguire queste fasi in questo tutorial, è necessario quanto segue:

Un Account AWS al quale è possibile effettuare l'accesso 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 account AWS in AWS Management Console, selezionare Supporto nella barra di navigazione nell'angolo in alto a destra, quindi scegliere Centro di supporto. Il numero dell'account (ID) viene visualizzato nel riquadro di navigazione a sinistra.
Creazione e modifica di utenti, ruoli e policy IAM nella AWS Management Console. Tuttavia, se hai bisogno di aiuto per ricordare una procedura di gestione di IAM, questo tutorial fornisce i collegamenti da cui potrai visualizzare le istruzioni dettagliate.

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.

Creare la seguente policy gestita dal cliente denominata access-assume-role. Per ulteriori informazioni sulla creazione della policy JSON, consulta Creazione di policy IAM.

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.
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "TutorialAssumeRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::account-ID-without-hyphens: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, consulta Creare gruppi IAM e Modificare gli utenti nei gruppi IAM.

Creare i seguenti utenti IAM e collegare la policy di autorizzazione access-assume-role. Assicurarsi di selezionare Fornire l'accesso agli utenti a AWS Management Console, poi aggiungere i seguenti tag.

Nome utente Chiave tag utente Valore tag utente

Nome utente	Chiave tag utente	Valore tag utente
access-Arnav-peg-eng	`access-project` `access-team` `cost-center`	`peg` `eng` `987654`
access-Mary-peg-qas	`access-project` `access-team` `cost-center`	`peg` `qas` `987654`
access-Saanvi-uni-eng	`access-project` `access-team` `cost-center`	`uni` `eng` `123456`
access-Carlos-uni-qas	`access-project` `access-team` `cost-center`	`uni` `qas` `123456`

access-Arnav-peg-eng

access-project

access-team

cost-center

peg

eng

987654

access-Mary-peg-qas

access-project

access-team

cost-center

peg

qas

987654

access-Saanvi-uni-eng

access-project

access-team

cost-center

uni

eng

123456

access-Carlos-uni-qas

access-project

access-team

cost-center

uni

qas

123456

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.

Per ulteriori policy che è possibile adattare a questa esercitazione, vedere le pagine seguenti:

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.


{
 "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 informazioni su quali operazioni non sono consentite da questo blocco, consulta Operazioni, risorse e chiavi di condizione per AWS Secrets Manager. Questa pagina mostra che le operazioni eseguite sul tipo di risorsa Segreto supportano la chiave di condizione secretsmanager:ResourceTag/tag-key. Alcune azioni di Secrets Manager 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 Chiavi di contesto multivalore.
- 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 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 Crea un ruolo per concedere le autorizzazioni a un utente IAM. Se decidi di utilizzare la federazione anziché gli utenti e i ruoli IAM, consulta Tutorial IAM: Utilizzo dei tag di sessione SAML per ABAC.

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

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 IAM access-Arnav-peg-eng e apri la console di Secrets Manager all'indirizzo https://console.aws.amazon.com/secretsmanager/.
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 sullo scambio dei ruoli nella AWS Management Console, consultare Passare da un utente a un IAM ruolo (console)
Passare al ruolo access-peg-engineering.

Archiviare un nuovo segreto utilizzando le seguenti informazioni. Per informazioni su come archiviare un segreto, consulta Creazione di un segreto di base nella Guida per l'utente di AWS Secrets Manager.

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. Ѐ possibile ignorare questi avvisi poiché in questo tutorial si non utilizzano questi servizi AWS specifici.

Nella sezione Seleziona tipo di segreto, scegliere Altro tipo di segreti. Nelle due caselle di testo, inserire test-access-key e test-access-secret.
Nel campo Nome segreto inserire il valore test-access-peg-eng.
Aggiungere diverse combinazioni di tag dalla tabella seguente e visualizzare il comportamento previsto.
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.

Valore tag `access-project`	Valore tag `access-team`	Valore tag `cost-center`	Tag aggiuntivi	Comportamento previsto
(nessuno)	(nessuno)	(nessuno)	(nessuno)	Negato perché il valore del tag `access-project` non corrisponde al valore del ruolo di `peg`.
`uni`	`eng`	`987654`	(nessuno)	Negato perché il valore del tag `access-project` non corrisponde al valore del ruolo di `peg`.
`peg`	`qas`	`987654`	(nessuno)	Negato perché il valore del tag `access-team` non corrisponde al valore del ruolo di `eng`.
`peg`	`eng`	`123456`	(nessuno)	Negato perché il valore del tag `cost-center` non corrisponde al valore del ruolo di `987654`.
`peg`	`eng`	`987654`	Proprietario = Jane	Negato perché il tag aggiuntivo `owner` non è consentito dalla policy, anche se tutti e tre i tag richiesti sono presenti e i relativi valori corrispondono ai valori del ruolo.
`peg`	`eng`	`987654`	Nome = Jane	Consentito perché tutti e tre i tag richiesti sono presenti e i loro valori corrispondono ai valori del ruolo. È anche possibile includere il tag opzionale `Name`.

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.

Nome utente Nome ruolo Nome segreto Tag segreto

Nome utente	Nome ruolo	Nome segreto	Tag segreto
access-Mary-peg-qas	access-peg-quality-assurance	test-access-peg-qas	access-project = `peg` access-team = `qas` cost-center = `987654`
access-Saanvi-uni-eng	access-uni-engineering	test-access-uni-eng	access-project = `uni` access-team = `eng` cost-center = `123456`
access-Carlos-uni-qas	access-uni-quality-assurance	test-access-uni-qas	access-project = `uni` access-team = `qas` cost-center = `123456`

access-Mary-peg-qas

access-peg-quality-assurance

test-access-peg-qas

access-project = peg

access-team = qas

cost-center = 987654

access-Saanvi-uni-eng

access-uni-engineering

test-access-uni-eng

access-project = uni

access-team = eng

cost-center = 123456

access-Carlos-uni-qas

access-uni-quality-assurance

test-access-uni-qas

access-project = uni

access-team = qas

cost-center = 123456

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

Accedi come uno dei seguenti utenti IAM:
- access-Arnav-peg-eng
- access-Mary-peg-qas
- access-Saanvi-uni-eng
- access-Carlos-uni-qas
Passa al ruolo corrispondente:
- access-peg-engineering
- access-peg-quality-assurance
- access-uni-engineering
- access-uni-quality-assurance
Per ulteriori informazioni sullo scambio dei ruoli nella AWS Management Console, consulta Passare da un utente a un IAM ruolo (console).
Nel riquadro di navigazione a sinistra, scegli l'icona del menu per espanderlo, quindi scegliere Segreti.
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.
Scegli il nome di uno dei segreti.

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.

Nome ruolo	Nome segreto	Comportamento previsto
`access-peg-engineering`	`test-access-peg-eng`	Consentito
	test-access-peg-qas	Negato
	test-access-uni-eng	Consentito
	test-access-uni-qas	Negato
access-peg-quality-assurance	test-access-peg-eng	Negato
	test-access-peg-qas	Consentito
	test-access-uni-eng	Negato
	test-access-uni-qas	Consentito
access-uni-engineering	test-access-peg-eng	Consentito
	test-access-peg-qas	Negato
	test-access-uni-eng	Consentito
	test-access-uni-qas	Negato
access-uni-quality-assurance	test-access-peg-eng	Negato
	test-access-peg-qas	Consentito
	test-access-uni-eng	Negato
	test-access-uni-qas	Consentito

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à. Quando l'azienda aggiunge nuovi progetti, team o persone ad AWS, non è necessario aggiornare le policy 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

Accedi come utente amministratore IAM e apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
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
Nel riquadro di navigazione sinistro, scegli Utenti.
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
Utilizza le procedure in Fase 4: verifica della creazione di segreti e Fase 5: verifica della visualizzazione dei segreti. 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.
Nella finestra principale del browser in cui hai effettuato l'accesso come amministratore, scegli l'utente access-Saanvi-uni-eng.
Nella scheda Autorizzazioni rimuovi la policy di autorizzazione access-assume-role.
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).

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 autorizzazioni di AWS non può includere corrispondenze a entrambi i valori. Per ulteriori informazioni, consulta Regole per il tagging in IAM e AWS STS. È invece necessario specificare manualmente i due ruoli che può assumere.

Per utilizzare questa policy, sostituisci il testo segnaposto in corsivo con le tue informazioni.
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "TutorialAssumeSpecificRoles",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::account-ID-without-hyphens:role/access-peg-engineering",
                "arn:aws:iam::account-ID-without-hyphens:role/access-cen-engineering"
            ]
        }
    ]
}
```
Utilizza le procedure in Fase 4: verifica della creazione di segreti e Fase 5: verifica della visualizzazione dei segreti. 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

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
Passa al ruolo corrispondente:
- access-peg-engineering
- access-peg-quality-assurance
- access-uni-engineering
- access-peg-quality-assurance
- access-cen-engineering
Per ulteriori informazioni sullo scambio dei ruoli nella AWS Management Console, consulta Passare da un utente a un IAM ruolo (console).

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 ed Eliminazione e ripristino di un segreto nella Guida per l'utente di AWS Secrets Manager.

La seguente tabella riporta il comportamento di aggiornamento ed eliminazione dei segreti ABAC per ogni ruolo.

Nome ruolo	Nome segreto	Comportamento previsto
access-peg-engineering	test-access-peg-eng	Consentito
	test-access-uni-eng	Negato
	test-access-uni-qas	Negato
access-peg-quality-assurance	test-access-peg-qas	Consentito
access-peg-quality-assurance	test-access-uni-eng	Negato
access-uni-engineering	test-access-uni-eng	Consentito
access-uni-engineering	test-access-uni-qas	Negato
access-peg-quality-assurance	test-access-uni-qas	Consentito

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 si concedono a un utente autorizzazioni amministrative complete utilizzando policy AdministratorAccess AWS gestite, queste policy non limitano 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 applicazione AWS valuta le richieste per consentire o negare l'accesso.

Risorse correlate

Per informazioni correlate, consulta le seguenti risorse:

Per informazioni su come monitorare i tag nell'account, consulta Monitoraggio delle modifiche ai tag sulle risorse AWS con flussi di lavoro serverless e Amazon CloudWatch Events.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Creazione di una policy gestita dal cliente

Utilizzo dei tag di sessione SAML per ABAC

Tutorial IAM: Definizione delle autorizzazioni per accedere alle risorse AWS in base ai tag

Nota

Argomenti

Panoramica del tutorial

Scenario

Riepilogo delle scelte principali

Prerequisiti

Fase 1: creazione degli utenti di test

Policy ABAC: assumere qualsiasi ruolo ABAC, ma solo quando i tag utente e ruolo corrispondono

Fase 2: creazione della policy ABAC

Policy ABAC: accesso alle risorse di Secrets Manager solo quando il tag del principale e quello della risorsa corrispondono

Importante

Fase 3: creazione di ruoli

Fase 4: verifica della creazione di segreti

Per testare la creazione di un segreto con e senza i tag richiesti

Importante

Fase 5: verifica della visualizzazione dei segreti

Per testare la visualizzazione di un segreto con e senza i tag richiesti

Fase 6: verifica della scalabilità

Per aggiungere il nuovo progetto a AWS

Policy ABAC: assunzione dei soli ruoli specifici

Fase 7: verifica dell'aggiornamento e dell'eliminazione dei segreti

Per verificare l'aggiornamento e l'eliminazione di un segreto con e senza i tag richiesti

Riepilogo

Nota

Risorse correlate