Una pipeline di deployment è un processo automatizzato che prende codice o artefatti predefiniti e li esegue in un ambiente di test o di produzione. Le pipeline di deployment vengono comunemente utilizzate per eseguire il deployment di applicazioni, configurazioni o infrastruttura cloud (Infrastructure as Code) e possono svolgere un ruolo importante nella postura di sicurezza complessiva di un deployment cloud.
Questa guida è rivolta a DevOps e security engineer e descrive le migliori pratiche per progettare pipeline di deployment sicure in base ai requisiti di riservatezza, integrità e disponibilità.
Architettura
Il seguente diagramma mostra il flusso di dati in una pipeline di deployment. Illustra come trasformare gli elementi in risorse.
Le pipeline di deployment fanno spesso parte di un flusso di lavoro di integrazione continua/deployment continuo (CI/CD) più ampio e in genere vengono implementate utilizzando uno dei seguenti modelli:
Modello push: in questo modello, implementi la pipeline di deployment utilizzando un sistema CI/CD centrale come Jenkins o GitLab. Questo sistema CI/CD potrebbe essere eseguito su Google Cloud, on-premise o in un altro ambiente cloud. Spesso, lo stesso sistema CI/CD viene utilizzato per gestire più pipeline di deployment.
Il modello push porta a un'architettura centralizzata con pochi sistemi CI/CD utilizzati per gestire un numero potenzialmente elevato di risorse o applicazioni. Ad esempio, puoi utilizzare una singola istanza Jenkins o GitLab per gestire l'intero ambiente di produzione, inclusi tutti i progetti e le applicazioni.
Modello pull:in questo modello, il processo di deployment viene implementato da un agente di cui viene eseguito il deployment insieme alla risorsa, ad esempio nello stesso cluster Kubernetes. L'agente estrae gli elementi o il codice sorgente da una posizione centralizzata e li esegue in locale. Ogni agente gestisce una o due risorse.
Il modello pull porta a un'architettura più decentralizzata con un potenzialmente elevato numero di agenti monouso.
Rispetto ai deployment manuali, l'utilizzo coerente delle pipeline di deployment può avere i seguenti vantaggi:
- Maggiore efficienza, perché non è richiesta alcuna operazione manuale.
- Maggiore affidabilità, perché il processo è completamente automatico e ripetibile.
- Maggiore tracciabilità, perché puoi risalire a tutte le modifiche apportate ai deployment nel codice o agli elementi di input.
Per funzionare, una pipeline di deployment richiede l'accesso alle risorse che gestisce:
- Una pipeline che esegue il deployment dell'infrastruttura utilizzando strumenti come Terraform potrebbe dover creare, modificare o addirittura eliminare risorse come istanze VM, subnet o bucket Cloud Storage.
- Una pipeline che esegue il deployment di applicazioni potrebbe dover caricare nuove immagini dei contenitori in Artifact Registry ed eseguire il deployment di nuove versioni dell'applicazione in App Engine, Cloud Run o Google Kubernetes Engine (GKE).
- Una pipeline che gestisce le impostazioni o esegue il deployment di file di configurazione potrebbe dover modificare i metadati delle istanze VM, le configurazioni di Kubernetes o i dati in Cloud Storage.
Se le pipeline di implementazione non sono protette correttamente, il loro accesso alle risorse di Google Cloud può diventare un punto debole della tua strategia di sicurezza. Una sicurezza indebolita può portare a diversi tipi di attacchi, tra cui:
Attacchi di attacco alla pipeline:anziché attaccare direttamente una risorsa, un malintenzionato potrebbe tentare di compromettere la pipeline di deployment, la relativa configurazione o l'infrastruttura di base. Sfruttando l'accesso della pipeline a Google Cloud, l'attore malintenzionato potrebbe indurre la pipeline a eseguire azioni dannose sulle risorse Cloud, come mostrato nel seguente diagramma:
Attacchi alla catena di approvvigionamento: anziché attaccare la pipeline di deployment, un malintenzionato potrebbe tentare di compromettere o sostituire l'input della pipeline, inclusi codice sorgente, librerie o immagini container, come mostrato nel seguente diagramma:
Per determinare se le pipeline di deployment sono protette in modo appropriato, non è sufficiente esaminare solo i criteri di autorizzazione e di rifiuto delle risorse Google Cloud in modo isolato. Devi invece prendere in considerazione l'intero grafo dei sistemi che concedono direttamente o indirettamente l'accesso a una risorsa. Questo grafico include le seguenti informazioni:
- La pipeline di deployment, il sistema CI/CD sottostante e l'infrastruttura sottostante
- Il repository di codice sorgente, i server sottostanti e l'infrastruttura sottostante
- Artefatti di input, relative posizioni di archiviazione e infrastruttura di base
- I sistemi che producono gli elementi di input e la relativa infrastruttura di base
I grafici di input complessi rendono difficile identificare l'accesso degli utenti alle risorse e le debolezze sistemiche.
Le sezioni che seguono descrivono le best practice per progettare le pipeline di deployment in modo da gestire le dimensioni del grafo e ridurre il rischio di movimenti laterali e attacchi alla catena di approvvigionamento.
Valutare gli obiettivi di sicurezza
È probabile che le tue risorse su Google Cloud varino in termini di sensibilità. Alcune risorse potrebbero essere altamente sensibili perché importanti per l'attività o riservate. Altre risorse potrebbero essere meno sensibili perché sono temporanee o destinate solo a scopi di test.
Per progettare una pipeline di deployment sicura, devi prima comprendere le risorse a cui la pipeline deve accedere e quanto sono sensibili. Più le tue risorse sono sensibili, più devi concentrarti sulla protezione della pipeline.
Le risorse a cui accedono le pipeline di deployment potrebbero includere:
- Applicazioni, come Cloud Run o App Engine
- Risorse cloud, come istanze VM o bucket Cloud Storage
- Dati, ad esempio oggetti Cloud Storage, record BigQuery o file
Alcune di queste risorse potrebbero dipendere da altre risorse, ad esempio:
- Le applicazioni potrebbero accedere a dati, risorse cloud e altre applicazioni.
Le risorse cloud, come istanze VM o bucket Cloud Storage, potrebbero contenere applicazioni o dati.
Come mostrato nel diagramma precedente, le dipendenze influiscono sulla sensibilità di una risorsa. Ad esempio, se utilizzi un'applicazione che accede a dati altamente sensibili, in genere devi trattarla come altamente sensibile. Analogamente, se una risorsa cloud come un bucket Cloud Storage contiene dati sensibili, in genere devi trattare il bucket come sensibile.
A causa di queste dipendenze, è meglio valutare prima la sensibilità dei tuoi dati. Dopo aver valutato i dati, puoi esaminare la catena di dipendenza e valutare la sensibilità delle risorse e delle applicazioni Cloud.
Classificare la sensibilità dei dati
Per comprendere la sensibilità dei dati nella pipeline di deployment, prendi in considerazione i seguenti tre obiettivi:
- Riservatezza: devi proteggere i dati da accessi non autorizzati.
- Integrità: devi proteggere i dati da modifiche o eliminazioni non autorizzate.
- Disponibilità: devi assicurarti che le persone e i sistemi autorizzati possano accedere ai dati nella pipeline di deployment.
Per ciascuno di questi scopi, chiediti cosa succederebbe se la pipeline fosse compromessa:
- Riservatezza: quanto sarebbe dannoso se i dati venissero divulgati a un malintenzionato o trapelati al pubblico?
- Integrità:quanto sarebbe dannoso se i dati venissero modificati o eliminati da un malintenzionato?
- Disponibilità: quanto sarebbe dannoso se un utente malintenzionato interrompesse il tuo accesso ai dati?
Per rendere i risultati confrontabili tra le risorse, è utile introdurre categorie di sicurezza. Lo standard per la classificazione della sicurezza (FIPS-199) suggerisce di utilizzare le seguenti quattro categorie:
- Alto: i danni sarebbero gravi o catastrofici
- Moderato: i danni sarebbero gravi
- Basso: i danni sarebbero limitati
- Non applicabile:lo standard non si applica
A seconda dell'ambiente e del contesto, un insieme diverso di categorie potrebbe essere più appropriato.
La riservatezza e l'integrità dei dati della pipeline rientrano in un ampio spettro, in base alle categorie di sicurezza appena discusse. Le seguenti sottosezioni contengono esempi di risorse con misurazioni diverse di riservatezza e integrità:
Risorse con bassa riservatezza, ma integrità bassa, moderata e alta
I seguenti esempi di risorse hanno tutte un livello di riservatezza basso:
- Integrità bassa: dati di test
- Integrità moderata:contenuti del server web pubblico, vincoli delle norme per la tua organizzazione
- Elevata integrità: immagini container, immagini disco, configurazioni di applicazioni, criteri di accesso (elenchi consentiti e vietati), vincoli, dati relativi al livello di accesso
Risorse con riservatezza media, ma integrità bassa, moderata e alta
I seguenti esempi di risorse hanno tutte una classificazione di riservatezza media:
- Integrità bassa: contenuti del server web interno
- Integrità moderata: audit log
- Elevata integrità: file di configurazione dell'applicazione
Risorse con elevata riservatezza, ma integrità bassa, moderata e alta
I seguenti esempi di risorse hanno tutte un'elevata riservatezza:
- Integrità bassa: dati di utilizzo e informazioni che consentono l'identificazione personale
- Integrità moderata: segreti
- Elevata integrità: dati finanziari, chiavi KMS
Classificare le applicazioni in base ai dati a cui accedono
Quando un'applicazione accede a dati sensibili, anche l'applicazione e la pipeline di deployment che la gestisce possono diventare sensibili. Per valutare questa sensibilità, esamina i dati a cui devono accedere l'applicazione e la pipeline.
Dopo aver identificato e classificato tutti i dati a cui accede un'applicazione, puoi utilizzare le seguenti categorie per classificare inizialmente l'applicazione prima di progettare una pipeline di deployment sicura:
- Riservatezza: la categoria più alta di tutti i dati a cui è stato eseguito l'accesso
- Integrità: la categoria più alta di tutti i dati a cui è stato eseguito l'accesso
- Disponibilità: la categoria più alta di tutti i dati a cui è stato eseguito l'accesso
Questa valutazione iniziale fornisce indicazioni, ma potrebbero esserci altri fattori da prendere in considerazione, ad esempio:
- Due set di dati potrebbero avere una bassa riservatezza se presi singolarmente. Tuttavia, se combinati, possono rivelare nuovi approfondimenti. Se un'applicazione ha accesso a entrambi gli insiemi di dati, potrebbe essere necessario classificarla come di media o alta riservatezza.
- Se un'applicazione ha accesso a dati ad alta integrità, in genere devi classificarla come ad alta integrità. Tuttavia, se questo accesso è di sola lettura, una classificazione di alta integrità potrebbe essere troppo rigida.
Per informazioni dettagliate su un approccio formalizzato per classificare le applicazioni, consulta la Guida per la mappatura dei tipi di informazioni e sistemi di informazione alle categorie di sicurezza (NIST SP 800-60 Vol. 2 Rev1).
Classificare le risorse cloud in base ai dati e alle applicazioni che ospitano
Tutti i dati o le applicazioni di cui esegui il deployment su Google Cloud sono ospitati da una risorsa Google Cloud:
- Un'applicazione potrebbe essere ospitata da un servizio App Engine, da un'istanza VM o da un cluster GKE.
- I dati potrebbero essere ospitati da un disco permanente, un bucket Cloud Storage o un set di dati BigQuery.
Quando una risorsa cloud ospita dati o applicazioni sensibili, anche la risorsa e la pipeline di deployment che la gestisce possono diventare sensibili. Ad esempio, devi considerare un servizio Cloud Run e la relativa pipeline di deployment sensibili quanto l'applicazione che ospitano.
Dopo aver classificato i dati e le applicazioni, crea una categoria di sicurezza iniziale per l'applicazione. Per farlo, determina un livello tra le seguenti categorie:
- Riservatezza: la categoria più alta per qualsiasi dato o applicazione ospitata
- Integrità: la categoria più alta per qualsiasi dato o applicazione ospitata
- Disponibilità: la categoria più alta di qualsiasi dato o applicazione ospitata
Quando effettui la valutazione iniziale, non essere troppo severo, ad esempio:
- Se cripti dati altamente riservati, tratta la chiave di crittografia come altamente riservata. Tuttavia, puoi utilizzare una categoria di sicurezza inferiore per la risorsa contenente i dati.
- Se memorizzi copie ridondanti di dati o esegui istanze ridondanti delle stesse applicazioni su più risorse, puoi impostare la categoria della risorsa su un livello inferiore rispetto a quella dei dati o dell'applicazione che ospita.
Limitare l'utilizzo delle pipeline di deployment
Se la pipeline di deployment deve accedere a risorse Google Cloud sensibili, devi considerare la relativa posizione di sicurezza. Più le risorse sono sensibili, più devi cercare di proteggere la pipeline. Tuttavia, potresti riscontrare i seguenti limiti pratici:
- Se utilizzi un'infrastruttura esistente o un sistema CI/CD esistente, questa infrastruttura potrebbe limitare il livello di sicurezza che puoi raggiungere in modo realistico. Ad esempio, il tuo sistema CI/CD potrebbe supportare solo un insieme limitato di controlli di sicurezza o potrebbe essere in esecuzione su un'infrastruttura che ritieni meno sicura di alcuni dei tuoi ambienti di produzione.
- Quando configuri nuova infrastruttura e nuovi sistemi per eseguire la pipeline di implementazione, la protezione di tutti i componenti in modo da soddisfare i requisiti di sicurezza più rigorosi potrebbe non essere conveniente.
Per gestire queste limitazioni, può essere utile impostare vincoli su quali scenari devono e non devono utilizzare le pipeline di deployment e un determinato sistema CI/CD. Ad esempio, le implementazioni più sensibili sono spesso gestite meglio al di fuori di una pipeline di implementazione. Questi deployment possono essere manuali, utilizzando un sistema di gestione delle sessioni con privilegi o un sistema di gestione degli accessi con privilegi oppure qualcos'altro, come i proxy dello strumento.
Per impostare i vincoli, definisci i controlli di accesso da applicare in base alle categorie di risorse. Tieni conto delle indicazioni fornite nella tabella seguente:
| Categoria della risorsa | Controlli di accesso |
|---|---|
| Bassa | Nessuna approvazione necessaria |
| Moderata | Il team lead deve approvare |
| Alta | È necessario l'approvazione di più lead e le azioni devono essere registrate |
Confronta questi requisiti con le funzionalità dei tuoi sistemi di gestione del codice sorgente (SCM) e CI/CD ponendo le seguenti domande e altre:
- I tuoi sistemi SCM o CI/CD supportano i controlli di accesso e i meccanismi di approvazione necessari?
- I controlli sono protetti da eventuali manomissioni se malintenzionati attaccano l'infrastruttura di base?
- La configurazione che definisce i controlli è protetta in modo appropriato?
A seconda delle funzionalità e delle limitazioni imposte dai sistemi SCM o CI/CD, puoi definire i vincoli relativi ai dati e alle applicazioni per le pipeline di deployment. Prendi in considerazione le indicazioni riportate nella seguente tabella:
| Categoria della risorsa | Vincoli |
|---|---|
| Bassa | È possibile utilizzare le pipeline di deployment e gli sviluppatori possono approvare autonomamente i deployment. |
| Moderata | È possibile utilizzare le pipeline di deployment, ma un responsabile del team deve approvare ogni commit e deployment. |
| Alta | Non utilizzare pipeline di deployment. Gli amministratori devono invece utilizzare un sistema di gestione degli accessi privilegiati e la registrazione delle sessioni. |
Mantenere la disponibilità delle risorse
L'utilizzo di una pipeline di deployment per gestire le risorse può influire sulla disponibilità di queste risorse e introdurre nuovi rischi:
- Causa interruzioni: una pipeline di deployment potrebbe inviare codice o file di configurazione difettosi, causando il malfunzionamento di un sistema precedentemente funzionante o rendendo i dati inutilizzabili.
- Interruzione prolungata: per risolvere un'interruzione, potrebbe essere necessario eseguire nuovamente una pipeline di deployment. Se la pipeline di deployment è interrotta o non è disponibile per altri motivi, l'interruzione potrebbe prolungarsi.
Una pipeline che può causare o prolungare le interruzioni del servizio comporta un rischio di attacchi di tipo denial of service: un malintenzionato potrebbe utilizzare la pipeline di deployment per causare intenzionalmente un'interruzione del servizio.
Crea procedure di accesso di emergenza
Quando una pipeline di deployment è l'unico modo per eseguire il deployment o la configurazione di un'applicazione o di una risorsa, la disponibilità della pipeline può diventare critica. In casi estremi, se una pipeline di deployment è l'unico modo per gestire un'applicazione business-critical, potrebbe essere necessario considerare anche la pipeline di deployment come business-critical.
Poiché le pipeline di deployment sono spesso costituite da più sistemi e strumenti, mantenere un elevato livello di disponibilità può essere difficile o non conveniente.
Puoi ridurre l'influenza delle pipeline di deployment sulla disponibilità creando procedure di accesso di emergenza. Ad esempio, crea un percorso di accesso alternativo che può essere utilizzato se la pipeline di deployment non è operativa.
La creazione di una procedura di accesso di emergenza in genere richiede la maggior parte delle seguenti operazioni:
- Gestisci uno o più account utente con accesso privilegiato alle risorse Google Cloud pertinenti.
- Memorizza le credenziali degli account utente con accesso di emergenza in una posizione sicura o utilizza un sistema di gestione degli accessi privilegiati per mediare l'accesso.
- Stabilisci una procedura che i dipendenti autorizzati possono seguire per accedere alle credenziali.
- Controlla e rivedi l'utilizzo degli account utente con accesso di emergenza.
Assicurati che gli elementi di input soddisfino le tue esigenze di disponibilità
In genere, le pipeline di deployment devono scaricare il codice sorgente da un repository centralizzato di codice sorgente prima di poter eseguire un deployment. Se il repository del codice sorgente non è disponibile, l'esecuzione della pipeline di deployment potrebbe non riuscire.
Molte pipeline di deployment dipendono anche da elementi di terze parti. Questi artefatti
potrebbero includere librerie provenienti da origini come npm, Maven Central o la Galleria NuGet, nonché immagini di base del contenitore e pacchetti .deb e .rpm. Se una delle origini di terze parti non è disponibile, l'esecuzione della pipeline di deployment potrebbe non riuscire.
Per mantenere un determinato livello di disponibilità, devi assicurarti che gli elementi di input della pipeline di deployment soddisfino tutti i requisiti di disponibilità uguali o superiori. Il seguente elenco può aiutarti a garantire la disponibilità degli elementi di input:
- Limita il numero di origini per gli elementi di input, in particolare quelle di terze parti
- Gestisci una cache di elementi di input che le pipeline di deployment possono utilizzare se i sistemi di origine non sono disponibili
Tratta le pipeline di deployment e la relativa infrastruttura come sistemi di produzione
Le pipeline di deployment fungono spesso da tessuto connettivo tra gli ambienti di sviluppo, gestione temporanea e produzione. A seconda dell'ambiente, potrebbero essere implementati più passaggi:
- Nella prima fase, la pipeline di deployment aggiorna un ambiente di sviluppo.
- Nella fase successiva, la pipeline di deployment aggiorna un ambiente di staging.
- Nella fase finale, la pipeline di deployment aggiorna l'ambiente di produzione.
Quando utilizzi una pipeline di deployment in più ambienti, assicurati che la pipeline soddisfi le esigenze di disponibilità di ciascun ambiente. Poiché gli ambienti di produzione in genere hanno le richieste di disponibilità più elevate, devi trattare la pipeline di deployment e la relativa infrastruttura di base come un sistema di produzione. In altre parole, applica all'infrastruttura che esegue le pipeline di deployment gli stessi standard di controllo dell'accesso dell'accesso, di sicurezza e di qualità che utilizzi per i tuoi sistemi di produzione.
Limitare l'ambito delle pipeline di deployment
Più risorse può accedere a una pipeline di deployment, più danni può causare se viene compromessa. Una pipeline di deployment compromessa che ha accesso a più progetti o addirittura all'intera organizzazione potrebbe, nel peggiore dei casi, causare danni permanenti a tutti i dati e le applicazioni su Google Cloud.
Per evitare questo scenario peggiore, limita l'ambito delle pipeline di deployment. Definisci l'ambito di ogni pipeline di deployment in modo che debba accedere solo a un numero relativamente ridotto di risorse su Google Cloud:
- Anziché concedere l'accesso a livello di progetto, concedi alle pipeline di deployment l'accesso solo alle singole risorse.
- Evita di concedere l'accesso alle risorse in più progetti Google Cloud.
- Suddividi le pipeline di deployment in più fasi se hanno bisogno di accedere a più progetti o ambienti. Quindi, fissa le pedane singolarmente.
Mantenere la riservatezza
Una pipeline di deployment deve mantenere la riservatezza dei dati che gestisce. Uno dei principali rischi legati alla riservatezza è l'esfiltrazione di dati.
Esistono diversi modi in cui un malintenzionato potrebbe tentare di utilizzare una pipeline di deployment per esfiltrare i dati dalle tue risorse Google Cloud. tra cui:
- Diretta: un malintenzionato potrebbe modificare la pipeline di deployment o la relativa configurazione in modo da estrarre i dati dalle risorse Google Cloud e poi copiarli altrove.
- Indiretta: un malintenzionato potrebbe utilizzare la pipeline di deployment per eseguire il deployment di codice compromesso, che poi ruba i dati dal tuo ambiente Google Cloud.
Puoi ridurre i rischi per la riservatezza riducendo al minimo l'accesso alle risorse riservate. Tuttavia, la rimozione di tutto l'accesso alle risorse riservate potrebbe non essere praticabile. Pertanto, devi progettare la pipeline di deployment in modo che soddisfi le esigenze di riservatezza delle risorse che gestisce. Per determinare queste richieste, puoi utilizzare il seguente approccio:
- Determina i dati, le applicazioni e le risorse a cui deve accedere la pipeline di deployment e classificali.
- Individua la risorsa con la categoria di riservatezza più elevata e utilizzala come categoria iniziale per la pipeline di deployment.
Analogamente alla procedura di classificazione per applicazioni e risorse cloud, questa valutazione iniziale non è sempre appropriata. Ad esempio, potresti utilizzare una pipeline di deployment per creare risorse che alla fine conterranno informazioni estremamente confidenti. Se limiti la pipeline di deployment in modo che possa creare, ma non leggere, queste risorse, potrebbe essere sufficiente una categoria di riservatezza inferiore.
Per mantenere la riservatezza, il modello Bell-LaPadula suggerisce che una pipeline di deployment non deve:
- Utilizzare elementi di input con un livello di riservatezza più elevato
- Scrivere dati in una risorsa con riservatezza inferiore
In base al modello Bell-LaPadula, il diagramma precedente mostra come i dati devono scorrere nella pipeline per contribuire a garantire la loro riservatezza.
Non consentire alle pipeline di deployment di leggere dati non necessari
Spesso le pipeline di deployment non hanno bisogno di accedere ai dati, ma potrebbero comunque averlo. Questa eccessiva concessione di accesso può essere causata da:
- Concessione di autorizzazioni di accesso errate. Ad esempio, a una pipeline di deployment potrebbe essere concesso l'accesso a Cloud Storage a livello di progetto. Di conseguenza, la pipeline di deployment può accedere a tutti i bucket Cloud Storage del progetto, anche se l'accesso a un singolo bucket potrebbe essere sufficiente.
- Utilizzo di un ruolo eccessivamente permissivo. A una pipeline di deployment potrebbe essere concesso un ruolo che fornisce l'accesso completo a Cloud Storage, ad esempio. Tuttavia, è sufficiente l'autorizzazione per creare nuovi bucket.
Più dati può accedere una pipeline, maggiore è il rischio che qualcuno o qualcosa possa rubare i tuoi dati. Per ridurre al minimo questo rischio, evita di concedere alle pipeline di deployment l'accesso a dati di cui non hanno bisogno. Molte pipeline di deployment non richiedono affatto l'accesso ai dati, perché il loro unico scopo è gestire la configurazione o i deployment del software.
Non consentire alle pipeline di deployment di scrivere in posizioni non necessarie
Per rimuovere i dati, un malintenzionato deve avere accesso e un modo per trasferirli al di fuori del tuo ambiente. Più sono le posizioni di archiviazione e di rete a cui una pipeline di deployment può inviare dati, più è probabile che un malintenzionato possa utilizzare una di queste posizioni per l'esfiltrazione.
Puoi contribuire a ridurre il rischio limitando il numero di località di rete e di archiviazione in cui una pipeline può inviare dati:
- Revoca l'accesso in scrittura alle risorse di cui la pipeline non ha bisogno, anche se le risorse non contengono dati riservati.
- Bloccare l'accesso a internet o limitare le connessioni a un insieme di località di rete elencate nella lista consentita.
La limitazione dell'accesso in uscita è particolarmente importante per le pipeline classificate come moderatamente riservate o altamente riservate perché hanno accesso a dati riservati o materiale di chiavi crittografiche.
Utilizza i Controlli di servizio VPC per contribuire a impedire ai deployment compromessi di rubare dati
Invece di consentire alla pipeline di deployment di eseguire l'esfiltrazione di dati, un malintenzionato potrebbe tentare di utilizzare la pipeline di deployment per eseguire il deployment di codice compromesso. Il codice compromesso può quindi rubare i dati all'interno del tuo ambiente Google Cloud.
Puoi contribuire a ridurre il rischio di queste minacce di furto di dati utilizzando Controlli di servizio VPC. I Controlli di servizio VPC ti consentono di limitare l'insieme di risorse e API a cui è possibile accedere da determinati progetti Google Cloud.
Mantenere l'integrità
Per mantenere l'ambiente Google Cloud protetto, devi proteggerne l'integrità. tra cui:
- Impedire la modifica o l'eliminazione non autorizzata di dati o configurazione
- Impedire il deployment di codice o configurazioni non attendibili
- Garantire che tutte le modifiche lascino un audit trail chiaro
Le pipeline di deployment possono aiutarti a mantenere l'integrità del tuo ambiente consentendoti di:
- Implementa procedure di approvazione, ad esempio sotto forma di revisioni del codice
- Applica una procedura coerente per tutte le modifiche alla configurazione o al codice
- Esegui test automatici o controlli rapidi prima di ogni deployment
Per essere efficace, devi cercare di assicurarti che i malintenzionati non possano aggirare o minare queste misure. Per impedire questo tipo di attività, devi proteggere l'integrità di:
- La pipeline di deployment e la relativa configurazione
- L'infrastruttura sottostante
- Tutti gli input consumati dalla pipeline di deployment
Per evitare che la pipeline di deployment diventi vulnerabile, cerca di assicurarti che gli standard di integrità della pipeline di deployment corrispondano o superino le richieste di integrità delle risorse che gestisce. Per determinare queste esigenze, puoi utilizzare il seguente approccio:
- Determina i dati, le applicazioni e le risorse a cui deve accedere la pipeline di deployment e classificali.
- Trova la risorsa con la categoria di integrità più alta e utilizzala come categoria per la pipeline di deployment.
Per mantenere l'integrità della pipeline di deployment, il modello Biba suggerisce di:
- La pipeline di deployment non deve utilizzare artefatti di input di integrità inferiore.
- La pipeline di deployment non deve scrivere dati in una risorsa di maggiore integrità.
In base al modello Biba, il diagramma precedente mostra come devono scorrere i dati nella pipeline per contribuire a garantire la loro integrità.
Verificare l'autenticità degli elementi di input
Molte pipeline di deployment utilizzano elementi provenienti da origini di terze parti. Questi elementi possono includere:
- Immagini di base Docker
.rpmo.deb- Librerie Maven,
.npmo NuGet
Un malintenzionato potrebbe tentare di modificare la pipeline di deployment in modo che utilizzi versioni compromesse di elementi di terze parti:
- Compromissione del repository che memorizza gli elementi
- Modifica della configurazione della pipeline di deployment per utilizzare un repository di origine diverso
- Caricamento di pacchetti dannosi con nomi simili o che contengono errori ortografici
Molti gestori pacchetti ti consentono di verificare l'autenticità di un pacchetto supportando la firma del codice. Ad esempio, puoi utilizzare PGP per firmare i pacchetti RPM e Maven. Puoi utilizzare Authenticode per firmare i pacchetti NuGet.
Puoi utilizzare la firma del codice per ridurre il rischio di diventare vittima di pacchetti di terze parti compromessi:
- Richiedere la firma di tutti gli elementi di terze parti
- Gestire un elenco selezionato di certificati o chiavi pubbliche di publisher attendibili
- Consentire alla pipeline di deployment di verificare la firma degli elementi di terze parti rispetto all'elenco di publisher attendibili
In alternativa, puoi verificare gli hash degli elementi. Puoi utilizzare questo approccio per gli elementi che non supportano la firma del codice e che cambiano raramente.
Assicurati che l'infrastruttura di base soddisfi le tue esigenze di integrità
I malintenzionati potrebbero tentare di compromettere l'infrastruttura della pipeline di deployment, ad esempio:
- Il software CI/CD che esegue la pipeline di deployment
- Gli strumenti utilizzati dalla pipeline, ad esempio Terraform, kubectl o Docker
- Il sistema operativo e tutti i suoi componenti
Poiché l'infrastruttura alla base delle pipeline di deployment è spesso complessa e potrebbe contenere componenti di vari fornitori o origini, questo tipo di violazione della sicurezza può essere difficile da rilevare.
Puoi contribuire a ridurre il rischio di compromissione dell'infrastruttura adottando le seguenti misure:
- Mantenimento dell'infrastruttura e di tutti i relativi componenti secondo gli stessi standard di integrità della pipeline di deployment e delle risorse Google Cloud che gestisce
- Assicurarsi che gli strumenti provengano da una fonte attendibile e verificarne l'autenticità
- Ricostruzione regolare dell'infrastruttura da zero
- Esecuzione della pipeline di deployment su VM isolate
Applica i controlli di integrità nella pipeline
Sebbene gli utenti malintenzionati rappresentino una minaccia, non sono l'unica possibile fonte di modifiche al software o alla configurazione che possono compromettere l'integrità del tuo ambiente Google Cloud. Queste modifiche possono anche essere apportate dagli sviluppatori e essere semplicemente accidentali, dovute a scarsa conoscenza o al risultato di errori ortografici e altri errori.
Puoi contribuire a ridurre il rischio di applicare inavvertitamente modifiche rischiose configurando le pipeline di deployment in modo da applicare controlli di integrità aggiuntivi. Questi controlli possono includere:
- Eseguire l'analisi statica del codice e della configurazione
- Richiedere che tutte le modifiche superino un insieme di regole (policy as code)
- Limitare il numero di modifiche che possono essere apportate contemporaneamente
Passaggi successivi
- Scopri le nostre best practice per utilizzare gli account di servizio nelle pipeline di deployment.
- Consulta le nostre best practice per la protezione degli account di servizio.
- Scopri di più su come indagare e rispondere alle minacce.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.