Domande frequenti su AWS Key Management Service

AWS KMS implementa le policy di utilizzo e gestione che decidi di definire. Puoi scegliere di permettere agli utenti e ai ruoli di IAM inclusi nel tuo account o in altri account di utilizzare e gestire le chiavi.

AWS KMS è progettato in modo che nessuno, nemmeno i dipendenti di AWS, possa ottenere dal servizio le chiavi KMS in chiaro. AWS KMS utilizza moduli di sicurezza hardware (HSM) conformi agli standard FIPS 140-2, o in approvazione, per proteggere la riservatezza e l'integrità delle tue chiavi. Le chiavi KMS in chiaro non escono mai dagli HSM, non vengono mai scritte su disco e vengono utilizzate nella memoria volatile degli HSM solo per il tempo necessario per eseguire l'operazione di crittografia richiesta. Gli aggiornamenti software agli host del servizio e al firmware dei moduli di sicurezza hardware (HSM) di AWS KMS vengono monitorati mediante un processo di controllo multilaterale che viene tenuto sotto controllo e verificato da un gruppo indipendente interno di Amazon e da un laboratorio certificato NIST in conformità con FIPS 140-2.

Per ulteriori informazioni su questi controlli di sicurezza, consulta la documentazione tecnica dettagli della crittografia di AWS KMS. È anche possibile consultare il certificato dei moduli di sicurezza hardware di AWS KMS per lo standard FIPS 140-2 e la relativa policy sulla sicurezza per ulteriori dettagli su come i moduli siano conformi ai requisiti di sicurezza dello standard FIPS 140-2. Inoltre, puoi scaricare una copia del report System and Organization Controls (SOC) da AWS Artifact per ulteriori informazioni sui controlli di sicurezza adottati dal servizio per proteggere le chiavi KMS.

Non devi fare nulla. Tutte le chiavi AWS KMS, indipendentemente dalla loro data o origine di creazione, vengono automaticamente protette mediante i moduli di sicurezza hardware (HSM) che sono stati convalidati con la sicurezza FIPS 140-2 livello 3.

Gli HSM convalidati con la sicurezza FIPS 140-2 livello 3 sono distribuiti in tutte le Regioni AWS in cui è offerto AWS KMS.
NOTA: per regolamento, AWS KMS nelle regioni cinesi non può utilizzare gli HSM FIPS del NIST e utilizza invece gli HSM certificati dall'Office of the State Commercial Cryptographic Administration (OSCCA) cinese.

AWS KMS è un servizio su due livelli. Gli endpoint API ricevono le richieste del client tramite una connessione HTTPS utilizzando solo pacchetti di cifratura TLS che supportino l'opzione PFS (Perfect Forward Secrecy). Questi endpoint API autenticano e autorizzano la richiesta prima di inoltrarla agli HSM di AWS KMS per le operazioni di crittografia, o al tuo cluster AWS CloudHSM se utilizzi la funzionalità dello storage per chiavi personalizzate di KMS.

È possibile configurare le applicazioni affinché si connettano agli endpoint HTTPS conformi allo standard FIPS 140-2 univoci della regione. Gli endpoint HTTPS conformi allo standard FIPS 140-2 di AWS KMS sono basati suOpenSSL FIPS Object Module. Puoi rivedere la policy di sicurezza del modulo OpenSSL qui. Gli endpoint HTTPS conformi allo standard FIPS 140-2 sono disponibili in tutte le regioni di tipo commerciale in cui è disponibile AWS KMS.

Sì. AWS KMS dispone delle funzionalità e dei controlli di sicurezza che permettono di facilitare la conformità ai requisiti di crittografia e gestione delle chiavi descritti principalmente nelle sezioni 3.5 e 3.6 dello standard PCI DSS 3.2.1.

Per ulteriori dettagli sui servizi conformi con lo standard PCI DSS in AWS, leggi la sezione Domande frequenti sullo standard PCI DSS.

Puoi impostare AWS KMS in modo che generi chiavi dati che possono essere restituite per l’utilizzo nella tua applicazione. Le chiavi dati vengono crittografate in base a una chiave master definita in AWS KMS per poter archiviare in modo sicuro la chiave dati crittografata assieme ai dati crittografati. La chiave dati crittografata (e pertanto anche i dati di origine) possono essere decrittografati solo dagli utenti con autorizzazioni a utilizzare la chiave master originale usata per decrittografare la chiave dati crittografata.

No. Le chiavi AWS KMS vengono create e utilizzate solo all'interno del servizio per garantirne la sicurezza, nonché per implementare le policy e fornire un registro centralizzato relativo al loro utilizzo.

