Una pipeline di deployment è un processo automatizzato che prende codice o artefatti predefiniti e ne esegue il deployment in un ambiente di test o di produzione. Le pipeline di deployment sono comunemente utilizzate per eseguire il deployment di applicazioni, configurazione o infrastruttura cloud (Infrastructure as Code) e possono svolgere un ruolo importante nella strategia di sicurezza complessiva di un deployment cloud.
Questa guida è rivolta a DevOps e ingegneri della sicurezza e descrive le best practice per la progettazione di pipeline di deployment sicure in base ai tuoi requisiti di riservatezza, integrità e disponibilità.
Architettura
Il seguente diagramma mostra il flusso di dati in una pipeline di deployment. Illustra come trasformare gli artefatti in risorse.
Le pipeline di deployment fanno spesso parte di un flusso di lavoro più ampio di integrazione continua/deployment continuo (CI/CD) e sono generalmente implementate utilizzando uno dei seguenti modelli:
Push del modello: in questo modello, implementi la pipeline di deployment utilizzando un sistema CI/CD centrale come Jenkins o GitLab. Questo sistema CI/CD può essere eseguito su Google Cloud, on-premise o in un ambiente cloud diverso. Spesso, lo stesso sistema CI/CD viene utilizzato per gestire più pipeline di deployment.
Il modello push porta a un'architettura centralizzata con alcuni sistemi CI/CD che vengono utilizzati per gestire un numero potenzialmente elevato di risorse o applicazioni. Ad esempio, potresti utilizzare una singola istanza Jenkins o GitLab per gestire l'intero ambiente di produzione, inclusi tutti i relativi progetti e applicazioni.
Modello pull: in questo modello, il processo di deployment è implementato da un agente il cui deployment viene eseguito insieme alla risorsa, ad esempio nello stesso cluster Kubernetes. L'agente estrae artefatti o codice sorgente da una posizione centralizzata e ne esegue il deployment localmente. Ogni agente gestisce una o due risorse.
Il modello pull porta a un'architettura più decentralizzata con un numero potenzialmente elevato di agenti a uso specifico.
Rispetto ai deployment manuali, l'utilizzo coerente delle pipeline di deployment può offrire i seguenti vantaggi:
- Maggiore efficienza, in quanto non è richiesto alcun lavoro manuale.
- Maggiore affidabilità, perché il processo è completamente automatizzato e ripetibile.
- Maggiore tracciabilità, poiché puoi tracciare tutti i deployment per rilevare eventuali modifiche al codice o artefatti di input.
Per l'esecuzione, una pipeline di deployment richiede l'accesso alle risorse che gestisce:
- Una pipeline che esegue il deployment dell'infrastruttura utilizzando strumenti come Terraform potrebbe richiedere la creazione, la modifica o l'eliminazione di risorse come istanze VM, subnet o bucket Cloud Storage.
- Una pipeline che esegue il deployment delle applicazioni potrebbe dover caricare nuove immagini container 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 dei file di configurazione potrebbe dover modificare i metadati dell'istanza VM, le configurazioni di Kubernetes o modificare i dati in Cloud Storage.
Se le pipeline di deployment non sono protette in modo adeguato, il loro accesso alle risorse Google Cloud può diventare un punto debole nella tua strategia di sicurezza. Un indebolimento della sicurezza può portare a diversi tipi di attacchi, tra cui:
Attacchi di avvelenamento da tubazioni: anziché attaccare direttamente una risorsa, un utente malintenzionato potrebbe tentare di compromettere la pipeline di deployment, la configurazione o l'infrastruttura sottostante. Sfruttando l'accesso della pipeline a Google Cloud, il malintenzionato potrebbe far eseguire alla pipeline azioni dannose sulle risorse Cloud, come mostrato nel diagramma seguente:
Attacchi alla catena di fornitura: anziché attaccare la pipeline di deployment, un utente malintenzionato potrebbe tentare di compromettere o sostituire l'input della pipeline, tra cui codice sorgente, librerie o immagini container, come mostrato nel seguente schema:
Per determinare se le pipeline di deployment sono protette in modo appropriato, non è sufficiente esaminare solo i criteri di autorizzazione e quelli di negazione delle risorse Google Cloud in modo isolato. Devi invece considerare l'intero grafico 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 del codice sorgente, i server sottostanti e l'infrastruttura sottostante
- Artefatti di input, relative posizioni di archiviazione e infrastruttura sottostante
- I sistemi che producono gli artefatti di input e la loro infrastruttura sottostante
Grafici di input complessi rendono difficile l'identificazione dell'accesso degli utenti alle risorse e le debolezze sistemiche.
Le seguenti sezioni descrivono le best practice per la progettazione di pipeline di deployment in modo da gestire le dimensioni del grafico e ridurre il rischio di attacchi di spostamento laterale e attacchi alla catena di fornitura.
Valutare gli obiettivi di sicurezza
È probabile che le risorse su Google Cloud varino in termini di sensibilità. Alcune risorse potrebbero essere altamente sensibili perché sono fondamentali 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 deve accedere la pipeline e quanto sono sensibili. Più le risorse sono sensibili, più dovresti 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, come oggetti Cloud Storage, record BigQuery o file
Alcune di queste risorse potrebbero avere dipendenze da altre risorse, ad esempio:
- Le applicazioni potrebbero accedere a dati, risorse cloud e altre applicazioni.
Le risorse cloud, come le istanze VM o i 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 l'applicazione dovrebbe essere trattata come altamente sensibile. Analogamente, se una risorsa cloud come un bucket Cloud Storage contiene dati sensibili, in genere il bucket deve essere considerato sensibile.
A causa di queste dipendenze, ti consigliamo di valutare innanzitutto la sensibilità dei dati. Dopo aver valutato i dati, puoi esaminare la catena di dipendenze 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, considera 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 obiettivi, chiediti che cosa accadrebbe se la tua pipeline venisse violata:
- Riservatezza: quanto sarebbe dannoso se i dati fossero divulgati a un malintenzionato o divulgati al pubblico?
- Integrità: quanto sarebbe dannoso se i dati fossero stati modificati o eliminati da un utente malintenzionato?
- Disponibilità: quanto sarebbe dannoso se un utente malintenzionato interrompesse l'accesso ai tuoi dati?
Per rendere i risultati comparabili tra le risorse, è utile introdurre le categorie di sicurezza. Standards for Security Categorization (FIPS-199) consiglia di utilizzare le quattro categorie seguenti:
- Elevato:danni 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 delle pipeline rientrano in un ambito specifico, in base alle categorie di sicurezza appena descritte. Le seguenti sottosezioni contengono esempi di risorse con diverse misurazioni di riservatezza e integrità:
Risorse con bassa riservatezza, ma integrità bassa, moderata e alta
I seguenti esempi di risorse presentano tutti una scarsa riservatezza:
- Integrità bassa: dati di test
- Integrità moderata: contenuti del server web pubblico, vincoli dei criteri per la tua organizzazione
- Alta integrità: immagini container, immagini disco, configurazioni di applicazioni, criteri di accesso (liste consentite e bloccate), blocchi, dati a livello di accesso
Risorse con riservatezza media, ma integrità bassa, moderata e alta
Gli esempi di risorse seguenti hanno tutti una riservatezza media:
- Integrità bassa: contenuti del server web interno
- Integrità moderata: audit log
- Integrità elevata: file di configurazione dell'applicazione
Risorse con elevata riservatezza, ma integrità bassa, moderata e elevata
Gli esempi di risorse riportati di seguito sono tutti con un livello di riservatezza elevato:
- Bassa integrità: dati sull'utilizzo e informazioni che consentono l'identificazione personale
- Integrità moderata: secret
- Integrità elevata: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 qualificare questa sensibilità, esamina i dati a cui l'applicazione e la pipeline devono accedere.
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 tra i dati a cui si ha accesso
- Integrità: la categoria più alta tra i dati a cui si ha accesso
- Disponibilità: la categoria più alta di tutti i dati a cui si ha accesso
Questa valutazione iniziale fornisce indicazioni, ma potrebbero esserci ulteriori fattori da considerare, ad esempio:
- Due set di dati potrebbero essere isolati con una scarsa riservatezza. Ma, una volta combinati, potrebbero rivelare nuove informazioni. Se un'applicazione ha accesso a entrambi i set di dati, potrebbe essere necessario categorizzarla con riservatezza media o elevata.
- Se un'applicazione ha accesso a dati ad alta integrità, in genere è consigliabile classificarla come ad alta integrità. Tuttavia, se questo accesso è di sola lettura, una classificazione ad alta integrità potrebbe essere troppo rigorosa.
Per i dettagli su un approccio formale per classificare le applicazioni, consulta la Guida per la mappatura di tipi di sistemi informatici e informatici 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 può essere ospitata da un servizio App Engine, un'istanza VM o un cluster GKE.
- I dati potrebbero essere ospitati da un disco permanente, da un bucket Cloud Storage o da un set di dati BigQuery.
Quando una risorsa cloud ospita applicazioni o dati sensibili, anche la risorsa e la pipeline di deployment che la gestisce possono diventare sensibili. Ad esempio, dovresti considerare un servizio Cloud Run e la sua pipeline di deployment sensibili quanto l'applicazione che ospita.
Dopo aver classificato i dati e le applicazioni, crea una categoria di sicurezza iniziale per l'applicazione. A questo scopo, determina un livello dalle seguenti categorie:
- Riservatezza: la categoria più alta tra quelle in hosting su dati o applicazioni
- Integrità: la categoria più alta tra tutte quelle in hosting sui dati o sulle applicazioni
- Disponibilità: la categoria più alta di tutti i dati o le applicazioni in hosting
Quando effettui la valutazione iniziale, non essere troppo rigoroso, ad esempio:
- Se cripti dati altamente riservati, considera la chiave di crittografia estremamente riservata. Tuttavia, puoi utilizzare una categoria di sicurezza inferiore per la risorsa contenente i dati.
- Se archivi copie ridondanti di dati o esegui istanze ridondanti delle stesse applicazioni su più risorse, puoi ridurre la categoria della risorsa rispetto a quella dei dati o dell'applicazione che ospita.
Vincola l'uso delle pipeline di deployment
Se la tua pipeline di deployment deve accedere a risorse sensibili di Google Cloud, devi valutare la sua strategia di sicurezza. Più le risorse sono sensibili, migliore sarà il tentativo di proteggere la pipeline. Tuttavia, è possibile che si verifichino le seguenti limitazioni pratiche:
- Quando utilizzi un'infrastruttura esistente o un sistema CI/CD esistente, l'infrastruttura potrebbe limitare il livello di sicurezza che puoi realisticamente raggiungere. Ad esempio, il tuo sistema CI/CD potrebbe supportare solo un insieme limitato di controlli di sicurezza o essere in esecuzione su un'infrastruttura che consideri meno sicura di alcuni dei tuoi ambienti di produzione.
- Durante la configurazione di nuove infrastrutture e sistemi per eseguire la pipeline di deployment, la protezione di tutti i componenti in modo che soddisfi i requisiti di sicurezza più severi potrebbe non essere conveniente.
Per gestire queste limitazioni, può essere utile impostare vincoli su quali scenari dovrebbero e non dovrebbero utilizzare le pipeline di deployment e un particolare sistema CI/CD. Ad esempio, i deployment più sensibili sono spesso gestiti meglio al di fuori di una pipeline di deployment. Questi deployment possono essere manuali, utilizzando un sistema di gestione delle sessioni con privilegi o un sistema di gestione degli accessi con privilegi o qualcos'altro, come i proxy degli strumenti.
Per impostare i vincoli, definisci i controlli di accesso da applicare in base alle categorie di risorse. Considera le indicazioni fornite nella seguente tabella:
| Categoria della risorsa | Controlli di accesso |
|---|---|
| Bassa | Nessuna approvazione necessaria |
| Moderata | Il responsabile del team deve approvare |
| Alta | È necessario approvare più lead e registrare le azioni |
Confronta questi requisiti con le funzionalità dei tuoi sistemi di gestione del codice sorgente (SCM) e CI/CD ponendo le seguenti domande e altro ancora:
- I tuoi sistemi SCM o CI/CD supportano i controlli dell'accesso e i meccanismi di approvazione necessari?
- I controlli sono protetti dalla sovvertenza se i malintenzionati attaccano l'infrastruttura sottostante?
- 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 a dati e applicazioni per le pipeline di deployment. Tieni in considerazione le indicazioni fornite nella seguente tabella:
| Categoria della risorsa | Vincoli |
|---|---|
| Bassa | È possibile utilizzare le pipeline di deployment e gli sviluppatori possono autoapprovare i deployment. |
| Moderata | È possibile usare 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 con privilegi e la registrazione delle sessioni. |
Mantieni la disponibilità delle risorse
L'utilizzo di una pipeline di deployment per gestire le risorse può influire sulla loro disponibilità e introdurre nuovi rischi:
- Causa interruzioni: una pipeline di deployment potrebbe inviare file di codice o di configurazione errati, causando l'interruzione di un sistema precedentemente funzionante o i dati inutilizzabili.
- Prolungamento delle interruzioni: per risolvere un'interruzione, potresti dover rieseguire una pipeline di deployment. Se la pipeline di deployment non funziona o non è disponibile per altri motivi, l'interruzione potrebbe prolungarsi.
Una pipeline che può causare o prolungare le interruzioni, comporta un rischio di tipo denial of service: un malintenzionato potrebbe utilizzare la pipeline di deployment per causare intenzionalmente un'interruzione.
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 una risorsa, la disponibilità della pipeline può diventare fondamentale. Nei casi estremi, in cui una pipeline di deployment è l'unico modo per gestire un'applicazione business-critical, potrebbe anche essere necessario considerare la pipeline di deployment business-critical.
Poiché le pipeline di deployment sono spesso costituite da più sistemi e strumenti, mantenere un livello elevato di disponibilità può essere difficile o antieconomico.
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 possa essere utilizzato se la pipeline di deployment non è operativa.
La creazione di una procedura di accesso di emergenza richiede in genere la maggior parte dei seguenti processi:
- Gestisci uno o più account utente con accesso privilegiato alle risorse Google Cloud pertinenti.
- Archivia le credenziali degli account utente con accesso di emergenza in un luogo sicuro o utilizza un sistema di gestione degli accessi con privilegi per brokerare l'accesso.
- Stabilisci una procedura che i dipendenti autorizzati possano seguire per accedere alle credenziali.
- Controlla ed esamina l'utilizzo degli account utente con accesso di emergenza.
Assicurati che gli artefatti di input soddisfino le tue esigenze di disponibilità
In genere, le pipeline di deployment devono scaricare il codice sorgente da un repository centrale del 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 artefatti di terze parti. Tali artefatti potrebbero includere librerie da origini come npm, Maven Central o NuGet Gallery, nonché immagini di base container 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 artefatti di input della pipeline di deployment soddisfino tutti gli stessi requisiti di disponibilità uguali o superiori. Il seguente elenco può aiutarti ad assicurare la disponibilità degli artefatti di input:
- Limita il numero di origini per gli artefatti di input, in particolare per le origini di terze parti
- Conserva una cache di artefatti di input che le pipeline di deployment possono utilizzare se i sistemi di origine non sono disponibili
Tratta le pipeline di deployment e la loro infrastruttura come sistemi di produzione
Le pipeline di deployment spesso fungono da tessuto connettivo tra ambienti di sviluppo, gestione temporanea e produzione. A seconda dell'ambiente, potrebbero implementare più fasi:
- Nella prima fase, la pipeline di deployment aggiorna un ambiente di sviluppo.
- Nella fase successiva, la pipeline di deployment aggiorna un ambiente di gestione temporanea.
- 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 ogni ambiente. Poiché gli ambienti di produzione hanno in genere le esigenze di disponibilità più elevate, dovresti trattare la pipeline di deployment e l'infrastruttura sottostante 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 applichi all'infrastruttura che utilizzi per i sistemi di produzione.
Limita l'ambito delle pipeline di deployment
Maggiore è il numero di risorse a cui una pipeline di deployment può accedere, maggiori sono i danni che può causare se compromessa. Una pipeline di deployment compromessa che ha accesso a più progetti o anche all'intera organizzazione potrebbe, nel peggiore dei casi, causare danni duraturi a tutti i tuoi dati e alle tue 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 abbia accesso solo a un numero relativamente ridotto di risorse su Google Cloud:
- Anziché concedere l'accesso a livello di progetto, concedi l'accesso alle pipeline di deployment 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 i passaggi 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.
Un utente malintenzionato può tentare di utilizzare una pipeline di deployment per esfiltrare i dati dalle tue risorse Google Cloud in diversi modi. Ad esempio:
- Diretto: un utente malintenzionato potrebbe modificare la pipeline di deployment o la sua configurazione in modo da estrarre i dati dalle risorse Google Cloud e poi copiarli altrove.
- Indiretto: un utente malintenzionato potrebbe utilizzare la pipeline di deployment per eseguire il deployment di codice compromesso, che a sua volta ruba i dati dal tuo ambiente Google Cloud.
Puoi ridurre i rischi di riservatezza riducendo al minimo l'accesso alle risorse riservate. Tuttavia, rimuovere completamente l'accesso alle risorse riservate potrebbe non essere pratico. Pertanto, devi progettare la pipeline di deployment in modo da soddisfare le esigenze di riservatezza delle risorse che gestisce. Per determinare queste domande, puoi utilizzare il seguente approccio:
- Determinare i dati, le applicazioni e le risorse a cui la pipeline di deployment deve accedere e classificarli.
- Trova la risorsa con la categoria di riservatezza più alta e utilizzala come categoria iniziale per la pipeline di deployment.
Analogamente al processo 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 contengono informazioni altamente riservate. Se limiti la pipeline di deployment in modo che possa creare queste risorse, ma non può leggerle, potrebbe essere sufficiente una categoria di riservatezza inferiore.
Per mantenere la riservatezza, il modello Bell-LaPadula consiglia che una pipeline di deployment non deve:
- Utilizza artefatti di input di maggiore riservatezza
- Scrivere dati in una risorsa con minore riservatezza
Secondo il modello Bell-LaPadula, il diagramma precedente mostra come i dati devono scorrere nella pipeline per garantirne la riservatezza.
Non consentire alle pipeline di deployment di leggere i dati di cui non hanno bisogno
Le pipeline di deployment spesso non hanno bisogno di accedere ai dati, ma potrebbero ancora averne. Questa concessione eccessiva di accesso può derivare 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. Ad esempio, a una pipeline di deployment può essere assegnato un ruolo che fornisce accesso completo a Cloud Storage. Tuttavia, sarebbe sufficiente l'autorizzazione per creare nuovi bucket.
Maggiore è il numero di dati a cui una pipeline può accedere, 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 non necessari. Molte pipeline di deployment non richiedono in alcun modo l'accesso ai dati, poiché il loro unico scopo è gestire la configurazione o i deployment del software.
Non lasciare che le pipeline di deployment scrivano in località non necessarie
Per rimuovere i dati, un utente malintenzionato ha bisogno dell'accesso e di un modo per trasferirli al di fuori del tuo ambiente. Maggiore è il numero di posizioni di archiviazione e rete a cui una pipeline di deployment può inviare dati, maggiore è la probabilità che un utente malintenzionato possa utilizzare una di queste posizioni per l'esfiltrazione.
Puoi ridurre i rischi limitando il numero di località di rete e di archiviazione dove una pipeline può inviare dati:
- Revoca l'accesso in scrittura alle risorse non necessarie per la pipeline, anche se le risorse non contengono dati riservati.
- Blocca l'accesso a internet o limita le connessioni a un insieme di posizioni di rete nella lista consentita.
La limitazione dell'accesso in uscita è particolarmente importante per le pipeline che hai classificato come moderatamente o altamente confidenziale perché hanno accesso a dati riservati o materiale delle chiavi di crittografia.
Utilizza i Controlli di servizio VPC per impedire ai deployment compromessi di sottrarre dati
Invece di lasciare che la pipeline di deployment esegua l'esfiltrazione di dati, un utente malintenzionato potrebbe tentare di utilizzare la pipeline di deployment per eseguire il deployment di codice compromesso. Il codice compromesso può quindi rubare i dati dal tuo ambiente Google Cloud.
Puoi ridurre il rischio di queste minacce di furto di dati utilizzando Controlli di servizio VPC. I Controlli di servizio VPC consentono di limitare l'insieme di risorse e API a cui è possibile accedere da determinati progetti Google Cloud.
Mantenere l'integrità
Per proteggere il tuo ambiente Google Cloud, devi proteggerne l'integrità. Ciò include:
- Impedire la modifica o l'eliminazione non autorizzata di dati o configurazioni
- Impedire il deployment di configurazioni o codice non attendibili
- Assicurarsi che tutte le modifiche lascino un audit trail chiaro
Le pipeline di deployment possono aiutarti a mantenere l'integrità dell'ambiente offrendoti:
- Implementare processi di approvazione, ad esempio sotto forma di revisioni del codice
- Applica un processo 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 garantire che i malintenzionati non possano minare o aggirare queste misure. Per impedire tali attività, devi proteggere l'integrità dei seguenti elementi:
- La pipeline di deployment e la sua configurazione
- L'infrastruttura sottostante
- Tutti gli input utilizzati dalla pipeline di deployment
Per evitare che la pipeline di deployment diventi vulnerabile, prova a garantire che gli standard di integrità della pipeline di deployment corrispondano o superino le richieste di integrità delle risorse che gestisce. Per determinare queste richieste, puoi utilizzare il seguente approccio:
- Determinare i dati, le applicazioni e le risorse a cui la pipeline di deployment deve accedere e classificarli.
- 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 consiglia che:
- La pipeline di deployment non deve consumare artefatti di input con una minore integrità.
- La pipeline di deployment non deve scrivere dati in una risorsa con maggiore integrità.
Secondo il modello Biba, il diagramma precedente mostra come devono scorrere i dati nella pipeline per garantirne l'integrità.
Verificare l'autenticità degli artefatti di input
Molte pipeline di deployment consumano artefatti di origini di terze parti. Tali artefatti potrebbero includere:
- Immagini di base Docker
.rpmo.debpacchetti- Librerie Maven,
.npmo NuGet
Un utente malintenzionato potrebbe tentare di modificare la pipeline di deployment in modo da utilizzare versioni compromesse degli artefatti di terze parti:
- Compromettere il repository in cui sono archiviati gli artefatti
- Modificare la configurazione della pipeline di deployment per utilizzare un repository di origine diverso
- Caricamento di pacchetti dannosi con nomi simili o contenenti errori di battitura.
Molti gestori di pacchetti 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 pacchetti NuGet.
Puoi utilizzare la firma del codice per ridurre il rischio di rimanere vittima di pacchetti di terze parti compromessi:
- Richiedere che tutti gli elementi di terze parti siano firmati
- Gestire un elenco selezionato di chiavi pubbliche o certificati di publisher attendibili
- Consentire alla pipeline di deployment di verificare la firma degli artefatti di terze parti rispetto all'elenco di publisher attendibili
In alternativa, puoi verificare gli hash degli artefatti. Puoi utilizzare questo approccio per gli artefatti che non supportano la firma del codice e non cambiano di frequente.
Assicurati che l'infrastruttura sottostante soddisfi le tue esigenze di integrità
Anziché compromettere la pipeline di deployment stessa, i malintenzionati potrebbero tentare di comprometterne l'infrastruttura, 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 infrastruttura compromessa:
- Mantenere l'infrastruttura e tutti i suoi componenti con gli stessi standard di integrità della pipeline di deployment e delle risorse Google Cloud che gestisce
- Assicurarsi che gli strumenti provengano da una fonte affidabile e verificarne l'autenticità
- Ricreando regolarmente l'infrastruttura da zero
- Esecuzione della pipeline di deployment su shielded VM
Applica i controlli di integrità nella pipeline
Sebbene i malintenzionati rappresentino una minaccia, non sono l'unica fonte possibile di modifiche al software o alla configurazione che possono compromettere l'integrità dell'ambiente Google Cloud. Queste modifiche possono anche provenire dagli sviluppatori ed essere semplicemente involontarie, a causa della mancanza di consapevolezza o del risultato di errori di battitura e altri errori.
Puoi ridurre il rischio di applicare inavvertitamente modifiche rischiose configurando le pipeline di deployment per applicare controlli dell'integrità aggiuntivi. Questi controlli possono includere:
- Esecuzione dell'analisi statica del codice e della configurazione
- Richiedere tutte le modifiche per passare una serie di regole (criterio come codice)
- 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 analisi e risposta alle minacce.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.