Altre considerazioni sulla sicurezza per Azure Pipelines

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

Quando si tratta di proteggere Azure Pipelines, esistono diverse altre considerazioni da tenere presenti, ad esempio la protezione di infrastruttura condivisa, repository, progetti e altro ancora.

Proteggere l'infrastruttura condivisa

Le risorse protette in Azure Pipelines sono un'astrazione dell'infrastruttura reale. Seguire queste raccomandazioni per proteggere l'infrastruttura sottostante.

Usare pool ospitati da Microsoft

I pool ospitati da Microsoft offrono isolamento e una macchina virtuale pulita per ogni esecuzione di una pipeline. Se possibile, usare pool ospitati da Microsoft anziché pool self-hosted.

Separare gli agenti per ogni progetto

Un agente può essere associato solo a un singolo pool. È possibile condividere gli agenti tra i progetti associando il pool a più progetti. In pratica, più progetti potrebbero usare lo stesso agente consecutivamente. Anche se conveniente, questo approccio può introdurre rischi di spostamento laterale.

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 gli agenti

Anche se si potrebbe essere tentati, l'esecuzione dell'agente in un'identità con accesso diretto alle risorse di Azure DevOps può essere rischiosa. Questa configurazione è prevalente nelle organizzazioni che usano Microsoft Entra ID, ma comporta rischi. Se si esegue l'agente con un'identità supportata da Microsoft Entra ID, può accedere direttamente alle API di Azure DevOps senza basarsi sul token di accesso del processo. Per una maggiore sicurezza, prendere in considerazione l'esecuzione dell'agente usando un account locale non privilegiato, ad esempio servizio di rete.

Importante

In Azure DevOps è presente un gruppo denominato Project Collection Service Accounts, che può essere fuorviante. In base all'ereditarietà, anche i membri degli account del servizio raccolta progetti sono considerati membri di Project Collection Administrators. Alcuni clienti eseguono gli agenti di compilazione usando un'identità supportata da Microsoft Entra ID e queste identità possono far parte degli account del servizio raccolta progetti. Tuttavia, se gli avversari eseguono una pipeline su uno di questi agenti di compilazione, potrebbero potenzialmente ottenere il controllo sull'intera organizzazione di Azure DevOps.

Esistono istanze in cui gli agenti self-hosted operano con account con privilegi elevati. Questi agenti usano spesso questi account con privilegi per accedere ai segreti o agli ambienti di produzione. Tuttavia, se gli avversari eseguono una pipeline compromessa su uno di questi agenti di compilazione, ottengono l'accesso a tali segreti. Gli avversari possono quindi spostarsi in un secondo momento attraverso altri sistemi accessibili tramite questi account.

Per migliorare la sicurezza del sistema, è consigliabile usare l'account con privilegi più bassi per l'esecuzione di agenti self-hosted. Si consideri, ad esempio, l'uso dell'account del computer o di un'identità del servizio gestito. Inoltre, affida azure Pipelines alla gestione dell'accesso ai segreti e agli ambienti.

Ridurre al minimo l'ambito delle connessioni al servizio

Assicurarsi che le connessioni al servizio abbiano accesso solo alle risorse necessarie. Quando possibile, prendere in considerazione l'uso della federazione dell'identità del carico di lavoro al posto di 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.

Assicurarsi che l'ambito della connessione al servizio di Azure sia limitato all'accesso solo alle risorse necessarie. Evitare di concedere diritti di collaboratore generali per l'intera sottoscrizione di Azure agli utenti.

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. Analogamente, quando si configura l'app GitHub, concedere l'accesso solo ai repository che si intende compilare usando Azure Pipelines.

Proteggere i progetti

Oltre alle singole risorse, è fondamentale considerare i gruppi di risorse in Azure DevOps. Le risorse si organizzano in base ai progetti team e capire a cosa può accedere la pipeline in base alle impostazioni del progetto e al contenimento è essenziale.

