Categories
Ultime Notizie

Perché il tuo NAS non dovrebbe fungere anche da Key Management System (KMS): uno sguardo all’architettura client KMIP e alla separazione delle responsabilità

Il KMS deve rimanere separato dai dati di produzione

Quando le aziende iniziano ad adottare il Key Management Interoperability Protocol (KMIP), il KMS dovrebbe rimanere separato dal dispositivo che memorizza i dati di produzione, invece di permettere a un dispositivo archiviazione generico di assumere entrambi i ruoli. Questo è un principio fondamentale della Separazione dei compiti (SoD): il KMS e l’amministratore dei dati di produzione dovrebbero essere due ruoli distinti.

Il Key Management System (KMS) funge da radice di fiducia per l’intero ambiente, richiedendo un ambiente con un’impronta minima e massima sicurezza. Al contrario, un NAS è progettato come un sistema archiviazione ad alta capacità e multi-servizio che funziona come client KMIP, rendendo i due fondamentalmente opposti per natura.

Filosofia di progettazione di QNAP: la decisione di QNAP di non supportare QNAP NAS come KMS è una scelta architetturale intenzionale volta a mantenere il principio della separazione dei compiti, assegnando l’autorità di gestione delle chiavi a un KMS dedicato e auditabile, mentre il NAS è responsabile solo della richiesta delle chiavi crittografiche quando necessario, garantendo che l’architettura di crittografia dell’organizzazione rimanga conforme ed efficace.

Utilizzare un NAS come KMS: una trappola di conformità spesso trascurata

Nella pratica, è comune vedere team che necessitano di un KMS per gestire centralmente le chiavi di crittografia per le cartelle condivise e volume al fine di soddisfare i requisiti degli audit di sicurezza. Tuttavia, poiché le soluzioni KMS commerciali possono essere costose, utilizzano dispositivi archiviazione per ridurre i costi.

Tuttavia, questa è una falsa economia: le organizzazioni possono pensare di aver risparmiato sul costo di un KMS, ma stanno facendo affidamento sull’architettura sbagliata per assumere il ruolo più critico. Il denaro risparmiato non si traduce necessariamente in una reale sicurezza e si allontana anche dalla filosofia di progettazione fondamentale di un KMS.

Alcune soluzioni archiviazione sul mercato offrono un ruolo KMS integrato, ma da una prospettiva di audit, un design in cui dati e chiavi risiedono sullo stesso sistema manca di una chiara separazione delle responsabilità. Un’unica interfaccia di gestione con controllo sia sui dati che sulle chiavi rappresenta di per sé un single point of failure che gli auditor difficilmente accetteranno, indipendentemente dalla robustezza della tecnologia di crittografia.

Root of Trust: perché il KMS ha requisiti di sicurezza molto più elevati rispetto ai sistemi ordinari

La chiave per comprendere questo è il concetto di Single Root of Trust.

Quando un’organizzazione raggiunge il punto in cui è richiesto KMIP, significa che le chiavi di crittografia devono essere gestite centralmente in tutto l’ambiente, invece di essere utilizzate solo dai sistemi NAS. Gli scenari tipici enterprise on-premises includono:

  • Piattaforme di virtualizzazione: crittografia di macchine virtuali e datastore VMware vSphere/vSAN, Hyper-V e Nutanix
  • Database Transparent Data Encryption (TDE): Oracle e SQL Server
  • Sistemi di backup: chiavi di crittografia per software di backup di livello enterprise come Veeam e Commvault
  • Server archiviazione condivisi (NAS)
  • Array archiviazione auto-crittografanti
  • Hardware auto-crittografante: Self-Encrypting Drives (SED), librerie di nastri e array archiviazione auto-crittografanti

Una volta che KMS diventa il Single Root of Trust per tutti i dispositivi sopra elencati, i suoi requisiti di sicurezza sono molto più elevati rispetto a quelli di qualsiasi dispositivo che gestisce. In particolare, le soluzioni KMS di livello enterprise devono generalmente fornire: un keystore supportato da Hardware Security Module (HSM), una rigorosa separazione dei ruoli, un ciclo di vita completo e auditabile delle chiavi e una validazione indipendente del modulo crittografico.

Pertanto, il KMS svolge un ruolo a un livello di sicurezza superiore rispetto ai sistemi che gestisce.

