Procedure consigliate per la sicurezza

  • Articolo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Quando si gestiscono informazioni e dati, in particolare in una soluzione basata sul cloud come Azure DevOps Services, la sicurezza deve essere la priorità principale. Anche se Microsoft garantisce la sicurezza dell'infrastruttura cloud sottostante, la configurazione della sicurezza all'interno di Azure DevOps è responsabilità dell'utente.

Anche se non obbligatorio, l'incorporazione delle procedure consigliate può migliorare significativamente l'esperienza e rafforzare la sicurezza. Le raccomandazioni seguenti sono progettate per semplificare la gestione di un ambiente Azure DevOps sicuro.

Proteggere l'ambiente Azure DevOps

Usare le procedure consigliate seguenti per rimuovere gli utenti, esaminare gli eventi di controllo e l'integrazione con Microsoft Entra ID.

Rimuovere utenti

  • Rimuovere gli utenti inattivi dagli account Microsoft (ACCOUNT del servizio gestito): rimuovere direttamente gli utenti inattivi dall'organizzazione se si usano account del servizio gestito. Non è possibile creare query per gli elementi di lavoro assegnati agli account MSA rimossi.
  • Disabilitare o eliminare gli account utente di Microsoft Entra: se si è connessi all'ID Microsoft Entra, disabilitare o eliminare l'account utente Microsoft Entra mantenendo attivo l'account utente di Azure DevOps. Questa azione consente di continuare a eseguire query sulla cronologia degli elementi di lavoro usando l'ID utente di Azure DevOps.
  • Revocare le api utente: esaminare e revocare regolarmente eventuali TOKEN utente esistenti per garantire la gestione sicura di questi token di autenticazione critici.
  • Revocare autorizzazioni speciali concesse ai singoli utenti: controllare e revocare eventuali autorizzazioni speciali concesse ai singoli utenti per garantire l'allineamento con il principio dei privilegi minimi.
  • Riassegnare il lavoro dagli utenti rimossi: prima di rimuovere gli utenti, riassegnare gli elementi di lavoro ai membri del team correnti per distribuire il carico in modo efficace.

Usare Microsoft Entra ID

  • Stabilire un sistema di identità unificato: connettere Azure DevOps a Microsoft Entra ID per creare un singolo piano per l'identità. Questa coerenza riduce la confusione e riduce al minimo i rischi per la sicurezza derivanti da errori di configurazione manuale.
  • Implementare una governance con granularità fine: usare Microsoft Entra ID per assegnare ruoli e autorizzazioni diversi a gruppi specifici in diversi ambiti di risorse. Questa azione garantisce l'accesso controllato e si allinea alle procedure consigliate per la sicurezza.
  • Migliorare le funzionalità di sicurezza: abilitare altre funzionalità di sicurezza con Microsoft Entra ID, ad esempio:
    • Autenticazione a più fattori (MFA): richiedere più fattori, ad esempio la verifica della password e del telefono per l'autenticazione utente. Criteri di accesso condizionale: definire regole di accesso in base a condizioni come posizione, dispositivo o livello di rischio.

Per altre informazioni, vedere gli articoli seguenti:

Esaminare gli eventi di controllo

Con l'organizzazione connessa a Microsoft Entra, eseguire le attività seguenti per migliorare la sicurezza e monitorare i modelli di utilizzo:

  • Abilita il controllo: tenere traccia e visualizzare gli eventi correlati a azioni, autorizzazioni e modifiche dell'utente.
  • Esaminare regolarmente gli eventi di controllo: cercare modelli di utilizzo imprevisti, in particolare dagli amministratori e da altri utenti.

Proteggere la rete

Le funzioni seguenti sono modi efficaci per migliorare la sicurezza della rete quando si usa Azure DevOps.

  • Configurare l'elenco di indirizzi IP consentiti: limitare l'accesso a indirizzi IP specifici per consentire il traffico solo da origini attendibili, riducendo la superficie di attacco.
  • Usare la crittografia: crittografa sempre i dati in transito e inattivi. Proteggere i canali di comunicazione usando protocolli come HTTPS.
  • Convalidare i certificati: assicurarsi che i certificati siano validi e rilasciati dalle autorità attendibili quando si stabiliscono connessioni.
  • Implementare web application firewall (WAF): filtrare, monitorare e bloccare il traffico dannoso basato sul Web con waf per un ulteriore livello di protezione da attacchi comuni.

