Introduzione alle autorizzazioni e all'accesso

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

Questo articolo illustra come gestire i livelli di accesso e le autorizzazioni tramite ereditarietà, gruppi di sicurezza, ruoli e altro ancora in Azure DevOps. Per iniziare, comprendere i concetti chiave seguenti.

• Informazioni sulle autorizzazioni:

  • Tutti gli utenti aggiunti ad Azure DevOps vengono aggiunti a uno o più gruppi di sicurezza predefiniti.
  • Ai gruppi di sicurezza vengono assegnate autorizzazioni che consentono o negano l'accesso a una funzionalità o a un'attività.
  • I membri di un gruppo di sicurezza ereditano le autorizzazioni assegnate al gruppo.
  • Le autorizzazioni vengono definite a livelli diversi: organizzazione/raccolta, progetto o oggetto.
  • Altre autorizzazioni vengono gestite tramite assegnazioni basate su ruoli, ad esempio amministratore del team, gestione delle estensioni e vari ruoli delle risorse della pipeline.
  • Amministrazione istrator possono definire gruppi di sicurezza personalizzati per gestire le autorizzazioni per aree funzionali diverse.

• Informazioni sui livelli di accesso:

  • Tutti gli utenti aggiunti ad Azure DevOps vengono assegnati a un livello di accesso, che concede o limita l'accesso per selezionare le funzionalità del portale Web.
  • Esistono tre livelli di accesso principali: Stakeholder, Basic e Basic + Test Plans.
  • L'accesso degli stakeholder consente di accedere gratuitamente a un numero illimitato di utenti a un set limitato di funzionalità. Per altre informazioni, vedere Informazioni di riferimento rapido sull'accesso di tipo Stakeholder.

• Informazioni sulle funzionalità di anteprima:
  • Man mano che vengono introdotte nuove funzionalità, gli utenti possono abilitarli o disabilitarli tramite le funzionalità di anteprima per accedervi.
  • Un piccolo subset di nuove funzionalità viene gestito a livello di organizzazione e abilitato o disabilitato dai proprietari dell'organizzazione.

Ad esempio, la maggior parte degli utenti di Azure DevOps viene aggiunta al gruppo di sicurezza Collaboratori e ha concesso il livello di accesso Basic . Il gruppo Collaboratori fornisce l'accesso in lettura e scrittura ai repository, al rilevamento del lavoro, alle pipeline e altro ancora. L'accesso di base consente l'accesso a tutte le funzionalità e le attività per l'uso di Azure Boards, Azure Repos, Azure Pipelines e Azure Artifacts. Agli utenti che richiedono l'accesso per gestire i piani di test di Azure è necessario concedere l'accesso Basic + Test Plans o Advanced .

Gli amministratori devono essere aggiunti al gruppo Amministratori raccolta di progetti o Amministratori progetto. Amministrazione istrator gestiscono gruppi di sicurezza e autorizzazioni dal portale Web, principalmente da Impostazioni del progetto. I collaboratori gestiscono anche le autorizzazioni per gli oggetti creati dal portale Web.

Per una panoramica delle autorizzazioni predefinite, vedere Informazioni di riferimento rapido sulle autorizzazioni predefinite.

Gruppi di sicurezza e appartenenza

Con la creazione di un'organizzazione, una raccolta o un progetto, Azure DevOps crea un set di gruppi di sicurezza predefiniti, a cui vengono assegnate automaticamente le autorizzazioni predefinite. Sono definiti più gruppi di sicurezza con le azioni seguenti:

• Quando si creano gruppi di sicurezza personalizzati ai livelli seguenti:
  • A livello di progetto
  • A livello di organizzazione o raccolta
  • A livello di server (solo locale)
• Quando si aggiunge un team, viene creato un gruppo di sicurezza del team

Non è possibile creare un gruppo di sicurezza a livello di oggetto, ma è possibile assegnare un gruppo personalizzato a un livello di oggetto e assegnare autorizzazioni a tale livello. Per altre informazioni, vedere Impostare le autorizzazioni a livello di oggetto.

