Proteggere Azure Pipelines

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Le pipeline offrono potenti funzionalità per l'esecuzione di script e la distribuzione di codice negli ambienti di produzione, ma è fondamentale bilanciare questa potenza con la sicurezza. Non si vuole mai che una pipeline diventi un canale per codice dannoso. Bilanciare la sicurezza con la flessibilità e il potere necessari per i team di sviluppo è essenziale.

Questo articolo offre una panoramica delle configurazioni necessarie relative alla sicurezza per proteggere le pipeline da minacce e vulnerabilità.

Prerequisiti

Limitare l'accesso a progetti, repository e connessioni ai servizi

Per migliorare la sicurezza, considerare la separazione dei progetti, l'uso delle politiche di branch e l'aggiunta di ulteriori misure di sicurezza per i fork. Ridurre al minimo l'ambito delle connessioni al servizio e usare i metodi di autenticazione più sicuri.

• Progetti separati: gestire ogni prodotto e team in progetti separati. Ciò impedisce alle pipeline di un prodotto di accedere involontariamente alle risorse aperte da un altro prodotto, riducendo al minimo l'esposizione laterale.
• Usare le identità a livello di progetto: usare un'identità di compilazione basata su progetto per le pipeline anziché un'identità a livello di raccolta. Le identità a livello di progetto possono accedere solo alle risorse all'interno del progetto associato, riducendo al minimo il rischio di accesso non autorizzato da parte di utenti malintenzionati. Per altre informazioni, vedere identità di build con ambito e ambito di autorizzazione del lavoro.
• Usare i criteri di ramo: per garantire modifiche sicure al codice e alla pipeline, applicare autorizzazioni e criteri di ramo. Prendere in considerazione anche l'aggiunta di autorizzazioni e controlli della pipeline ai repository.
• Aggiungere ulteriore sicurezza per i fork: quando si lavora con repository pubblici da GitHub, prendere in considerazione con attenzione l'approccio ai build dei fork. I fork provenienti dall'esterno dell'organizzazione rappresentano rischi specifici.
  • Non fornire segreti alle compilazioni fork: per impostazione predefinita, le pipeline sono configurate per la compilazione di fork, ma i segreti e le risorse protette non vengono esposti automaticamente ai processi in tali pipeline. È essenziale non disabilitare questa protezione per mantenere la sicurezza.
  • Prendere in considerazione l'attivazione manuale delle compilazioni fork: disattivare le compilazioni automatiche del fork e usare i commenti dei pull request per compilare manualmente questi contributi. Questa impostazione consente di esaminare il codice prima di attivare una compilazione. Per altre informazioni, vedere Disattivare le compilazioni automatiche del fork.
  • Non fornire segreti alle compilazioni fork: per impostazione predefinita, i segreti associati alla pipeline non vengono resi disponibili per le convalide delle richieste pull dei fork. Non abilitare l'opzione Rendi i segreti disponibili per le compilazioni di fork. Per istruzioni su come trovare e verificare questa impostazione, vedere Contributi dai fork.
  • Prendere in considerazione l'attivazione manuale delle compilazioni fork: disattivare le compilazioni automatiche del fork e usare i commenti dei pull request per compilare manualmente questi contributi. Questa impostazione consente di esaminare il codice prima di attivare una compilazione. Per istruzioni su come eseguire questa operazione, vedere Disattivare le compilazioni fork automatiche.
  • Usare agenti ospitati da Microsoft per le compilazioni fork: evitare di eseguire compilazioni da fork su agenti self-hosted. In questo modo, le organizzazioni esterne possono eseguire codice esterno nei computer all'interno della rete aziendale. Quando possibile, usare gli agenti ospitati da Microsoft.
  • Usare l'app GitHub azure Pipelines per la limitazione dell'ambito del token: quando si compila una richiesta pull tramite fork di GitHub, Azure Pipelines garantisce che la pipeline non possa modificare alcun contenuto del repository GitHub. Questa restrizione si applica solo se si usa l'app GitHub Azure Pipelines per l'integrazione con GitHub.

