Policy delle chiavi, grant e condizioni

Creare una chiave è solo metà del lavoro; controllare chi può usarla è l'altra metà. KMS utilizza diversi meccanismi di accesso sovrapposti.

Il più importante è la key policy, ovvero la policy basata sulla risorsa associata direttamente alla chiave.

Ogni chiave KMS ha una key policy che costituisce l'autorità principale per l'accesso.

• A differenza della maggior parte dei servizi, una chiave KMS deve avere una key policy.
• Se la key policy non concede l'accesso, le sole policy IAM non possono farlo.

Questo rende la key policy il punto di controllo.

Per accedere a una chiave KMS, la key policy deve abilitare IAM; dopodiché IAM e key policy operano insieme.

La key policy predefinita include un'istruzione che concede l'accesso ai principal IAM dell'account, nel rispetto delle relative policy IAM. Senza tale istruzione, solo i principal indicati direttamente nella key policy possono usare la chiave.

Un grant è un modo flessibile e temporaneo per delegare l'uso di una chiave.

• Consente operazioni specifiche a un principal, spesso in modo programmatico.
• I servizi AWS utilizzano i grant per accedere alle chiavi per Suo conto.

I grant possono essere ritirati o revocati quando non sono più necessari, il che li rende ideali per deleghe di breve durata.

Scelga in base alla durata e al livello di granularità:

• Utilizzi la key policy e IAM per accessi ampi e di lunga durata.
• Utilizzi i grant per autorizzazioni granulari e temporanee, spesso create dinamicamente da servizi o applicazioni.

I grant evitano di modificare la key policy per esigenze di breve durata.

KMS supporta potenti condition key nelle policy, come kms:ViaService.

ViaService limita l'uso della chiave alle richieste provenienti tramite uno specifico servizio AWS (ad esempio solo tramite S3), così un principal può decrittografare solo quando la chiamata viene effettuata da S3 e non direttamente.

Il contesto di crittografia è un insieme di coppie chiave-valore passate con encrypt/decrypt e associate crittograficamente all'operazione.

• Per decrittografare è necessario fornire lo stesso contesto.
• Il contesto compare in CloudTrail per il controllo.

Le policy possono richiedere un contesto specifico con la condizione kms:EncryptionContext.

Per consentire a un altro account di usare una chiave, la key policy deve autorizzare quell'account esterno e il principal esterno deve disporre anche dell'autorizzazione IAM.

Si tratta dello stesso modello a due lati dei ruoli tra account: la policy della risorsa (in questo caso la key policy) e la policy IAM del chiamante devono entrambe consentire l'azione.

Applichi il principio del privilegio minimo alle chiavi:

• Separi gli amministratori delle chiavi (che gestiscono la chiave) dagli utenti delle chiavi (che eseguono encrypt/decrypt).
• Eviti kms:* per gli utenti.
• Utilizzi ViaService e il contesto di crittografia per limitare ulteriormente l'ambito.

In questo modo si limita l'impatto di un'eventuale compromissione di un principal.

Un errore classico consiste nel modificare una key policy e rimuovere l'istruzione che abilita IAM.

Senza di essa, persino gli amministratori dell'account perdono l'accesso e, poiché la key policy è il punto di controllo, si può perdere completamente l'accesso alla chiave. Mantenga sempre nella key policy un principal amministrativo a livello di account per evitare di rendere la chiave irrecuperabile.

Combini CloudTrail (ogni chiamata KMS con il relativo contesto) e IAM Access Analyzer (le key policy che concedono accesso esterno) per verificare chi può usare e chi usa effettivamente ciascuna chiave.

Una revisione regolare individua le key policy troppo permissive prima che diventino un rischio.

Ragioni sull'accesso a KMS.

Ha imparato come viene controllato l'accesso a KMS.

• La key policy è il principale punto di controllo e deve abilitare IAM per consentirne l'uso.
• I grant forniscono una delega temporanea e granulare.
• Le condizioni, come ViaService e il contesto di crittografia, limitano ulteriormente l'ambito.