Proteggere l'ambiente della piattaforma DevOps per Zero Trust

Questo articolo aiuta, come membro del team DevOps, a implementare il principio Zero Trust dei privilegi minimi e proteggere l'ambiente della piattaforma DevOps. Include contenuto dell'eBook Protezione di ambienti DevOps aziendali ed evidenzia le procedure consigliate per la gestione dei segreti e dei certificati.

Le aziende moderne si basano sulle piattaforme DevOps per la distribuzione, incluse pipeline e ambienti di produzione che gli sviluppatori devono essere produttivi. In passato, i metodi di sicurezza delle applicazioni non considerarono la superficie di attacco aumentata esposta dalle pipeline e dagli ambienti di produzione attuali. Man mano che gli hacker si spostano a sinistra e assegnare strumenti upstream, sono necessari approcci innovativi per proteggere gli ambienti della piattaforma DevOps.

Nel diagramma seguente si noti che l'ambiente della piattaforma DevOps si connette all'ambiente dell'applicazione e alle estensioni della pipeline di integrazione continua e recapito continuo (CI/CD).

Le estensioni della pipeline CI/CD presentano agli hacker opportunità di intraprendere escalation dei privilegi dall'ambiente dell'applicazione. Le estensioni e le integrazioni aumentano le vulnerabilità della superficie di attacco. È fondamentale difendersi dalle minacce antimalware.

Come e perché gli utenti malintenzionati hanno come destinazione le pipeline

Le pipeline e gli ambienti di produzione potrebbero essere indipendenti da procedure e processi standard di sicurezza delle applicazioni. In genere richiedono credenziali di accesso di alto livello che possono fornire accesso profondo e significativo agli utenti malintenzionati.

Mentre gli utenti malintenzionati trovano nuovi modi per compromettere i sistemi, i vettori di attacco più comuni per le pipeline includono:

• Estrazione di variabili di runtime e inserimento di argomenti.
• Script che recuperano i principi del servizio o le credenziali dalle pipeline.
• Token di accesso personali configurati in modo errato che consentono a chiunque abbia la chiave di accedere all'ambiente della piattaforma DevOps.
• Vulnerabilità e errori di configurazione negli strumenti integrati che richiedono l'accesso al codice (spesso di sola lettura, ma talvolta accesso in scrittura). Gli strumenti integrati possono includere framework di test, test di sicurezza delle applicazioni statici (SAST) e test dinamici della sicurezza delle applicazioni (DAST).

Procedure consigliate per la gestione dei segreti e dei certificati

Evitare una violazione irreversibile può essere semplice quanto efficace la gestione dei segreti. Il diagramma seguente illustra un esempio di segreto, password, token di accesso e gestione dei certificati effettivi.

Come illustrato nel diagramma precedente, lo sviluppatore avvia una compilazione per una richiesta del cliente. GitHub avvia quindi uno strumento di esecuzione con l'ID ruolo dell'app dell'insieme di credenziali e l'ID segreto. L'entità attendibile richiede periodicamente un nuovo ID segreto dall'insieme di credenziali e ottiene l'ID segreto GitHub da GitHub. L'insieme di credenziali usa l'ID ruolo e l'ID segreto di GitHub per accedere e ottenere asset di firma del codice. Runner personalizza e firma il codice dell'app per dispositivi mobili.

Le procedure consigliate seguenti consentono di creare una configurazione sicura che riduce al minimo l'esposizione dei segreti e dei parametri.

• Fornire una risorsa di archiviazione sicura per segreti e certificati in ogni fase del ciclo di vita dell'applicazione. Sviluppare sempre come se fosse un progetto open source. Assicurarsi che i team archiviano i segreti negli insiemi di credenziali delle chiavi anziché nel codice o negli ambienti del team. Usare il servizio cloud Azure Key Vault per archiviare e accedere ai segreti in modo sicuro.
• Configurare Azure per considerare attendibile l'OIDC di GitHub come identità federata. OpenID Connect (OIDC) consente ai flussi di lavoro di GitHub Actions di accedere alle risorse in Azure senza dover archiviare le credenziali di Azure come segreti GitHub di lunga durata.