Per altre informazioni, vedere Procedure consigliate per la gestione delle applicazioni.

Autorizzazioni per l'ambito

Il sistema gestisce le autorizzazioni a vari livelli, ovvero singole, raccolte, progetti e oggetti, e le assegna a uno o più gruppi predefiniti per impostazione predefinita. Per migliorare la sicurezza, eseguire le azioni seguenti:

  • Fornire l'accesso con privilegi minimi: concedere agli utenti e ai servizi l'accesso minimo necessario per eseguire le funzioni aziendali.
  • Disabilitare l'ereditarietà: quando possibile, disabilitare l'ereditarietà. L'ereditarietà può concedere inavvertitamente l'accesso o le autorizzazioni agli utenti imprevisti a causa della natura consentita per impostazione predefinita. Per altre informazioni, vedere la sezione sull'ereditarietà delle autorizzazioni

Per altre informazioni sulle autorizzazioni, vedere gli articoli seguenti:

Autorizzazioni a livello di progetto

  • Limitare l'accesso a progetti e repository: ridurre il rischio di perdita di informazioni riservate e distribuzione di codice non sicuro limitando l'accesso a progetti e repository. Usare i gruppi di sicurezza predefiniti o personalizzati per gestire le autorizzazioni.
  • Disabilitare "Consenti progetti pubblici": nelle impostazioni dei criteri dell'organizzazione disabilitare l'opzione per creare progetti pubblici. Cambiare la visibilità del progetto dal pubblico al privato in base alle esigenze. Agli utenti che non hanno eseguito l'accesso hanno accesso in sola lettura ai progetti pubblici, mentre gli utenti connessi possono accedere a progetti privati e apportare modifiche consentite.
  • Limita la creazione del progetto: impedisci agli utenti di creare nuovi progetti per mantenere il controllo sull'ambiente.

Accesso guest esterno

  • Blocca l'accesso guest esterno: disabilitare il criterio "Consenti l'invio di inviti a qualsiasi dominio" per impedire l'accesso guest esterno se non è necessario.
  • Usare indirizzi di posta elettronica o UPN distinti: usare indirizzi di posta elettronica diversi o nomi upN (UPN) per gli account personali e aziendali per eliminare l'ambiguità tra account personali e correlati al lavoro.
  • Raggruppare gli utenti guest esterni: inserire tutti gli utenti guest esterni in un singolo gruppo di Microsoft Entra e gestire le autorizzazioni per questo gruppo in modo appropriato. Rimuovere le assegnazioni dirette per assicurarsi che le regole di gruppo vengano applicate a questi utenti.
  • Rivalutare le regole regolarmente: rivedere regolarmente le regole nella scheda Regole di gruppo della pagina Utenti. Prendere in considerazione eventuali modifiche all'appartenenza a gruppi nell'ID Microsoft Entra che potrebbero influire sull'organizzazione. Microsoft Entra ID può richiedere fino a 24 ore per aggiornare l'appartenenza dinamica ai gruppi e le regole vengono rivalutate automaticamente ogni 24 ore e ogni volta che una regola di gruppo cambia.

Per altre informazioni, vedere Guest B2B in Microsoft Entra ID.

Gestire i gruppi di sicurezza

Gruppi di utenti e sicurezza

La tabella seguente illustra le raccomandazioni per l'assegnazione delle autorizzazioni ai gruppi di sicurezza e ai gruppi di utenti.

