KMaaS e gestione dei secrets nell’era del multicloud | ZeroUno

KMaaS e gestione dei secrets nell’era del multicloud

pittogramma Zerouno

Tech InDepth

KMaaS e gestione dei secrets nell’era del multicloud

Rispetto alla gestione dei secrets (tool per gestire le credenziali digitali di autenticazione), i fornitori di servizi cloud non sono attrezzati per risolvere le sfide associate alla gestione delle chiavi in ambienti multicloud. Il KMaaS può fare la differenza

22 Giu 2021

di Laura Zanotti - Fonte TechTarget

KMaaS è l’acromino di Key Management as a Service, un approccio che risolve le problematiche di gestione legate alle svariate chiavi crittografiche utilizzate per accedere ai vari servizi distribuiti nel multicloud. Secondo il rapporto Key Management as a Service Market – Global Industry Analysis, Size, Share, Growth, Trends and Forecast 2021-2027, la dimensione del mercato KMaaS dovrebbe crescere a una media annua del 26% nel periodo 2021-2027.

Perché la gestione delle chiavi crittografiche è problematica

Il tema è che oggi le applicazioni vengono eseguite attraverso secrets (tool che consentono di gestire le credenziali digitali di autenticazione) per assicurare che solo le entità autenticate e autorizzate possano accedere alle risorse disponibili su piattaforme, stack di tool e ambienti cloud. Nel processo di gestione delle chiavi di crittografia in un sistema crittografico sono inclusi tre algoritmi: generazione di chiavi, crittografia e decrittografia.

WEBINAR
12 Ottobre 2021 - 12:00
Come creare un rapporto duraturo con i clienti grazie a un post-vendita innovativo?
Cloud
Marketing

Il problema è che la configurazione di un certificato di crittografia e il suo utilizzo per crittografare i secrets sono operazioni che vengono eseguite diversamente da applicazione ad applicazione.

La gestione dei secrets è sempre più complessa

Per distribuire una semplice applicazione nel cloud, sono necessarie chiavi SSH per accedere alle virtual machine, chiavi API per interagire con i servizi esterni e certificati X.509 v3 per l’accesso al server web. Inoltre, sono necessari certificati client per l’autenticazione a servizi Web protetti, chiavi crittografiche per secretare i dati archiviati nonché password per middleware o gli archivi dati di back-end.

Memorizzare tutti questi secrets in modo sicuro non è affatto scontato, specialmente in un ecosistema sempre più pieno di nuvole. Con il consolidamento del multicloud, crescono le sfide legate al moltiplicarsi delle chiavi. Ecco perché il KMaaS si presenta come una vera e propria soluzione… chiavi in mano, includendo anche tutto il processo di generazione, uso, archiviazione, distruzione e rotazione delle chiavi. Prima di approfondire l’approccio è bene capire meglio il contesto.

Il cloud sfida i tradizionali approcci di gestione dei secrets

Storicamente, i moduli di sicurezza hardware (HSM) per uso interno hanno aiutato a proteggere i secrets fornendo una posizione fisica sicura e a prova di manomissione per la loro archiviazione. Allo stesso modo, la gestione delle chiavi di crittografia, spesso sotto forma di servizi ha contribuito a fornire un archivio centrale e sicuro per l’archiviazione di chiavi e secrets. Il cloud, tuttavia, ha stressato la gestione dei secrets. Utilizzare i metodi di gestione tradizionali può non essere la soluzione migliore in quanto il cloud astrae i livelli inferiori del substrato tecnologico creando nuovi livelli di complessità.

Esempi con le applicazioni IaaS e HSM

Si consideri, ad esempio, un’applicazione presentata in IaaS. Tutto ciò che si trova sotto il sistema operativo è fornito dal provider. L’implementazione di servizi collegati fisicamente, come gli HSM (che si ricorda essere soluzioni attraverso cui è possibile produrre e gestire chiavi digitali per la strong authentication), rimane fuori dal controllo diretto del cliente. Pertanto, un cliente può utilizzare offerte HSM basate su cloud, rese disponibili dal provider di servizi cloud ma non da altri. Per PaaS e SaaS, l’HSM non è un’opzione, ad eccezione di quelle offerte rese disponibili dal fornitore di servizi. Anche l’infrastruttura è fuori portata. Ciò significa che i servizi di gestione delle chiavi tramite API del fornitore di servizi cloud, ad esempio, sono inaccessibili anche dal punto di vista del cliente.

Gestione dei secrets cloud: l’offerta dei provider

Molti fornitori di servizi cloud offrono opzioni a supporto della gestione dei secrets cloud, ad esempio:

  • Azure fornisce Key Vault
  • AWS fornisce Key Management Service
  • Google Cloud Platform fornisce Cloud Key Management Service

Ciascuna di queste offerte può aiutare ad affrontare l’archiviazione sicura dei secrets all’interno del contesto di un determinato provider di servizi cloud. Sebbene questi servizi forniti dal provider funzionino bene, sono specifici per il provider cloud in uso e differiscono tutti per l’interfaccia fornita al cliente. Ma cosa succede quando i clienti necessitano di un servizio di gestione dei secrets per estendere più provider cloud o un ambiente ibrido?

KMaaS: i vantaggi del modello as a Service

