Proteggere i repository e le richieste pull

servizi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Proteggi Azure Repos combinando il controllo degli accessi, i criteri delle pull request e i controlli di stato sui branch più importanti. Questo articolo illustra come limitare le modifiche dirette, richiedere i revisori appropriati, applicare i requisiti di lavoro e di compilazione e aggiungere GitHub controlli di sicurezza avanzata prima dell'unione delle richieste pull.

Minacce e controlli

Usare i controlli seguenti insieme per ridurre i rischi più comuni per le richieste pull.

Prerequisites

Prima di configurare i criteri di ramo:

• Assicurarsi che il repository di destinazione e il branch esistano già.
• Decidere quali gruppi possono gestire le autorizzazioni, ignorare i criteri e approvare le richieste pull.
• Se si intende richiedere la convalida della compilazione o i controlli dello stato di GitHub Advanced Security, creare prima la pipeline di compilazione.

Baseline di sicurezza per la maggior parte dei team

Per un tipico ramo di produzione, mainad esempio , iniziare con questa baseline:

Passaggio 1: Limita l'accesso al repository e al branch

Iniziare con le autorizzazioni. I criteri sono più efficaci quando solo un piccolo set di utenti può ignorarli.

Esaminare le autorizzazioni del repository

Usare le autorizzazioni del repository per controllare chi può leggere, contribuire, amministrare le impostazioni o contribuire alle richieste pull. Per informazioni di riferimento dettagliate sulle autorizzazioni, vedere Impostare le autorizzazioni del repository Git.

Usare il modello seguente:

• Concedere ai collaboratori le autorizzazioni necessarie per lavorare nei rami di funzionalità.
• Riservare l'amministrazione del repository per un piccolo gruppo di amministratori.
• Evitare concessioni estese di autorizzazioni per ignorare i criteri.

Limitare le autorizzazioni per i rami

Per i rami protetti, esaminare e limitare attentamente queste autorizzazioni:

• Ignorare i criteri durante il completamento delle richieste pull
• Ignorare le politiche mentre si esegue il push
• Forza push (riscrivere la cronologia, eliminare rami e tag)
• Modificare le politiche
• Gestire autorizzazioni

Utilizzare Set branch permissions per configurare queste impostazioni.

Modello consigliato per main:

Passaggio 2: Richiedere una revisione avanzata delle richieste pull

Richiedere un numero minimo di revisori

Usa Richiedi un numero minimo di revisori nei rami importanti, come main e i rami di rilascio.

Impostazioni consigliate:

• Numero minimo di revisori: 2 per rami condivisi ad alto valore
• Richiedere almeno un'approvazione per l'ultima iterazione
• Consentire ai richiedenti di approvare le proprie modifiche: Off
• Impedire al pusher più recente di approvare le proprie modifiche: On quando si vuole una separazione più forte dei compiti

Configurare il criterio per il numero minimo di revisori

az repos policy approver-count create \
  --blocking true \
  --branch main \
  --enabled true \
  --minimum-approver-count 2 \
  --creator-vote-counts false \
  --reset-on-source-push true \
  --repository-id <repository-id>

Verificare il risultato:

• L'elenco dei criteri di ramo mostra il criterio per i revisori come abilitato.
• Le richieste di pull nel branch non possono essere completate finché non viene raggiunto il numero richiesto di approvazioni.

Per informazioni dettagliate sui criteri, vedere Criteri e impostazioni dei rami.

Includere automaticamente i revisori per i file sensibili

Usare Revisori inclusi automaticamente quando determinati file o cartelle richiedono l'approvazione di una persona o di un team specifico.

Ecco alcuni candidati appropriati:

• codice di distribuzione e infrastruttura
• codice di autenticazione e autorizzazione
• cartelle sensibili alla conformità
• modelli di pipeline condivisi

Configurare il criterio dei revisori inclusi automaticamente

