La
compromissione di account privilegiati e credenziali è la principale causa degli attacchi IT più gravi. La maggior parte dei team di sicurezza ha stabilito i requisiti minimi per proteggere le credenziali privilegiate di persone e applicazioni nei sistemi IT tradizionali, ad esempio Windows, mentre gli
ambienti DevOps e cloud vengono spesso
presi in considerazione in ritardo. Con l’accelerazione delle iniziative di trasformazione digitale, questi requisiti devono estendersi anche DevOps, cloud e identità non umane. La sfida per il team di sicurezza è: come agire affinché ciò avvenga?
La cultura di sviluppatori e DevOps è molto diversa da quella di coloro che si occupano di sicurezza e, per far sì che le best practice diventino realtà, le necessità
devono allinearsi alla cultura DevOps. Se gli sviluppatori pensano che i requisiti di sicurezza stiano rallentando le loro attività, cercheranno di evitare l’adozione di nuove misure (in questo caso per proteggere account privilegiati, credenziali e segreti).
Nel caso in cui l’aggiunta di nuovi processi venisse respinta, sarà opportuno
sottolineare le efficienze operative che si potrebbero ottenere. Ad esempio, gestire manualmente le credenziali privilegiate richiede impegno e responsabilità dello sviluppatore. Liberandolo da tale compito, il team DevOps potrà dedicare ancora più tempo alle proprie attività. Ecco
quattro best practice per definire i requisiti di protezione delle credenziali in ambienti con una robusta sicurezza degli accessi privilegiati.
Centralizzare la gestione dei segreti per DevOps e cloud
È consigliabile implementare un sistema di gestione dei segreti centralizzato che
agisca da intermediario tra gli utenti (identità sia umane che non umane/macchine) e database, risorse, altri tool e sistemi critici a cui è necessario accedere. In questo modo è possibile salvaguardare i segreti dato che gli utenti
non visualizzeranno le credenziali attuali. Ad esempio, se uno sviluppatore ha la necessità di accedere alla console cloud, si autenticherà tramite il sistema di gestione dei secret, che verificherà se è autorizzato e fornirà l’eventuale accesso alla console senza rivelare le credenziali privilegiate.
Questo sistema centralizzato dovrebbe
archiviare tutti i segreti e le credenziali utilizzati da sviluppatori e amministratori DevOps in un vault a prova di manomissione che offre anche sicurezza multi-layer, dalla crittografia alla rotazione regolare delle credenziali, fino all’integrazione con l’autenticazione multi-fattore. Il monitoraggio e il log delle credenziali aiuta a
instillare senso di responsabilità negli utenti. Per supportare l’individuazione delle anomalie in modo veloce, è opportuno stabilire una linea per l’utilizzo base dei modelli e dotare ogni macchina di un’identità unica, in modo tale da analizzare e monitorare gli accessi ai segreti in modo più semplice.
Estendere le capacità aziendali di audit e monitoraggio
È davvero importante avere una panoramica completa di
chi accede a quali elementi ed essere in grado di analizzare e monitorare gli accessi in tutto l’ambiente. La soluzione per la gestione centralizzata dei segreti dovrebbe essere integrata in un sistema centrale, ad esempio utilizzando un server o Active Directory LDAP per l’autenticazione. Inoltre, è importante
avere consapevolezza della situazione quando si tratta di vulnerabilità, minacce IT e integrazioni di cyber sicurezza con le soluzioni di controllo e analytics, come Security Information e Event Management (SIEM) e User ed Entity Behavior Analytics (UEBA).
Eliminare le credenziali privilegiate da tool e applicazioni DevOps
È necessario rimuovere i secret da ogni tool, file, script e codici di configurazione e richiedere che i segreti vengano
recuperati da un vault sicuro. Questa best practice deve essere una priorità. Serviranno tempo e diversi passaggi per raggiungere l’obiettivo, ma si può iniziare, ad esempio, richiedendo che tutte le nuove applicazioni vengano sviluppate per rispondere a questa esigenza.
Includere inavvertitamente chiavi di accesso e credenziali in un codice assegnato a un repository è un errore comune, che ha condotto però a
numerose violazioni e attività fraudolente (quali il mining di
criptovalute). Per evitare che ciò accada è opportuno che segreti, chiavi di accesso cloud e altre credenziali sensibili non siano mai inclusi in un codice. Questi standard dovrebbero essere definiti sia per i codici sviluppati in-house che per quelli di terze parti.
Sviluppare modelli di codice riutilizzabile per fornire segreti alle applicazioni
I team di sicurezza dovrebbero collaborare in modo congiunto con quelli DevOps per determinare come fornire i secret alle applicazioni,
in base ai requisiti delle app e alle preferenze degli sviluppatori. Alcuni potrebbero preferire un approccio basato su API call, in cui un’applicazione effettua un’API call ad un vault, da cui ricevere il secret per l’applicazione. Altri potrebbero optare per l’injection dei secret, in cui un programma che funge da intermediario recupera i segreti e li trasmette all’ambiente applicativo.
Per limitare l’esposizione e i rischi, è importante assicurarsi che quando i secret sono all’esterno del vault protetto, siano
effimeri, non persistenti e ruotati di frequente. Ad esempio, con un file mappato in memoria, il secret dovrebbe risultare inaccessibile una volta terminato il processo.
Massimo Carlotti è Sales Engineer Italy di CyberArk