Proteggere le connessioni al servizio

• Ridurre al minimo l'ambito delle connessioni al servizio: le connessioni al servizio devono avere accesso solo alle risorse necessarie. Quando si crea una nuova connessione al servizio Azure Resource Manager, scegliere sempre un gruppo di risorse specifico. Assicurarsi che il gruppo di risorse contenga solo le macchine virtuali o le risorse necessarie per la compilazione. Per istruzioni su come configurare le connessioni al servizio, vedere Usare una connessione al servizio Azure Resource Manager.
• Usare la federazione dell'identità del carico di lavoro per l'autenticazione: quando possibile, usare la federazione dell'identità del carico di lavoro anziché un'entità servizio per la connessione al servizio di Azure. La federazione delle identità del carico di lavoro usa Open ID Connect (OIDC), una tecnologia standard del settore, per facilitare l'autenticazione tra Azure e Azure DevOps senza basarsi sui segreti. Per istruzioni su come eseguire questa operazione, vedere Creare una connessione al servizio con la federazione delle identità di workload (automatica).
• Ridurre al minimo l'accesso all'app GitHub: quando si configura l'app GitHub in Azure DevOps, concedere l'accesso solo ai repository che si intende compilare usando le pipeline.

Usare le pipeline YAML invece delle pipeline classiche

Per una maggiore sicurezza e per ridurre il rischio di errori di configurazione accidentali, usare le pipeline YAML anziché le pipeline classiche. Questa precauzione impedisce un problema di sicurezza derivante da YAML e pipeline classiche che condividono le stesse risorse, ad esempio le connessioni al servizio. Se l'organizzazione usa pipeline classiche, eseguire la migrazione delle pipeline a YAML.

• YAML offre i vantaggi dell'infrastruttura come codice: trattare le pipeline YAML come qualsiasi altro codice perché i passaggi e le dipendenze sono definiti nel codice. Esiste anche una chiara visibilità delle configurazioni della pipeline e un rischio ridotto di errori di configurazione accidentali.
• Le pipeline YAML possono essere combinate con misure di sicurezza avanzate: tramite revisioni del codice e richieste pull, usare i criteri di ramo per configurare un processo di revisione per le richieste pull per evitare operazioni di merge non valide.
• Gestione degli accessi alle risorse: i proprietari delle risorse controllano se una pipeline YAML può accedere a risorse specifiche. Questa funzionalità di sicurezza impedisce attacchi come il furto di un altro repository. Usare Approvazioni e controlli per fornire il controllo di accesso per ogni esecuzione di una pipeline.
  • Controllo del ramo protetto: se sono presenti processi di revisione del codice manuali per rami specifici, è possibile estendere questa protezione alle pipeline. Un controllo del ramo protetto per una risorsa impedisce l'esecuzione automatica delle pipeline in rami non autorizzati.
  • Controllo di approvazione manuale: usare un controllo di approvazione manuale per bloccare le richieste della pipeline dall'uso di una risorsa protetta fino all'approvazione manuale da parte di utenti o gruppi specificati.
  • Controllo orario di ufficio: usare questo controllo per assicurarsi che una distribuzione della pipeline venga avviata entro un intervallo di tempo e un giorno specificato.
• Disabilitare la creazione di pipeline classiche: Disabilitare in modo indipendente la creazione di pipeline di compilazione classiche e di rilascio classiche. Quando entrambi sono disabilitati, non è possibile creare pipeline di compilazione classica, pipeline di versione classica, gruppi di attività o gruppi di distribuzione tramite l'interfaccia utente o l'API REST. Per altre informazioni, vedere Disabilitare la creazione di pipeline classiche.

Agenti sicuri

Per proteggere i contenitori, contrassegnare i volumi come di sola lettura, impostare i limiti delle risorse, usare immagini attendibili, analizzare le vulnerabilità e applicare i criteri di sicurezza.