az repos policy required-reviewer create \
  --blocking true \
  --branch main \
  --enabled true \
  --message "Security review required for protected paths." \
  --path-filter "/.azure/*;/infra/*;/pipelines/*" \
  --repository-id <repository-id> \
  --required-reviewer-ids <reviewer-email-or-emails>

Verificare il risultato:

• Una richiesta pull che modifica i file corrispondenti aggiunge automaticamente i revisori configurati.
• La richiesta pull non può essere completata fino a quando non vengono soddisfatti i criteri di revisore necessari.

Per altre informazioni, vedere Includere automaticamente i revisori del codice.

Passaggio 3: Applicare la tracciabilità e la convalida

Verificare la presenza di elementi di lavoro collegati

Attiva Controlla gli elementi di lavoro collegati quando il team ha bisogno della tracciabilità delle modifiche tra le pull request e il monitoraggio del lavoro.

Configurare i criteri degli elementi di lavoro collegati

az repos policy work-item-linking create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id>

Verifica il risultato: le pull request senza elementi di lavoro collegati indicano che il criterio non è soddisfatto.

Per altre informazioni, vedere Verificare la presenza di elementi di lavoro collegati.

Convalida compilazione

Usa la convalida della build per richiedere l'esecuzione corretta di una pipeline per le pull request prima del merge.

Impostazioni consigliate per i rami protetti:

• Attivazione: Automatica
• Requisito dei criteri: Required
• Scadenza della compilazione: scegliere un valore che corrisponda alla frequenza con cui si modifica il ramo protetto

Configurare i criteri di convalida della build

az repos policy build create \
  --blocking true \
  --branch main \
  --build-definition-id <pipeline-id> \
  --display-name "PR validation" \
  --enabled true \
  --manual-queue-only false \
  --queue-on-source-update-only true \
  --repository-id <repository-id> \
  --valid-duration 0

Verificare il risultato:

• L'apertura o l'aggiornamento di una pull request mette in coda la build di convalida configurata.
• La pull request non può essere completata finché la build obbligatoria non viene completata con successo.

Per altre informazioni, vedere Convalida della compilazione.

Verificare la risoluzione dei commenti

Usare Verifica la risoluzione dei commenti per assicurarsi che i thread di revisione vengano risolti prima del completamento della richiesta pull.

Configurare i criteri di risoluzione dei commenti

az repos policy comment-required create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id>

Verificare il risultato: le richieste pull con commenti non risolti rimangono bloccate fino a quando i revisori o gli autori non risolvono i thread.

Per altre informazioni, vedere Verificare la risoluzione dei commenti.

Limitare i tipi di unione

Utilizzare Limita i tipi di merge come impostazione di governance della cronologia del repository. Questo criterio consente di standardizzare la modalità di visualizzazione dei commit delle richieste pull dopo l'unione, ma non è un controllo di sicurezza diretto.

Scegliere una strategia di merge in base al modo in cui il team esamina, traccia e controlla la cronologia.

Viene usato un esempio:

• Richiedere fusioni squash per il lavoro su funzionalità di breve durata.
• Non consentire il rebase o lo squash nei branch in cui il processo di audit richiede commit di merge.

Considerazioni su controllo e tracciabilità:

• Squash crea una cronologia più pulita del ramo di destinazione, ma comprime più commit di origine in un solo commit in fase di unione.
• Se il modello di audit dipende dal mantenimento dell'esatta sequenza dei commit di un branch di funzionalità, è preferibile adottare strategie con commit di merge rispetto allo squash.
• Mantieni i criteri coerenti con il modo in cui gli sviluppatori esaminano ed eseguono il debug della cronologia nelle pull request e nel ramo di destinazione.

Esempio di Azure DevOps CLI:

az repos policy merge-strategy create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id> \
  --allow-no-fast-forward true \
  --allow-rebase false \
  --allow-rebase-merge false \
  --allow-squash false

Per altre informazioni, vedere Limitare i tipi di merge.

Passaggio 4: Aggiungere GitHub controlli di stato di sicurezza avanzata

I controlli dello stato di GitHub Advanced Security contribuiscono a impedire il merge delle pull request quando vengono introdotte nuove vulnerabilità critiche o ad alta gravità.