Il materiale delle chiavi è estremamente ridotto: le chiavi, i metadati e le policy insieme solitamente ammontano solo a pochi megabyte per la maggior parte delle aziende. Un KMS ideale segue il principio di minimizzazione: elimina tutte le funzioni non correlate alla gestione delle chiavi, mantiene solo una singola responsabilità, riduce il confine di fiducia il più possibile e facilita la verifica indipendente.

Al contrario, il valore di NAS si basa sulle sue capacità multifunzionali, tra cui alta capacità, servizi file, un ricco ecosistema di applicazioni e supporto per diversi protocolli di comunicazione. Questi sono i punti di forza di NAS come piattaforma dati, ma rappresentano un obiettivo di progettazione diverso rispetto all’approccio “minimalista e a scopo unico” richiesto dal KMS.

QNAP QuTS hero: Scegliere correttamente il ruolo di “KMIP Client”

Nell’architettura di QNAP, il ruolo di NAS è quello di un client KMIP capace—affidando la custodia delle chiavi a un KMS dedicato e concentrandosi sulle sue funzioni principali di archiviazione. Il client KMIP di QuTS hero offre le seguenti caratteristiche di progettazione:

  • Custodia remota delle chiavi: Le chiavi di cifratura sono archiviate su un server KMIP remoto, riducendo al minimo il rischio di accesso non autorizzato o perdita delle chiavi a livello di NAS.
  • Scambio di chiavi conforme a FIPS 140-3: Il processo di scambio delle chiavi è progettato secondo i requisiti di sicurezza FIPS 140-3 e gli standard di conformità di livello aziendale.
  • TLS reciproco canale crittografato: Il NAS e il server KMIP comunicano tramite TLS reciproco (mTLS). La porta 5696 è utilizzata di default e entrambe le parti devono avere certificati validi e non scaduti installati.
  • Applicazione automatica delle chiavi e sblocco all’avvio: Le cartelle condivise crittografate e i Logical Unit Number (LUN) crittografati possono recuperare automaticamente le chiavi. Finché il client e il server mantengono la connettività, l’accesso rimane disponibile dopo il riavvio del sistema.
  • Gestione completa del ciclo di vita dei certificati: Supporta la generazione, importazione, sostituzione, download e eliminazione dei certificati, consentendo agli utenti di visualizzare lo stato e le date di scadenza.

Per quanto riguarda le versioni supportate, il client KMIP è disponibile da QuTS hero h6.0. Per installarlo e configurarlo, installare “KMIP Client” da App Center, quindi andare su Pannello di controllo > Sistema > Sicurezza > Impostazioni KMIP.

Questo è proprio il vantaggio di questa divisione delle responsabilità: la massima responsabilità di sicurezza per la convalida del modulo crittografico CMVP è gestita da un KMS professionale, invece di richiedere che ogni dispositivo archiviazione assuma questa responsabilità autonomamente. Il NAS deve solo soddisfare i requisiti di progettazione FIPS 140-3 per lo scambio di chiavi e delegare la radice di fiducia all’autorità appropriata.

Come scegliere un KMS compatibile con KMIP

Una volta stabilito il modello “NAS come client”, il passo successivo è selezionare un’autorità di gestione delle chiavi appropriata. L’approccio consigliato è scegliere tra due percorsi in base ai requisiti di audit e al budget:

Scenario Approccio consigliato Soluzioni rappresentative
Requisiti rigorosi di audit Utilizza soluzioni KMS commerciali certificate esistenti Thales CipherTrust Manager, Entrust KeyControl, IBM Guardium Key Lifecycle Manager, HashiCorp Vault Enterprise (motore KMIP)
Il budget è il criterio principale Distribuisci un server KMIP self-hosted su un host dedicato, controllato e auditabile utilizzando container HashiCorp Vault / OpenBao (motore KMIP), Cosmian KMS; PyKMIP è solo per test

La chiave non è quale host esegue il KMS, ma se l’host è rafforzato, il controllo degli accessi è applicato e possono essere generati audit trail per la revisione. Finché l’autorità di gestione delle chiavi rimane indipendente dalla produzione archiviazione e soddisfa i requisiti di governance descritti sopra, sia le soluzioni commerciali che quelle self-hosted possono fornire una base solida per la tua architettura di crittografia.

