Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

AWS CloudHSM migliori pratiche di integrazione delle applicazioni

Segui le best practice riportate in questa sezione per ottimizzare l'integrazione dell'applicazione con il AWS CloudHSM cluster.

Avvia il tuo Client SDK

Prima che l'SDK del client possa connettersi al cluster, è necessario avviarlo. Quando esegui il bootstrap degli indirizzi IP nel cluster, ti consigliamo di utilizzare il parametro quando possibile. --cluster-id Questo metodo compila la configurazione con tutti gli indirizzi IP HSM del cluster senza dover tenere traccia di ogni singolo indirizzo. In questo modo si aggiunge una maggiore resilienza all'inizializzazione dell'applicazione nel caso in cui un HSM sia in fase di manutenzione o durante un'interruzione della zona di disponibilità. Per ulteriori dettagli, consulta Esegui il bootstrap di Client SDK.

Effettua l'autenticazione per eseguire operazioni

In AWS CloudHSM, è necessario autenticarsi nel cluster prima di poter eseguire la maggior parte delle operazioni, come le operazioni crittografiche.

Autenticazione con la CLI di CloudHSM: puoi autenticarti con la CLI di CloudHSM utilizzando la sua modalità di comando singolo o la modalità interattiva. Usa il comando per autenticarti in modalità interattiva. Accedi a un HSM utilizzando CloudHSM CLI Per eseguire l'autenticazione in modalità a comando singolo, è necessario impostare le variabili CLOUDHSM_ROLE di ambiente e. CLOUDHSM_PIN Per ulteriori informazioni su questa operazione, fare riferimento aModalità di comando singolo. AWS CloudHSM consiglia di archiviare in modo sicuro le credenziali HSM quando non vengono utilizzate dall'applicazione.

Autenticazione con PKCS #11: in PKCS #11, si accede utilizzando l'API C_Login dopo aver aperto una sessione utilizzando C_. OpenSession È necessario eseguire solo un C_Login per slot (cluster). Dopo aver effettuato correttamente l'accesso, è possibile aprire sessioni aggiuntive utilizzando C_ OpenSession senza la necessità di eseguire operazioni di accesso aggiuntive. Per esempi sull'autenticazione con PKCS #11, vedere. Esempi di codice per la libreria PKCS #11 per AWS CloudHSM Client SDK 5

Autenticazione con JCE: il provider JCE supporta l'accesso sia AWS CloudHSM implicito che esplicito. Il metodo che funziona per te dipende dal tuo caso d'uso. Quando possibile, consigliamo di utilizzare l'accesso implicito perché l'SDK gestirà automaticamente l'autenticazione se l'applicazione si disconnette dal cluster e deve essere nuovamente autenticata. L'utilizzo dell'accesso implicito consente inoltre di fornire credenziali all'applicazione quando si utilizza un'integrazione che non consente di avere il controllo sul codice dell'applicazione. Per ulteriori informazioni sui metodi di accesso, consulta. Fase 2: Fornire le credenziali al provider JCE

Autenticazione con OpenSSL: con OpenSSL Dynamic Engine, fornisci le credenziali tramite variabili di ambiente. AWS CloudHSM consiglia di archiviare in modo sicuro le credenziali HSM quando non vengono utilizzate dall'applicazione. Se possibile, è necessario configurare l'ambiente per recuperare e impostare sistematicamente queste variabili di ambiente senza immetterle manualmente. Per i dettagli sull'autenticazione con OpenSSL, consulta. Installa il motore AWS CloudHSM dinamico OpenSSL per Client SDK 5

Autenticazione con KSP: puoi autenticarti con Key Storage Provider (KSP) utilizzando il gestore di credenziali di Windows o variabili di ambiente, vedi. Installa il Key Storage Provider (KSP) per AWS CloudHSM Client SDK 5

Gestisci efficacemente le chiavi nella tua applicazione

Usa gli attributi chiave per controllare cosa possono fare le chiavi: quando generi una chiave, usa gli attributi chiave per definire una serie di autorizzazioni che consentiranno o negheranno tipi specifici di operazioni per quella chiave. Si consiglia di generare le chiavi con il minor numero di attributi necessari per completare l'attività. Ad esempio, non si dovrebbe consentire a una chiave AES utilizzata per la crittografia anche di estrarre le chiavi dall'HSM. Per ulteriori informazioni, consulta le nostre pagine sugli attributi per il seguente client SDKs:

Quando possibile, memorizza nella cache gli oggetti chiave per ridurre al minimo la latenza: le operazioni di ricerca chiave interrogheranno ogni HSM del cluster. Questa operazione è costosa e non è scalabile in base al numero di HSM presenti nel cluster.

Per prestazioni ottimali, si AWS consiglia di utilizzare i comandi key find (come Cerca AWS CloudHSM le chiavi per attributi usando KMU eElenca le chiavi per un utente con CLI CloudhSM) una sola volta durante l'avvio dell'applicazione e di memorizzare nella cache l'oggetto chiave restituito nella memoria dell'applicazione. Se avete bisogno di questo oggetto chiave in un secondo momento, dovreste recuperare l'oggetto dalla cache invece di interrogarlo per ogni operazione, il che comporterebbe un notevole sovraccarico di prestazioni.

Usa il multithreading

AWS CloudHSM supporta applicazioni multithread, ma ci sono alcuni aspetti da tenere a mente con le applicazioni multithread.

Con PKCS #11, è necessario inizializzare la libreria PKCS #11 (chiamata) una sola volta. C_Initialize A ogni thread dovrebbe essere assegnata la propria sessione (). C_OpenSession Non è consigliabile utilizzare la stessa sessione in più thread.

Con JCE, il AWS CloudHSM provider deve essere inizializzato una sola volta. Non condividete istanze di oggetti SPI tra thread. Ad esempio, Cipher, Signature, Digest, Mac KeyFactory o KeyGenerator gli oggetti devono essere utilizzati solo nel contesto del proprio thread.

Gestisci gli errori di limitazione

È possibile che si verifichino errori di limitazione HSM nelle seguenti circostanze:

Limitazione HSMPer informazioni su come gestire al meglio questo scenario, consulta la sezione.

Per garantire che il cluster sia di dimensioni adeguate e non subisca limitazioni, consigliamo di AWS eseguire un test di carico nel proprio ambiente con il traffico di picco previsto.

Integra i nuovi tentativi nelle operazioni del cluster

AWS può sostituire l'HSM per motivi operativi o di manutenzione. Per rendere l'applicazione resiliente a tali situazioni, AWS consiglia di implementare la logica di riprova lato client su tutte le operazioni instradate verso il cluster. Si prevede che i tentativi successivi di operazioni non riuscite a causa di sostituzioni abbiano esito positivo.

Implementa strategie di disaster recovery

In risposta a un evento, potrebbe essere necessario spostare il traffico lontano da un intero cluster o regione. Le sezioni seguenti descrivono diverse strategie per eseguire questa operazione.

Usa il peering VPC per accedere al tuo cluster da un altro account o regione: puoi utilizzare il peering VPC per accedere al tuo AWS CloudHSM cluster da un altro account o regione. Per informazioni su come configurarlo, consulta Cos'è il peering VPC? nella VPC Peering Guide. Dopo aver stabilito le connessioni peering e configurato i gruppi di sicurezza in modo appropriato, è possibile comunicare con gli indirizzi IP HSM nello stesso modo in cui si farebbe normalmente.

Connettiti a più cluster dalla stessa applicazione: il provider JCE, la libreria PKCS #11 e la CLI CloudhSM in Client SDK 5 supportano la connessione a più cluster dalla stessa applicazione. Ad esempio, è possibile avere due cluster attivi, ciascuno in regioni diverse, e l'applicazione può connettersi a entrambi contemporaneamente e bilanciare il carico tra i due come parte delle normali operazioni. Se l'applicazione non utilizza Client SDK 5 (l'SDK più recente), non è possibile connettersi a più cluster dalla stessa applicazione. In alternativa, puoi mantenere attivo e funzionante un altro cluster e, in caso di interruzione regionale, spostare il traffico sull'altro cluster per ridurre al minimo i tempi di inattività. Consulta le rispettive pagine per i dettagli:

Ripristinare un cluster da un backup: è possibile creare un nuovo cluster da un backup di un cluster esistente. Per ulteriori informazioni, consulta Backup dei cluster in AWS CloudHSM.