Gruppi di sicurezza predefiniti

I gruppi di sicurezza seguenti sono definiti per impostazione predefinita per ogni progetto e organizzazione. In genere si aggiungono utenti o gruppi ai gruppi Reader, Contributors o Project Amministrazione istrators.

Project

Organizzazione o raccolta

- Creare Amministrazione istrator -Contributori - Project Amministrazione istrators - Utenti validi del progetto -Lettori - Rilascio di Amministrazione istrator - TeamName Team

- Amministrazione istrator della raccolta di progetti - Amministrazione istratori di compilazione della raccolta di progetti - Account del servizio di compilazione raccolta progetti - Account del servizio proxy di raccolta progetti - Account del servizio raccolta progetti - Account del servizio di test della raccolta di progetti - Raccolta progetti utenti validi - Utenti con ambito progetto - Gruppo di servizi di sicurezza

Per una descrizione di ognuno di questi gruppi, vedere Gruppi di sicurezza, account di servizio e autorizzazioni. Per le assegnazioni di autorizzazioni predefinite effettuate ai gruppi di sicurezza predefiniti più comuni, vedere Autorizzazioni e accesso predefiniti.

Per gli utenti a cui viene assegnata la gestione delle funzionalità a livello di progetto, ad esempio team, aree e percorsi di iterazione, repository, hook del servizio e endpoint del servizio, aggiungerli al gruppo Project Amministrazione istrators. Per gli utenti a cui è stata eseguita la gestione delle funzionalità a livello di organizzazione o raccolta, ad esempio progetti, criteri, processi, criteri di conservazione, pool di agenti e di distribuzione e estensioni, aggiungerle al gruppo di Amministrazione istrator della raccolta di progetti. Per altre informazioni, vedere Informazioni sulle impostazioni a livello di utente, team, progetto e organizzazione.

Per una descrizione di ogni gruppo e di ogni autorizzazione, vedere Informazioni di riferimento su Autorizzazioni e gruppi, Gruppi.

Gestione a livello di appartenenza, autorizzazione e accesso

Azure DevOps controlla l'accesso tramite queste tre aree funzionali connesse:

• Gestione delle appartenenze supporta l'aggiunta di singoli account utente e di gruppi a gruppi di sicurezza predefiniti. Ogni gruppo predefinito viene associato a un set di autorizzazioni predefinite. Tutti gli utenti aggiunti a qualsiasi gruppo di sicurezza vengono aggiunti al gruppo Utenti validi. Un utente valido è un utente che può connettersi a un progetto, a una raccolta o a un'organizzazione.

• Gestione delle autorizzazioni controlla l'accesso a specifiche attività funzionali a diversi livelli del sistema. Le autorizzazioni a livello di oggetto impostano le autorizzazioni per un file, una cartella, una pipeline di compilazione o una query condivisa. Le impostazioni di autorizzazione corrispondono a Allow, Deny, Inherited allow, Inherited deny, System allow, System deny e Not set. Per altre informazioni, vedere Ereditarietà delle autorizzazioni e gruppi di sicurezza più avanti in questo articolo.

• La gestione a livello di accesso controlla l'accesso alle funzionalità del portale Web. In base a ciò che è stato acquistato per un utente, gli amministratori impostano il livello di accesso dell'utente su Stakeholder, Basic, Basic + Test o Visual Studio Enterprise (in precedenza Avanzate).

Ogni area funzionale usa i gruppi di sicurezza per semplificare la gestione all'interno della distribuzione. Gli utenti e i gruppi vengono aggiunti tramite il contesto di amministrazione Web. Le autorizzazioni vengono impostate automaticamente in base al gruppo di sicurezza a cui si aggiungono utenti. In alternativa, le autorizzazioni ottengono in base all'oggetto, al progetto, alla raccolta o al livello del server a cui si aggiungono gruppi.

I membri dei gruppi di sicurezza possono essere costituiti da una combinazione di utenti, altri gruppi e gruppi di Microsoft Entra.