Una chiave KMS per regione singola generata da AWS KMS viene archiviata e utilizzata solo nella regione in cui è stata creata. Con le chiavi multi-Regione AWS KMS puoi scegliere di replicare una chiave primaria multi-Regione in più Regioni all'interno della stessa partizione AWS.

I log disponibili in AWS CloudTrail riportano tutte le richieste dell'API AWS KMS, comprese quelle di gestione (ad esempio, creazione, rotazione, disabilitazione e modifiche delle policy) e quelle di crittografia (ad esempio, crittografia/decrittografia). Per visualizzare questi log, attiva CloudTrail nel tuo account.

CloudHSM offre un cluster HSM single-tenant convalidato nel cloud privato virtuale (VPC) Amazon per memorizzare e utilizzare le chiavi. Avrai così il controllo completo sulle modalità di utilizzo delle chiavi, mediante un meccanismo di autenticazione indipendente da AWS. L'utilizzo delle chiavi contenute nel cluster di CloudHSM sarà analogo a quello delle applicazioni in esecuzione in Amazon EC2. CloudHSM è perfetto per diversi casi d'uso, ad esempio per la gestione di DRM, infrastrutture a chiave pubblica, firma di documenti e funzionalità di crittografia con interfacce PKCS#11, Java JCE e Microsoft CNG.
 

AWS KMS consente invece di creare e controllare le chiavi di crittografia usate dalle applicazioni e dai servizi AWS supportati in più regioni in tutto il mondo mediante di un'unica console. Per proteggere la sicurezza delle chiavi, il servizio utilizza un HSM FIPS già conforme agli standard FIPS 140-2 o che è in fase conformità. La gestione centralizzata di tutte le chiavi consente di definire chi può utilizzare e gestire le chiavi e secondo quali condizioni, nonché stabilire ogni quanto devono essere aggiornate. L'integrazione di AWS KMS con CloudTrail ti permette di monitorare l'uso delle chiavi a supporto delle attività di verifica delle normative e della conformità. Interagisci con AWS KMS dalle tue applicazioni utilizzando l'SDK AWS se desideri chiamare direttamente le API del servizio, tramite altri servizi AWS integrati con AWS KMS oppure utilizzando SDK di crittografia AWS se desideri eseguire la crittografia lato client.

Con AWS KMS pagherai solo le risorse utilizzate, senza alcun costo minimo. L'utilizzo del servizio non richiede alcun impegno di lungo termine né costi di configurazione. Alla fine del mese, verrà addebitato sulla carta di credito il costo delle risorse utilizzate in quel mese.

Ti vengono addebitati i costi mensili per tutte le chiavi KMS create e per le richieste API inoltrate al servizio, al netto del piano gratuito.
 

Per informazioni aggiornate relative ai prezzi, visita la pagina dei prezzi di AWS KMS.

Sì. Grazie al piano gratuito AWS, puoi iniziare a utilizzare AWS KMS gratuitamente* in tutte le regioni. L'archiviazione, nel tuo account, delle chiavi AWS KMS gestite da AWS create per tuo conto dai servizi AWS è gratuita. È disponibile un piano gratuito che fornisce un numero di richieste mensili gratuite al servizio. Per informazioni aggiornate sui prezzi e sul piano gratuito, visita la pagina dei prezzi di AWS KMS.

*Le richieste API che coinvolgono le chiavi KMS asimmetriche e le richieste alle API GenerateDataKeyPair e GenerateDataKeyPairWithoutPlaintext non sono incluse nel piano gratuito.

Salvo diversamente specificato, i prezzi sono al netto di eventuali tasse e imposte doganali, inclusa l'IVA ed eventuali imposte sulle vendite. Per i clienti con indirizzo di fatturazione in Giappone, l'utilizzo dei servizi AWS è soggetto all'imposta sul consumo giapponese. Ulteriori informazioni sono disponibili qui.

Sì. È possibile importare in AWS KMS una copia delle chiavi da un'infrastruttura di gestione delle chiavi esistente per utilizzarle con tutti i servizi AWS con cui si integra e con le tue applicazioni.

Puoi usare una chiave importata per avere un maggiore controllo su creazione, ciclo di vita, gestione e durabilità di una chiave in AWS KMS. L'importazione delle chiavi permette di soddisfare con maggiore semplicità i requisiti di conformità, tra cui è talvolta inclusa la possibilità di generare e conservare una copia sicura della chiave all'interno dell'infrastruttura e di eliminare immediatamente la copia importata dall'infrastruttura AWS.

