Domande frequenti su AWS Key Management Service

Le seguenti domande frequenti non si applicano ad AWS Key Management Service (KMS) nella regione AWS Cina (Pechino), gestita da Sinnet, e nella regione AWS Cina (Ningxia), gestita da NWCD. Consulta il link delle domande frequenti per i contenuti relativi a queste due regioni della Cina.

AWS KMS è un servizio gestito che ti permette di creare e controllare in modo semplice le chiavi utilizzate per le tue operazioni di crittografia. Il servizio fornisce una soluzione di generazione, storage, gestione e auditing delle chiavi altamente disponibile per consentirti di crittografare o di firmare digitalmente i dati all'interno delle tue applicazioni o controllare la crittografia dei dati tramite i servizi AWS.

Qualora si abbia la necessità di rendere sicuri i dati presenti nei servizi AWS, si dovrebbe utilizzare AWS KMS per gestire in modo centralizzato le chiavi di crittografia che regolano l'accesso ai dati stessi. Gli sviluppatori che devono crittografare i dati nelle applicazioni devono utilizzare SDK di crittografia AWS con AWS KMS per generare in modo semplice, utilizzare e proteggere chiavi di crittografia simmetriche nel tuo codice. Gli sviluppatori che devono firmare digitalmente o verificare i dati utilizzando chiavi asimmetriche, dovrebbero utilizzare il servizio per creare e gestire le chiavi private di cui hai bisogno. Coloro che desiderano avvalersi di un’infrastruttura scalabile di gestione delle chiavi per supportare gli sviluppatori e le relative applicazioni devono utilizzare questo servizio per ridurre i carichi operativi e i costi di licenza. Coloro che hanno la responsabilità di garantire la sicurezza dei dati per scopi normativi o di conformità dovrebbero utilizzare il servizio poiché permette di dimostrare in modo semplice che i dati sono protetti in modo omogeneo. Inoltre, il servizio rientra nell’ambito di applicazione di un vasto gruppo di regimi di conformità regionali e di settore.

Il modo più semplice per iniziare a usare AWS KMS è quello di scegliere di crittografare i dati con un servizio AWS che utilizza le chiavi root gestite da AWS create automaticamente da ogni servizio. Se desideri il pieno controllo sulla gestione delle chiavi, compresa la capacità di condividerne l'accesso attraverso account o servizi, puoi creare delle chiavi gestite cliente AWS KMS in AWS KMS. Puoi anche utilizzare le chiavi KMS create direttamente nelle tue applicazioni. È possibile accedere ad AWS KMS dalla console KMS raggruppata sotto Sicurezza, identità e conformità nella home page dei servizi AWS della console AWS KMS. Alle API AWS KMS è possibile accedere direttamente anche tramite la CLI (Command Line Interface) di AWS KMS o l'SDK AWS per l'accesso programmatico. Le API AWS KMS possono anche essere usate indirettamente per crittografare i dati all'interno delle tue applicazioni tramite SDK di crittografia AWS. Per ulteriori informazioni, visita la pagina delle Nozioni di base.

Per informazioni sulla disponibilità, consulta l’elenco globale di regioni nella pagina Prodotti e servizi per Regione.

È possibile eseguire le principali funzioni di gestione elencate di seguito:

• Creare chiavi simmetriche, asimmetriche e HMAC in cui il materiale della chiave viene utilizzato esclusivamente all'interno del servizio
• Creare chiavi simmetriche in cui il materiale della chiave viene generato e utilizzato all'interno di un archivio di chiavi personalizzato sotto il tuo controllo e supportato da AWS CloudHSM o nel tuo gestore di chiavi esterno al di fuori di AWS
• Importare il proprio materiale relativo a una chiave simmetrica, asimmetrica e HMAC da utilizzare nei servizi AWS supportati e nella propria applicazione
• Definire gli utenti e i ruoli AWS Identity and Access Management (IAM) che possono gestire le chiavi
• Definire gli utenti e i ruoli IAM che possono utilizzare le chiavi per crittografare e decrittografare i dati
• Scegliere di utilizzare chiavi generate dal servizio per effettuarne la rotazione in modo automatico
  
• Disabilitare temporaneamente le chiavi in modo che non possano essere utilizzate da altri utenti
• Riabilitare le chiavi disabilitate
• Programmare l’eliminazione delle chiavi non più in utilizzo
• Eseguire l'audit dell'utilizzo delle chiavi mediante l'analisi dei log in AWS CloudTrail

Puoi iniziare a utilizzare il servizio richiedendo la creazione di una chiave AWS KMS. Controlla il ciclo di vita della chiave KMS gestita dal cliente e chi la potrà utilizzare o gestire. Una volta creata una chiave KMS, potrai inviare i dati direttamente al servizio AWS KMS così che siano crittografati, decrittati, firmati o verificati o per generare o verificare un HMAC utilizzando tale chiave KMS. Queste chiavi richiedono l'impostazione di policy di utilizzo per stabilire gli utenti che possono eseguire delle azioni e a quali condizioni.