Fare Non
Usare Microsoft Entra ID, Active Directory o gruppi di sicurezza di Windows quando si gestiscono molti utenti. Non modificare le autorizzazioni predefinite per il gruppo Project Valid Users .Don't change the default permissions for the Project Valid Users group. Questo gruppo può accedere e visualizzare le informazioni sul progetto. Per altre informazioni, vedere Gruppi di utenti validi.
Quando si aggiungono team, prendere in considerazione le autorizzazioni da assegnare ai membri del team che devono creare e modificare percorsi di area, percorsi di iterazione e query. Non aggiungere utenti a più gruppi di sicurezza contenenti livelli di autorizzazione diversi. In alcuni casi, un livello di autorizzazione Deny potrebbe eseguire l'override di un livello di autorizzazione Consenti . Si supponga, ad esempio, di avere due gruppi di sicurezza nel progetto Azure DevOps: sviluppatori e tester. Il gruppo Sviluppatori dispone dell'autorizzazione per modificare gli elementi di lavoro impostati su Consenti. Tuttavia, assicurarsi che determinati elementi di lavoro sensibili non vengano modificati da nessuno tranne alcuni individui chiave. A tale scopo, creare un nuovo gruppo di sicurezza denominato Editor elementi sensibili e impostare l'autorizzazione per modificare gli elementi di lavoro su Nega per questo gruppo. Se un utente è membro del gruppo Developers e del gruppo Editor di elementi sensibili, l'autorizzazione Nega dal gruppo Editor elementi sensibili ha la precedenza sull'autorizzazione Consenti dal gruppo Sviluppatori . Di conseguenza, questo utente non può modificare gli elementi di lavoro sensibili, anche se ha l'autorizzazione Consenti nel gruppo Sviluppatori. Questo comportamento garantisce che le autorizzazioni di negazione vengano applicate rigorosamente, fornendo un livello superiore di sicurezza e controllo sulle azioni sensibili all'interno dell'ambiente Azure DevOps.
Quando si aggiungono molti team, è consigliabile creare un gruppo personalizzato Amministratori team in cui si alloca un subset delle autorizzazioni disponibili per gli amministratori del progetto. Non modificare le assegnazioni predefinite effettuate ai gruppi Project Valid Users . Se si rimuove o si imposta Visualizza informazioni a livello di istanza su Nega per uno dei gruppi Utenti validi di Project, nessun utente del gruppo può accedere a qualsiasi progetto, raccolta o distribuzione per cui si imposta l'autorizzazione.
Valutare la possibilità di concedere alle cartelle di query dell'elemento di lavoro l'autorizzazione Contribuire a utenti o gruppi che richiedono la possibilità di creare e condividere query sugli elementi di lavoro per il progetto. Non assegnare autorizzazioni annotate come Assegna solo agli account del servizio agli account utente.
Mantenere i gruppi il più piccolo possibile. L'accesso deve essere limitato e i gruppi devono essere controllati di frequente.
Sfruttare i ruoli predefiniti e impostarli su Collaboratore per gli sviluppatori. Gli amministratori vengono assegnati al gruppo di sicurezza Amministratore di progetto con autorizzazioni elevate. Ciò consente loro di configurare le autorizzazioni di sicurezza.

Accesso JUST-in-time per i gruppi di amministratori

Se si dispone dell'accesso amministratore raccolta progetti e amministratore progetto, è possibile modificare la configurazione dell'organizzazione o del progetto. Per migliorare la sicurezza per questi gruppi di amministratori predefiniti, è consigliabile implementare l'accesso JIT usando un gruppo di Microsoft Entra Privileged Identity Management (PIM). Questo approccio consente di concedere autorizzazioni elevate solo quando necessario, riducendo il rischio associato all'accesso permanente.

Configurare l'accesso

  1. Creare un gruppo assegnabile a ruoli in Microsoft Entra ID.
  2. Aggiungere il gruppo Microsoft Entra al gruppo Azure DevOps.

Nota

Quando si configura l'accesso JIT usando un gruppo di Microsoft Entra Privileged Identity Management (PIM), assicurarsi che qualsiasi utente con accesso con privilegi elevati mantenga anche l'accesso standard all'organizzazione. In questo modo, possono visualizzare le pagine necessarie e aggiornare le relative autorizzazioni in base alle esigenze.

Usare l'accesso

  1. Attivare l'accesso.
  2. Aggiornare le autorizzazioni in Azure DevOps.
  3. Eseguire l'azione che richiede l'accesso amministratore.

Nota

Gli utenti hanno eseguito l'accesso con privilegi elevati in Azure DevOps per un massimo di 1 ora dopo la disattivazione dell'accesso al gruppo PIM.

