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à. # ABAC per AWS KMS Il controllo degli accessi basato sugli attributi (ABAC) è una strategia di autorizzazione che definisce le autorizzazioni in base agli attributi. AWS KMS supporta ABAC consentendovi di controllare l'accesso alle chiavi gestite dai clienti in base ai tag e agli alias associati alle chiavi KMS. Le chiavi di condizione dei tag e degli alias che consentono ad ABAC di AWS KMS fornire un modo potente e flessibile per autorizzare i mandanti a utilizzare le chiavi KMS senza modificare le politiche o gestire le sovvenzioni. Ma occorre usare queste funzionalità con cura in modo che ai principali non sia inavvertitamente autorizzato o negato l'accesso. Se si utilizza ABAC, tenere presente che l'autorizzazione per gestire tag e alias è ora un'autorizzazione di controllo di accesso. Assicurarsi di conoscere i tag e gli alias esistenti in tutte le chiavi KMS prima di distribuire una policy che dipende da tag o alias. Prendere ragionevoli precauzioni quando si aggiungono, eliminano e aggiornano gli alias e quando si taggano e si rimuovono i tag delle chiavi. Assegna le autorizzazioni per gestire tag e alias solo alle entità che ne hanno bisogno e limita i tag e gli alias che possono gestire. **Note** Quando usi ABAC for AWS KMS, fai attenzione a non concedere ai principali il permesso di gestire tag e alias. La modifica di un tag o di un alias potrebbe consentire o negare l'autorizzazione a una chiave KMS. Gli amministratori chiave che non dispongono dell'autorizzazione per modificare le policy chiave o creare concessioni possono controllare l'accesso alle chiavi KMS se dispongono dell'autorizzazione per gestire tag o alias. È possibile che occorrano fino a cinque minuti affinché le modifiche a tag e alias diventano effettive per l'autorizzazione delle chiavi KMS. Le modifiche recenti potrebbero essere visibili nelle operazioni API prima che influiscano sull'autorizzazione. Per controllare l'accesso a una chiave KMS in base al relativo alias, è necessario utilizzare una chiave di condizione. Non è possibile utilizzare un alias per rappresentare una chiave KMS nell'elemento `Resource` di un'istruzione di policy. Quando viene visualizzato un alias nell'elemento `Resource`, l'istruzione di policy si applica all'alias e non alla chiave KMS associata. **Ulteriori informazioni** + Per dettagli sul AWS KMS supporto per ABAC, inclusi esempi, consulta e. [Usa gli alias per controllare l'accesso alle chiavi KMS](alias-authorization.md) [Usa i tag per controllare l'accesso alle chiavi KMS](tag-authorization.md) + Per informazioni più generali sull'uso dei tag per controllare l'accesso alle AWS risorse, vedi A [cosa serve ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)? AWS e [Controllo dell'accesso alle AWS risorse utilizzando i tag delle risorse](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) nella *Guida per l'utente IAM*. ## Chiavi di condizione ABAC per AWS KMS Per autorizzare l'accesso alle chiavi del servizio di gestione delle chiavi in base ai relativi tag e alias, utilizzare le seguenti chiavi di condizione in una policy chiave o in una policy IAM. | Chiavi di condizione ABAC | Description | Tipo di politica | AWS KMS operazioni | | --- | --- | --- | --- | | [leggi: ResourceTag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) | Il tag (chiave e valore) sulla chiave KMS corrisponde al tag (chiave e valore) o al modello di tag nella policy | Solo policy IAM | Operazioni delle risorse delle chiavi KMS 2 | | [aws:RequestTag//*tag-key*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag) | Il tag (chiave e valore) nella richiesta corrisponde al tag (chiave e valore) o al modello di tag nella policy | Policy chiave e policy IAM1 | [TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html), [UntagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_UntagResource.html) | | [aws: TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys) | Le chiavi tag nella richiesta corrispondono alle chiavi tag nella policy | Policy chiave e policy IAM1 | [TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html), [UntagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_UntagResource.html) | | [km: ResourceAliases](conditions-kms.md#conditions-kms-resource-aliases) | Gli alias associati alla chiave KMS corrispondono agli alias o ai modelli di alias nella policy | Solo policy IAM | Operazioni delle risorse delle chiavi KMS 2 | | [km: RequestAlias](conditions-kms.md#conditions-kms-request-alias) | L'alias che rappresenta la chiave KMS nella richiesta corrisponde agli alias o ai modelli di alias nella policy. | Policy chiave e policy IAM1 | [Operazioni crittografiche](kms-cryptography.md#cryptographic-operations), [DescribeKey[GetPublicKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetPublicKey.html)](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) | 1Qualsiasi chiave di condizione che può essere utilizzata in una policy chiave può essere utilizzata anche in una policy IAM, ma solo se [la policy chiave lo consente](key-policy-default.md#key-policy-default-allow-root-enable-iam). 2Un'*operazione delle risorse delle chiavi KMS* è un'operazione autorizzata per una determinata chiave KMS. Per identificare le operazioni delle risorse delle chiavi KMS, nella [tabella delle autorizzazioni AWS KMS](kms-api-permissions-reference.md#kms-api-permissions-reference-table), cerca un valore della chiave KMS nella colonna `Resources`per l'operazione. Ad esempio, è possibile utilizzare queste chiavi di condizione per creare le seguenti policy. + Una policy IAM con `kms:ResourceAliases` che consente di utilizzare le chiavi KMS con un particolare alias o modello di alias. Ciò è leggermente diverso dalle policy che si basano sui tag: sebbene sia possibile utilizzare modelli di alias in una policy, ogni alias deve essere unico in una Account AWS regione and. Ciò consente di applicare una politica a un set selezionato di chiavi KMS senza elencare la chiave ARNs delle chiavi KMS nell'informativa sulla politica. Per aggiungere o rimuovere chiavi KMS dal set, modificare l'alias della chiave KMS. + Una policy chiave con `kms:RequestAlias` che consente ai principali di utilizzare una chiave KMS in un'operazione `Encrypt`, ma solo quando la richiesta `Encrypt` utilizza tale alias per identificare la chiave KMS. + Una policy IAM con `aws:ResourceTag/tag-key` che nega l'autorizzazione a utilizzare le chiavi KMS con una chiave di tag e un valore di tag specifici. Ciò consente di applicare una politica a un set selezionato di chiavi KMS senza elencare la chiave ARNs delle chiavi KMS nell'informativa sulla politica. Per aggiungere o rimuovere le chiavi del servizio di gestione delle chiavi dal set, taggare o rimuovere la chiave KMS. + Una policy IAM con `aws:RequestTag/tag-key` che consente ai gruppi di eliminare solo i tag della chiave KMS `"Purpose"="Test"`. + Una policy IAM con `aws:TagKeys` che nega l'autorizzazione ad aggiungere o eliminare un tag a una chiave KMS con una chiave tag `Restricted`. ABAC rende la gestione degli accessi flessibile e scalabile. Ad esempio, puoi utilizzare la chiave di condizione `aws:ResourceTag/tag-key` per creare una policy IAM che consente ai principali di utilizzare una chiave KMS per le operazioni specificate solo quando la chiave KMS ha un tag `Purpose=Test`. La policy si applica a tutte le chiavi KMS in tutte le Regioni dell' Account AWS. Quando è collegata a un utente o a un ruolo, la policy IAM seguente consente alle entità principali di utilizzare tutte le chiavi KMS esistenti con un tag `Purpose=Test` per le operazioni specificate. Per fornire questo accesso a chiavi KMS nuove o esistenti, non è necessario modificare le policy. È sufficiente collegare il tag `Purpose=Test` alle chiavi KMS. Allo stesso modo, per rimuovere questo accesso dalle chiavi KMS con un tag `Purpose=Test`, modifica o elimina il tag. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AliasBasedIAMPolicy", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "arn:aws:kms:*:111122223333:key/*", "Condition": { "StringEquals": { "aws:ResourceTag/Purpose": "Test" } } } ] } ``` ------ Tuttavia, se si utilizza questa funzione, fare attenzione nella gestione di tag e alias. L'aggiunta, la modifica o l'eliminazione di un tag o di un alias può inavvertitamente consentire o negare l'accesso a una chiave KMS. Gli amministratori chiave che non dispongono dell'autorizzazione per modificare le policy chiave o creare concessioni possono controllare l'accesso alle chiavi KMS se dispongono dell'autorizzazione per gestire tag e alias. Per mitigare questo rischio, considera di [limitare le autorizzazioni per la gestione di tag](tag-permissions.md#tag-permissions-conditions) e [alias](alias-access.md#alias-access-limiting). Ad esempio, potrebbe essere necessario consentire solo ai principali di gestire la gestione dei tag `Purpose=Test`. Per informazioni dettagliate, consulta [Usa gli alias per controllare l'accesso alle chiavi KMS](alias-authorization.md) e [Usa i tag per controllare l'accesso alle chiavi KMS](tag-authorization.md). ## Tag o alias? AWS KMS supporta ABAC con tag e alias. Entrambe le opzioni offrono una strategia di controllo degli accessi flessibile e scalabile, ma sono leggermente diverse l'una dall'altra. Potresti decidere di utilizzare tag o utilizzare alias in base ai tuoi modelli di utilizzo particolari AWS . Ad esempio, se sono già state concesse autorizzazioni di assegnazione di tag alla maggior parte degli amministratori, potrebbe essere più semplice controllare una strategia di autorizzazione basata sugli alias. Oppure, se stai per raggiungere la quota di [alias per chiave KMS](resource-limits.md#aliases-per-key), potresti preferire una strategia di autorizzazione basata sui tag. I seguenti vantaggi sono di interesse generale. ** Vantaggi del controllo degli accessi basato su tag** + Stesso meccanismo di autorizzazione per diversi tipi di AWS risorse. Puoi utilizzare lo stesso tag o codice tag per controllare l'accesso a più tipi di risorse, ad esempio un cluster Amazon Relational Database Service (Amazon RDS), un volume Amazon Elastic Block Store (Amazon EBS) e una chiave KMS. Questa funzione consente diversi modelli di autorizzazione più flessibili rispetto ai tradizionali controlli di accesso basati sui ruoli. + Autorizzare l'accesso a un gruppo di chiavi KMS. È possibile utilizzare i tag per gestire l'accesso a un gruppo di chiavi KMS nello stesso Account AWS e nella stessa Regione. Assegnare lo stesso tag o chiave di tag alle chiavi KMS scelte. Quindi crea una semplice dichiarazione easy-to-maintain politica basata sul tag o sulla chiave del tag. Per aggiungere o rimuovere una chiave KMS dal gruppo di autorizzazioni, aggiungere o rimuovere il tag. Non è necessario modificare la policy. **Vantaggi del controllo degli accessi basato su alias** + Autorizza l'accesso alle operazioni di crittografia in base agli alias. La maggior parte delle condizioni delle policy basate sulla richiesta per gli attributi, incluso [aws:RequestTag/*tag-key*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag), influiscono solo sulle operazioni che aggiungono, modificano o eliminano l'attributo. Ma la chiave [kms: RequestAlias](conditions-kms.md#conditions-kms-request-alias) condition controlla l'accesso alle operazioni crittografiche in base all'alias utilizzato per identificare la chiave KMS nella richiesta. Ad esempio, è possibile concedere a un'entità principale l'autorizzazione per utilizzare una chiave KMS in u'operazione `Encrypt` ma solo quando il valore del parametro `KeyId` è `alias/restricted-key-1`. Per soddisfare questa condizione, è necessario quanto segue: + La chiave KMS deve essere associata a tale alias. + La richiesta deve utilizzare l'alias per identificare la chiave KMS. + Il principale deve disporre dell'autorizzazione per utilizzare la chiave KMS soggetta alla condizione `kms:RequestAlias`. Ciò è particolarmente utile se le applicazioni utilizzano comunemente nomi alias o alias ARNs per fare riferimento alle chiavi KMS. + Fornisci autorizzazioni molto limitate. Un alias deve essere univoco in una regione and. Account AWS Di conseguenza, concedere ai principali l'accesso a una chiave KMS basata su un alias può essere molto più restrittivo rispetto a concedere loro l'accesso basato su un tag. Diversamente dagli alias, i tag possono essere assegnati a più chiavi KMS nello stesso account e nella stessa Regione. Se si sceglie, è possibile utilizzare un modello alias, ad esempio `alias/test*`, per consentire agli entità principali di accedere a un gruppo di chiavi KMS nello stesso account e nella stessa Regione. Tuttavia, l'autorizzazione o la negazione dell'accesso a un alias specifico consente un controllo molto rigoroso sulle chiavi KMS. # Risoluzione dei problemi ABAC per AWS KMS Controllare l'accesso alle chiavi KMS in base ai tag e agli alias è comodo e potente. Tuttavia, è incline a alcuni errori prevedibili che vorrai prevenire. ## Accesso modificato a causa della modifica dei tag Se un tag viene eliminato o il relativo valore viene modificato, ai principali che hanno accesso a una chiave KMS basata solo su tale tag verrà negato l'accesso alla chiave KMS. Ciò può verificarsi anche quando un tag incluso in un'istruzione di policy di negazione viene aggiunto a una chiave KMS. L'aggiunta di un tag relativo alla policy a una chiave KMS può consentire l'accesso a principali a cui è necessario negare l'accesso a una chiave KMS. Si supponga, ad esempio, che un principale abbia accesso a una chiave KMS in base al tag `Project=Alpha`, ad esempio l'autorizzazione fornita dalla seguente istruzione della policy IAM di esempio. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "IAMPolicyWithResourceTag", "Effect": "Allow", "Action": [ "kms:GenerateDataKeyWithoutPlaintext", "kms:Decrypt" ], "Resource": "arn:aws:kms:ap-southeast-1:111122223333:key/*", "Condition": { "StringEquals": { "aws:ResourceTag/Project": "Alpha" } } } ] } ``` ------ Se il tag viene eliminato dalla chiave KMS o il valore del tag viene modificato, l'entità principale non dispone più dell'autorizzazione per utilizzare la chiave KMS per le operazioni specificate. [Ciò potrebbe diventare evidente quando il responsabile tenta di leggere o scrivere dati in un AWS servizio che utilizza una chiave gestita dal cliente. Per tracciare la modifica del tag, controlla CloudTrail i log [TagResource](ct-tagresource.md)o UntagResource le immissioni.](ct-untagresource.md) Per ripristinare l'accesso senza aggiornare la policy, modifica i tag sulla chiave KMS. Questa azione ha un impatto minimo diverso dal breve periodo in cui sta entrando in vigore AWS KMS. Per evitare un errore come questo, dai le autorizzazioni per l'assegnazione e l'eliminazione di tag solo ai principali che ne hanno bisogno e [limita le autorizzazioni per l'assegnazione di tag](tag-permissions.md#tag-permissions-conditions) ai tag che devono gestire. Prima di modificare un tag, cerca le policy per rilevare l'accesso che dipende dal tag e ottenere le chiavi KMS in tutte le Regioni che dispongono del tag. Potresti prendere in considerazione la creazione di un CloudWatch allarme Amazon quando vengono modificati determinati tag. ## Modifica dell'accesso a causa della modifica degli alias Se un alias viene eliminato o associato a una chiave KMS diversa, ai principali che hanno accesso alla chiave KMS basata solo su tale alias verrà negato l'accesso alla chiave KMS. Ciò può verificarsi anche quando un alias associato a una chiave KMS è incluso in un'istruzione della policy di negazione. L'aggiunta di un alias relativo alla policy a una chiave KMS può inoltre consentire l'accesso a principali a cui è necessario negare l'accesso a una chiave KMS. Ad esempio, la seguente dichiarazione politica IAM utilizza la chiave [kms: ResourceAliases](conditions-kms.md#conditions-kms-resource-aliases) condition per consentire l'accesso alle chiavi KMS in diverse regioni dell'account con uno qualsiasi degli alias specificati. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AliasBasedIAMPolicy", "Effect": "Allow", "Action": [ "kms:List*", "kms:Describe*", "kms:Decrypt" ], "Resource": "arn:aws:kms:*:111122223333:key/*", "Condition": { "ForAnyValue:StringEquals": { "kms:ResourceAliases": [ "alias/ProjectAlpha", "alias/ProjectAlpha_Test", "alias/ProjectAlpha_Dev" ] } } } ] } ``` ------ Per tracciare la modifica dell'alias, esamina i CloudTrail log e le [CreateAlias](ct-createalias.md)immissioni. [UpdateAlias[DeleteAlias](ct-deletealias.md)](ct-updatealias.md) Per ripristinare l'accesso senza aggiornare la policy, modifica gli alias associati alla chiave KMS. Poiché ogni alias può essere associato a una sola chiave KMS in un account e in una Regione, la gestione degli alias è un po' più difficile della gestione dei tag. Il ripristino dell'accesso ad alcune entità principali a una chiave KMS può negare l'accesso alla stessa o ad altre entità principali a una chiave KMS diversa. Per evitare questo errore, assegna autorizzazioni di gestione degli alias solo alle entità principali che ne hanno bisogno e [limita le autorizzazioni per la gestione degli alias](alias-access.md#alias-access-limiting) agli alias che devono gestire. Prima di aggiornare o eliminare un alias, cerca le policy per rilevare l'accesso che dipende dall'alias e trova le chiavi KMS in tutte le Regioni associate all'alias. ## Accesso negato a causa di quota alias Gli utenti autorizzati a utilizzare una chiave KMS entro una ResourceAliases condizione [kms:](conditions-kms.md#conditions-kms-resource-aliases) riceveranno un'`AccessDenied`eccezione se la chiave KMS supera gli [alias predefiniti per quota di chiavi KMS per quell'account e quella regione](resource-limits.md#aliases-per-key). Per ripristinare l'accesso, elimina gli alias associati alla chiave KMS in modo da rispettare la quota. In alternativa, utilizza un meccanismo alternativo per consentire agli utenti di accedere alla chiave KMS. ## Modifica dell'autorizzazione ritardata Le modifiche apportate a tag e alias possono richiedere fino a cinque minuti per influenzare l'autorizzazione delle chiavi KMS. Di conseguenza, una modifica di tag o alias potrebbe riflettersi nelle risposte delle operazioni API prima che influiscano sull'autorizzazione. È probabile che questo ritardo sia più lungo dell'eventuale breve ritardo di coerenza che influisce sulla maggior parte delle operazioni. AWS KMS Ad esempio, potrebbe esserci una policy IAM che consente a determinate entità principali di utilizzare una chiave KMS con un tag `"Purpose"="Test"`. Quindi aggiungi il tag `"Purpose"="Test"` su una chiave KMS. Sebbene l'[TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html)operazione sia stata completata e la [ListResourceTags](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListResourceTags.html)risposta confermi che il tag è stato assegnato alla chiave KMS, i responsabili potrebbero non avere accesso alla chiave KMS per un massimo di cinque minuti. Per evitare errori, inserisci questo ritardo previsto nel tuo codice. ## Richieste non riuscite a causa di aggiornamenti alias Quando aggiorni un alias, associ un alias esistente a una chiave KMS diversa. La [decrittografia](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) e [ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html)le richieste che specificano il [nome alias](concepts.md#key-id-alias-name) o l'alias [ARN](concepts.md#key-id-alias-ARN) potrebbero non riuscire perché l'alias è ora associato a una chiave KMS che non crittografava il testo cifrato. Questa situazione in genere restituisce `IncorrectKeyException` o `NotFoundException`. O se la richiesta non ha un parametro `KeyId` o `DestinationKeyId`, l'operazione potrebbe avere esito negativo con l'eccezione `AccessDenied` perché il chiamante non ha più accesso alla chiave KMS che ha crittografato il testo cifrato. È possibile tracciare la modifica esaminando i log e le voci di registro. CloudTrail [CreateAlias[UpdateAlias[DeleteAlias](ct-deletealias.md)](ct-updatealias.md)](ct-createalias.md) È inoltre possibile utilizzare il valore del `LastUpdatedDate` campo nella [ListAliases](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListAliases.html)risposta per rilevare una modifica. Ad esempio, la seguente risposta di [ListAliases](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListAliases.html)esempio mostra che l'`ProjectAlpha_Test`alias nella `kms:ResourceAliases` condizione è stato aggiornato. Di conseguenza, le entità principali che hanno un accesso basato sugli alias perdono l'accesso alla chiave KMS associata in precedenza. Al contrario, hanno accesso alla nuova chiave KMS associata. ``` $ aws kms list-aliases --query 'Aliases[?starts_with(AliasName, `alias/ProjectAlpha`)]' { "Aliases": [ { "AliasName": "alias/ProjectAlpha_Test", "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Test", "TargetKeyId": "0987dcba-09fe-87dc-65ba-ab0987654321", "CreationDate": 1566518783.394, "LastUpdatedDate": 1605308931.903 }, { "AliasName": "alias/ProjectAlpha_Restricted", "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Restricted", "TargetKeyId": "1234abcd-12ab-34cd-56ef-1234567890ab", "CreationDate": 1553410800.010, "LastUpdatedDate": 1553410800.010 } ] } ``` Non è semplice rimediare a questa modifica. È possibile aggiornare nuovamente l'alias per associarlo alla chiave KMS originale. Tuttavia, prima di agire, è necessario considerare l'effetto di tale modifica sulla chiave KMS attualmente associata. Se le entità utilizzavano quest'ultima chiave KMS nelle operazioni di crittografia, potrebbe essere necessario continuare ad accedervi. In questo caso, è possibile aggiornare la policy per assicurarsi che le entità principali dispongano dell'autorizzazione per utilizzare entrambe le chiavi KMS. È possibile evitare un errore come questo: prima di aggiornare un alias, cerca le policy per rilevare l'accesso che dipende dall'alias. Quindi ottieni le chiavi KMS in tutte le Regioni associate all'alias. Assegna autorizzazioni di gestione degli alias solo alle entità principali che ne hanno bisogno e [limita le autorizzazioni per la gestione degli alias](alias-access.md#alias-access-limiting) agli alias che devono gestire.