I servizi AWS e i toolkit lato client che, per proteggere i dati, integrano AWS KMS utilizzano un metodo noto come crittografia a busta. Grazie a questo metodo, AWS KMS genera le chiavi di dati che vengono utilizzate per crittografare i dati in locale nel servizio AWS o nell'applicazione. Le chiavi dei dati vengono esse stesse crittografate tramite una chiave AWS KMS definita dall'utente. Le chiavi di dati non vengono conservate o gestite da AWS KMS. I servizi AWS crittografano i dati e archiviano una copia crittografata della chiave dei dati assieme ai dati crittografati. Quando un servizio deve decrittografare i tuoi dati, chiede ad AWS KMS di decrittografare la chiave dei dati utilizzando la tua chiave KMS. Se l'utente che richiede dati dal servizio AWS è autorizzato a decrittografarli secondo la policy del KMS, il servizio AWS riceverà la chiave dei dati decrittografata da AWS KMS. Il servizio AWS quindi decodifica i dati e li restituisce in testo non crittografato. Tutte le richieste di utilizzo delle chiavi KMS vengono registrate in CloudTrail per permettere di capire chi ha usato determinate chiavi, in che contesto e quando.

In genere esistono tre scenari per il modo in cui i dati vengono crittografati tramite AWS KMS. Innanzitutto, puoi utilizzare le API AWS KMS direttamente per crittografare e decrittografare i dati utilizzando le tue chiavi KMS archiviate nel servizio. In secondo luogo, puoi scegliere di far crittografare i tuoi dati dai servizi AWS utilizzando le tue chiavi KMS archiviate nel servizio. In questo caso i dati vengono crittografati utilizzando le chiavi dei dati protette dalle tue chiavi KMS. Infine, puoi usare l'SDK di crittografia AWS che è integrato con AWS KMS per eseguire la crittografia all'interno delle tue applicazioni, indipendentemente dal fatto che operino o no in AWS.

AWS KMS è integrato perfettamente con la maggior parte degli altri servizi AWS per semplificare le procedure di crittografia dei dati in questi servizi. In alcuni casi i dati vengono crittografati per impostazione predefinita utilizzando le chiavi archiviate in AWS KMS ma che sono di proprietà e gestite dal servizio AWS in questione. In molti casi sei tu ad avere la proprietà e la gestione delle chiavi AWS KMS all'interno del tuo account. Alcuni servizi ti offrono la possibilità di gestire tu stesso le chiavi o di demandare questo compito al servizio. Consulta l'elenco dei servizi AWS attualmente integrati con AWS KMS. Per ulteriori informazioni su come i servizi integrati utilizzano AWS KMS, consulta la Guida per gli sviluppatori di AWS KMS.

Anche se AWS KMS è in grado di supportare l’invio di dati fino a 4 KB da crittografare direttamente, la crittografia tramite la tecnica basata su envelope offre vantaggi significativi a livello di prestazioni. I dati crittografati direttamente da AWS KMS devono prima essere trasferiti mediante la rete. La crittografia tramite la tecnica basata su envelope riduce il carico della rete, dato che sulla rete transitano solo la richiesta e la consegna della chiave di dati molto più piccola. La chiave dati viene utilizzata localmente nella tua applicazione o nel servizio AWS di crittografia, evitando di dover inviare l'intero blocco di dati ad AWS KMS e subire la latenza della rete.

È possibile selezionare una chiave KMS specifica da utilizzare quando si desidera che il servizio AWS esegua automaticamente la crittografia dei dati. In questo caso si parla di chiavi KMS gestite dal cliente sulle quali hai il pieno controllo. Sei tu che definisci il controllo dell'accesso e la policy di utilizzo per ogni chiave e puoi concedere ad altri account e servizi le autorizzazioni per utilizzarle. Oltre alle chiavi gestite dal cliente, AWS KMS fornisce anche due tipi di chiavi gestite da AWS: (1) le chiavi KMS gestite da AWS sono chiavi create nel tuo account ma gestite da AWS e (2) le chiavi di proprietà di AWS sono chiavi interamente di proprietà e gestite dagli account AWS. Puoi tenere traccia delle chiavi gestite da AWS nel tuo account. Qualsiasi utilizzo viene registrato in AWS CloudTrail, ma non hai il controllo diretto sulle chiavi. Le chiavi di proprietà di AWS sono le più automatizzate e forniscono la crittografia dei dati all'interno di AWS, ma non forniscono controlli delle policy o log CloudTrail sulla loro attività delle chiavi.