È possibile importare chiavi simmetriche, chiavi asimmetriche (RSA e curva ellittica) e chiavi HMAC.

Durante l'importazione, la chiave deve essere protetta da una chiave pubblica fornita da AWS KMS usando l'algoritmo di protezione supportato. Ciò verifica che la tua chiave crittografata possa essere decrittografata solo da AWS KMS.

Esistono due differenze principali:
 

1. Tu hai la responsabilità di conservare una copia protetta delle chiavi importate nell'infrastruttura di gestione delle chiavi così da poterle reimportare in qualsiasi momento. AWS, tuttavia, garantisce la disponibilità, sicurezza e durabilità delle chiavi generate da AWS KMS per tuo conto fino a quando non ne programmi l'eliminazione.
2. Puoi impostare un periodo di scadenza per una chiave importata. AWS KMS eliminerà automaticamente il materiale di cifratura dopo la scadenza. Puoi anche eliminare il materiale di cifratura importato on demand. In entrambi i casi, il materiale di cifratura viene eliminato, ma la referenza della chiave KMS in AWS KMS e i metadati associati vengono mantenuti, per cui in futuro il materiale di cifratura può essere reimportato. Le chiavi generate da AWS KMS non hanno una data di scadenza e non possono essere cancellate subito perché vi è un periodo di attesa obbligatorio che varia da 7 a 30 giorni. Tutte le chiavi KMS gestite dal cliente, indipendentemente dal fatto che il materiale di cifratura sia stato importato o no, possono essere disabilitate manualmente o programmate per essere cancellate. In questo caso, viene eliminata la chiave KMS stessa, non solo il materiale di cifratura sottostante.

Puoi reimportare una copia del materiale di cifratura con un periodo di scadenza valido in AWS KMS sotto la chiave AWS KMS originale in modo che possa essere utilizzato.

Sì. Una volta importata la chiave in una chiave AWS KMS, inizierai a ricevere con una frequenza di pochi minuti una notifica di parametro di CloudWatch che indicherà il tempo rimanente alla sua scadenza della chiave importata. Riceverai inoltre una notifica di evento di CloudWatch una volta scaduta la chiave importata sotto la tua chiave AWS KMS. Puoi creare una funzione basata su tali parametri o eventi per reimportare automaticamente la chiave con un nuovo periodo di scadenza per non metterne a repentaglio la disponibilità.

AWS KMS supporta chiavi a 256 bit durante la creazione di una chiave KMS per la crittografia e la decrittografia. Le chiavi dati generate e rinviate al chiamante possono essere di 256 bit, 128 bit o di un valore arbitrario fino a 1024 byte. Quando AWS KMS utilizza una chiave KMS a 256 bit per crittografare e decrittografare per conto dell’utente, viene utilizzato l’algoritmo AES in modalità Galois Counter (AES-GCM).

AWS KMS supporta i seguenti tipi di chiavi asimmetriche: RSA 2048, RSA 3072, RSA 4096, ECC NIST P-256, ECC NIST P-384, ECC NIST-521 e ECC SECG P-256k1. AWS KMS supporta gli algoritmi di crittografia RSAES_OAEP_SHA_1 e RSAES_OAEP_SHA_256 con i tipi di chiavi RSA 2048, RSA 3072 e RSA 4096. Gli algoritmi di crittografia non possono essere utilizzati con tipi di chiavi basate su curve ellittiche (ECC NIST P-256, ECC NIST P-384, ECC NIST-521 e ECC SECG P-256k1).

Quando si utilizzano tipi di chiave basati su curva ellittica, AWS KMS supporta gli algoritmi di negoziazione della chiave ECDH.

Quando si utilizzano i tipi di chiavi RSA, AWS KMS supporta i seguenti algoritmi di firma: RSASSA_PSS_SHA_256, RSASSA_PSS_SHA_384, RSASSA_PSS_SHA_512, RSASSA_PKCS1_V1_5_SHA_256, RSASSA_PKCS1_V1_5_SHA_384 e RSASSA_PKCS1_V1_5_SHA_512. Quando si utilizzano i tipi di chiavi basati su curve ellittiche, AWS KMS supporta i seguenti algoritmi di firma: ECDSA_SHA_256, ECDSA_SHA_384 e ECDSA_SHA_512.

La porzione pubblica del materiale della chiave asimmetrica è generato in AWS KMS e può essere utilizzata per la verifica della firma digitale chiamando l’API “Verify” oppure, per la crittografia della chiave pubblica, l’API “Encrypt”. La chiave pubblica può anche essere utilizzata al di fuori di AWS KMS per la verifica o la crittografia. È possibile chiamare l’API GetPublicKey per recuperare la porzione pubblica della chiave KMS asimmetrica.

