Domande frequenti su AWS CloudHSM

Sarà applicata una tariffa oraria per le ore (intere o parziali) di provisioning di ciascun modulo di sicurezza hardware in un cluster AWS CloudHSM. Non sarà addebitato alcun costo per i cluster senza moduli di sicurezza hardware né per l'archiviazione automatica di backup crittografati. Per ulteriori informazioni, visita la pagina dei prezzi di AWS CloudHSM. Nota che i trasferimenti di dati di rete da e verso gli HSM vengono addebitati separatamente. Per ulteriori informazioni, consulta i prezzi per trasferimento dei dati di EC2.

No, non è previsto alcun piano gratuito per AWS CloudHSM.

No, la tariffa oraria, che varia a seconda della regione, non dipende dalla frequenza con cui si utilizza l’HSM.

No, non offriamo prezzi per le istanze riservate per AWS CloudHSM.

Sì. Per iniziare a utilizzare AWS CloudHSM vi sono alcuni prerequisiti richiesti, fra cui un cloud privato virtuale (VPC) nell'area geografica in cui desideri usufruire del servizio AWS CloudHSM. Per maggiori dettagli, consulta il documento AWS CloudHSM User Guide.

No. AWS gestisce sia firmware sia hardware. Il firmware viene gestito da terzi e dovrà essere prima valutato dal NIST per la conformità allo standard FIPS 140-2 Level 3. Solo il firmware con crittografia firmata secondo lo standard FIPS (a cui AWS non ha accesso) può essere installato.

AWS consiglia vivamente di utilizzare almeno due moduli di sicurezza hardware in due zone di disponibilità differenti per tutti gli ambienti di produzione. Per i carichi di lavoro mission critical, sono consigliati almeno tre moduli in almeno due zone di disponibilità differenti. Il client CloudHSM gestirà automaticamente i moduli guasti e bilancerà il carico tra due o più moduli in modo trasparente.