Altre procedure consigliate per la sicurezza dell'ambiente DevOps

Per difendersi dagli eventi imprevisti di sicurezza, esaminare le procedure consigliate seguenti per rafforzare gli ambienti della piattaforma DevOps. Per una descrizione dettagliata di queste raccomandazioni, vedere l'eBook Protezione di ambienti DevOps aziendali.

• Equipaggiare ogni ambiente della piattaforma DevOps con audit trail. Esaminare i log di controllo per tenere traccia degli utenti che hanno ottenuto l'accesso, delle modifiche apportate e della data/ora per qualsiasi sistema attivo. In particolare, includere piattaforme DevOps con pipeline CI/CD che passano all'ambiente di produzione. Gli audit trail per gli strumenti DevOps offrono metodi affidabili per correggere le minacce più rapidamente, trovare e inviare avvisi sulle attività sospette a possibili violazioni o vulnerabilità e individuare potenziali dati o uso improprio dei privilegi. Assicurarsi che i audit trail e i controlli granulari siano disponibili in ogni ambiente.
• Proteggere la catena di approvvigionamento software. Con ogni libreria inserita nella codebase, si espande la supply chain del software e si ereditano le dipendenze da ogni progetto o strumento open source. Con cautela, rimuovere librerie non necessarie e componenti open source per ridurre la superficie di attacco della supply chain software.
• Automatizzare le analisi dei modelli IaC (Infrastructure-as-Code). Con gli ambienti IaC, è facile eseguire l'analisi di errori di configurazione, controlli di conformità e problemi di criteri. L'implementazione di controlli di conformità e controlli di accesso genera il comportamento di sicurezza dell'intera infrastruttura. Verificare la sicurezza delle integrazioni degli strumenti che soddisfano i requisiti di sistema di automazione.
• Automatizzare i flussi di lavoro di approvazione. Per consentire a qualsiasi flusso di lavoro di approvazione di eseguire il push del codice nell'ambiente di produzione, alcuni controlli automatici o manuali devono confermare la sicurezza, il valore aziendale, lo stato e la qualità di ogni richiesta. Questi controlli funzionano come un gate tra sviluppo e produzione per evitare attacchi Denial of Service e hacker che inseriscono il codice in ambienti di produzione senza contrassegnare o attivare un avviso.
• Consenti solo integrazioni dello strumento DevOps verificate. Come negli ambienti di sviluppo, gli strumenti DevOps sono dotati di estensioni e integrazioni per rendere efficiente e sicuro il team DevOps. Verificare che le integrazioni verificate richiedano il privilegio minimo possibile per eseguire il lavoro. Implementare l'accesso con privilegi minimi quando possibile e assicurarsi il livello corretto di autorizzazioni di lettura/scrittura. Informazioni su come disabilitare o limitare GitHub Actions per l'organizzazione.

Passaggi successivi

• Proteggere l'ambiente di sviluppo consente di implementare principi Zero Trust negli ambienti di sviluppo con procedure consigliate per privilegi minimi, sicurezza dei rami e strumenti di attendibilità, estensioni e integrazioni.
• Incorporare la sicurezza Zero Trust nel flusso di lavoro dello sviluppatore consente di innovare in modo rapido e sicuro.
• Gli ambienti DevOps sicuri per Zero Trust descrivono le procedure consigliate per proteggere gli ambienti DevOps con un approccio Zero Trust per impedire agli hacker di compromettere le caselle degli sviluppatori, infettare le pipeline di rilascio con script dannosi e ottenere l'accesso ai dati di produzione tramite ambienti di test.
• Implementare i principi Zero Trust come descritto nel memorandum 22-09 (a supporto dell'ordine esecutivo degli Stati Uniti 14028, Miglioramento della sicurezza informatica nazionale) usando Microsoft Entra ID come sistema centralizzato di gestione delle identità.
• Accelerare e proteggere il codice con Azure DevOps con strumenti che offrono agli sviluppatori il codice più veloce e sicuro per l'esperienza cloud.