Accesso del partner all'HSM tramite VPN: definire le operazioni chiave

Qualcuno presso il partner deve firmare un documento con una chiave designata, e la richiesta arriva formulata come una questione di rete: devono raggiungere l'HSM. Trattate quella frase come sintomo di un contratto di servizio non definito e non come un problema di routing, perché un tunnel che raggiunge l'apparecchio non concede nulla da solo. Tre cancelli stanno dietro la richiesta: raggiungibilità, identità dell'HSM e politica delle chiavi, e ciascuno è amministrato in un luogo diverso da un team diverso. Scriveteli uno alla volta, altrimenti finirete per concedere una rotta perché la conversazione sul certificato era più difficile.

Tenete presente il caso concreto: il partner invia un documento approvato per la firma con una chiave nominata, e nient'altro. Tutto quanto segue deriva da quella singola frase.

Raggiungibilità, identità e politica delle chiavi sono tre cancelli

Il concentratore VPN decide chi può aprire un tunnel e quali indirizzi può toccare. L'HSM decide da solo quale record utente a esso presentato può accedere. La politica delle chiavi decide poi cosa quel record utente può fare con una chiave specifica. Superare il primo cancello lascia gli altri due esattamente come erano, per questo una stretta di mano riuscita dimostra così poco e per questo un partner può raggiungere l'apparecchio e fallire comunque ogni operazione.

Assegnate un proprietario a ogni cancello prima di scrivere i requisiti. Quando nessuno possiede il secondo, l'esito abituale è che venga distribuita un'identità ampia di amministratore HSM perché è l'unica credenziale che funziona.

Primo cancello: il percorso di rete dato al partner

Nominate il client o servizio approvato, la destinazione che gli serve, e il protocollo e la porta su cui quel servizio ascolta. Poi limitate l'accesso dal lato VPN a quella coppia in entrambe le direzioni, incluso il percorso di ritorno, così che la politica sia una frase che potete rileggere al partner. L'amministrazione del gateway, le interfacce di gestione dell'HSM e i sistemi interni non correlati devono stare fuori dall'accesso ordinario del partner, non solo fuori dalla rotta predefinita.

Un segmento dedicato rende visibili quegli attraversamenti, ma il nome di un segmento non impone nulla. Il traffico deve passare attraverso il controllo che pensate attraversi. Ammettere una connessione dal partner non è nemmeno un'affermazione che ogni macchina presso il partner sia affidabile.

Secondo cancello: cosa si autentica davvero all'HSM

Un'identità VPN e un'identità HSM sono oggetti separati a meno che un'integrazione supportata non le unisca deliberatamente. Con un client PKCS#11, l'applicazione esegue un accesso contro uno slot con una credenziale memorizzata da qualche parte sull'host del partner, e quel login è ciò che l'HSM valuta.

AWS CloudHSM è un riferimento utile perché la sua documentazione tiene separati i due: gli utenti HSM sono distinti dagli utenti IAM, e il tipo di utente determina ciò che l'account può fare. Un crypto officer gestisce utenti e chiavi ma non è l'identità che esegue operazioni crittografiche, mentre un crypto user può usare le chiavi senza poterle gestire. Quella separazione è la forma che volete anche sull'apparecchio di un altro fornitore, dove i nomi dei ruoli saranno diversi.

Qualunque identità emettiate, deve poter essere rimossa e attribuita alla granularità che vi servirà in seguito. Un'unica credenziale operativa condivisa tra più partner rende contenimento e responsabilità più difficili proprio nell'incidente in cui entrambi contano di più.

Terzo cancello: quale chiave e quale operazione

Firma, decifratura, generazione di chiavi, wrapping delle chiavi e amministrazione degli utenti sono permessi separati e devono essere elencati separatamente. In termini PKCS#11, attributi come CKA_SENSITIVE e CKA_EXTRACTABLE descrivono se il materiale della chiave può lasciare il modulo in forma utilizzabile, e sono impostati per chiave e non per apparecchio. Leggete la politica effettiva sulla chiave invece di dedurre la non esportabilità dalla parola hardware o dalla presenza di un tunnel.

Poi trovate l'approvazione aziendale. Se solo i documenti approvati possono essere firmati, quale componente stabilisce tale approvazione prima che la richiesta raggiunga l'HSM? Un'interfaccia crittografica che accetta una richiesta autorizzata non ha idea se il documento sia stato esaminato, quindi quel controllo spetta al servizio davanti ad essa.

Un client consentito compromesso può anche abusare delle operazioni che la sua credenziale autorizza legittimamente senza mai estrarre una chiave privata. Proteggere il materiale delle chiavi memorizzate e controllare l'uso delle chiavi sono quindi due condizioni di accettazione, non una.

I rifiuti fanno parte del test di accettazione

Accettate la richiesta di firma consentita e accettate anche i rifiuti: un'identità non autorizzata, una chiave non correlata e un'operazione di gestione dal percorso del partner. Registrate il chiamante, l'operazione, l'identificatore della chiave, l'ora e l'esito, e tenete il materiale delle chiavi private, le credenziali e il contenuto dei documenti fuori dai log diagnostici generali.

Assegnate un proprietario per l'uscita del partner, per un sospetto compromesso dal lato del partner e per le modifiche di politica e il ripristino. Cambiare una rotta non ripristina la fiducia in un host che potrebbe essere già compromesso, quindi la revoca deve raggiungere anche l'identità HSM.

Una stretta di mano VPN completata appartiene a quel registro. Non può sostituire un singolo risultato specifico dell'HSM.