Gruppi di sicurezza di Active Directory e Microsoft Entra

È possibile popolare i gruppi di sicurezza aggiungendo singoli utenti. Tuttavia, per semplificare la gestione, è più semplice se si popolano questi gruppi usando l'ID Microsoft Entra per Azure DevOps Services e Active Directory (AD) o i gruppi di utenti di Windows per Azure DevOps Server. Questo metodo consente di gestire l'appartenenza ai gruppi e le autorizzazioni in modo più efficiente in più computer.

Se è necessario gestire solo un piccolo set di utenti, è possibile ignorare questo passaggio. Tuttavia, se prevedi che l'organizzazione possa crescere, potresti voler configurare Active Directory o Microsoft Entra ID. Inoltre, se si prevede di pagare per servizi aggiuntivi, è necessario configurare Microsoft Entra ID per l'uso con Azure DevOps per supportare la fatturazione.

Nota

Senza Microsoft Entra ID, tutti gli utenti di Azure DevOps devono accedere usando account Microsoft ed è necessario gestire l'accesso dell'account in base ai singoli account utente. Anche se si gestisce l'accesso all'account usando gli account Microsoft, è necessario configurare una sottoscrizione di Azure per gestire la fatturazione.

Per configurare Microsoft Entra ID per l'uso con Azure DevOps Services, vedere Connessione'organizzazione all'ID Microsoft Entra.

Quando l'organizzazione è connessa all'ID Microsoft Entra, esistono molti criteri dell'organizzazione che è possibile abilitare o disabilitare per proteggere l'organizzazione. Per altre informazioni, vedere Informazioni su sicurezza, autenticazione e autorizzazione, Criteri di sicurezza.

Per gestire l'accesso dell'organizzazione con Microsoft Entra ID, fare riferimento agli articoli seguenti:

• Aggiungi o elimina utenti utilizzando Microsoft Entra ID
• Risolvere i problemi di accesso con Microsoft Entra ID

Azure DevOps registra le modifiche apportate a un gruppo Microsoft Entra entro un'ora da tale modifica in Microsoft Entra ID. Tutte le autorizzazioni ereditate tramite l'appartenenza al gruppo vengono aggiornate. Se si vuole aggiornare l'appartenenza a Microsoft Entra e le autorizzazioni ereditate in Azure DevOps, disconnettersi e quindi eseguire nuovamente l'accesso o attivare un aggiornamento per rivalutare l'autorizzazione.

Gruppi di utenti validi

Quando si aggiungono account di utenti direttamente a un gruppo di sicurezza, questi vengono aggiunti automaticamente a uno dei gruppi di utenti validi.

• Utenti validi per la raccolta di progetti: tutti i membri aggiunti a un gruppo a livello di organizzazione.
• Utenti validi progetto: tutti i membri aggiunti a un gruppo a livello di progetto.

Le autorizzazioni predefinite assegnate a questi gruppi sono principalmente limitate all'accesso in lettura, ad esempio Visualizzare le risorse di compilazione, Visualizzare le informazioni a livello di progetto e Visualizzare le informazioni a livello di raccolta.

Tutti gli utenti aggiunti a un progetto possono visualizzare gli oggetti in altri progetti all'interno di una raccolta. Se è necessario limitare l'accesso alla visualizzazione, è possibile impostare restrizioni tramite il nodo del percorso dell'area.

Se si rimuove o si nega l'autorizzazione Visualizza informazioni a livello di istanza per uno dei gruppi Utenti validi, nessun membro del gruppo è in grado di accedere al progetto, alla raccolta o alla distribuzione, a seconda del gruppo impostato.

Gruppo Utenti con ambito progetto

