HSM nel cloud con un controllo chiaro delle chiavi.

Collegamento privato, risoluzione dei nomi, autenticazione e latenza influenzano ogni chiamata crittografica. Testiamo il percorso con il profilo di carico reale e pianifichiamo il comportamento in caso di connessione interrotta. Un secondo endpoint è utile solo se lì sono disponibili in modo adeguato chiavi e autorizzazioni. I servizi di gestione delle chiavi esterni o le chiavi gestite dal cliente si differenziano inoltre per i dati e i servizi che controllano effettivamente. Documentiamo questi confini in modo che i responsabili di business comprendano l'influenza residua del fornitore.

Un piano di uscita descrive quali chiavi possono essere esportate, quali dati dovrebbero essere cifrati nuovamente e quali servizi devono essere sostituiti. Ne fanno parte scadenze, conferme di cancellazione e dipendenze dai backup. Nel progetto concordiamo obiettivi di esercizio raggiungibili e verifichiamo il ripristino e la revoca dei diritti. Una promessa generica di piena portabilità non sarebbe credibile senza questa verifica.

AWS CloudHSM e Azure Key Vault Managed HSM rappresentano modelli di integrazione e di esercizio diversi. AWS CloudHSM offre collegamenti client HSM per le applicazioni adatte a questo scopo; Azure Managed HSM mette a disposizione un servizio gestito per le chiavi con integrazione Azure. Verifichiamo API, tipi di chiave, identità e modello di ripristino per ogni workload. Un cambio non è quindi una semplice sostituzione di un indirizzo server. Decisivo è capire se l'applicazione specifica e il livello di controllo richiesto sono adatti al servizio.

Bring Your Own Key descrive innanzitutto l'inserimento del proprio materiale delle chiavi in un servizio supportato. Da solo non chiarisce chi può avviare le operazioni sulle chiavi o dove vengono elaborati i dati in chiaro. Con la gestione esterna delle chiavi si aggiungono ulteriori dipendenze tecniche, ad esempio un servizio esterno per determinate operazioni di rilascio o decapsulamento. Documentiamo questi confini di fiducia e testiamo anche la revoca mirata dei diritti. Funzioni e limitazioni vengono verificate per il servizio cloud specifico.

Un'applicazione esistente deve essere trasferita, ma la gestione delle sue chiavi deve restare controllabile. OTOKO® verifica innanzitutto se l'interfaccia esistente può continuare a essere utilizzata o se è necessario un adattamento. Nel progetto pilota misuriamo i tempi di risposta dalla rete di destinazione, verifichiamo ruoli di amministratore separati e testiamo il ripristino. Il piano di uscita descrive sia le chiavi esportabili sia i casi in cui sarebbero necessarie una nuova generazione delle chiavi e una migrazione dei dati. Ne risulta un modello operativo con responsabilità definite.