Procedure consigliate per la sicurezza

Articolo
03/25/2024

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

Quando si lavora con informazioni e dati, in particolare in una soluzione basata sul cloud come Azure DevOps Services, la priorità della sicurezza deve essere sempre la preoccupazione principale. Anche se Microsoft mantiene la sicurezza dell'infrastruttura cloud sottostante, è responsabilità dell'utente configurare la sicurezza in Azure DevOps.

Anche se non è obbligatorio, incorporando le procedure consigliate durante l'uso di Azure DevOps è possibile migliorare l'esperienza e renderla più sicura. Sono stati compilate le procedure consigliate seguenti che mirano a proteggere l'ambiente Azure DevOps:

Protezione dell'ambiente Azure DevOps
Limitare l'accesso tramite autorizzazioni con ambito a livello di organizzazione/raccolta, progetto o oggetto
Mantenere un controllo rigoroso degli amministratori e dei gruppi di sicurezza
Definire l'ambito degli account del servizio e delle connessioni al servizio
Informazioni sulle procedure consigliate per l'autenticazione durante l'integrazione con Azure DevOps
Proteggere aree di prodotto specifiche e servizi associati, ad esempio Azure Artifacts, Azure Boards, Azure Pipelines, Azure Repos, Piani di test di Azure e integrazioni di GitHub.

Proteggere l'ambiente Azure DevOps

Rimozione di utenti

Se l'organizzazione usa account DEL servizio gestito, rimuovere gli utenti inattivi direttamente dall'organizzazione, in quanto non è possibile impedire l'accesso. In questo caso, non è possibile creare una query per gli elementi di lavoro assegnati all'account utente rimosso. Per altre informazioni, vedere Eliminare gli utenti da Azure DevOps.
Se l'organizzazione è connessa all'ID Microsoft Entra, è possibile disabilitare o eliminare l'account utente Microsoft Entra e lasciare attivo l'account utente di Azure DevOps. In questo modo, è possibile continuare a eseguire query sulla cronologia degli elementi di lavoro usando l'ID utente di Azure DevOps.
Revocare i PT utente.
Revocare tutte le autorizzazioni speciali che possono essere state concesse ai singoli account utente.
Riassegnare il lavoro agli utenti che si stanno rimuovendo ai membri del team correnti.

Usare Microsoft Entra ID

Integrare Azure DevOps con Microsoft Entra ID per avere un singolo piano per l'identità. La coerenza e una singola fonte autorevole aumentano la chiarezza e riducono i rischi di sicurezza derivanti da errori umani e complessità di configurazione. La governance fondamentale per la fine consiste nell'avere più assegnazioni di ruolo (con definizioni di ruolo diverse e ambiti di risorse diversi per gli stessi gruppi di Microsoft Entra). Senza Microsoft Entra ID, l'utente è esclusivamente responsabile del controllo dell'accesso dell'organizzazione.

L'uso di Microsoft Entra ID consente anche di accedere ad altre funzionalità di sicurezza, ad esempio l'autenticazione a più fattori o altri criteri di accesso condizionale.

Per altre informazioni, vedere gli articoli seguenti:

Esaminare gli eventi di controllo

Dopo aver creato un'organizzazione supportata da Microsoft Entra, è possibile attivare Il controllo nei criteri di sicurezza. Esaminare periodicamente gli eventi di controllo per monitorare e reagire a modelli di utilizzo imprevisti da parte degli amministratori e di altri utenti.

Proteggere la rete

A tale scopo, possono essere inclusi alcuni modi:

Configurare un elenco di indirizzi consentiti per limitare indirizzi IP specifici.
Usare sempre la crittografia.
Convalidare i certificati.
Implementare web application firewall (WAF), in modo che possano filtrare, monitorare e bloccare qualsiasi traffico dannoso basato sul Web da e verso Azure DevOps.
Per altre informazioni, vedere questa guida sulle procedure consigliate per la gestione delle applicazioni

Autorizzazioni con ambito

Il sistema gestisce le autorizzazioni a livelli diversi, ovvero singoli, raccolte, progetti e oggetti, e li assegna a uno o più gruppi predefiniti per impostazione predefinita.

Concedere solo agli utenti e ai servizi la quantità minima di accesso necessaria per eseguire le funzioni aziendali.
Disabilitare l'ereditarietà laddove possibile. A causa della natura predefinita dell'ereditarietà, gli utenti imprevisti possono ottenere l'accesso o le autorizzazioni. Per altre informazioni, vedere Ereditarietà.
Altre informazioni sulle autorizzazioni sono disponibili qui:

Autorizzazioni a livello di progetto

Limitare l'accesso ai progetti e ai repository per ridurre il rischio di perdita di informazioni riservate e la distribuzione di codice non sicuro nell'ambiente di produzione.
Usare i gruppi di sicurezza predefiniti o i gruppi di sicurezza personalizzati per gestire le autorizzazioni. Per altre informazioni, vedere Concedere o limitare le autorizzazioni per selezionare le attività.
Disabilitare "Consenti progetti pubblici" nelle impostazioni dei criteri dell'organizzazione per impedire a ogni utente dell'organizzazione di creare un progetto pubblico. Azure DevOps Services consente di modificare la visibilità dei progetti da pubblico a privato e viceversa. Se gli utenti non hanno eseguito l'accesso all'organizzazione, hanno accesso in sola lettura ai progetti pubblici. Se gli utenti hanno eseguito l'accesso, è possibile concedere l'accesso a progetti privati e apportare eventuali modifiche consentite.
Non consentire agli utenti di creare nuovi progetti.

Accesso guest esterno

Bloccare completamente l'accesso guest esterno disabilitando il criterio "Consenti l'invio di inviti a qualsiasi dominio". È consigliabile farlo se non c'è bisogno di affari.
Usare un indirizzo di posta elettronica o un nome dell'entità utente diverso (UPN) per gli account personali e aziendali, anche se è consentito. Questa azione elimina la sfida di disambiguare tra l'azienda e gli account personali quando il messaggio di posta elettronica/UPN è lo stesso.
Inserire tutti gli utenti guest esterni in un singolo gruppo Microsoft Entra e gestire le autorizzazioni di tale gruppo in modo appropriato. È possibile gestire e controllare facilmente in questo modo.
- Rimuovere le assegnazioni dirette in modo che le regole di gruppo si applichino a tali utenti. Per altre informazioni, vedere Aggiungere una regola di gruppo per assegnare i livelli di accesso.
- Rivalutare le regole regolarmente nella scheda Regole di gruppo della pagina Utenti. Chiarire se le modifiche apportate all'appartenenza a un gruppo in Microsoft Entra ID potrebbero influire sull'organizzazione. Microsoft Entra ID può richiedere fino a 24 ore per aggiornare l'appartenenza dinamica ai gruppi. Ogni 24 ore e ogni volta che una regola di gruppo cambia, le regole vengono rivalutate automaticamente nel sistema.
Per altre informazioni, vedere Guest B2B in Microsoft Entra ID.

Gestire i gruppi di sicurezza

Gruppi di utenti e sicurezza

Vedere le raccomandazioni seguenti per l'assegnazione delle autorizzazioni ai gruppi di sicurezza e ai gruppi di utenti.

Cosa fare	Cosa non fare
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.
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 Nega può eseguire l'override di un livello di autorizzazione Consenti.
Quando si aggiungono molti team, è consigliabile creare un gruppo personalizzato di team Amministrazione istrators in cui si alloca un subset delle autorizzazioni disponibili per Project Amministrazione istrators.	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.

Per altre informazioni, vedere Gruppi di utenti validi.

Accesso JUST-in-time per i gruppi di amministratori

È possibile modificare la configurazione dell'organizzazione o del progetto se si dispone dell'accesso a Project Collection Amministrazione istrator e Project Amministrazione istrator. Per proteggere l'accesso a questi gruppi di amministratori predefiniti, richiedere l'accesso JIT usando un gruppo di Microsoft Entra Privileged Identity Management (PIM).

Configurare l'accesso

Nota

Assicurarsi che qualsiasi utente con accesso con privilegi elevati usando un gruppo PIM abbia anche accesso standard all'organizzazione, in modo che possa visualizzare la pagina per aggiornare le autorizzazioni.

Usare l'accesso

Attivare l'accesso.
Aggiornare le autorizzazioni in Azure DevOps.
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

Verificare che gli account del servizio abbiano zero diritti di accesso interattivi.
Limitare i privilegi dell'account del servizio al minimo necessario.
Usare un'identità diversa per l'account lettore di report, se si usano account di dominio per gli account del servizio. Per altre informazioni, vedere Account e dipendenze del servizio.
Usare gli account locali per gli account utente, se si installa un componente in un gruppo di lavoro. Per altre informazioni, vedere Requisiti dell'account del servizio.
Usare le connessioni al servizio quando possibile. Le connessioni al servizio forniscono un meccanismo sicuro per connettersi a servizi diversi senza la necessità di passare direttamente le variabili segrete alla compilazione. - Limitare queste connessioni alla posizione specifica in cui devono essere usate e niente di più.
Monitorare l'attività dell'account del servizio e creare lo streaming di controllo. Il controllo consente di rilevare e reagire alle attività e agli accessi sospetti.
Per altre informazioni, vedere Tipi di connessione di Common Service.