Il limite di dimensione è di 4 KB. Nel caso si voglia firmare digitalmente dati di dimensioni maggiori di 4 KB, è possibile creare un messaggio di acquisizione dei dati e di inviarlo ad AWS KMS. La firma digitale è creata sulla base dell'acquisizione dei dati e quindi rinviata. Nella richiesta API Sign, dovrai specificare se inviare l'intero messaggio o un messaggio di acquisizione come un parametro. Qualsiasi dato inviato alle API Encrypt, Decrypt o Re-Encrypt che utilizzano operazioni asimmetriche deve anche essere di dimensioni inferiori ai 4 KB.

Nella console, ciascuna chiave avrà un nuovo campo chiamato Tipo chiave. Tale campo riporterà le voci Chiave simmetrica o Chiave asimmetrica per indicare il tipo di chiave. L'API DescribeKey risponderà riportando un campo KeyUsage che specifica se la chiave può essere utilizzata per firmare, generare HMAC o crittografare.

No. La rotazione automatica delle chiavi non è supportata per le chiavi KMS HMAC asimmetriche. In generale, la rotazione delle chiavi asimmetriche o HMAC può compromettere notevolmente il carico di lavoro esistente, poiché è necessario ritirare e sostituire tutte le istanze di chiavi utilizzate in passato con altre parti. Se necessario, puoi ruotarle manualmente creando una nuova chiave KMS e mappando l'alias di una chiave esistente a partire dalla vecchia chiave KMS su quella nuova.

No. Quando si crea una chiave KMS, è necessario specificare se la chiave può essere utilizzata per decrittare o firmare le operazioni. Una chiave RSA può essere utilizzata per firmare o crittografare, ma non per eseguire entrambe le operazioni allo stesso tempo. I tipi di chiavi a curve ellittiche possono essere utilizzati solo per firmare.

Sì. I limiti della frequenza di richieste al secondo varia a seconda dei tipi di chiavi e degli algoritmi utilizzati. Per maggiori dettagli, consulta la pagina dei limiti di AWS KMS.

No. Non è possibile utilizzare la funzionalità di archiviazione delle chiavi personalizzate con chiavi asimmetriche.

Non direttamente. AWS KMS non archivia o associa certificati digitali con le chiavi KMS asimmetriche che crea. È possibile richiedere a un'autorità di certificazione quale l'Autorità privata per la gestione del certificato AWS di emettere un certificato per la porzione pubblica della chiave KMS asimmetrica. Ciò permetterà alle entità che utilizzano la chiave pubblica di verificare che questa appartenga realmente a te.

La funzionalità dell'archivio di chiavi personalizzate di AWS KMS combina i controlli forniti da CloudHSM con l'integrazione e la facilità d'uso di AWS KMS. Puoi configurare il tuo cluster CloudHSM e autorizzare AWS KMS a utilizzarlo come storage dedicato per le tue chiavi al posto di quello per chiavi predefinite di AWS KMS. Quando crei le chiavi in AWS KMS, puoi scegliere di generare il materiale di cifratura nel tuo cluster CloudHSM. Le chiavi KMS generate nella tua archiviazione per chiavi personalizzate non lasciano mai in chiaro gli HSM nel cluster CloudHSM e tutte le operazioni di AWS KMS che utilizzano quelle chiavi vengono eseguite solo nei tuoi HSM. Per tutti gli altri aspetti, le chiavi KMS archiviate nella tua archiviazione per chiavi personalizzate sono coerenti con le altre chiavi di AWS KMS.

Ulteriori indicazioni per stabilire se l'uso di un archivio di chiavi personalizzate è appropriato sono disponibili in questo blog.

Dato che controlli il tuo cluster CloudHSM, puoi scegliere di gestire il ciclo di vita delle tue chiavi KMS in modo indipendente da AWS KMS. Un archivio per chiavi personalizzate potrebbe essere utile per tre ragioni. In primo luogo, potrebbero esservi delle chiavi che devono essere esplicitamente protette in un HSM single-tenant o in un HSM sul quale hai il controllo diretto. Secondo, potrebbe essere necessario rimuovere immediatamente il materiale di cifratura da AWS KMS e dimostrare di averlo fatto con mezzi indipendenti. Infine, potresti dover essere in grado di controllare l'uso delle tue chiavi indipendentemente da AWS KMS o CloudTrail.

