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, comprese pipeline e ambienti di produzione che gli sviluppatori richiedono per 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 attori malintenzionati si spostano a sinistra nel processo di sviluppo e prendono di mira strumenti a monte, sono necessari approcci innovativi per proteggere gli ambienti della tua 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 offrono ai cybercriminali opportunità di effettuare elevazioni 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 attori 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 attori malintenzionati.

Anche se gli attori malintenzionati trovano nuovi modi per compromettere i sistemi, le vulnerabilità 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 un runner con l'ID ruolo dell'AppRole di Vault e l'ID segreto. L'entità attendibile richiede periodicamente un nuovo ID segreto dal Vault e ottiene l'ID segreto di GitHub da GitHub. Il Vault utilizza l'ID ruolo e l'ID segreto di GitHub per effettuare l'accesso e ottenere risorse per la 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 di accesso aumenta la postura 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 cancello tra sviluppo e produzione per impedire attacchi di negazione del servizio e impedire che attori malintenzionati inseriscano codice negli ambienti di produzione senza essere rilevati 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 attori malintenzionati di compromettere le caselle degli sviluppatori, infettare le pipeline di versione con script dannosi e ottenere l'accesso ai dati di produzione tramite ambienti di test.
• Accelerare e proteggere il codice con Azure DevOps con strumenti che offrono agli sviluppatori il codice più veloce e sicuro per l'esperienza cloud.