Prima di aggiungere il criterio di verifica dello stato:

1. Abilita GitHub Advanced Security sul repository.
2. Configurare le attività della pipeline di sicurezza avanzata necessarie.
3. Aggiungere un criterio di convalida della build per il ramo della pull request.
4. Attivare Wait for Processing: true per le attività documentate di Sicurezza avanzata.
5. Eseguire correttamente la pipeline almeno una volta in modo che il controllo dello stato venga visualizzato nell'elenco Stato da controllare .

Iniziare con AdvancedSecurity/NewHighAndCritical se il repository ha già avvisi non risolti. Dopo aver ridotto il backlog, valuta di passare a AdvancedSecurity/AllHighAndCritical.

Percorso del browser:

1. Aprire il ramo di destinazione in Criteri di ramo.
2. In Controlli di stato selezionare +.
3. Impostare Stato su verificaAdvancedSecurity/NewHighAndCritical.
4. Lasciare Opzioni avanzate nei valori predefiniti.
5. Salva la politica.

I controlli di stato di sicurezza avanzati vengono configurati dai controlli di stato nel browser dopo aver abilitato l'analisi avanzata della sicurezza e la convalida della compilazione per il repository. Per la configurazione necessaria, vedere Configurare i controlli di stato della richiesta pull.

Verificare il risultato:

• Le richieste pull con nuovi risultati elevati o critici mostrano che il controllo dello stato non è riuscito.
• Il criterio del ramo impedisce il completamento finché i rilievi non vengono risolti o il criterio non viene reso facoltativo.

Per informazioni dettagliate sull'installazione, vedere:

• Configurare i controlli di stato della richiesta pull
• Controlli di stato delle richieste pull disponibili

Piani di implementazione di esempio

Baseline del repository con riservatezza inferiore

Se il repository ha una sensibilità inferiore e si vuole un punto di partenza gestibile:

1. Limitare le autorizzazioni di bypass del branch in main.
2. Richiedere almeno uno o due revisori.
3. Attivare gli elementi di lavoro collegati.
4. Aggiungere la convalida della compilazione.
5. Attivare la risoluzione dei commenti.

Repository a elevata sensibilità

Se il repository contiene asset critici per la distribuzione, l'identità o la conformità:

1. Limitare le autorizzazioni di aggiramento dei criteri agli amministratori.
2. Richiedi due revisori per main.
3. Aggiungere revisori inclusi automaticamente per i percorsi protetti.
4. Richiedi elementi di lavoro collegati.
5. Aggiungere la convalida della compilazione.
6. Aggiungere i controlli dello stato di GitHub Advanced Security se si usano Azure DevOps Services.

Facoltativo: usare l'assistenza dell'IA per rivedere la configurazione dei criteri del ramo

L'assistenza per l'intelligenza artificiale è facoltativa. Le autorizzazioni del branch, i criteri e i controlli di stato impongono le protezioni del repository, indipendentemente dal fatto che si utilizzi o meno l'intelligenza artificiale.

È possibile usare questi prompt per esaminare la configurazione dei criteri, identificare le lacune e ottenere raccomandazioni di base più velocemente. Se si configura Azure DevOps SERVER MCP, l'assistente può usare il contesto di Azure DevOps per migliorare le risposte. Per indicazioni sulla configurazione, vedere Abilitare l'assistenza di intelligenza artificiale con Azure DevOps server MCP.

Per iniziare, usare prompt come il seguente:

Convalidare sempre i comandi generati e le raccomandazioni in base alle autorizzazioni del repository, alle impostazioni del ramo e alla documentazione corrente Azure DevOps prima di applicarli.

Suggerimenti per la risoluzione dei problemi

Contenuti correlati

• Impostare le autorizzazioni del repository Git
• Impostare le autorizzazioni del ramo
• Criteri e impostazioni dei rami
• Controlli di stato delle richieste pull disponibili
• Configurare GitHub sicurezza avanzata
• Informazioni su pull request