• Usare gli agenti ospitati da Microsoft anziché gli agenti self-hosted: gli agenti ospitati da Microsoft offrono isolamento e una macchina virtuale pulita per ogni esecuzione di una pipeline. Usare agenti ospitati da Microsoft anziché agenti ospitati autonomamente. Per altre informazioni, vedere Agenti ospitati da Microsoft.
• Agenti separati per ogni progetto: per attenuare lo spostamento laterale e prevenire la contaminazione incrociata tra progetti, mantenere pool di agenti separati, ognuno dedicato a un progetto specifico.
• Usare account con privilegi limitati per eseguire agenti: per migliorare la sicurezza del sistema, utilizzare un account con il minor numero di privilegi per l'esecuzione di agenti self-hosted. Considera, ad esempio, l'uso del tuo account macchina o di un'identità di servizio gestita. Non eseguire un agente con un'identità con accesso diretto alle risorse di Azure DevOps.
• Isolare gli artefatti di produzione e i pool di agenti sensibili: usare pool di agenti diversi per evitare problemi di sicurezza.
  • Usare un pool di agenti separato per gli artefatti di produzione: isolare gli artefatti di produzione usando un pool di agenti distinto, impedendo distribuzioni accidentali da rami non di produzione.
  • Segmentare i pool sensibili: Creare pool separati per carichi di lavoro sensibili e senza distinzione. Autorizzare solo le credenziali nelle definizioni di compilazione associate al pool appropriato.
• Configurare firewall restrittivi per gli agenti self-hosted: configurare i firewall in modo che siano il più restrittivi possibile, consentendo comunque agli agenti di funzionare, bilanciando la sicurezza e l'usabilità.
• Aggiornare regolarmente i pool di agenti self-hosted: mantenere aggiornati gli agenti self-hosted con aggiornamenti regolari per garantire che il codice vulnerabile non sia in esecuzione, riducendo il rischio di sfruttamento.

Usare in modo sicuro variabili e parametri

Usare in modo sicuro variabili e parametri nelle pipeline seguendo le procedure consigliate per l'impostazione dei segreti. Le migliori pratiche includono la limitazione dell'uso dei segreti, l'utilizzo delle variabili al momento della coda, e l'abilitazione della convalida degli argomenti nei task shell per proteggere la pipeline da minacce e vulnerabilità.

• Limitare l'accesso ai segreti: rimuovere eventuali segreti o chiavi dalla visualizzazione nelle pipeline. Passare a metodi di autenticazione senza segreti, ad esempio la federazione dell'identità del carico di lavoro o impostare segreti nell'interfaccia utente, in un gruppo di variabili o in un gruppo di variabili originato da Azure Key Vault.
• Abilita la convalida dei parametri della shell: quando l'impostazione Abilita la convalida dei parametri degli argomenti delle attività della shell è abilitata, è presente un controllo aggiunto per i caratteri come punti e virgola, virgolette e parentesi. Attivare Abilita la convalida dei parametri degli argomenti delle attività della shell a livello di organizzazione o progetto sotto Impostazioni>Pipeline>Impostazioni.
• Limitare le variabili che possono essere impostate in fase di coda: impedire agli utenti di definire nuove variabili in fase di coda abilitando l'impostazione delle variabili limite che possono essere impostate in fase di coda in Impostazioni pipeline dell'organizzazione>>.
• Usare parametri anziché variabili: a differenza delle variabili, una pipeline in esecuzione non può modificare i parametri della pipeline. I parametri hanno tipi di dati, number ad esempio e string, e possono essere limitati a subset di valori specifici. Questa restrizione è utile quando un aspetto configurabile dall'utente della pipeline deve accettare solo valori da un elenco predefinito, assicurandosi che la pipeline non accetti dati arbitrari.
• Segreti di riferimento dai modelli: invece di includere script inline con parametri segreti direttamente nella pipeline YAML, usare i modelli per astrarre le informazioni riservate lontano dalla pipeline principale. Per implementare questo approccio, creare un file YAML separato per lo script e quindi archiviare lo script in un repository separato e sicuro. È quindi possibile fare riferimento al modello e passare una variabile privata nel file YAML come parametro. La variabile sicura deve provenire da Azure Key Vault, da un gruppo di variabili o dall'interfaccia utente della pipeline. Per altre informazioni, vedere Usare i modelli.
• Limitare i segreti con i criteri di ramo e le autorizzazioni per i gruppi di variabili: è possibile usare una combinazione di autorizzazioni per i gruppi di variabili, inserimento condizionale di processi e criteri di ramo per garantire che i segreti siano legati al main ramo. Per altre informazioni, vedere Proteggere i segreti.
• Usare setvariable per limitare le variabili di impostazione: usare l'attributo settableVariables per configurare le variabili che gli autori di pipeline possono impostare in una pipeline. Senza questa impostazione, gli autori della pipeline possono dichiarare nuove variabili illimitate con il setvariable comando di registrazione. Quando si specifica un elenco with settableVariablesvuoto, l'impostazione di tutte le variabili non è consentita. Per altre informazioni, vedere l'attributosettableVariables nello schema YAML.