I leader IT devono essere consapevoli di quali sono le sfide collegate alla gestione delle chiavi multicloud e come implementare una strategia di successo per proteggere le infrastrutture ibrida e il multicloud. La gestione delle chiavi multicloud, in particolare, riguarda l’estensione delle capacità di gestione delle chiavi in ​​ambienti in cui sono in uso più cloud diversi. I modelli KMaaS (Cloud Key Management-as-a-Service) sono emersi per fornire questa funzionalità come servizio basato su cloud con un provisioning rapido.

A seconda dell’offerta KMaaS, le chiavi possono essere richieste tramite:

  • Key Management Interoperability Protocol, ovvero uno standard per la richiesta di chiavi da un server di gestione delle chiavi
  • API REST che, utilizzando moduli stub forniti dal fornitore come Public-Key Cryptography Standard 11, permette di impiegare il KMS (Key Management Service)

Il vantaggio di questo tipo di approccio è di normalizzare l’interfaccia associata al meccanismo di gestione delle chiavi. Pertanto, le applicazioni che utilizzano il gestore delle chiavi sottostante diventano più portabili. Il meccanismo utilizzato da un componente dell’applicazione per richiedere l’accesso alle chiavi o ad altri secrets sarà lo stesso in un’applicazione ospitata in un data center oggi, ad esempio, anche se domani quel componente si sposterà nel cloud. Questo si verifica quando un’organizzazione passa a un cloud pubblico per il ripristino di emergenza o per motivi di domanda o, ancora, lo migra al cloud pubblico o tra cloud pubblici. L’approccio rafforza la sicurezza riducendo al minimo la necessità di riemettere i secrets quando ci si sposta tra ambienti o di esportare i secrets per la trasmissione in un’altra posizione.

Ricadute positive anche su altri processi

Oltre alla standardizzazione dell’interfaccia programmatica, il KMaaS standardizza anche i processi di amministrazione. Gli elementi amministrativi, come la fatturazione, i flussi di approvazione, la manutenzione degli inventari chiave e altre attività, sono centralizzati. Questo consente una visibilità centrale e un sovraccarico ridotto associato alla formazione del personale sui flussi di lavoro amministrativi.

4 considerazioni sull’implementazione di KMaaS multicloud

I leader IT devono riconoscere che l’utilizzo di uno strumento KMaaS non significa automaticamente che l’utilizzo dell’organizzazione sarà sicuro. È importante esaminare a fondo e convalidare le opzioni KMaaS. Quando ci si avvicina al mercato KMaaS, ci sono quattro criteri da tenere a mente:

  1. Assicurarsi che dal punto di vista dell’architettura i meccanismi per archiviare e recuperare le chiavi favoriscano l’utilizzo dell’organizzazione. Ad esempio, le organizzazioni che intendono distribuire un’applicazione Java potrebbero dare la priorità ai fornitori che forniscono un’estensione di crittografia Java
  2. Considerare, oltre ai requisiti di prestazioni e sicurezza associati all’utilizzo del cliente, come i componenti e le applicazioni si connetteranno al servizio. Anche l’utilizzo di un’API REST (probabilmente il meccanismo più diffuso per l’interfacciamento con il servizio) richiederà la connettività al servizio di gestione delle chiavi dalla posizione in cui è necessaria la chiave. Ci sono altri casi in cui ciò non è richiesto, ad esempio un cloud privato virtuale protetto senza connettività diretta in uscita. I clienti in questa situazione devono trovare un meccanismo che gli consenta di connettersi, eseguire il proxy della richiesta, utilizzare componenti forniti dal fornitore che possono memorizzare nella cache o esplorare mezzi alternativi.
  3. Inventare i secrets esistenti che verranno archiviati in KMaaS. Se è già presente un servizio di gestione delle chiavi locale, esaminare cosa vi è archiviato e come vengono usati tali secrets. Questa valutazione preliminare può aiutare i leader IT a definire le aspettative su quanto sarà difficile spostare l’utilizzo e determinare quali metodi di accesso funzioneranno meglio. Prestare particolare attenzione a come verranno convalidate e approvate le richieste di accesso e come verranno gestite la rotazione e la scadenza delle chiavi, oltre ad altri requisiti speciali.
  4. Riconoscere che gli attuali processi di gestione delle chiavi multicloud potrebbero non essere equivalenti. Prestare particolare attenzione alle situazioni in cui la sostituzione di componenti esistenti non è possibile o necessaria. Ad esempio, le organizzazioni che utilizzano oggi un HSM fisico probabilmente scopriranno che le chiavi archiviate non sono esportabili. Questa è l’impostazione predefinita per la maggior parte degli HSM poiché le operazioni crittografiche vengono eseguite nel dispositivo stesso. Ciò significa che una chiave non esce mai dai confini dell’HSM, mentre un gestore delle chiavi, KMaaS o altro, non si comporta allo stesso modo. Alcune organizzazioni possono avere requisiti di sicurezza o di utilizzo legittimi per i quali ciò è vantaggioso. Capire perché le chiavi sono protette nel modo in cui sono è un elemento importante per decidere il giusto approccio in base ai rischi e alle esigenze aziendali.
Z

Laura Zanotti - Fonte TechTarget

Giornalista

Ha iniziato a lavorare come technical writer e giornalista negli anni '80, collaborando con tutte le nascenti riviste di informatica e Telco. In oltre 30 anni di attività ha intervistato centinaia di Cio, Ceo e manager, raccontando le innovazioni, i problemi e le strategie vincenti delle imprese nazionali e multinazionali alle prese con la progressiva convergenza tra mondo analogico e digitale. E ancora oggi continua a farlo...

Articolo 1 di 5