Definire l'ambito delle connessioni al servizio

Definire l'ambito di Azure Resource Manager e altre connessioni al servizio, solo alle risorse e ai gruppi a cui devono accedere. Le connessioni al servizio non devono avere diritti di collaboratore generali per l'intera sottoscrizione di Azure.
Usare la federazione dell'identità del carico di lavoro per le connessioni al servizio Azure Resource Manager (ARM). La federazione delle identità del carico di lavoro consente di creare connessioni al servizio senza segreto in Azure Pipelines in Azure.
Non concedere agli utenti diritti di collaboratore generici o generali per la sottoscrizione di Azure.
Non usare le connessioni al servizio di Azure classico, perché non è possibile definire l'ambito delle autorizzazioni.
Assicurarsi che il gruppo di risorse contenga solo Macchine virtuali (VM) o risorse a cui deve accedere la compilazione.
Usare un account del servizio team specifico per lo scopo per autenticare una connessione al servizio.
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 e le identità gestite
Usare i token di accesso personale (PAT) con moderazione

Prendere in considerazione le entità servizio

Esplorare alternative come entità servizio e identità gestite che consentono di usare i token Microsoft Entra per accedere alle risorse di Azure DevOps. Tali token comportano un minor rischio quando vengono perse rispetto alle reti PAT e contengono vantaggi come una facile gestione delle credenziali.

Usare con moderazione le reti PAT

Se possibile, è consigliabile usare sempre i servizi di gestione delle identità per l'autenticazione anziché le chiavi crittografiche, perché la gestione sicura delle chiavi con il codice dell'applicazione è complessa e può causare errori come la pubblicazione accidentale di chiavi di accesso sensibili nei repository di codice pubblico come GitHub. Tuttavia, se è necessario usare token di accesso personale (PAT), prendere in considerazione le linee guida seguenti:

I PT devono essere sempre limitati a ruoli specifici.
Le reti AP non devono fornire l'accesso globale a più organizzazioni.
Le reti AP non devono concedere autorizzazioni di scrittura o gestione per le build o le versioni.
I token DI aggiornamento devono avere una data di scadenza e devono essere mantenuti segreti perché sono fondamentali come password.
Le reti AP non devono mai essere hardcoded nel codice dell'applicazione, anche se è tentata di farlo per semplificare il codice.
Amministrazione istrator devono controllare regolarmente tutti i PT usando LE API REST e revocano tutti gli elementi che non soddisfano i criteri precedenti.
Mantieni i tuoi TOKEN segreti. I token sono fondamentali come le password.
Archiviare i token in un luogo sicuro.
Non impostare token di codice rigido nelle applicazioni. Può essere tentabile semplificare il codice per ottenere un token per un lungo periodo di tempo e archiviarlo nell'applicazione, ma non farlo.
Assegnare ai token una data di scadenza.
Per altre informazioni, vedere gli articoli seguenti:
- Gestire i CRITERI con i criteri : per gli amministratori
- Usare i criteri di accesso di azure

Proteggere Gli artefatti di Azure

Assicurarsi di comprendere la differenza tra feed, progetti e amministratori della raccolta di progetti. Per altre informazioni, vedere Configurare le impostazioni di Azure Artifacts.
Per altre informazioni, vedere Impostare le autorizzazioni del feed.

Proteggere Azure Boards

Prima di personalizzare un processo, vedere Configurare e personalizzare Azure Boards .
Vedere gli articoli seguenti:

Proteggere Azure Pipelines

Usare estende i modelli.
Per altre informazioni su come impostare i livelli di autorizzazione per le pipeline, vedere Impostare le autorizzazioni della pipeline.
Per altre informazioni sulle procedure consigliate per la sicurezza di Azure Pipelines, vedere Protezione di Azure Pipelines.

Criteri

Richiedere almeno un revisore esterno al richiedente originale. Il responsabile approvazione condivide la coproprietà delle modifiche e deve essere tenuto ugualmente responsabile per qualsiasi potenziale impatto.
Richiedere il superamento della compilazione CI. Questo requisito è utile per stabilire la qualità del codice di base, tramite l'linting del codice, gli unit test e i controlli di sicurezza, ad esempio analisi di virus e credenziali.
Assicurarsi che il richiedente pull originale non possa approvare la modifica.
Non consentire il completamento di una richiesta pull ,anche se alcuni revisori votano per attendere o rifiutare.
Reimpostare i voti del revisore del codice quando vengono apportate modifiche recenti.
Bloccare le pipeline di versione eseguendole solo in rami di produzione specifici.
Abilitare "Imponi tabella impostabile in fase di coda per le variabili" nelle impostazioni della pipeline dell'organizzazione.
Non consentire agli utenti di eseguire l'override di questo valore durante l'esecuzione di questa pipeline, per le variabili impostate nell'editor.