Per impostazione predefinita, gli utenti aggiunti a un'organizzazione possono visualizzare tutte le informazioni e le impostazioni del progetto. Queste impostazioni includono l'elenco di utenti, l'elenco di progetti, i dettagli di fatturazione, i dati di utilizzo e altro ancora a cui si accede tramite le impostazioni dell'organizzazione.

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 gli utenti selezionati, ad esempio stakeholder, utenti guest di Microsoft Entra o membri di un determinato gruppo di sicurezza, è 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 non possono accedere alle pagine delle impostazioni dell'organizzazione, ad eccezione di Panoramica e Progetti, e sono limitati ad accedere solo ai progetti a cui sono stati aggiunti.

Avviso

Quando la funzionalità Limita visibilità utente e collaborazione a progetti specifici è abilitata per l'organizzazione, gli utenti con ambito progetto non sono in grado di cercare gli 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 si sta lavorando a una risoluzione. Per risolvere automaticamente questo problema, disabilitare la funzionalità Limita visibilità utente e collaborazione a progetti specifici per l'organizzazione.

Per altre informazioni, vedere Gestire le funzionalità di anteprima.

Nota

I gruppi di sicurezza appartengono al livello di organizzazione, anche se accedono solo a un progetto specifico. Alcuni gruppi possono essere nascosti nel portale Web a seconda delle autorizzazioni utente. È possibile trovare tutti i nomi di gruppo in un'organizzazione con lo strumento dell'interfaccia della riga di comando di Azure devops o le API REST. Per altre informazioni, vedere Aggiungere e gestire gruppi di sicurezza.

Livelli di accesso

I livelli di accesso controllano le funzionalità visibili agli utenti nel portale Web. L'accesso dipende dalle licenze utente.

Se si vuole concedere a un utente l'accesso alle funzionalità di gestione del portfolio Agile o di gestione dei test case, modificare i livelli di accesso, non le autorizzazioni.

L'impostazione del livello di accesso per utenti o gruppi non fornisce loro l'accesso a un progetto o al portale Web. Solo gli utenti o i gruppi aggiunti a un team o a un gruppo di sicurezza possono connettersi a un progetto e al portale Web. Assicurarsi che gli utenti dispongano sia delle autorizzazioni che del livello di accesso di cui hanno bisogno. A tale scopo, assicurarsi che vengano aggiunti al progetto o a un team.

Autorizzazioni

Come illustrato nell'immagine seguente, i gruppi di sicurezza definiti a livello di progetto e raccolta possono essere assegnati alle autorizzazioni assegnate a livello di oggetto, progetto e organizzazione.

Per una descrizione di ogni gruppo di sicurezza predefinito, vedere Gruppi di sicurezza, account di servizio e autorizzazioni.

Stati di autorizzazione

Un'autorizzazione può avere le assegnazioni seguenti. Concedono o limitano l'accesso come indicato.

L'utente o il gruppo dispone delle autorizzazioni per eseguire un'attività:

• Consenti
• Consenti (ereditato)
• Consenti (sistema)

L'utente o il gruppo non dispone dell'autorizzazione per eseguire un'attività:

• Nega
• Nega (ereditato)
• Nega (sistema)
• Non impostato

Stato autorizzazione	Descrizione
Consenti	Concede esplicitamente agli utenti di eseguire attività specifiche e non viene ereditata dall'appartenenza al gruppo.
Consenti (ereditato)	Concede ai membri del gruppo di eseguire attività specifiche.
Consenti (sistema)	Concede l'autorizzazione che ha la precedenza prima delle autorizzazioni utente. Non modificabile e archiviato in un database di configurazione, invisibile agli utenti.
Nega	Impedisce esplicitamente agli utenti di eseguire attività specifiche e non viene ereditata dall'appartenenza al gruppo. Per la maggior parte dei gruppi e per quasi tutte le autorizzazioni, Nega ha la precedenza su Consenti. Se un utente appartiene a due gruppi e uno di essi dispone di un set di autorizzazioni specifico su Nega, tale utente non può eseguire attività che richiedono tale autorizzazione anche se appartengono a un gruppo con tale autorizzazione impostata su Consenti.
Nega (ereditato)	Limita i membri del gruppo a eseguire attività specifiche. Esegue l'override di un consenti esplicito.
Nega (sistema)	Limita l'autorizzazione che ha la precedenza prima delle autorizzazioni utente. Non modificabile e archiviato in un database di configurazione, invisibile agli utenti.
Non impostato	Nega implicitamente agli utenti la possibilità di eseguire attività che richiedono tale autorizzazione, ma consente l'appartenenza a un gruppo che dispone di tale autorizzazione per avere la precedenza, nota anche come Consenti (ereditata) o Nega (ereditata).