Esistono due differenze nella gestione delle chiavi in un archivio di chiavi personalizzate supportato da CloudHSM rispetto all'archivio di chiavi AWS KMS predefinito. Il materiale di cifratura non può essere importato nell'archivio per chiavi personalizzate e AWS KMS non può ruotare automaticamente le chiavi. Per tutto il resto, compreso il tipo di chiavi che possono essere generate, il modo in cui le chiavi utilizzano gli alias e come le policy sono definite, le chiavi archiviate in un'archiviazione per chiavi personalizzate sono gestite come qualsiasi altra chiave KMS gestita dal cliente di AWS KMS.

No, solo le chiavi KMS gestite dal cliente possono essere archiviate e gestite in un archivio di chiavi personalizzate di AWS KMS supportato da CloudHSM. Le chiavi KMS gestite da AWS create per tuo conto da altri servizi AWS per crittografare i tuoi dati sono sempre generate e archiviate nell'archivio per chiavi di default di AWS KMS.

No, le richieste dell'API ad AWS KMS relative all'uso di una chiave KMS per crittografare e decrittografare i dati vengono gestite nello stesso modo. I processi di autenticazione e autorizzazione operano indipendentemente da dove è conservata la chiave. Tutte le attività che utilizzano una chiave in un archivio di chiavi personalizzate supportato da CloudHSM sono registrate in CloudTrail nello stesso modo. Tuttavia, le operazioni effettive di crittografia avvengono esclusivamente nello storage per chiavi personalizzate o in quello per chiavi predefinite di AWS KMS.

Oltre all'attività registrata su CloudTrail da AWS KMS, l'uso di un archivio di chiavi personalizzate fornisce altri tre meccanismi di audit. Innanzitutto, CloudHSM registra anche tutte le attività API su CloudTrail, come la creazione di cluster e l'aggiunta o la rimozione di HSM. In secondo luogo, ogni cluster acquisisce anche i propri log locali per registrare l'attività di gestione degli utenti e delle chiavi. In terzo luogo, ogni istanza di CloudHSM copia i log dell'attività di gestione delle chiavi e degli utenti locali in AWS CloudWatch.

Se usi un archivio di chiavi personalizzate di AWS KMS hai la responsabilità di garantire che le tue chiavi siano disponibili per l'uso da parte di AWS KMS. Errori nella configurazione di CloudHSM e la cancellazione accidentale del materiale di cifratura all'interno di un cluster CloudHSM potrebbero influire sulla disponibilità. Anche il numero di HSM che utilizzi e la tua scelta delle zone di disponibilità (AZ) possono influire sulla resilienza del tuo cluster. Come in qualsiasi sistema di gestione delle chiavi, è importante capire in che modo la disponibilità delle chiavi può incidere sul recupero dei tuoi dati crittografati.

La velocità con cui le chiavi archiviate in un archivio di chiavi personalizzate AWS KMS supportato da CloudHSM possono essere utilizzate tramite chiamate API AWS KMS è inferiore a quella delle chiavi archiviate nell'archivio di chiavi AWS KMS predefinito. Per i limiti delle prestazioni correnti, consulta la Guida per gli sviluppatori di AWS KMS.

L'uso di un archivio di chiavi personalizzate non incide sui prezzi di AWS KMS. Tuttavia, ogni storage per chiavi personalizzate richiede che il cluster AWS CloudHSM contenga almeno due HSM. Questi HSM vengono addebitati in base ai prezzi di AWS CloudHSM standard. L'uso di un archivio di chiavi personalizzate non comporta ulteriori costi.

Gli utenti AWS KMS che desiderano utilizzare un archivio di chiavi personalizzate dovranno impostare un cluster AWS CloudHSM, aggiungere gli HSM, gestire utenti di HSM ed, eventualmente, ripristinare gli HSM dal backup. Queste sono attività sensibili per la sicurezza e dovresti assicurarti di disporre delle risorse e dei controlli organizzativi appropriati.

No, la possibilità di importare il proprio materiale di cifratura in un archivio di chiavi personalizzate di AWS KMS non è supportata. Le chiavi memorizzate in un archivio di chiavi personalizzate possono essere generate solo negli HSM che formano il cluster CloudHSM.

No, la possibilità di migrare le chiavi tra i diversi tipi di storage per chiavi AWS KMS non è attualmente supportata. Tutte le chiavi devono essere create nello storage per chiavi in cui verranno utilizzate, tranne nei casi in cui si importa il proprio materiale di cifratura nello storage per chiavi predefinite di AWS KMS.

La possibilità di ruotare automaticamente il materiale di cifratura in uno storage per chiavi personalizzate di AWS KMS non è supportata. La rotazione delle chiavi deve essere eseguita manualmente creando nuove chiavi e rimappando gli alias delle chiavi di AWS KMS utilizzati dal codice dell'applicazione per usare le nuove chiavi per le future operazioni di crittografia.