Agenti

Concedere le autorizzazioni al minor numero possibile di account.
Avere il firewall più restrittivo che lascia gli agenti utilizzabili.
Aggiornare regolarmente i pool per assicurarsi che la flotta di compilazione non esegua codice vulnerabile che un attore malintenzionato possa sfruttare.
Usare un pool di agenti separato per gli artefatti di compilazione che vengono spediti o distribuiti nell'ambiente di produzione.
Segmentare il pool "sensibile" da pool senza distinzione e consentire solo l'uso delle credenziali nelle definizioni di compilazione bloccate in tale pool.

Definizioni

Gestire le definizioni di pipeline con YAML (Yet Another Markup Language). YAML è il metodo preferito per la gestione delle definizioni di pipeline, poiché fornisce tracciabilità per le modifiche e può seguire le linee guida per l'approvazione.
Proteggere la definizione della pipeline Modificare l'accesso al numero minimo di account.

Input

Includere controlli di integrità per le variabili negli script di compilazione. Un controllo di integrità può attenuare un attacco di inserimento dei comandi tramite le variabili impostabili.
Impostare il minor numero possibile di variabili di compilazione su "Impostabile in fase di rilascio".

Attività

Evitare di recuperare in remoto le risorse, ma, se necessario, usare il controllo delle versioni e l'hash.
Non registrare i segreti.
Non archiviare segreti nelle variabili della pipeline, usare Azure Key Vault. Analizzare regolarmente le pipeline di compilazione per assicurarsi che i segreti non vengano archiviati nelle variabili della pipeline di compilazione.
Non consentire agli utenti di eseguire compilazioni su rami o tag arbitrari nelle pipeline critiche per la sicurezza.
Disabilitare l'ereditarietà nella pipeline, poiché le autorizzazioni ereditate sono ampie e non riflettono accuratamente le esigenze per le autorizzazioni.
Limitare gli ambiti di autorizzazione del processo in tutti i casi.

Repository e rami

Impostare il criterio "Richiedi un numero minimo di revisori", in modo che ogni richiesta pull venga esaminata da almeno due responsabili approvazione.
Configurare criteri di sicurezza specifici per ogni repository o ramo, anziché a livello di progetto. I criteri di sicurezza riducono i rischi, applicano gli standard di gestione delle modifiche e migliorano la qualità del codice del team.
Archiviare i segreti di produzione in un insieme di credenziali delle chiavi separato e assicurarsi che l'accesso venga concesso solo in base alla necessità di mantenere separate le compilazioni non di produzione.
Non combinare gli ambienti di test con l'ambiente di produzione, incluso l'uso delle credenziali.
Disabilitare la copia fork. Più fork ci sono, più difficile è tenere traccia della sicurezza di ogni fork. Inoltre, un utente può creare facilmente una copia tramite fork di un repository nel proprio account privato.
Non fornire segreti alle compilazioni fork.
Prendere in considerazione l'attivazione manuale delle compilazioni fork.
Usare gli agenti ospitati da Microsoft per le compilazioni fork.
Per Git, controllare le definizioni di compilazione di produzione nel repository Git del progetto, in modo che possano essere analizzate per ottenere le credenziali.
Configurare un controllo del ramo in modo che solo le pipeline in esecuzione nel contesto del production ramo possano usare .prod-connection
Per altre informazioni, vedere Altre considerazioni sulla sicurezza.

Proteggere Azure Repos

Migliorare la qualità del codice con i criteri dei rami. Per altre informazioni sulle autorizzazioni e i criteri dei rami, vedere Impostare le autorizzazioni per i rami.

Proteggere i piani di test di Azure

Proteggere le integrazioni di GitHub

Disabilitare l'autenticazione basata su TOKEN di accesso personale, in modo che il flusso OAuth venga usato con la connessione al servizio GitHub.
Non autenticare mai le connessioni al servizio GitHub come identità che è un amministratore o proprietario di qualsiasi repository.
Non usare mai un token di accesso personale di GitHub per autenticare le connessioni al servizio GitHub con ambito completo.
Non usare un account GitHub personale come connessione al servizio con Azure DevOps.