In alcuni casi, i membri della raccolta di progetti Amministrazione istrators o i gruppi di team foundation Amministrazione istrators possono sempre ottenere l'autorizzazione anche se viene negata tale autorizzazione in un gruppo diverso. In altri casi, ad esempio l'eliminazione dell'elemento di lavoro o le pipeline, il fatto di essere membro del gruppo Di Amministrazione istrators di Project non ignora le autorizzazioni Nega impostate altrove.

Avviso

Quando si modifica un'autorizzazione per un gruppo, viene modificata l'autorizzazione per tutti gli utenti membri di tale gruppo. A seconda delle dimensioni del gruppo, è possibile influire sulla capacità di centinaia di utenti di svolgere il proprio lavoro modificando una sola autorizzazione. Assicurarsi quindi di comprendere i potenziali effetti prima di apportare una modifica.

Ereditarietà delle autorizzazioni e gruppi di sicurezza

Alcune autorizzazioni vengono gestite tramite una gerarchia. All'interno di questa gerarchia, le autorizzazioni possono essere ereditate dall'elemento padre o sottoposto a override. I gruppi di sicurezza assegnano un set di autorizzazioni a tali membri del gruppo. Ad esempio, ai membri del gruppo Collaboratori o del gruppo Project Amministrazione istrators vengono assegnate le autorizzazioni impostate su Consentito per tali gruppi.

Se un'autorizzazione non è consentita o negata direttamente per un utente, può essere ereditata nei modi seguenti.

• Gli utenti ereditano le autorizzazioni dai gruppi a cui appartengono. Quando un utente dispone di un'autorizzazione di appartenenza diretta o di gruppo Consenti , un'autorizzazione di appartenenza diretta o di gruppo Nega ne esegue l'override.

  I membri di Project Collection Amministrazione istrators o Team Foundation Amministrazione istrators mantengono la maggior parte delle autorizzazioni consentite, anche se appartengono ad altri gruppi che negano tali autorizzazioni. Le autorizzazioni per l'operazione degli elementi di lavoro sono l'eccezione a questa regola.

• Le autorizzazioni a livello di oggetto assegnate per i nodi di una gerarchia, ovvero aree, iterazioni, cartelle di controllo della versione, cartelle di query degli elementi di lavoro, vengono ereditate nella gerarchia. Ovvero, le autorizzazioni di un utente impostate su area-1 vengono ereditate da area-1/sub-area-1, se la stessa autorizzazione non è consentita o negata in modo esplicito per area-1/sub-area-1. Se un'autorizzazione viene impostata in modo esplicito per un oggetto, ad esempio area-1/sub-area-1, il nodo padre non viene ereditato, indipendentemente dal fatto che venga negato o consentito. Se non è impostata, le autorizzazioni per tale nodo vengono ereditate dal predecessore più vicino con l'autorizzazione impostata in modo esplicito. Infine, nella gerarchia degli oggetti, la specificità prevale sull'ereditarietà. Ad esempio, un utente le cui autorizzazioni sono impostate in modo esplicito su Nega su 'area-1' ma sono impostate in modo esplicito su Consenti per 'area-1/sub-area-1' riceve un'opzione Consenti su 'area-1/sub-area-1'.

Per comprendere perché viene ereditata un'autorizzazione, è possibile sospendere un'impostazione di autorizzazione e quindi scegliere Perché? Per aprire una pagina Sicurezza , vedere Visualizzare le autorizzazioni.

Nota