Sì, AWS KMS non richiede l'accesso esclusivo al tuo cluster CloudHSM. Se disponi già di un cluster, puoi utilizzarlo come archivio di chiavi personalizzate e continuare a usarlo per le tue altre applicazioni. Tuttavia, se il tuo cluster supporta carichi di lavoro elevati, non AWS KMS, potresti avere una velocità effettiva ridotta per le operazioni che utilizzano le chiavi KMS nella tua archiviazione per chiavi personalizzate. Analogamente, una frequenza di richieste AWS KMS elevata per il tuo archivio per chiavi personalizzate potrebbe influire sulle tue altre applicazioni.

Per una panoramica del servizio, visita il sito Web di AWS CloudHSM, mentre per maggiori dettagli sulla configurazione e l'uso del servizio leggi la Guida per l'utente di AWS CloudHSM.

Un archivio di chiavi esterne è un archivio di chiavi personalizzato supportato da un'infrastruttura di gestione delle chiavi esterna che possiedi e gestisci al di fuori di AWS. Tutte le operazioni di crittografia o decrittografia che utilizzano una chiave KMS in un archivio du chiavi esterne vengono eseguite nel gestore delle chiavi con chiavi e operazioni di crittografia che sono sotto il tuo controllo e sono fisicamente inaccessibili ad AWS.

XKS può aiutarti a rispettare le regole o i regolamenti che richiedono che le chiavi di crittografia vengano archiviate e utilizzate al di fuori di AWS sotto il tuo controllo.

Le richieste ad AWS KMS dai servizi AWS integrati per tuo conto o dalle tue applicazioni vengono inoltrate a un componente nella tua rete chiamato XKS Proxy. Tale XKS Proxy è una specifica API open source che aiuta te e il tuo fornitore di gestione delle chiavi a creare un servizio che accetti queste richieste e le inoltri alla tua infrastruttura di gestione delle chiavi per utilizzare le sue chiavi per la crittografia e la decrittografia.

Thales, Entrust, Atos, Fortanix, DuoKey, Securonix, Utimaco, Salesforce, T-Systems e HashiCorp dispongono di soluzioni che si integrano con le specifiche XKS Proxy. Per informazioni su disponibilità, prezzi e modalità di utilizzo delle soluzioni di questi fornitori, consulta la rispettiva documentazione. Incoraggiamo te e il tuo partner dell'infrastruttura di gestione delle chiavi a sfruttare la specifica XKS Proxy open source per creare una soluzione che soddisfi le tue esigenze. La specifica API per XKS Proxy è disponibile qui.

Le chiavi esterne supportano le seguenti operazioni di crittografia simmetrica: Encrypt, ReEncrypt, Decrypt e GenerateDataKey.

Puoi utilizzare le chiavi XKS per crittografare i dati in qualsiasi servizio AWS che si integra con AWS KMS utilizzando le chiavi gestite dal cliente. Consulta qui l'elenco dei servizi supportati. I servizi AWS chiamano l'API GenerateDataKey di AWS KMS per richiedere una chiave di dati univoca in testo semplice per crittografare i dati. La chiave di dati in testo semplice viene restituita al servizio insieme a una copia crittografata della chiave di dati da archiviare insieme ai dati crittografati. Per produrre la copia crittografata della chiave di dati, la chiave di dati in testo normale viene prima crittografata da una chiave archiviata in AWS KMS univoca per il tuo account AWS. Questa chiave di dati crittografata viene quindi inoltrata alla tua implementazione di XKS Proxy collegata al tuo gestore di chiavi esterno per essere crittografata una seconda volta sotto la chiave che definisci nel tuo gestore di chiavi esterno. La chiave di dati con doppia crittografia risultante viene restituita nella risposta alla richiesta dell'API GenerateDataKey.

La connessione di rete tra AWS KMS, l'implementazione di XKS Proxy e il gestore di chiavi esterne deve essere protetta con un protocollo di crittografia point-to-point come TLS. Tuttavia, per proteggere i tuoi dati che escono da AWS KMS fino a quando non raggiungono il tuo gestore di chiavi esterne, AWS KMS li crittografa prima con una chiave KMS gestita internamente nel tuo account specifica per ciascuna chiave KMS definita nel tuo archivio di chiavi esterne. Il testo cifrato risultante viene inoltrato al tuo gestore di chiavi esterne, che lo crittografa utilizzando la chiave nel gestore. La doppia crittografia fornisce il controllo di sicurezza che nessun testo criptato può mai essere decrittografato senza utilizzare il materiale della chiave nel tuo gestore di chiavi esterne. Fornisce inoltre il controllo di sicurezza che il testo criptato che esce dalla rete AWS sia crittografato utilizzando gli HSM AWS KMS certificati FIPS 140. Poiché per decrittografare i dati deve essere utilizzato il tuo gestore di chiavi esterne, se revochi l'accesso ad AWS KMS, i tuoi dati crittografati sottostanti diventano inaccessibili.