Definire l'ambito degli account del servizio

  • Creare account di servizio per utilizzo singolo: ogni servizio deve avere un account dedicato per ridurre al minimo i rischi. Evitare di usare gli account utente normali come account del servizio.
  • Seguire le convenzioni di denominazione e documentazione: usare nomi chiari e descrittivi per gli account del servizio e documentare lo scopo e i servizi associati.
  • Identificare e disabilitare gli account di servizio inutilizzati: esaminare e identificare regolarmente gli account non più in uso. Disabilitare gli account inutilizzati prima di prendere in considerazione l'eliminazione.
  • Limitare i privilegi: limitare i privilegi dell'account del servizio al minimo necessario. Evitare diritti di accesso interattivi per gli account del servizio.
  • Usare identità separate per i lettori di report: se si usano account di dominio per gli account del servizio, usare un'identità diversa per i lettori di report per isolare le autorizzazioni e impedire l'accesso non necessario.
  • Usare gli account locali per le installazioni di gruppi di lavoro: quando si installano componenti in un gruppo di lavoro, usare gli account locali per gli account utente. Evitare account di dominio in questo scenario.
  • Sfruttare le connessioni al servizio: usare le connessioni al servizio quando possibile per connettersi in modo sicuro ai servizi senza passare le variabili segrete direttamente alle compilazioni. Limitare le connessioni a casi d'uso specifici.
  • Monitorare l'attività dell'account del servizio: implementare il controllo e creare flussi di controllo per monitorare l'attività dell'account del servizio.

Per altre informazioni, vedere Tipi di connessione di Common Service.

Definire l'ambito delle connessioni al servizio

  • Definire l'ambito delle connessioni al servizio: limitare l'accesso definendo l'ambito delle connessioni al servizio Azure Resource Manager a risorse e gruppi specifici. Evitare di concedere diritti di collaboratore generali nell'intera sottoscrizione di Azure.
  • Usare la federazione dell'identità del carico di lavoro: eseguire l'autenticazione con le risorse di Azure usando OpenID Connect (OIDC) senza segreti. Creare automaticamente o manualmente la federazione dell'identità del carico di lavoro se si ha il ruolo Proprietario per la sottoscrizione di Azure, non si connettono ad ambienti Azure Stack o Azure US Government e le attività delle estensioni del Marketplace usate.
  • Gruppi di risorse di ambito: assicurarsi che i gruppi di risorse contengano solo le Macchine virtuali (VM) o le risorse necessarie per il processo di compilazione.
  • Evitare le connessioni al servizio classiche: scegliere connessioni moderne del servizio Azure Resource Manager invece di quella classica, che non prevede opzioni di ambito.
  • Usare account del servizio team specifici dello scopo: autenticare le connessioni al servizio usando account del servizio team specifici dello scopo per mantenere la sicurezza e il controllo.

Per altre informazioni, vedere Tipi di connessione di Common Service.

Scegliere il metodo di autenticazione corretto

Selezionare i metodi di autenticazione dalle origini seguenti:

Prendere in considerazione le entità servizio

Esplorare alternative come entità servizio e identità gestite:

  • Usare le entità servizio: rappresentare gli oggetti di sicurezza all'interno di un'applicazione Microsoft Entra. Definire le operazioni che un'applicazione può eseguire in un determinato tenant. Configurare durante la registrazione dell'applicazione nel portale di Azure. Configurare per accedere alle risorse di Azure, incluso Azure DevOps. Utile per le app che necessitano di accesso e controllo specifici.
  • Usare le identità gestite: simile all'entità servizio di un'applicazione. Specificare le identità per le risorse di Azure. Consenti ai servizi che supportano l'autenticazione di Microsoft Entra di condividere le credenziali. Azure gestisce automaticamente la gestione e la rotazione delle credenziali. Ideale per la gestione dei dettagli di accesso senza problemi.

Usare con moderazione le reti PAT

  • Definire l'ambito delle route PAT per ruoli specifici: assegnare solo le autorizzazioni necessarie per attività specifiche. Evitare di concedere l'accesso globale a più organizzazioni o repository per ridurre al minimo il rischio di uso improprio accidentale.
  • Evitare di scrivere o gestire le autorizzazioni per le compilazioni e le versioni: le reti PAW non devono avere autorizzazioni di scrittura o gestione per compilazioni, versioni o altre risorse critiche. La limitazione di queste autorizzazioni consente di evitare azioni indesiderate che potrebbero influire sulle pipeline o sulle distribuzioni.
  • Impostare le date di scadenza e mantenere i segreti delle reti ATS: impostare sempre una data di scadenza per i token di aggiornamento.set date and keep PAT secret: Always set an expiration date for PAT. Rivedirli e rinnovarli regolarmente in base alle esigenze. Trattare le reti PAT come critiche come password, mantenendole riservate ed evitando la condivisione pubblica o l'hardcoding nel codice dell'applicazione.
  • Evitare di impostare come hardcoding i PT nel codice dell'applicazione: invece di incorporare LET direttamente nel codice, usare file di configurazione sicuri o variabili di ambiente per archiviare e recuperare in modo dinamico LET. dinamicamente.
  • Controllare e revocare regolarmente le api PAT inutilizzate: gli amministratori devono esaminare periodicamente tutte le api REST usando le API REST. Revocare eventuali PT che non sono più necessari o che non soddisfano i criteri consigliati.