Per abilitare la pagina di anteprima delle impostazioni delle autorizzazioni del progetto, vedere Abilitare le funzionalità di anteprima.

Pagina anteprima

Verrà visualizzata una nuova finestra di dialogo che mostra le informazioni sull'ereditarietà per tale autorizzazione.

Pagina corrente

Verrà visualizzata una nuova finestra che mostra le informazioni sull'ereditarietà per tale autorizzazione.

Procedure consigliate per le autorizzazioni

Fare:

• Usa Microsoft Entra ID, Active Directory o gruppi di sicurezza di Windows quando gestisci un numero elevato di utenti.
• Quando si aggiunge un team, prendere in considerazione le autorizzazioni da assegnare ai lead del team, ai master scrum e ad altri membri del team. Prendere in considerazione chi crea e modifica i percorsi di area, i percorsi di iterazione e le query.
• Quando si aggiungono molti team, è consigliabile creare un gruppo personalizzato di team Amministrazione istrators in cui è possibile allocare un subset delle autorizzazioni disponibili per Project Amministrazione istrators.
• 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.

Che cosa non fare:

• Non aggiungere utenti a più gruppi di sicurezza, che contengono livelli di autorizzazione diversi. In alcuni casi, un livello di autorizzazione Nega può eseguire l'override di un livello di autorizzazione Consenti.
• Non modificare le assegnazioni predefinite effettuate ai gruppi Utenti validi. Se l'autorizzazione Visualizza informazioni a livello di istanza per uno dei gruppi Utenti validi viene rimossa o impostata su Nega, nessun utente del gruppo potrà accedere al progetto, alla raccolta o alla distribuzione, a seconda del gruppo impostato.
• Non assegnare ad account utente autorizzazioni che sono destinate solo agli account del servizio.

Autorizzazioni basate sui ruoli

Con le autorizzazioni basate sui ruoli, si assegnano account utente o gruppi di sicurezza a un ruolo, con ogni ruolo a cui è stata assegnata una o più autorizzazioni. Ecco i ruoli principali e i collegamenti ad altre informazioni.

• Ruoli di sicurezza dell'artefatto o del feed di pacchetti: i ruoli supportano vari livelli di autorizzazione per modificare e gestire i feed dei pacchetti.
• Ruolo Di gestione estensioni del Marketplace: i membri del ruolo Manager possono installare le estensioni e rispondere alle richieste di installazione delle estensioni.
• Ruoli di sicurezza della pipeline: diversi ruoli vengono usati per gestire le risorse della libreria, le risorse della pipeline a livello di progetto e di raccolta.
• Il ruolo di amministratore del team Gli amministratori del team sono in grado di gestire tutti gli strumenti del team.

I membri dei gruppi project Amministrazione istrators o Project Collection Amministrazione istrators possono gestire tutti gli strumenti del team per tutti i team.

Funzionalità di anteprima

I flag di funzionalità controllano l'accesso per selezionare nuove funzionalità. Azure DevOps introduce periodicamente nuove funzionalità inserendole dietro un flag di funzionalità. I membri del progetto e i proprietari dell'organizzazione possono abilitare o disabilitare le funzionalità di anteprima. Per altre informazioni, vedere Gestire o abilitare le funzionalità.

Passaggi successivi

Autorizzazioni e accesso predefiniti

Articoli correlati

• Risolvere i problemi relativi all'accesso e alle autorizzazioni
• Informazioni su sicurezza, autenticazione e autorizzazione
• Cos'è Microsoft Entra ID?
• Informazioni su Microsoft Entra ID
• Informazioni di riferimento su autorizzazioni e gruppi
• Strumenti di gestione della sicurezza e delle autorizzazioni
• Aggiungere utenti a un'organizzazione
• Aggiungere e gestire gruppi di sicurezza
• Gestire token, spazi dei nomi, autorizzazioni
• Funzionamento della fatturazione
• Configurare la fatturazione per il pagamento per utenti, pipeline e test di carico basati sul cloud in Azure DevOps