Sì. Le chiavi XKS possono anche essere utilizzate all'interno delle tue applicazioni quando utilizzi una soluzione di crittografia simmetrica lato client che utilizza AWS KMS come provider di chiavi. Le soluzioni AWS di crittografia lato client open source come l'SDK di crittografia AWS, il client di crittografia S3 e il client di crittografia DynamoDB supportano le chiavi XKS.

Tutte le chiavi XKS devono essere create come nuove chiavi in KMS. Non puoi migrare chiavi KMS esistenti in chiavi XKS ospitate nel tuo gestore di chiavi esterne.

Puoi crittografare nuovamente i dati esistenti con chiavi XKS appena generate, supponendo che il servizio AWS o la tua applicazione supporti l'azione. Molti servizi AWS ti aiuteranno a copiare una risorsa crittografata e designare una nuova chiave KMS da utilizzare per crittografare la copia. Puoi configurare la chiave XKS nel comando COPY fornito dal servizio AWS. Puoi crittografare nuovamente i dati crittografati lato client nelle tue applicazioni chiamando l'API ReEncrypt KMS e configurando la chiave XKS.

Come tutte le chiavi gestite dal cliente, le chiavi XKS hanno un prezzo di 1 dollaro al mese per chiave fino a quando non vengono eliminate. Le richieste con chiavi XKS vengono addebitate alla stessa tariffa di qualsiasi altra chiave simmetrica AWS KMS. Scopri di più sui prezzi nella pagina dei prezzi di AWS KMS.

Sì. La rotazione automatica delle chiavi è supportata dalla specifica XKS ed è una funzionalità fornita dalla maggior parte dei fornitori che supportano XKS. La rotazione automatica delle chiavi XKS avviene interamente nel gestore di chiavi esterno e funziona in modo simile alla rotazione automatica delle chiavi AWS KMS create e gestite all'interno di KMS. Quando si utilizza una chiave KMS XKS ruotata per crittografare i dati, il gestore delle chiavi esterno utilizza il materiale chiave corrente. Quando si utilizza la chiave XKS ruotata per decrittografare il testo cifrato, il gestore di chiavi esterno utilizza la versione del materiale chiave utilizzato per crittografarlo. Finché le chiavi XKS precedenti utilizzate per creare testi criptati precedenti sono ancora abilitate nel tuo gestore di chiavi esterno, sarai in grado di effettuare correttamente la richiesta API Decrypt nelle versioni di tali chiavi XKS.