Il metodo migliore per proteggere un segreto è non avere un segreto al primo posto. Evitare di usare segreti quando possibile, non archiviarli mai nei file YAML e assicurarsi che non vengano registrati o stampati per mantenere la sicurezza.

• Evitare di usare segreti quando possibile: verificare se la pipeline può usare un metodo diverso rispetto all'uso di un segreto per eseguire un'attività, ad esempio una connessione al servizio con la federazione dell'identità del carico di lavoro o un'identità gestita. Le identità gestite consentono alle applicazioni e ai servizi di eseguire l'autenticazione con Azure senza richiedere credenziali esplicite. Per ulteriori informazioni, consulta Utilizzare i principali del servizio e le identità gestite. Non inserire segreti in YAML: non archiviare mai i valori sensibili come testo non crittografato in un file di Azure Pipelines .yml .
• Non registrare o stampare segreti: evitare di visualizzare i segreti nella console, di usarli nei parametri della riga di comando o di salvarli nei file. Azure Pipelines tenta di eseguire lo scrub dei segreti dai log laddove possibile, ma non riesce a intercettare ogni modo in cui i segreti possono essere persi.
• Non usare dati strutturati come JSON come segreti: creare singoli segreti per ogni valore sensibile. Questo approccio garantisce una migliore accuratezza dell'azione e riduce al minimo il rischio di esporre i dati sensibili inavvertitamente.

Controllare e ruotare i segreti

Per proteggere le pipeline, controllare regolarmente la gestione dei segreti nelle attività e nei log, esaminare e rimuovere segreti non necessari e ruotare i segreti per ridurre al minimo i rischi per la sicurezza.

• Controlla la gestione dei segreti nelle attività e nei log: controlla le attività per assicurarsi che i segreti non vengano inviati agli host o stampati nei log. Verificare che non siano presenti segreti in alcun file di log, inclusi i log degli errori.
• Esaminare i segreti registrati: Verificare che i segreti nella pipeline siano ancora necessari e rimuovere quelli che non lo sono più per ridurre il disordine e i potenziali rischi per la sicurezza.
• Ruotare i segreti: ruotare regolarmente i segreti per ridurre al minimo l'intervallo di tempo durante il quale potrebbe essere sfruttato un segreto compromesso.

Impedire l'esecuzione di codice dannoso

Per assicurarsi che solo il codice testato e sanificato venga eseguito tramite la pipeline, esaminare regolarmente le pipeline per individuare i problemi comuni.