Ogni processo nella pipeline riceve un token di accesso con autorizzazioni per leggere le risorse aperte. In alcuni casi, le pipeline potrebbero anche aggiornare queste risorse. Ciò significa che, anche se l'account utente potrebbe non avere accesso diretto a una risorsa, a script e attività specifiche in esecuzione nella pipeline, potrebbe comunque accedervi. Inoltre, il modello di sicurezza di Azure DevOps consente l'accesso a queste risorse da altri progetti all'interno dell'organizzazione. Se si decide di limitare l'accesso alla pipeline a determinate risorse, questa decisione si applica a tutte le pipeline all'interno di un progetto. Le pipeline specifiche non possono essere concesse in modo selettivo all'accesso alle risorse aperte.

Progetti separati

Data la natura delle risorse aperte, prendere in considerazione la gestione di ogni prodotto e team in progetti separati. In questo modo si impedisce alle pipeline di accedere involontariamente alle risorse aperte da un altro prodotto, riducendo così al minimo l'esposizione laterale. Tuttavia, quando più team o prodotti condividono un progetto, l'isolamento granulare delle risorse diventa difficile.

Se l'organizzazione Azure DevOps è stata creata prima di agosto 2019, le esecuzioni potrebbero comunque avere accesso alle risorse aperte in tutti i progetti dell'organizzazione. L'amministratore dell'organizzazione deve esaminare un'impostazione di sicurezza critica in Azure Pipelines che abilita l'isolamento del progetto per le pipeline.

È possibile trovare questa impostazione in Impostazioni>organizzazione Impostazioni pipeline>o direttamente: . https://dev.azure.com/Organization_Name/_settings/pipelinessettings

Proteggere i repository

Nei repository di controllo della versione è possibile archiviare il codice sorgente, il file YAML della pipeline e gli script e gli strumenti necessari. Per garantire modifiche sicure al codice e alla pipeline, è fondamentale applicare autorizzazioni e criteri di ramo. Prendere in considerazione anche l'aggiunta di autorizzazioni e controlli della pipeline ai repository.

Esaminare anche le impostazioni di controllo di accesso predefinite per i repository.

Tenere presente che la progettazione di Git significa che la protezione a livello di ramo presenta limitazioni. Gli utenti con accesso push a un repository possono in genere creare nuovi rami. Se si lavora con progetti open source GitHub, chiunque abbia un account GitHub può creare un fork del repository e proporre contributi. Poiché le pipeline sono associate a un repository (non a rami specifici), è essenziale trattare il codice e i file YAML come potenzialmente non attendibili.

Forks

Quando si lavora con repository pubblici da GitHub, è essenziale considerare attentamente l'approccio alle compilazioni fork. I fork, provenienti dall'esterno dell'organizzazione, rappresentano rischi specifici. Per proteggere i prodotti da codice con contributi potenzialmente non attendibili, prendere in considerazione le raccomandazioni seguenti

Nota

Queste raccomandazioni si applicano principalmente alla creazione di repository pubblici da GitHub.

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.

Nota

Quando si abilitano le compilazioni fork per accedere ai segreti, Azure Pipelines limita il token di accesso usato per impostazione predefinita. Questo token ha accesso limitato alle risorse aperte rispetto a un normale token di accesso. Per concedere la creazione di fork alle stesse autorizzazioni delle compilazioni regolari, abilitare l'impostazione Crea fork per le compilazioni con le stesse autorizzazioni delle compilazioni regolari.

Prendere in considerazione l'attivazione manuale delle compilazioni fork

È possibile disattivare le compilazioni automatiche del fork e usare invece i commenti delle richieste pull come modo per compilare manualmente questi contributi. Questa impostazione consente di esaminare il codice prima di attivare una compilazione.

Usare gli 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. Per gli agenti self-hosted, implementare l'isolamento di rete e assicurarsi che gli agenti non persistenzano lo stato tra i processi.

Esaminare le modifiche al codice

