Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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. La combinazione di entrambi determina l'accesso dell'utente 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. Ciascuna piattaforma sfrutta l'infrastruttura e i servizi di Platform as a Service di Microsoft Azure, inclusi i database SQL di Azure, per offrire un servizio affidabile e disponibile a livello globale per i tuoi 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:
- 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.
Autenticazione
Per accedere all'account senza chiedere ripetutamente il nome utente e la password, è possibile usare uno dei metodi di autenticazione disponibili. Ciò è utile per accedere all'account a livello di codice anziché tramite il sito Web o se si è uno sviluppatore di app che si basa sulle API REST di Azure DevOps. Alcuni dei meccanismi di autenticazione più diffusi includono:
- OAuth per creare applicazioni che eseguono azioni per conto degli utenti dell'app. Gli utenti devono fornire il consenso all'app. Microsoft Entra OAuth è consigliato per le nuove app.
- I principali di servizio possono essere utilizzati per creare app o strumenti che automatizzano i flussi di lavoro e accedono regolarmente alle risorse dell'organizzazione. Usare questa identità dell'applicazione per rilasciare token Microsoft Entra per conto dell'applicazione stessa.
- I token di accesso personale (PAT) possono essere usati per le richieste ad hoc o la creazione anticipata di prototipi. Non è consigliabile per lo sviluppo di app a lungo termine perché possono essere facilmente trapelate e usate in modo dannoso quando trapelano. Alcuni clienti sono ancora dipendenti dai PATs e ora hanno
Suggerimento
Ricordarsi di archiviare sempre le credenziali in modo sicuro.
Per impostazione predefinita, l'organizzazione consente l'accesso a tutti i metodi di autenticazione. Gli amministratori dell'organizzazione possono limitare l'accesso a questi metodi di autenticazione disabilitando i criteri di sicurezza. Gli amministratori tenant possono ridurre ancora di più il rischio PAT (token di accesso personale) limitando i modi in cui queste possono essere create.
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 abilitare o disabilitare vari criteri se si è un amministratore a livello di organizzazione (amministratore della raccolta progetti o amministratore di tenant di Azure DevOps), a seconda dei criteri. Alcuni importanti da considerare includono:
- Specificare un URL dell'informativa sulla privacy che descrive come gestire la privacy dei dati guest interni ed esterni.
- Determinare se gli utenti dell'organizzazione devono essere autorizzati a creare progetti pubblici.
Se l'organizzazione è connessa all'ID Microsoft Entra, sono disponibili altre funzionalità di sicurezza per l'organizzazione.
- Limitare la creazione dell'organizzazione a utenti specifici.
- Invitare ospiti esterni all'organizzazione
- Consentire agli amministratori del team e del progetto di invitare nuovi utenti
- Abilitare la convalida dei criteri di accesso condizionale ( CAP).
- Tenere traccia di eventi e flussi di controllo nell'organizzazione.
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.
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, qualsiasi utente o gruppo aggiunto al gruppo Project-Scoped Utenti è limitato nei modi seguenti:
- È possibile accedere solo alle pagine Panoramica e Progetti delle impostazioni organizzazione.
- Può connettersi e visualizzare solo i progetti aggiunti in modo esplicito a.
- È 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
Quando si usa questa funzionalità di anteprima, considerare le limitazioni seguenti:
- 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 del gruppo limitato possono selezionare solo gli utenti che vengono aggiunti in modo esplicito ad Azure DevOps e non agli utenti che hanno accesso tramite l'appartenenza al gruppo Microsoft Entra.
- Gli utenti guest membri del gruppo limitato con accesso predefinito in Microsoft Entra ID non possono cercare gli utenti con la selezione utenti.
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 altre funzionalità oltre alle 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