• Analisi del codice: Eseguire l'escape dei caratteri speciali negli argomenti per evitare l'iniezione di comandi nella shell. È possibile usare GitHub Advanced Security per Azure DevOps per automatizzare l'analisi del codice.
• Convalidare gli input e usare i parametri: convalidare i parametri di input e gli argomenti per evitare comportamenti imprevisti. Usare query con parametri negli script per impedire l'inserimento di SQL. I parametri di runtime consentono di evitare problemi di sicurezza correlati alle variabili, ad esempio l'inserimento di argomenti.
• Non usare PATH negli script: basarsi sull'impostazione dell'agente PATH è pericoloso perché può essere modificato da uno script o uno strumento precedente. Usare sempre un percorso completamente qualificato.
• Controllare le attività disponibili: disabilitare la possibilità di installare ed eseguire attività dal Marketplace, che offre un maggiore controllo sul codice eseguito in una pipeline.

Proteggere i contenitori

Informazioni su come proteggere i contenitori tramite modifiche di configurazione, analisi e criteri.

• Contrassegnare i volumi come di sola lettura: i contenitori includono montaggi di volumi forniti dal sistema per attività, strumenti e componenti esterni necessari per lavorare con l'agente host. Impostare externals, taskse tools su sola lettura per la sicurezza aggiunta.
• Impostare limiti di risorse specifici del contenitore: impostare limiti sulla CPU e sulla memoria per impedire ai contenitori di consumare risorse eccessive, che possono causare vulnerabilità denial of service o di sicurezza.
• Usare immagini attendibili: usare immagini ufficiali e verificate da origini affidabili, ad esempio Registro Azure Container o Hub Docker. Specificare sempre una versione o un tag specifico per mantenere la coerenza e l'affidabilità, anziché basarsi sul tag latest. Aggiornare regolarmente le immagini di base per includere le patch di sicurezza e le correzioni di bug più recenti.
• Analizzare i contenitori per individuare le vulnerabilità e applicare la protezione dalle minacce di runtime: usare strumenti come Microsoft Defender for Cloud per monitorare e rilevare i rischi per la sicurezza. Registro Azure Container offre inoltre un'analisi integrata delle vulnerabilità per garantire la sicurezza delle immagini dei contenitori prima della distribuzione. È anche possibile integrare strumenti di analisi di terze parti tramite le estensioni di Azure DevOps per i controlli di sicurezza aggiunti.
• Implementare criteri di sicurezza per impedire l'escalation dei privilegi e garantire che i contenitori vengano eseguiti con la quantità minima di privilegi necessari: ad esempio, il servizio Azure Kubernetes, il controllo degli accessi in base al ruolo e l'ammissione di sicurezza dei pod consentono di applicare criteri che limitano i privilegi dei contenitori, garantire l'esecuzione non radice e limitare l'accesso alle risorse critiche.
• Usare i criteri di rete: i criteri di rete possono essere usati per limitare la comunicazione tra contenitori, assicurando che solo i contenitori autorizzati possano accedere a risorse sensibili all'interno della rete. Inoltre, è possibile applicare i Criteri di Azure per AKS per mettere in pratica le migliori procedure di sicurezza dei contenitori, come ad esempio garantire che vengano distribuite solo immagini di contenitori attendibili.

Usare i modelli per applicare le procedure consigliate

Iniziare con un modello minimo e applicare gradualmente le estensioni. Questo approccio garantisce che quando si implementano procedure di sicurezza, si dispone di un punto di partenza centralizzato che copre tutte le pipeline.

• Usa modelli di estensione: I modelli di estensione definiscono la struttura esterna e offrono punti specifici per personalizzazioni mirate. L'uso di modelli di estensione può impedire a codice dannoso di infiltrarsi in una pipeline.
• Limitare l'accesso con i passaggi: limitare l'accesso alla rete mediante passaggi come il download dei pacchetti eseguiti in un contenitore anziché nell'host. Quando i passaggi vengono eseguiti in un contenitore, si impedisce a un attore malintenzionato di modificare la configurazione dell'agente o di lasciare codice dannoso per un'esecuzione successiva.

Articoli correlati

• Ciclo di vita dello sviluppo della sicurezza Microsoft
• Centro di fiducia di Azure