Moduli di sicurezza hardware: chiavi in hardware certificato

Determinante è l'evidenza richiesta per il vostro caso d'uso. Verifichiamo certificato, stato, versione hardware e firmware, nonché le condizioni di impiego documentate. FIPS, Common Criteria e le valutazioni per i pagamenti hanno ambiti di validità diversi. Un singolo certificato non attesta automaticamente l'intera soluzione.

Esistono diverse verifiche per gli HSM. Non tutte le verifiche sono adatte a ogni utilizzo. Verifichiamo il tipo esatto di dispositivo, la versione del software e l'uso consentito. Un'evidenza relativa al dispositivo non vale automaticamente per l'intero sistema.

Un unico produttore può semplificare l'integrazione e la gestione operativa. Requisiti diversi possono tuttavia richiedere piattaforme diverse. Per prima cosa separiamo i domini di sicurezza e i casi d'uso. Se a tal fine servano più produttori è una decisione che motiviamo; la separazione in sé non impone automaticamente marchi diversi.

Un unico produttore può semplificare la gestione operativa. A volte compiti diversi richiedono dispositivi diversi. Verifichiamo se servono anche produttori diversi.

Hardware proprio, gestione operativa affidata a terzi e servizi gestiti si differenziano per responsabilità, costi e disponibilità. Ubicazioni e regioni vengono definite in modo esplicito. Backup, ripristino, supporto del produttore e un'eventuale uscita futura rientrano nella stessa decisione.

Potete utilizzare dispositivi propri oppure sottoscrivere un servizio. Costi e compiti differiscono. Insieme definiamo ubicazioni, responsabilità e ripristino. Pianifichiamo anche un eventuale cambio successivo.

Il supporto PQC dipende da hardware, firmware, interfacce e applicazione. Un aggiornamento annunciato non dimostra che esista una configurazione validata e utilizzabile in produzione. Inventariamo chiavi e protocolli, verifichiamo lo stato dichiarato dal produttore e pianifichiamo transizioni compatibili, comprese le controparti e il ripristino.

I nuovi algoritmi crittografici devono essere supportati dal dispositivo e dall'applicazione. Un aggiornamento annunciato non basta come prova. Verifichiamo i sistemi esistenti e pianifichiamo una transizione adeguata.

Un modulo di sicurezza hardware protegge le chiavi crittografiche ed esegue le operazioni supportate all'interno di un confine di sicurezza definito. Se una chiave può essere esportata dipende dalla sua configurazione e dal meccanismo supportato. Provider PKCS #11, CNG o Java e interfacce di gestione delle chiavi svolgono compiti diversi. Verifichiamo l'intera catena applicativa, invece di fermarci alla semplice indicazione di un'interfaccia. La crittografia e i moduli di sicurezza hardware sono la nostra competenza principale. Conosciamo le serie dei produttori, i numeri dei certificati e i limiti delle singole piattaforme. Accompagniamo il vostro progetto dalla scelta alla cerimonia delle chiavi fino all'esercizio.

Quattro compiti tipici mostrano dove ha senso impiegare gli HSM. Quali evidenze e meccanismi di protezione siano necessari dipende dalla vostra applicazione e dai requisiti concreti. Un HSM da solo non attesta né la sicurezza dell'intero ambiente né la sua conformità.

Questi quattro esempi mostrano possibili compiti per un HSM. Le evidenze necessarie dipendono dal vostro utilizzo. Un dispositivo certificato non rende automaticamente sicuro l'intero ambiente.

Root CA e issuing CA possono utilizzare le proprie chiavi private tramite un collegamento HSM supportato. Ne fanno parte profili di certificato adeguati, ruoli e procedure di revoca. Anche con la chiave protetta, un server CA compromesso può generare richieste non autorizzate; per questo proteggiamo anche le approvazioni e l'applicazione.

Un'autorità di certificazione rilascia certificati. Le sue chiavi private possono trovarsi in un HSM. Il software deve comunque essere protetto. Altrimenti chi ne prendesse il controllo potrebbe richiedere firme non autorizzate.