Per i servizi che non memorizzano nella cache le chiavi, la successiva chiamata API che utilizza questa chiave XKS KMS avrà esito negativo. Alcuni servizi implementano la memorizzazione nella cache delle chiavi di dati o altri schemi di derivazione delle chiavi per la gestione dei costi di prestazioni, latenza o KMS. La memorizzazione nella cache di queste chiavi può variare da 5 minuti a 24 ore. Qualsiasi risorsa protetta attualmente in uso (come il database RDS o l'istanza EC2) risponderà in modo diverso dopo aver negato l'accesso alla chiave. Consulta la documentazione relativa al servizio AWS per i dettagli.

Per eseguire l'autenticazione al proxy dell'archivio chiavi esterno, AWS KMS firma tutte le richieste al proxy utilizzando le credenziali AWS SigV4 configurate sul proxy e fornite a KMS. AWS KMS autentica il proxy dell'archivio chiavi esterno utilizzando certificati TLS lato server. Facoltativamente, il tuo proxy può abilitare il TLS reciproco per un'ulteriore garanzia che accetti solo richieste da AWS KMS.

Tutti i consueti meccanismi di autorizzazione di AWS KMS (policy IAM, policy delle chiavi AWS KMS, concessioni) che utilizzi con altre chiavi KMS funzionano allo stesso modo per le chiavi KMS negli archivi di chiavi esterne.

Inoltre, i tuoi partner e/o i partner dei gestori di chiavi esterne hanno la possibilità di implementare un livello secondario di controlli di autorizzazione basati sui metadati della richiesta inclusi in ogni richiesta inviata da AWS KMS a XKS Proxy. Questi metadati includono l'utente/ruolo AWS chiamante, l'ARN della chiave KMS e l'API KMS specifica richiesta. Ciò ti consente di applicare policy di autorizzazione granulari sull'uso di una chiave nel tuo gestore di chiavi esterno oltre a fidarti semplicemente di qualsiasi richiesta da AWS KMS. La scelta dell'applicazione delle policy utilizzando questi attributi di richiesta è lasciata alle singole implementazioni di XKS Proxy.

L'ID univoco generato per ogni richiesta in arrivo ad AWS KMS che coinvolge chiavi XKS viene inoltrato anche a XKS Proxy. Puoi utilizzare i dati di log (se disponibili) dal tuo proxy XKS o gestore di chiavi esterno per riconciliare le richieste fatte ad AWS KMS con quelle fatte al tuo gestore di chiavi esterno. Questa funzionalità ti consente di verificare che tutte le richieste di utilizzo delle chiavi nel tuo gestore di chiavi esterne abbiano avuto origine da una chiamata che hai avviato ad AWS KMS direttamente o tramite un servizio AWS integrato.

Rischio di disponibilità: sei responsabile della disponibilità di XKS Proxy e del materiale delle chiavi esterne. Questo sistema deve avere un'elevata disponibilità per verificare che ogni volta che hai bisogno di una chiave XKS per decrittografare una risorsa crittografata o crittografare nuovi dati, AWS KMS possa connettersi correttamente a XKS Proxy, che a sua volta può connettersi al tuo gestore di chiavi esterno per completare l'operazione crittografica necessaria usando la chiave. Ad esempio, supponiamo di aver crittografato un volume EBS utilizzando una chiave XKS e ora desideri avviare un'istanza EC2 e collegare quel volume crittografato. Il servizio EC2 passerà la chiave di dati crittografata univoca per quel volume ad AWS KMS per decrittografarla in modo che possa essere fornita nella memoria volatile della scheda Nitro per decrittografare e crittografare le operazioni di lettura/scrittura sul volume. Se XKS Proxy o il gestore di chiavi esterne non è disponibile per decrittografare la chiave del volume, l'istanza EC2 non verrà avviata. In questi tipi di errori, AWS KMS restituisce un'eccezione KMSInvalidStateException che indica che XKS Proxy non è disponibile. Spetta ora a te determinare perché XKS Proxy e il gestore delle chiavi non sono disponibili in base ai messaggi di errore forniti da KMS.

Rischio di durabilità: poiché le chiavi sono sotto il tuo controllo nei sistemi al di fuori di AWS, sei l'unico responsabile della durabilità di tutte le chiavi esterne che crei. Se la chiave esterna per una chiave XKS viene persa o eliminata definitivamente, tutto il testo criptato crittografato sotto la chiave XKS è irrecuperabile.

Rischio di prestazioni: sei responsabile della verifica che il XKS Proxy e l'infrastruttura dell'archivio chiavi esterno siano progettati con caratteristiche prestazionali sufficienti per soddisfare le proprie esigenze. Poiché ogni richiesta che utilizza le chiavi XKS richiede una connessione al tuo archivio di chiavi esterno, il tuo XKS Proxy può diventare un collo di bottiglia se il tasso di richiesta da AWS KMS supera il tasso di richiesta che il tuo XKS Proxy o il gestore di chiavi esterne può supportare. Inoltre, se il tempo trascorso di una singola richiesta (incluso un tentativo) da AWS KMS a XKS Proxy richiede più di 500 ms*, AWS KMS restituirà un errore 400 al suo client chiamante, comunicando in modo efficace che la tua chiave XKS non è disponibile e il client chiamante non dovrebbe riprovare. Questo comportamento è progettato per ridurre al minimo il rischio che i servizi AWS a monte o le tue applicazioni debbano reagire a sporadiche latenze eccessive causate da problemi di connettività alla tua infrastruttura.

*AWS KMS tenterà un singolo tentativo per qualsiasi richiesta che richiede 250 ms. Se anche la richiesta di ripetizione richiede più di 250 ms, al client chiamante verrà restituito un errore 400.

Poiché AWS non può controllare la disponibilità end-to-end della connessione tra AWS KMS e l'infrastruttura dell'archivio chiavi esterno, escludiamo specificamente l'uso di XKS nel nostro SLA di disponibilità KMS pubblico. Inoltre, le chiavi XKS sono escluse dallo SLA di disponibilità per qualsiasi servizio AWS in cui una chiave XKS è configurata dall'utente per crittografare i dati all'interno del servizio.