Informazioni su sicurezza, autenticazione e autorizzazione
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Azure DevOps usa vari concetti di sicurezza per garantire che solo gli utenti autorizzati possano accedere a funzionalità, funzioni e dati. Gli utenti ottengono l'accesso ad Azure DevOps tramite l'autenticazione delle credenziali di sicurezza e l'autorizzazione dei diritti dell'account per accedere a funzionalità o funzioni specifiche.
Questo articolo si basa sulle informazioni fornite in Introduzione alle autorizzazioni, all'accesso e ai gruppi di sicurezza. Gli amministratori possono trarre vantaggio dalla comprensione dei tipi di account, dei metodi di autenticazione, dei metodi di autorizzazione e dei criteri usati per proteggere Azure DevOps.
Tipi di account
- Utenti
- Proprietario dell'organizzazione
- Account di servizio
- Entità servizio o identità gestite
- Agenti di processo
Autenticazione
- Credenziali dell'utente
- Autenticazione di Windows
- Autenticazione a due fattori (2FA)
- Autenticazione della chiave SSH
- Token di accesso personali
- Configurazione di Oauth
- Active Directory Authentication Library
Autorizzazione
- Appartenenza al gruppo di sicurezza
- Controllo degli accessi in base al ruolo
- Livelli di accesso
- Flag di funzionalità
- Spazi dei nomi e autorizzazioni di sicurezza
Criteri
- URL dell'informativa sulla privacy
- Criteri di sicurezza e connessione delle applicazioni
- Criteri utente
- Repository Git e criteri di ramo
Tipi di account
- Utenti
- Account di servizio
- Entità servizio o identità gestite
- Agenti di processo
Autenticazione
- Credenziali dell'utente
- Autenticazione di Windows
- Autenticazione a due fattori (2FA)
- Autenticazione della chiave SSH
- Token di accesso personali
- Configurazione di Oauth
- Active Directory Authentication Library
Autorizzazione
- Appartenenza al gruppo di sicurezza
- Autorizzazioni basate sui ruoli
- Livelli di accesso
- Flag di funzionalità
- Spazi dei nomi e autorizzazioni di sicurezza
Criteri
- Repository Git e criteri di ramo
Importante
Azure DevOps non supporta l'autenticazione delle credenziali alternative. Se si usano ancora credenziali alternative, è consigliabile passare a un metodo di autenticazione più sicuro.
Sia Azure DevOps Services (cloud) che Azure DevOps Server (locale) supportano lo sviluppo di software dalla pianificazione alla distribuzione. Sfruttano la piattaforma distribuita come servizio e i servizi di Microsoft Azure, inclusi i database SQL di Azure, per offrire un servizio affidabile e disponibile a livello globale per i progetti.
Per altre informazioni su come Microsoft garantisce che i progetti di Azure DevOps Services siano sicuri, disponibili, sicuri e privati, vedere la panoramica sulla protezione dei dati di Azure DevOps Services.
Account
Anche se gli account utente umani sono l'obiettivo principale, Azure DevOps supporta anche vari altri tipi di account per operazioni diverse. Tra questi sono inclusi i tipi di account seguenti:
- Proprietario dell'organizzazione: creatore di un'organizzazione di Azure DevOps Services o proprietario assegnato. Per trovare il proprietario dell'organizzazione, vedere Cercare il proprietario dell'organizzazione.
- Account di servizio: organizzazione interna di Azure DevOps usata per supportare un servizio specifico, ad esempio il servizio pool di agenti, PipelinesSDK. Per le descrizioni degli account del servizio, vedere Gruppi di sicurezza, account di servizio e autorizzazioni.
- Entità servizio o identità gestite: applicazioni Microsoft Entra o identità gestite aggiunte all'organizzazione per eseguire azioni per conto di un'applicazione di terze parti. Alcune entità servizio fanno riferimento all'organizzazione interna di Azure DevOps per supportare le operazioni interne.
- Agenti di processo: account interni usati per eseguire processi specifici in base a una pianificazione regolare.
- Account di terze parti: account che richiedono l'accesso per supportare web hook, connessioni al servizio o altre applicazioni di terze parti.
Negli articoli relativi alla sicurezza gli "utenti" fanno riferimento a tutte le identità aggiunte all'hub utenti, che possono includere utenti umani e entità servizio.
- Account di servizio: organizzazione interna di Azure DevOps usata per supportare un servizio specifico, ad esempio il servizio pool di agenti, PipelinesSDK. Per le descrizioni degli account del servizio, vedere Gruppi di sicurezza, account di servizio e autorizzazioni.
- Entità servizio o identità gestite: applicazioni Microsoft Entra o identità gestite aggiunte all'organizzazione per eseguire azioni per conto di un'applicazione di terze parti. Alcune entità servizio fanno riferimento all'organizzazione interna di Azure DevOps per supportare le operazioni interne.
- Agenti di processo: account interni usati per eseguire processi specifici in base a una pianificazione regolare.
- Account di terze parti: account che richiedono l'accesso per supportare web hook, connessioni al servizio o altre applicazioni di terze parti.
Il modo più efficace per gestire gli account consiste nell'aggiungerli ai gruppi di sicurezza.
Nota
Il proprietario dell'organizzazione e i membri del gruppo Project Collection Administrators hanno accesso completo a quasi tutte le funzionalità e le funzioni.
Autenticazione
L'autenticazione verifica l'identità di un account in base alle credenziali fornite durante l'accesso ad Azure DevOps. Questi sistemi si integrano con e si basano sulle funzionalità di sicurezza degli altri sistemi seguenti:
- Microsoft Entra ID
- Account Microsoft (account del servizio gestito)
- Active Directory (AD)
Microsoft Entra ID e MSA supportano l'autenticazione cloud. È consigliabile usare Microsoft Entra ID per la gestione di un gruppo di utenti di grandi dimensioni. Per una base utenti di piccole dimensioni che accede all'organizzazione Azure DevOps, gli account Microsoft sono sufficienti. Per altre informazioni, vedere Informazioni sull'accesso ad Azure DevOps con Microsoft Entra ID.
Per le distribuzioni locali, Ad è consigliato per la gestione di un gruppo di utenti di grandi dimensioni. Per altre informazioni, vedere Configurare i gruppi da usare nelle distribuzioni locali.
Metodi di autenticazione, integrazione con altri servizi e app
Altre applicazioni e servizi possono integrarsi con Azure DevOps. Per accedere all'account senza richiedere ripetutamente le credenziali utente, le app possono usare i metodi di autenticazione seguenti:
Token di accesso personali (PAT) per generare token per conto dell'utente:
- Accedere a risorse o attività specifiche, ad esempio compilazioni o elementi di lavoro
- Client come Xcode e NuGet che richiedono nomi utente e password come credenziali di base e non supportano l'account Microsoft e le funzionalità di Microsoft Entra, come l'autenticazione a più fattori
- Accesso alle API REST di Azure DevOps
Azure DevOps OAuth per generare token per conto degli utenti per l'accesso alle API REST. Le API Accounts e Profiles supportano solo OAuth.
Autenticazione SSH per generare manualmente le chiavi di crittografia quando si usa Linux, macOS o Windows che esegue Git per Windows e non è possibile usare gestioni credenziali Git o PAT per l'autenticazione HTTPS.
Entità servizio o identità gestite per generare token Microsoft Entra per conto di un'applicazione o di un servizio, in genere automatizzando i flussi di lavoro che devono accedere alle risorse di Azure DevOps. La maggior parte delle azioni eseguite tradizionalmente da un account del servizio e un token di accesso personale possono essere eseguite usando un'entità servizio o un'identità gestita.
Per impostazione predefinita, l'account o la raccolta consente di accedere a tutti i metodi di autenticazione. È possibile limitare l'accesso limitando in modo specifico ogni metodo. Quando si nega l'accesso a un metodo di autenticazione, nessuna app può usare tale metodo per accedere all'account. Qualsiasi app che in precedenza aveva accesso riceve un errore di autenticazione e non può accedere all'account.
Per altre informazioni, vedere gli articoli seguenti:
Autorizzazione
L'autorizzazione verifica che l'identità che prova a connettersi abbia le autorizzazioni necessarie per accedere a un servizio, una funzionalità, una funzione, un oggetto o un metodo. L'autorizzazione si verifica sempre dopo la riuscita dell'autenticazione. Se una connessione non è autenticata, non riesce prima che vengano eseguiti controlli di autorizzazione. Anche se l'autenticazione ha esito positivo, un'azione specifica potrebbe comunque non essere consentita se l'utente o il gruppo non dispone dell'autorizzazione.
L'autorizzazione dipende dalle autorizzazioni assegnate all'utente, direttamente o tramite l'appartenenza a un gruppo di sicurezza o a un ruolo di sicurezza. I livelli di accesso e i flag di funzionalità possono anche gestire l'accesso a funzionalità specifiche. Per altre informazioni su questi metodi di autorizzazione, vedere Introduzione alle autorizzazioni, all'accesso e ai gruppi di sicurezza.
Spazi dei nomi e autorizzazioni di sicurezza
Gli spazi dei nomi di sicurezza determinano i livelli di accesso degli utenti per azioni specifiche sulle risorse.
- Ogni famiglia di risorse, ad esempio gli elementi di lavoro o i repository Git, ha uno spazio dei nomi univoco.
- Ogni spazio dei nomi contiene zero o più elenchi di controllo di accesso (ACL).
- Ogni ACL include un token, un flag di ereditarietà e voci di controllo di accesso (ACL).
- Ogni ACE ha un descrittore di identità, una maschera di bit delle autorizzazioni consentite e una maschera di bit delle autorizzazioni negate.
Per altre informazioni, vedere Informazioni di riferimento su spazi dei nomi e autorizzazioni per la sicurezza.
Criteri di sicurezza
Per proteggere l'organizzazione e il codice, è possibile impostare vari criteri. In particolare, è possibile abilitare o disabilitare i criteri seguenti:
Generali
- URL dell'informativa sulla privacy: specifica un URL che collega al documento personalizzato che descrive come gestire la privacy dei dati guest interni ed esterni. Per altre informazioni, vedere Aggiungere un URL dell'informativa sulla privacy per l'organizzazione.
Criteri di sicurezza e connessione delle applicazioni
Usare i criteri del tenant di Microsoft Entra per limitare la creazione di nuove organizzazioni solo agli utenti desiderati. Questo criterio viene disattivato per impostazione predefinita e valido solo quando l'organizzazione è connessa all'ID Microsoft Entra. Per altre informazioni, vedere Limitare la creazione dell'organizzazione.
I criteri seguenti determinano l'accesso concesso a utenti e applicazioni all'interno delle organizzazioni:
- Accesso alle applicazioni non Microsoft tramite OAuth.
- Accesso all'autenticazione SSH.
- Consenti progetti pubblici: se abilitata, gli utenti possono creare progetti pubblici che consentono ai membri di un progetto e agli utenti che non hanno eseguito l'accesso in sola lettura, l'accesso limitato agli artefatti e ai servizi del progetto. Per altre informazioni, vedere Rendere pubblico il progetto.
- Registra eventi di controllo: attivare la possibilità di tenere traccia degli eventi e dei flussi di controllo per l'organizzazione.
- Abilitare la convalida dei criteri di accesso condizionale (CAP) di Microsoft Entra.
Criteri utente
- Accesso guest esterno (valido solo quando l'organizzazione è connessa a Microsoft Entra ID.): se abilitata, gli inviti possono essere inviati agli account di posta elettronica degli utenti che non sono membri dell'ID Microsoft Entra del tenant tramite la pagina Utenti . Per altre informazioni, vedere Aggiungere utenti esterni all'organizzazione.
- Consenti agli amministratori del team e del progetto di invitare nuovi utenti: valido solo quando l'organizzazione è connessa a Microsoft Entra ID. Se abilitato, gli amministratori del team e del progetto possono aggiungere utenti tramite la pagina Utenti . Per altre informazioni, vedere Limitare gli inviti dei nuovi utenti da Project e Team Administrators.
- Richiedi accesso: valido solo quando l'organizzazione è connessa a Microsoft Entra ID. Se abilitata, gli utenti possono richiedere l'accesso a una risorsa. Una richiesta genera una notifica tramite posta elettronica agli amministratori che richiedono la verifica e l'accesso, in base alle esigenze. Per altre informazioni, vedere Aggiungere utenti esterni all'organizzazione.
- Invitare gli utenti di GitHub: valido solo quando l'organizzazione non è connessa all'ID Microsoft Entra. Se abilitata, gli amministratori possono aggiungere utenti in base ai propri account utente GitHub dalla pagina Utenti . Per altre informazioni, vedere Connettersi a GitHub/domande frequenti.
Gruppo Utenti con ambito progetto
Per impostazione predefinita, gli utenti aggiunti a un'organizzazione possono visualizzare tutte le informazioni e le impostazioni del progetto, inclusi elenchi di utenti, elenchi di progetti, dettagli di fatturazione, dati di utilizzo e altro ancora.
Importante
- Le funzionalità di visibilità limitate descritte in questa sezione si applicano solo alle interazioni tramite il portale Web. Con le API REST o
azure devops
i comandi dell'interfaccia della riga di comando, i membri del progetto possono accedere ai dati limitati. - Gli utenti guest membri del gruppo limitato con accesso predefinito in Microsoft Entra ID non possono cercare gli utenti con la selezione utenti. Quando la funzionalità di anteprima è disattivata per l'organizzazione o quando gli utenti guest non sono membri del gruppo limitato, gli utenti guest possono cercare tutti gli utenti di Microsoft Entra, come previsto.
Per limitare determinati utenti, ad esempio stakeholder, utenti guest di Microsoft Entra o membri di un gruppo di sicurezza specifico, è possibile abilitare la funzionalità Limita visibilità utente e collaborazione a progetti specifici per l'organizzazione. Dopo l'abilitazione, tutti gli utenti o i gruppi aggiunti al gruppo Utenti con ambito progetto sono limitati nei modi seguenti:
- È possibile accedere solo alle pagine Panoramica e Progetti delle impostazioni organizzazione.
- Può connettersi e visualizzare solo i progetti a cui sono stati aggiunti in modo esplicito.
- È possibile selezionare solo identità utente e gruppo aggiunte in modo esplicito al progetto a cui sono connessi.
Per altre informazioni, vedere Gestire l'organizzazione, Limitare la visibilità degli utenti per i progetti e altre funzionalità di anteprima e Gestire le funzionalità di anteprima.
Avviso
L'abilitazione della funzionalità Limita visibilità utente e collaborazione a progetti specifici impedisce agli utenti con ambito progetto di cercare utenti aggiunti all'organizzazione tramite l'appartenenza al gruppo Microsoft Entra, anziché tramite un invito esplicito dell'utente. Si tratta di un comportamento imprevisto e una risoluzione è in corso. Per risolvere questo problema, disabilitare la funzionalità Limita visibilità utente e collaborazione a progetti specifici per l'organizzazione.
Repository Git e criteri di ramo
Per proteggere il codice, è possibile impostare vari criteri di repository e ramo Git. Per altre informazioni, consulta gli articoli seguenti.
Sicurezza di Azure Repos e Azure Pipelines
Poiché i repository e le pipeline di compilazione e rilascio comportano problemi di sicurezza univoci, vengono usate funzionalità aggiuntive oltre le funzionalità descritte in questo articolo. Per altre informazioni, consulta gli articoli seguenti.
- Protezione di Azure Pipelines
- Pianificare come proteggere le pipeline YAML
- Protezione del repository
- Risorse della pipeline
- Raccomandazioni per strutturare i progetti nella pipeline in modo sicuro
- Sicurezza tramite modelli
- Come usare in modo sicuro variabili e parametri nella pipeline
- Raccomandazioni per proteggere l'infrastruttura condivisa in Azure Pipelines
- Altre considerazioni sulla sicurezza