Per altre informazioni, vedere Gestire i criteri PAT con i criteri per gli amministratori e Usare LET.

Proteggere Gli artefatti di Azure

Proteggere Azure Boards

Proteggere Azure Pipelines

Criteri

  • Richiedi revisori esterni: assicurarsi che almeno un revisore esterno al richiedente originale per un processo di revisione completo. Il responsabile approvazione condivide la coproprietà delle modifiche e la responsabilità per eventuali effetti potenziali.
  • Richiedere la compilazione CI da passare: stabilire una linea di base per la qualità del codice richiedendo che la compilazione integrazione continua (CI) passi prima di unire una richiesta pull. I controlli CI includono l'linting del codice, gli unit test e le analisi di sicurezza.
  • Non consentire l'approvazione automatica: impedire al richiedente della richiesta pull originale di approvare le proprie modifiche per garantire un processo di revisione non distorto ed evitare conflitti di interesse.
  • Non consentire il completamento della richiesta pull con voti "wait" o "reject": impedire il completamento della richiesta pull anche se alcuni revisori votano per attendere o rifiutare, incoraggiare l'indirizzamento a tutti i commenti prima dell'unione.
  • Reimpostare i voti dei revisori sulle modifiche: reimpostare i voti dei revisori quando le modifiche recenti vengono spostate nella richiesta pull per assicurarsi che i revisori rivalutano il codice aggiornato.
  • Bloccare le pipeline di versione: limitare le pipeline di versione a rami specifici (in genere produzione o principale) per evitare distribuzioni accidentali da altri rami.
  • Imponi variabili impostabili in fase di coda: abilita l'opzione "Imponi tabella impostabile in fase di coda" per le variabili della pipeline per impedire agli utenti di eseguire l'override dei valori delle variabili durante l'esecuzione della pipeline.
  • Non consentire le sostituzioni di variabili nell'editor: per le variabili impostate nell'editor della pipeline, non consentire l'override utente per mantenere la coerenza e impedire modifiche impreviste.

Agenti

  • Concedere le autorizzazioni con moderazione: limitare le autorizzazioni al set di account più piccolo necessario per ridurre la superficie di attacco.
  • Configurare firewall restrittivi per gli agenti: 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: mantenere aggiornata la flotta di agenti aggiornando regolarmente gli agenti per garantire che il codice vulnerabile non sia in esecuzione, riducendo il rischio di sfruttamento.
  • 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. Consentire solo le credenziali nelle definizioni di compilazione associate al pool appropriato.

Definizioni

  • Usare YAML per le definizioni di pipeline: definire le pipeline usando YAML (Yet Another Markup Language) per una migliore tracciabilità e conformità alle linee guida per l'approvazione e alle procedure di controllo della versione.
  • Limitare l'accesso alle definizioni della pipeline: limitare l'accesso alla modifica delle definizioni di pipeline al minimo necessario per ridurre il rischio di modifiche accidentali o non autorizzate.

Input

  • Includere controlli per le variabili negli script di compilazione: implementare controlli all'interno degli script di compilazione per attenuare potenziali attacchi di inserimento dei comandi tramite variabili impostabili. Convalidare i valori di input e impedire comandi indesiderati o dannosi.
  • Limitare le variabili di compilazione "impostabili in fase di rilascio": ridurre al minimo il numero di variabili di compilazione impostabili in fase di rilascio per ridurre la superficie di attacco e semplificare la gestione della configurazione.