Comprendere KMIP e FIPS: una panoramica completa

Durante la validazione dell’audit di crittografia, tre termini vengono spesso confusi tra loro, ma gli auditor li esaminano a livelli completamente diversi:

Concetto Cosa convalida Spiegazione
Interoperabilità Se un KMS può connettersi tramite KMIP e funzionare correttamente “La connessione del protocollo funziona correttamente”
Validazione degli algoritmi (NIST CAVP) Se le implementazioni dei fornitori di algoritmi come AES/SHA/RSA sono corrette “Le operazioni matematiche sono corrette”
Convalida del modulo crittografico (NIST CMVP, FIPS 140-2/140-3) Se l’intero modulo crittografico, inclusa la gestione delle chiavi e il perimetro del modulo crittografico, ha superato la convalida e ottenuto un certificato valido «L’intera cassaforte è stata convalidata rispetto ai requisiti di sicurezza»

Per gli auditor, il requisito più importante e solitamente più rigoroso è la convalida del modulo crittografico. Un’implementazione di algoritmo che supera CAVP, o un modulo in fase di test, non significa che abbia un certificato CMVP valido che copra i componenti di gestione delle chiavi su cui fate affidamento. Pertanto, indipendentemente dalla soluzione KMS selezionata, si consiglia di verificare lo stato di convalida direttamente tramite l’elenco di convalida NIST CMVP e di confermare l’ambito del certificato con i vostri auditor.

KMIP è di per sé un protocollo standard aperto che consente ai client e ai server KMIP di diversi fornitori di comunicare tra loro. Tuttavia, «essere interoperabili» è solo il punto di partenza; la vera sfida che le aziende devono affrontare è se la soluzione può superare la convalida di conformità.

Conclusione: Mantieni separati serratura e chiave

Nel momento in cui implementi KMIP, l’obiettivo non è trasformare il tuo NAS in un KMS, ma stabilire un’autorità di gestione delle chiavi indipendente, affidabile e verificabile per l’intero ambiente.

Come client KMIP, QNAP NAS affida la gestione delle chiavi a un KMS professionale per una governance centralizzata, concentrandosi su archiviazione e sui servizi dati. Questo non significa che manchi una funzionalità; al contrario, è una decisione deliberata per collocare la radice della fiducia dove deve essere. Mantenere separati serratura e chiave è ciò che rende la sicurezza efficace e consente audit di successo.

Per saperne di più sul processo di configurazione del client KMIP QuTS hero, consulta il Tutorial ufficiale di QNAP:

https://www.qnap.com/go/how-to/tutorial/article/how-to-use-kmip-client-for-secure-key-management

FAQ (FAQ)

D: Un NAS può essere utilizzato come server KMIP ?

R: Il NAS QNAP è progettato intenzionalmente per supportare solo il ruolo di client KMIP, non quello di server. Un KMS funge da root of trust e segue il principio della minimizzazione (responsabilità singola e il più piccolo confine di fiducia possibile), mentre un NAS è una piattaforma dati multiuso ad alta capacità. I due hanno obiettivi di progettazione diversi. Anche acquistando un altro NAS dedicato a fungere da KMS significherebbe solo utilizzare una piattaforma multiuso per un compito che richiede un sistema dedicato, lasciando inutilizzata la maggior parte della sua capacità. L’approccio corretto è utilizzare il NAS come client e far gestire e proteggere le chiavi da un KMS dedicato, verificabile e indipendente.

D: Da quale versione software QNAP supporta per la prima volta il client KMIP ?

R: Il client KMIP è supportato a partire da QuTS hero h6.0. Installa KMIP Client da App Center e abilitalo nelle impostazioni di sicurezza in Pannello di controllo.

D: Con un budget limitato, è necessario acquistare un costoso KMS commerciale?

R: Non necessariamente. Le aziende possono implementare soluzioni open source/supportate dalla community con motori KMIP, come HashiCorp Vault (Enterprise) o OpenBao, in una macchina virtuale o in un ambiente container indipendente e rinforzato. L’importante è separare questo ambiente dal NAS tramite isolamento fisico e separazione dei controlli di accesso, assicurandosi che possa generare audit trail completi degli accessi.

Leave a comment

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *