ABAC per AWS KMS

Il controllo dell'accesso basato su attributi (Attribute-Based Access Control, ABAC) è una strategia di autorizzazione che definisce le autorizzazioni in base agli attributi. AWS KMS supporta ABAC consentendo di controllare l'accesso alle chiavi gestite dal cliente in base ai tag e agli alias associati alle chiavi KMS. Le chiavi di condizione tag e alias che abilitano ABAC in AWS KMS forniscono un modo potente e flessibile per autorizzare le entità a utilizzare le chiavi KMS senza modificare le policy o gestire le concessioni. 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 per AWS KMS, presta attenzione quando concedi ai principali l'autorizzazione per 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 informazioni dettagliate sul supporto AWS KMS per ABAC, inclusi gli esempi, consulta Utilizzo degli alias per controllare l'accesso alle chiavi KMS e Utilizzo dei tag per controllare l'accesso alle chiavi KMS.

• Per informazioni generali sull'utilizzo dei tag per controllare l'accesso alle risorse AWS, consulta Cos'è ABAC per AWS? e Controllo degli accessi alle risorse AWS con i tag per le risorse nella Guida per l'utente di 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	Descrizione	Tipo di policy	Operazioni AWS KMS
seghe: 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	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, UntagResource
aws: TagKeys	Le chiavi tag nella richiesta corrispondono alle chiavi tag nella policy	Policy chiave e policy IAM1	TagResource, UntagResource
km: ResourceAliases	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	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, DescribeKeyGetPublicKey

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

²Un'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, cerca un valore della chiave KMS nella colonna Resourcesper 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. Questa differisce leggermente dalle policy che si basano sui tag: sebbene sia possibile utilizzare modelli di alias in una policy, ogni alias deve essere univoco in un Account AWS e una Regione. In questo modo è possibile applicare una policy a un set selezionato di chiavi KMS senza elencare gli ARN chiave delle chiavi KMS nell'istruzione di policy. 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 policy a un set selezionato di chiavi KMS senza elencare gli ARN chiave delle chiavi KMS nell'istruzione di policy. 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.

{
  "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 e alias. Ad esempio, potrebbe essere necessario consentire solo ai principali di gestire la gestione dei tag Purpose=Test. Per informazioni dettagliate, consulta Utilizzo degli alias per controllare l'accesso alle chiavi KMS e Utilizzo dei tag per controllare l'accesso alle chiavi KMS.

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 usare tag o usare alias in base ai particolari modelli di utilizzo 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, 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 risorse AWS.

  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, influiscono solo sulle operazioni che aggiungono, modificano o eliminano l'attributo. Ma la chiave kms: RequestAlias 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 ARN alias per fare riferimento alle chiavi KMS.

• Fornisci autorizzazioni molto limitate.

  L'alias deve essere univoco in un Account AWS e in una Regione. 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.

{
  "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, rivedi i CloudTrail log o le immissioni. TagResourceUntagResource

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 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 condition per consentire l'accesso alle chiavi KMS in diverse regioni dell'account con uno qualsiasi degli alias specificati.

{
  "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 CreateAliasimmissioni. UpdateAliasDeleteAlias

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 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: riceveranno un'AccessDeniedeccezione se la chiave KMS supera gli alias predefiniti per quota di chiavi KMS per quell'account e quella regione.

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. Questo ritardo è probabilmente più lungo del breve ritardo finale di coerenza che colpisce la 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'TagResourceoperazione sia stata completata e la ListResourceTagsrisposta confermi che il tag è 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 e ReEncryptle richieste che specificano il nome alias o l'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 CreateAliasUpdateAliasDeleteAlias È inoltre possibile utilizzare il valore del LastUpdatedDate campo nella ListAliasesrisposta per rilevare una modifica.

Ad esempio, la seguente risposta di ListAliasesesempio mostra che l'ProjectAlpha_Testalias 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 agli alias che devono gestire.