Prima di eseguire la pipeline in una richiesta pull tramite fork, esaminare attentamente le modifiche proposte e assicurarsi di avere familiarità con l'esecuzione.

La versione della pipeline YAML eseguita è quella della richiesta pull. Prestare quindi particolare attenzione alle modifiche apportate al codice YAML e al codice eseguito durante l'esecuzione della pipeline, ad esempio gli script della riga di comando o unit test.

Limitazione dell'ambito del token GitHub

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. Se si usano altre forme di integrazione di GitHub, ad esempio l'app OAuth, la restrizione non viene applicata.

Rami utente

Gli utenti dell'organizzazione con le autorizzazioni appropriate possono creare nuovi rami contenenti codice nuovo o aggiornato. Questo codice può essere eseguito nella stessa pipeline dei rami protetti. Se il file YAML nel nuovo ramo viene modificato, il file YAML aggiornato viene usato per eseguire la pipeline. Anche se questa progettazione consente una grande flessibilità e la modalità self-service, non tutte le modifiche sono sicure (sia che vengano apportate in modo dannoso o meno).

Se la pipeline usa il codice sorgente o è definita in Azure Repos, è necessario comprendere completamente il modello di autorizzazioni Azure Repos. In particolare, un utente con autorizzazione Create Branch a livello di repository può introdurre codice al repository anche se l'utente non dispone dell'autorizzazione Contribute .

Altre considerazioni sulla sicurezza

Quando si proteggono le pipeline, è necessario prendere in considerazione la serie di altri aspetti seguenti.

Basarsi su PATH

Fare affidamento sull'impostazione dell'agente PATH è pericoloso. Potrebbe non puntare al punto in cui si ritiene che lo faccia, poiché è stato potenzialmente modificato da uno script o uno strumento precedente. Per gli script e i file binari critici per la sicurezza, usare sempre un percorso completo del programma.

Segreti del log

Azure Pipelines tenta di eseguire lo scrubbing dei segreti dai log laddove possibile. Questo filtraggio viene eseguito con la massima diligenza possibile e non è in grado di individuare tutti i modi in cui i segreti possono essere divulgati. Evitate di ripetere i segreti nella console, di usarli nei parametri della riga di comando o di registrarli nei file.

Bloccare i contenitori

I contenitori hanno alcuni mapping dei montaggi di volumi forniti dal sistema nelle attività, nell'area di lavoro e nei componenti esterni necessari per comunicare con l'agente host. È possibile contrassegnare uno o tutti questi volumi di sola lettura.

resources:
  containers:
  - container: example
    image: ubuntu:22.04
    mountReadOnly:
      externals: true
      tasks: true
      tools: true
      work: false  # the default; shown here for completeness

In genere, la maggior parte delle persone deve impostare le prime tre directory come di sola lettura e lasciare work come lettura-scrittura. Se non si scrive nella work directory in un processo o un passaggio specifico, è possibile rendere work disponibile anche la sola lettura. Tuttavia, se le attività della pipeline comportano la modifica automatica, potrebbe essere necessario mantenere tasks la lettura/scrittura.

Controllare le attività disponibili

È possibile disabilitare la possibilità di installare ed eseguire attività dal Marketplace, che consente un maggiore controllo sul codice eseguito in una pipeline. È anche possibile disabilitare tutte le attività incluse nella casella (ad eccezione di Checkout, che è un'azione speciale sull'agente). È consigliabile non disabilitare le attività predefinite nella maggior parte dei casi.

Le attività installate direttamente con tfx sono sempre disponibili. Con entrambe queste funzionalità abilitate, sono disponibili solo queste attività.

Usare il servizio di controllo

Molti eventi della pipeline vengono registrati nel servizio di controllo. Esaminare periodicamente il log di controllo per assicurarsi che non siano state apportate modifiche dannose passate. Visitare https://dev.azure.com/ORG-NAME/_settings/audit per iniziare.

Passaggi successivi

Esaminare la panoramica della sicurezza