La creazione di una tua chiave KMS ti consente di avere un maggiore controllo rispetto a quello che hai con le chiavi KMS gestite da AWS. Quando crei una chiave KMS simmetrica gestita dal cliente puoi scegliere di usare il materiale di cifratura generato da AWS KMS, all'interno di un cluster AWS CloudHSM o in un gestore di chiavi esterno (tramite l'archivio di chiavi personalizzate), oppure di importare il tuo. Puoi definire un alias e una descrizione per la chiave e scegliere che la chiave venga ruotata se è stata generata da AWS KMS. Puoi inoltre definire tutti le autorizzazioni per la chiave in modo da controllare chi può utilizzarla o gestirla. Con le chiavi KMS asimmetriche gestite dal cliente, bisognerà fare attenzione a un paio di aspetti nell’ambito della loro gestione: il materiale delle chiavi può essere generato solo all’interno di AWS KMS HSM e non è possibile impostare la rotazione automatica delle chiavi.

Sì. Puoi scegliere di fare in modo che AWS KMS ruoti automaticamente le chiavi KMS in un intervallo configurabile di giorni (da 90 giorni a 2560 giorni (7 anni) o utilizzare l'API RotateKeyOnDemand per richiamare la rotazione immediata delle chiavi (limite di durata di 10 rotazioni su richiesta per chiave). La rotazione automatica delle chiavi non è supportata per le chiavi importate, le chiavi asimmetriche, le chiavi HMAC o le chiavi generate in un cluster AWS CloudHSM utilizzando la funzionalità di archiviazione per chiavi personalizzate di AWS KMS. È possibile ruotare le chiavi archiviate nell'archivio chiavi esterno (XKS) e gestire tutti gli eventi del ciclo di vita delle chiavi per le chiavi esterne nel gestore delle chiavi.  

Se scegli che sia AWS KMS a ruotare automaticamente le chiavi, non è necessario che crittografi nuovamente i dati. AWS KMS conserva automaticamente le versioni precedenti delle chiavi da usare per decrittografare i dati crittografati in base a una versione precedente di una chiave. Tutte le nuove richieste di crittografia su una chiave in AWS KMS sono crittografate con la versione più recente della chiave. Se ruoti manualmente le chiavi dell'archivio chiavi importate o personalizzate, potrebbe essere necessario crittografare nuovamente i dati a seconda che decidi di mantenere disponibili le vecchie versioni delle chiavi.

Se ruoti manualmente le chiavi dello storage per le chiavi personalizzate o importate, potresti dover crittografare nuovamente i tuoi dati a seconda che tu decida di mantenere disponibili le versioni precedenti delle chiavi.

Sì. Puoi programmare l'eliminazione di una chiave AWS KMS e dei relativi metadati creati in AWS KMS, con un periodo di attesa configurabile da 7 a 30 giorni. Il periodo di attesa definito consente di verificare l'eventuale impatto dell'eliminazione di una chiave sulle applicazioni e sugli utenti che la utilizzano. Il periodo di attesa predefinito è di 30 giorni. Puoi annullare l’eliminazione della chiave durante il periodo di attesa. Se per una chiave è stata pianificata l’eliminazione, tale chiave può essere utilizzata solo dopo aver annullato l’eliminazione durante il periodo di attesa. Se l’operazione di eliminazione non viene annullata, la chiave verrà eliminata alla scadenza del periodo di attesa configurato. Una volta eliminata, la chiave non potrà più essere utilizzata. Tutti i dati protetti mediante una chiave root eliminata risulteranno inaccessibili.

Per le chiavi AWS KMS con materiale di cifratura importato, esistono due metodi per eliminare il materiale cifratura senza eliminare l'ID della chiave AWS KMS o i relativi metadati. Il primo metodo prevede di eliminare su richiesta il materiale di cifratura importato senza periodo di attesa. Il secondo consiste nel definire, al momento dell'importazione del materiale di cifratura nella chiave AWS KMS, una data di scadenza basata sul periodo in cui AWS può utilizzare il materiale di cifratura importato prima che venga eliminato. Nel caso in cui occorresse utilizzarlo ancora, potrai comunque importare il materiale di cifratura nuovamente nella chiave AWS KMS.

Sì. AWS KMS è supportato negli SDK AWS, SDK di crittografia AWS, la crittografia lato client di Amazon DynamoDB e il client di crittografia di Amazon Simple Storage Service (S3) per facilitare la crittografia dei dati all'interno delle applicazioni ogni volta che sono in esecuzione. Per ulteriori informazioni, visita il sito Web di AWS Crypto Tools e Sviluppo su AWS.

È possibile creare fino a 100.000 chiavi KMS per account in ogni regione. Dal momento che tale limite è dato dalla somma delle chiavi KMS, sia abilitate che disabilitate, si consiglia di eliminare le chiavi disabilitate che non usi più. Le chiavi KMS gestite da AWS create automaticamente per l’utilizzo all’interno dei servizi AWS supportati non vengono considerate per il conteggio di questo limite. Non esiste alcun limite al numero di chiavi dati che possono essere derivate in base a una chiave KMS e utilizzate nell'applicazione o dai servizi AWS per crittografare automaticamente i dati. Puoi richiedere un aumento del limite per le chiavi KMS visitando Centro supporto AWS.

No. Le chiavi KMS o una porzione privata di una chiave KMS asimmetrica non possono essere esportate come testo semplice dagli HSM. Solo la porzione pubblica di una chiave KMS asimmetrica può essere esportata dalla console o chiamando l'API GetPublicKey.

Sì. Le chiavi di dati simmetriche possono essere esportate utilizzando l'API GenerateDataKey o l'API GenerateDataKeyWithoutPlaintext. Inoltre, la porzione privata e pubblicata delle coppie di chiavi dati asimmetriche possono essere entrambe esportate da AWS KMS utilizzando l'API GenerateDataKeyPair o l'API GenerateDataKeypairWithoutPlain.

La chiave dati simmetrica o la porzione privata dalla chiave dati asimmetrica vengono crittografate nella chiave KMS simmetrica da te definita quando richiedi ad AWS KMS di generare la chiave dati.

Il motivo principale per utilizzare la CA privata AWS è fornire un'infrastruttura per chiavi pubbliche (PKI) allo scopo di identificare le entità e garantire la sicurezza delle connessioni di rete. La PKI fornisce processi e meccanismi, principalmente utilizzando certificati X.509, per dare una struttura alle operazioni crittografiche con chiavi pubbliche. I certificati forniscono un’associazione tra un’identità e una chiave pubblica. Il processo di certificazione in un cui un’autorità di certificazione emette un certificato permette all’autorità fidata di dimostrare l’identità di un’altra entità firmando un certificato. La PKI fornisce identità, affidabilità distribuita, gestione per il ciclo di vita delle chiavi e stati dei certificati attraverso revoca. Tali funzioni aggiungono importanti processi e infrastruttura alle chiavi crittografiche asimmetriche e agli algoritmi sottostanti forniti da AWS KMS.

Una CA privata AWS ti permette di emettere certificati per identificare server Web e applicativi, mesh di servizi, utenti di VPN, endpoint API interni e dispositivi AWS IoT Core. I certificati permettono di stabilire le identità di tali risorse e creare canali di comunicazioni TLS/SSL crittografati. Se stai prendendo in considerazione l'utilizzo di chiavi per terminazioni TLS su server Web o applicativi, Elastic Load Balancer, endpoint di API Gateway, istanze Amazon Elastic Compute Cloud (EC2) o container, dovresti valutare anche l'utilizzo di un CA privata AWS per emettere certificati e fornire un'infrastruttura PKI.

Per contro, AWS KMS permette di generare, gestire e utilizzare chiavi asimmetriche per firme digitali e/o operazioni di crittografia che non richiedono certificati. Sebbene i certificati permettano di verificare l'identità del mittente e del destinatario tra parti non fidate, le operazioni asimmetriche offerte da AWS KMS sono tipicamente utili quando si dispone di altri meccanismi per dimostrare le identità e non è affatto necessario dimostrarle per ottenere i vantaggi in termini di sicurezza che si desiderano.

Non vi sono integrazioni native offerte da AWS KMS per qualsiasi altro fornitore di API crittografiche. È necessario utilizzare le API di AWS KMS direttamente o attraverso l’SDK AWS per integrare le capacità di firma e crittografia all’interno delle tue applicazioni.

Sì. L’Accordo sul livello di servizio (SLA) di AWS KMS offre un credito sui servizi qualora la percentuale di tempo di funzionamento mensile durante un ciclo di fatturazione sia inferiore a quella dell'impegno di servizio.

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 di moduli di sicurezza hardware single-tenant conformi in Amazon Virtual Private Cloud (VPC), che consente di 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à automaticamente addebitato sulla carta di credito il costo delle risorse usate nel corso del 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. Per ulteriori informazioni, fai clic qui.

Sì. È possibile importare in AWS KMS una copia delle chiavi da un'infrastruttura di gestione delle chiavi esistente per utilizzarla con il servizio 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 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 decidere se l'uso di un'archiviazione per chiavi personalizzate è appropriato per te sono disponibili in questoblog.

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 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 gli utenti di HSM ed, eventualmente, ripristinare gli HSM da un 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 della chiave esterna. 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 di chiavi esterne 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 di chiavi esterne, 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.