Protezione del repository

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

Il codice sorgente, il file YAML della pipeline e gli script e gli strumenti necessari sono tutti archiviati in un repository di controllo della versione. Le autorizzazioni e i criteri dei rami devono essere usati per garantire la sicurezza delle modifiche apportate al codice e alla pipeline. È anche possibile aggiungere autorizzazioni e controlli della pipeline ai repository.

È anche consigliabile esaminare il controllo di accesso predefinito per i repository.

Finora, a causa della progettazione di Git, la protezione a livello di ramo conterrà solo l'utente. Gli utenti con accesso push a un repository possono in genere creare nuovi rami. Se si usano progetti open source di GitHub, chiunque abbia un account GitHub può creare una copia tramite fork del repository e proporre i contributi. Poiché le pipeline sono associate a un repository e non a rami specifici, è necessario presupporre che il codice e i file YAML non siano attendibili.

Forks

Se si creano repository pubblici da GitHub, è necessario prendere in considerazione la propria posizione sulle build fork. I fork sono particolarmente pericolosi poiché provengono dall'esterno dell'organizzazione. Per proteggere i prodotti dal codice fornito, prendere in considerazione i consigli seguenti.

Nota

Le raccomandazioni seguenti 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 sono resi disponibili per i processi in tali pipeline per impostazione predefinita. Non disattivare questa seconda protezione.

Nota

Quando si abilitano le compilazioni fork per accedere ai segreti, Azure Pipelines per impostazione predefinita limita il token di accesso usato per le compilazioni fork. Ha accesso più limitato alle risorse aperte rispetto a un normale token di accesso. Per assegnare alla fork le stesse autorizzazioni delle compilazioni regolari, abilitare le compilazioni di fork hanno le stesse autorizzazioni delle normali compilazioni .

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

Non eseguire compilazioni da fork in agenti self-hosted. In questo modo si fornisce in modo efficace un percorso alle organizzazioni esterne per l'esecuzione di codice esterno nei computer all'interno della rete aziendale. Usare gli agenti ospitati da Microsoft se possibile. Per l'agente self-hosted, usare una forma di isolamento rete e assicurarsi che gli agenti non conservino 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 che verrà 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. Tale codice può essere eseguito con la stessa pipeline dei rami protetti. Inoltre, se viene modificato il file YAML nel nuovo ramo, verrà usato YAML aggiornato 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 .

Passaggi successivi

Altre informazioni sulla protezione offerta dai controlli sulle risorse protette.