AWS esegue backup crittografati automatici del cluster CloudHSM su base giornaliera. AWS effettua backup aggiuntivi nel momento in cui si verificano eventi del ciclo di vita del cluster (ad esempio l'aggiunta o la rimozione di moduli). Nel periodo di 24 ore che intercorre tra due backup, la responsabilità del materiale di crittografia creato o importato nel cluster spetta all'utente. Per assicurare la massima durevolezza, AWS consiglia vivamente di sincronizzare le nuove chiavi in almeno due moduli in due zone di disponibilità differenti. Consulta il documento AWS CloudHSM User Guide per ulteriori informazioni sulla verifica della sincronizzazione delle chiavi.

La disponibilità elevata è una caratteristica implementata automaticamente quando sono presenti almeno due moduli di sicurezza hardware disponibilità tra due zone di disponibilità in un cluster CloudHSM. Non è necessario procedere a ulteriori configurazioni. Nel caso in cui si dovesse verificare un guasto in un modulo di un cluster, verrà automaticamente sostituito e tutti i client saranno aggiornati in modo da riflettere la nuova configurazione senza interrompere il flusso di elaborazione. È anche possibile aggiungere moduli al cluster senza interrompere l'applicazione utilizzando l'API o il kit SDK AWS.

Un singolo cluster CloudHSM può contenere fino a 28 moduli di sicurezza hardware, secondo le restrizioni dei servizi dell'account. Per saperne di più sulle restrizioni dei servizi e su come richiedere un aumento delle restrizioni, consulta la nostra documentazione online.

AWS esegue tutti i giorni un backup dei cluster CloudHSM. Le chiavi possono inoltre essere esportate da un cluster e memorizzate on-premises, sempre che non siano state generate con l'attributo "non-exportable".

Sì, puoi consultare il contratto sul livello di servizio (SLA) per AWS CloudHSM qui.

No. Incluso nel servizio, riceverai l'accesso single-tenant al modulo di sicurezza hardware. Il relativo hardware può essere condiviso con altri clienti, ma l'istanza HSM offre accesso esclusivo.

La separazione delle attività e il controllo degli accessi basato su ruoli è intrinseco nella configurazione di AWS CloudHSM. AWS ha una credenziale limitata all'HSM che ci permette di monitorare e mantenere lo stato e la disponibilità del modulo, fare backup criptati ed estrarre e pubblicare log di audit nel tuo CloudWatch Logs. AWS non ha accesso alle chiavi e ai dati all'interno del tuo cluster CloudHSM e non può effettuare alcuna operazione oltre a quelle permesse a un utente dell'appliance HSM.

Consulta il documento AWS CloudHSM User Guide per ulteriori informazioni su separazione delle attività e sulle autorizzazioni relative ai moduli delle diverse classi di utenti.

Sì. AWS CloudHSM pubblica diversi parametri di Amazon CloudWatch per cluster CloudHSM e singoli moduli di crittografia hardware. Per ottenere e ricevere degli allarmi su questi parametri, è possibile utilizzare la console di Amazon CloudWatch, l'API o l'SDK.

Ogni modulo di sicurezza hardware dispone di un generatore deterministico di bit casuali o DRBG (Deterministic Random Bit Generator), alimentato da un generatore hardware di numeri casuali o TRNG (True Random Number Generator) integrato nel modulo hardware, in conformità allo standard SP800-90B.

AWS CloudHSM offre rilevamento sia fisico sia logico delle manomissioni e meccanismi di risposta che attivano l'eliminazione a più fasi delle chiavi hardware. L'hardware dei moduli è progettato in modo da rilevare una manomissione non appena ne viene violata la barriera fisica. I moduli di sicurezza hardware sono anche protetti contro gli attacchi di forza bruta. Dopo un determinato numero di tentativi di accesso a un modulo di sicurezza hardware con credenziali di amministratore o Crypto Officer (CO) non andati a buon fine, l'istanza HSM blocca l'amministratore/CO. Analogamente, dopo un determinato numero di tentativi di accesso a un'istanza HSM con credenziali Crypto User (CU) non andati a buon fine, l’utente verrà bloccato e dovrà essere sbloccato da un CO o da un amministratore.

Amazon monitora la disponibilità e le eventuali condizioni di errore del modulo e della rete e provvede alla loro manutenzione. In caso di guasto o di perdita di connessione di rete, il modulo di sicurezza hardware verrà automaticamente sostituito. Puoi verificare le condizioni di un determinato HSM utilizzando l’API, il kit SDK o gli strumenti CLI di AWS CloudHSM, nonché controllare in qualunque momento le condizioni complessive del servizio con il pannello di controllo per lo stato dei servizi AWS.

Se il tuo cluster AWS CloudHSM ha un solo HSM, sì, è possibile che le chiavi create dopo l'ultimo backup giornaliero vadano perdute. I cluster AWS CloudHSM con due o più HSM, idealmente in diverse zone di disponibilità, non perderanno le chiavi in caso di guasto di un singolo HSM. Per ulteriori informazioni, consulta le nostre best practice.

No. Amazon non ha accesso alle tue chiavi o alle tue credenziali, e non ha pertanto alcun modo di recuperare le tue chiavi qualora tu smarrisca le tue credenziali.

AWS CloudHSM è basato su hardware convalidato secondo lo standard Federal Information Processing Standard (FIPS) 140-2 Level 3. Informazioni sul profilo di sicurezza dello standard FIPS 140-2 per l'hardware utilizzato da CloudHSM e il firmware che esegue, sono disponibili nella nostra pagina di conformità.

Sì, CloudHSM offre istanze HSM convalidate secondo lo standard FIPS 140-2 Level 3. Segui la procedura illustrata nella sezione Verifica l’autenticità del tuo HSM del documento guida per l’utente di CloudHSM User Guide per verificare che l'hardware del modulo corrisponda a quello indicato nella pagina delle policy di sicurezza NIST indicata nella domanda precedente.

AWS CloudHSM è sempre conforme allo standard FIPS 140-2. Per verificare la conformità, segui le istruzioni nel documento CloudHSM User Guide ed esegui il comando getHsmInfo nell'interfaccia a riga di comando per visualizzare lo stato dello standard FIPS.

Sì. AWS CloudTrail registra le chiamate API di AWS del tuo account. Lo storico delle chiamate API di AWS creato da AWS CloudTrail consente di eseguire analisi di sicurezza, monitoraggio delle modifiche delle risorse e audit di conformità. Per ulteriori informazioni su AWS CloudTrail, consulta la sua homepage e attiva il servizio tramite la console di gestione AWS CloudTrail.

AWS CloudTrail non include i log di dispositivo o di accesso dei moduli di crittografia hardware. Tali parametri sono disponibili direttamente nell'account AWS tramite i log AWS CloudWatch. Per ulteriori informazioni, consulta AWS CloudHSM User Guide.

Consulta la pagina Conformità di sicurezza nel cloud AWS per ulteriori informazioni sui programmi di conformità che includono CloudHSM. Diversamente dagli altri servizi AWS, i requisiti di conformità che riguardano AWS CloudHSM sono affrontati nella maggior parte dei casi direttamente dallo standard FIPS 140-2 Level 3 relativo all'hardware, piuttosto che in programmi di audit separati.

Lo standard FIPS 140-2 Level 3 è un requisito necessario per alcuni casi d'uso, ad esempio la firma di documenti, i pagamenti o l'utilizzo come autorità di certificazione per i certificati SSL.

Per vedere quali sono i report di conformità nel cui ambito è incluso AWS CloudHSM, consulta la pagina Servizi AWS coperti dal programma di conformità. Per creare report di conformità gratuiti, self-service e on demand, utilizza AWS Artifact.

Se ti interessa esclusivamente la convalida FIPS per gli HSM fornita da AWS CloudHSM, consulta la pagina Convalida FIPS.

Le prestazioni possono variare in base alla configurazione, alla dimensione dei dati e al carico aggiuntivo dell'applicazione sulle istanze EC2. Per aumentare le prestazioni, puoi aggiungere istanze HSM aggiuntive ai tuoi cluster. Incoraggiamo i test di carico dell'applicazione per determinare le esigenze di scalabilità.

Per maggiori dettagli, consulta la pagina sulle prestazioni nella Guida per l'utente di AWS CloudHSM.

Per informazioni dettagliate sullo storage delle chiavi e sulla capacità dei cluster, consulta le quote di AWS CloudHSM.

Non direttamente. Dovresti utilizzare AWS Key Management Service (KMS) in associazione con lo storage per chiavi personalizzate per proteggere i dati Amazon RDS con chiavi generate e archiviate nel tuo cluster CloudHSM.

Diversi fornitori di terze parti supportano AWS CloudHSM come root of trust. Questo significa che puoi utilizzare una soluzione software di tua scelta nella creazione e nell'archiviazione delle chiavi sottostanti nel tuo cluster CloudHSM.

La libreria client AWS CloudHSM è un pacchetto software fornito da AWS che permette all'utente e alle applicazioni di interagire con i cluster CloudHSM.

No. Tutte le comunicazioni tra il client e il tuo HSM sono completamente crittografate. AWS non può visualizzare o intercettare le suddette comunicazioni e non ha visibilità sulle tue credenziali di accesso al cluster.

Le istruzioni sono disponibili nel documento CloudHSM User Guide.

No. Gli strumenti di CloudHSM comunicano direttamente con il cluster CloudHSM tramite la libreria client CloudHSM su un canale sicuro e autenticato in entrambe le direzioni. AWS non può intercettare alcuna comunicazione tra client, strumenti e moduli di sicurezza hardware. È dotato di crittografia end-to-end.

Puoi trovare una lista completa dei sistemi operativi supportati nella nostra documentazione online.

L'host su cui è in esecuzione la libreria client CloudHSM e/o su cui vengono impiegati gli strumenti dell'interfaccia a riga di comando deve essere raggiungibile in rete da tutti i moduli di sicurezza hardware nel cluster.

È possibile creare, modificare, eliminare e ottenere lo stato di cluster CloudHSM e moduli. Le operazioni eseguibili con l'API AWS CloudHSM sono limitate dalle ristrette autorizzazioni di accesso di AWS. L'API non potrà accedere ai contenuti dei moduli di sicurezza hardware né modificare utenti, policy e altre impostazioni. Consulta il documento CloudHSM per informazioni sull'API o la pagina Strumenti per Amazon Web Services per informazioni sul kit SDK.

Prima di tutto, è importante verificare che gli algoritmi e i modelli in uso siano supportati da AWS CloudHSM. L'account manager potrà inoltrarci richieste di nuove funzionalità, se necessario. Quindi, è necessario determinare la strategia di rotazione delle chiavi. Inoltre, abbiamo pubblicato una guida per la migrazione ad AWS CloudHSM approfondita. Ora si è pronti a iniziare con AWS CloudHSM.

La strategia di rotazione delle chiavi dipende dal tipo di applicazione. Di seguito sono elencati alcuni esempi.

• Chiavi private di firma: in genere le chiavi private in HSM corrispondono a certificati intermedi, che vengono a loro volta firmati da una radice offline dell'organizzazione. La modifica delle chiavi si ottiene creando un nuovo certificato intermedio. È necessario creare una nuova chiave privata generando un CSR corrispondente utilizzando OpenSSL in AWS CloudHSM. Quindi, va firmato il CSR con la stessa radice offline dell'organizzazione. Potrebbe essere necessario registrare il nuovo certificato con eventuali partner che non verificano automaticamente l'intera catena di certificati. In seguito, tutte le nuove richieste (ad esempio documenti, codice o altri certificati) devono essere firmate con la nuova chiave privata, che corrisponde al nuovo certificato. Sarà possibile continuare a verificare le firme dalla chiave privata originale utilizzando la chiave pubblica corrispondente. Non è necessario applicare alcuna revoca. Questo processo è simile a quello necessario per ritirare o archiviare una chiave di firma.
• Oracle Transparent Data Encryption: è possibile trasferire il tuo portafoglio passando da un hardware keystore (il tuo modulo di sicurezza hardware originale) a un software keystore per tornare a un hardware keystore (AWS CloudHSM). Nota: se stai utilizzando Amazon RDS, consulta le Domande frequenti sopra come “AWS CloudHSM supporta Amazon RDS Oracle TDE?”
• Chiave simmetrica per crittografia di tipo envelope: la crittografia di tipo envelope fa riferimento a un'architettura in cui una chiave nel modulo HSM crittografa e decrittografa diverse chiavi dati nell'applicazione host. È probabile che sia già un uso un processo di rotazione delle chiavi per passare in esaminare e decrittografare le chiavi dati con vecchie chiavi di wrapping, crittografandole nuovamente con la nuova chiave di wrapping. L'unica differenza durante la migrazione è che la nuova chiave di wrapping sarà creata e utilizzata in AWS CloudHSM invece che nel modulo originale. Se non è ancora presente un processo o uno strumento per la rotazione delle chiavi, sarà necessario crearne uno.

Ogni applicazione e caso d'uso sono differenti. Le soluzioni ai casi comuni sono analizzate nella guida per la migrazione a CloudHSM. Per ulteriori domande, apri un caso di supporto con i dettagli della tua applicazione, il tipo di HSM e di chiavi attualmente in uso e la loro eventuale esportabilità. Ti aiuteremo a scegliere il percorso di migrazione più appropriato.

No, ma AWS può aver bisogno di effettuare manutenzioni in caso di aggiornamenti necessari o hardware guasti. Se fosse necessario un intervento, faremo in modo di notificartelo in anticipo utilizzando Personal Health Dashboard.

Ricorda che sei responsabile della progettazione del tuo cluster per l'alta disponibilità. AWS consiglia vivamente di utilizzare i cluster CloudHSM con almeno due moduli di sicurezza hardware in zone di disponibilità differenti. Per scoprire le best practice consigliate, consulta la nostra documentazione online.

Puoi trovare le soluzioni ai problemi più comuni nella nostra guida alla risoluzione dei problemi. Se il problema persiste, contatta AWS Support.