Gli HSM di pagamento supportano funzioni dedicate per l'elaborazione dei PIN, le chiavi delle carte o la distribuzione delle chiavi. Verifichiamo i comandi, i meccanismi delle chiavi, i requisiti dei partner e lo stato di certificazione specifico del dispositivo. Un HSM per uso generico non è automaticamente un sostituto.

Un HSM di pagamento è pensato per le attività legate ai pagamenti. Può ad esempio aiutare nella verifica del PIN. Verifichiamo le funzioni necessarie e i requisiti dei vostri partner. Non tutti gli HSM possono svolgere questi compiti.

Le firme basate su HSM possono proteggere le chiavi per software e firmware. Il processo deve inoltre stabilire chi approva ciascun artefatto e chi può firmarlo. I requisiti per la custodia delle chiavi vengono verificati in base al certificato e al modello di fiducia utilizzati.

Una firma digitale aiuta a verificare il software e chi lo pubblica. L'HSM può proteggere la chiave di firma. Deve inoltre essere stabilito chi approva la firma di ciascun software.

Un sistema di gestione delle chiavi può collegare applicazioni e storage tramite protocolli supportati come KMIP e utilizzare un HSM come componente di protezione. Per BYOK, gestione esterna delle chiavi ed envelope encryption verifichiamo dove vengono utilizzate le singole chiavi e chi può avviare le operazioni. Il solo BYOK non esclude l'accesso ai dati da parte del fornitore.

Un sistema centrale può gestire le chiavi per applicazioni e storage. Un HSM può proteggere le chiavi particolarmente importanti. Verifichiamo chi può utilizzare quali chiavi. Una chiave propria nel cloud non significa automaticamente che il fornitore non possa leggere i dati.

Quattro domande determinano produttore e serie: il livello di certificazione richiesto, le prestazioni necessarie, le interfacce delle vostre applicazioni e il modello operativo. Le chiariamo in un workshop e documentiamo il risultato in un documento decisionale.

Quattro domande determinano produttore e serie. Primo, il livello di certificazione richiesto. Secondo, le prestazioni necessarie. Terzo, le interfacce delle vostre applicazioni. Quarto, il modello operativo. Chiariamo queste domande in un workshop. Documentiamo il risultato in un documento decisionale.

Il throughput si può confrontare solo indicando algoritmo, dimensione della chiave, parallelismo e collegamento client. Misuriamo inoltre latenza e comportamento in caso di guasto. Per la separazione dei tenant contano diritti, risorse condivise e amministrazione, non solo il numero delle partizioni.

La velocità dipende dal compito. Anche la dimensione della chiave e le richieste simultanee sono importanti. Testiamo la vostra applicazione. Se gli utenti sono separati, verifichiamo inoltre i diritti e le risorse condivise.

Provider, meccanismi e attributi delle chiavi devono essere adatti all'applicazione. Un simulatore può chiarire le prime questioni di sviluppo, ma non sostituisce una verifica del comportamento dell'hardware, delle prestazioni o della modalità di certificazione. I test rappresentativi vengono eseguiti nell'ambiente di destinazione previsto.

Dispositivo e applicazione devono essere compatibili. Un simulatore aiuta nei primi test. Non riproduce però tutte le caratteristiche dell'hardware reale. I test importanti vengono quindi eseguiti nell'ambiente di destinazione previsto.

Certificazioni e requisiti normativi non sono marchi di qualità intercambiabili. Ai fini della scelta associamo le evidenze al modulo specifico, alla sua versione di prodotto e all'uso previsto. Prima dell'acquisto verifichiamo lo stato consultando gli enti competenti.

Certificazioni e requisiti normativi non sono marchi di qualità intercambiabili. Ai fini della scelta associamo le evidenze al modulo specifico, alla sua versione di prodotto e all'uso previsto. Prima dell'acquisto verifichiamo lo stato consultando gli enti competenti.

Verificare certificato CMVP, Security Policy, versioni, modalità di esercizio e stato