Attività

  • Evitare il recupero remoto delle risorse: quando possibile, evitare di recuperare risorse da URL esterni durante il processo di compilazione. Se sono necessarie risorse remote, usare il controllo delle versioni e il controllo hash per garantire l'integrità.
  • Evitare di registrare segreti: non registrare mai informazioni riservate, ad esempio segreti o credenziali, nei log di compilazione per impedire l'esposizione involontaria e la compromissione della sicurezza.
  • Usare Azure Key Vault per i segreti: invece di archiviare i segreti direttamente nelle variabili della pipeline, usare Azure Key Vault per gestire e recuperare i segreti in modo sicuro.
  • Limitare l'esecuzione di compilazioni su rami o tag arbitrari: per le pipeline critiche per la sicurezza, limitare l'esecuzione di compilazioni a qualsiasi ramo o tag. Definire rami o tag autorizzati specifici per impedire esecuzioni accidentali o non autorizzate.
  • Disabilitare l'ereditarietà per le autorizzazioni della pipeline: le autorizzazioni ereditate possono essere eccessivamente ampie e potrebbero non riflettere accuratamente le esigenze. Disabilitare l'ereditarietà e impostare le autorizzazioni in modo esplicito per allinearsi ai requisiti di sicurezza.
  • Limitare gli ambiti di autorizzazione del processo: limitare sempre gli ambiti di autorizzazione del processo al minimo necessario. Ottimizzare le autorizzazioni in base alle attività specifiche eseguite da ogni processo.

Repository e rami

  • Richiedere un numero minimo di revisori: abilitare i criteri per garantire che ogni richiesta pull riceva revisioni da almeno due responsabili approvazione, promuovendo la revisione completa del codice e la responsabilità.
  • Configurare criteri di sicurezza specifici del repository: personalizzare i criteri di sicurezza per ogni repository o ramo invece dei criteri a livello di progetto per ridurre i rischi, applicare gli standard di gestione delle modifiche e migliorare la qualità del codice.
  • Isolare i segreti di produzione in un insieme di credenziali delle chiavi separato: archiviare i segreti di produzione separatamente in un insieme di credenziali delle chiavi di Azure e limitare l'accesso a una base di necessità per mantenere la separazione dalle compilazioni non di produzione.
  • Separare gli ambienti di test dall'ambiente di produzione: evitare di combinare ambienti di test con la produzione per garantire che le credenziali e i segreti non vengano usati in contesti di non produzione.
  • Disabilita la copia tramite fork: la disabilitazione della fork consente di gestire la sicurezza impedendo la proliferazione dei fork, rendendo più semplice tenere traccia della sicurezza in tutte le copie.
  • Evitare di fornire segreti alle compilazioni fork: evitare di condividere segreti con compilazioni fork per mantenerli riservati e non esposti ai fork.
  • Prendere in considerazione l'attivazione manuale delle compilazioni fork: attivare manualmente le compilazioni per i fork invece di consentire ai trigger automatici di fornire un controllo migliore sui controlli di sicurezza.
  • Usare gli agenti ospitati da Microsoft per le compilazioni fork: usare gli agenti ospitati da Microsoft per le compilazioni fork man mano che vengono mantenuti e protetti.
  • Analizzare le definizioni di compilazione di produzione nei repository Git: controllare regolarmente le definizioni di compilazione di produzione archiviate nel repository Git del progetto per eventuali credenziali o informazioni riservate.
  • Configurare i controlli di controllo dei rami per il contesto di produzione: configurare i controlli di controllo dei rami per limitare l'uso di connessioni sensibili (ad esempio, prod-connection) alle pipeline in esecuzione nel contesto del ramo di produzione, garantendo un'autorizzazione appropriata e impedendo un uso improprio accidentale.

Per altre informazioni, vedere Altre considerazioni sulla sicurezza.

Proteggere Azure Repos

Proteggere i piani di test di Azure

Proteggere le integrazioni di GitHub

  • Usare il flusso OAuth invece dei TOKEN: disabilitare l'autenticazione basata su PAT per le connessioni al servizio GitHub e optare per il flusso OAuth per una migliore sicurezza e integrazione.
  • Evitare identità di amministratore o proprietario: non autenticare mai le connessioni al servizio GitHub usando un'identità che è un amministratore o proprietario di qualsiasi repository. Limitare le autorizzazioni al livello necessario.
  • Evitare le connessioni a gitHub con ambito completo: evitare l'uso di un token di accesso personale GitHub con ambito completo per autenticare le connessioni al servizio. Usare i token con le autorizzazioni minime necessarie.
  • Evitare account GitHub personali come connessioni al servizio: non usare account GitHub personali come connessioni al servizio in Azure DevOps. Creare invece account di servizio dedicati o usare account a livello di organizzazione.