Informazioni su autorizzazioni e gruppi di sicurezza

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

Questo articolo illustra i livelli di accesso e le autorizzazioni tramite ereditarietà, gruppi di sicurezza, ruoli e altro ancora in Azure DevOps.

Per una panoramica delle autorizzazioni predefinite, vedere Informazioni di riferimento rapido sulle autorizzazioni predefinite. Per una descrizione di ogni gruppo di sicurezza predefinito, vedere Gruppi di sicurezza, account di servizio e informazioni di riferimento sulle autorizzazioni.

Livelli di accesso

A tutti gli utenti aggiunti ad Azure DevOps viene assegnato 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.

Per concedere a un utente l'accesso alle funzionalità di gestione del portfolio Agile o alla gestione dei test case, modificare i livelli di accesso, non le autorizzazioni. Per altre informazioni, vedere Informazioni sui livelli di accesso.

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.

Quando si tratta di gestire le autorizzazioni in Azure DevOps, sono coinvolti due gruppi chiave: Project Collection Amministrazione istrators e Project Amministrazione istrators. Vediamolo:

Project Collection Amministrazione istrators:

• Queste persone hanno il massimo livello di autorità all'interno di un'organizzazione o di una raccolta di progetti.
• Possono eseguire tutte le operazioni per l'intera raccolta.
• Le loro responsabilità includono la gestione di impostazioni, criteri e processi per l'organizzazione.
• Inoltre, possono creare e gestire tutti i progetti e le estensioni all'interno dell'organizzazione.

Project Amministrazione istrators:

• I Amministrazione istratori di progetto operano a livello di progetto.
• Gestiscono i gruppi di sicurezza e le autorizzazioni principalmente dalle impostazioni del progetto del portale Web.
• I collaboratori, d'altra parte, gestiscono le autorizzazioni per oggetti specifici creati all'interno del progetto.

Stati di autorizzazione

È possibile assegnare le autorizzazioni nei modi seguenti, concedendo o limitando 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 dei gruppi di Amministrazione istrators o Team Foundation Amministrazione istrators potrebbero 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, influisce su tutti gli utenti di tale gruppo. Anche una singola modifica delle autorizzazioni può influire su centinaia di utenti, quindi è fondamentale considerare gli effetti potenziali prima di apportare eventuali modifiche.

Ereditarietà delle autorizzazioni

Le autorizzazioni seguono una gerarchia, consentendo l'ereditarietà da un elemento padre o eseguendo l'override.

• Ereditarietà dei gruppi: gli utenti ereditano le autorizzazioni dai gruppi a cui appartengono. Se un utente dispone di un'autorizzazione Consenti direttamente o tramite l'appartenenza al gruppo, ma dispone anche di un'autorizzazione Nega tramite un altro gruppo, l'autorizzazione Nega ha la precedenza. Tuttavia, 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 (ad eccezione delle operazioni degli elementi di lavoro).
• Ereditarietà a livello di oggetto: le autorizzazioni a livello di oggetto (assegnate a nodi come aree, iterazioni, cartelle di controllo della versione e cartelle di query degli elementi di lavoro) vengono ereditate nella gerarchia.

Ad esempio, suddividere l'ereditarietà delle autorizzazioni e le regole di specificità e ricordare, le autorizzazioni esplicite hanno sempre la precedenza su quelle ereditate:

• Quando le autorizzazioni di un utente vengono impostate su un nodo di livello superiore (area-1), tali autorizzazioni vengono ereditate da tutti i sottonodi (area-1/area-secondaria-1) a meno che non venga eseguito esplicitamente l'override.
• Se un'autorizzazione non è consentita o negata in modo esplicito per un sottonodo, eredita l'autorizzazione dal relativo elemento padre.
• Tuttavia, se un'autorizzazione viene impostata in modo esplicito per un sottonodo (area-1/area secondaria-1), l'autorizzazione dell'elemento padre non viene ereditata, indipendentemente dal fatto che sia consentita o negata. Specificità:
• Nella gerarchia degli oggetti la specificità supera l'ereditarietà. Ciò significa che, se esistono autorizzazioni in conflitto, l'autorizzazione più specifica ha la precedenza.
• Si consideri ad esempio un utente:
  • Nega in modo esplicito in 'area-1' (nodo padre).
  • Consentire in modo esplicito "area-1/sub-area-1" (nodo figlio).
• In questo caso, l'utente riceve un elemento Allow on 'area-1/sub-area-1', ignorando l'elemento Deny ereditato dal nodo padre.

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

Una nuova finestra mostra le informazioni di ereditarietà per tale autorizzazione.

Gruppi di sicurezza e appartenenza

I gruppi di sicurezza assegnano autorizzazioni specifiche ai membri.

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

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 .

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.

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.
• La gestione a livello di accesso controlla l'accesso alle funzionalità del portale Web. In base all'acquisto 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ù efficiente popolare questi gruppi usando l'ID Microsoft Entra per Azure DevOps Services e Active Directory (AD) o i gruppi di utenti windows per Azure DevOps Server. Questo approccio consente di gestire l'appartenenza ai gruppi e le autorizzazioni in modo più efficace in più computer.

Se è sufficiente gestire un piccolo set di utenti, è possibile ignorare questo passaggio. Tuttavia, se si prevede che l'organizzazione possa crescere, è consigliabile configurare Active Directory o Microsoft Entra ID. Inoltre, se si prevede di usare servizi aggiuntivi, è essenziale 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, 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, è possibile definire e gestire vari criteri dell'organizzazione per migliorare la sicurezza e semplificare l'accesso alle applicazioni. Per altre informazioni, vedere Informazioni sulla sicurezza, criteri di sicurezza.

Per gestire l'accesso dell'organizzazione con Microsoft Entra ID, vedere gli 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. Per 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 seguenti.

• 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 forniscono principalmente l'accesso in lettura, ad esempio Visualizza risorse di compilazione, Visualizza informazioni a livello di progetto e Visualizza informazioni a livello di raccolta.

Tutti gli utenti aggiunti a un progetto possono visualizzare gli oggetti in altri progetti all'interno di una raccolta. Per 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 di 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, dettagli di fatturazione, dati di utilizzo e altro ancora, a cui è possibile accedere 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 utenti specifici, 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, qualsiasi utente o gruppo aggiunto al gruppo Utenti con ambito progetto non può accedere alle pagine delle impostazioni dell'organizzazione, ad eccezione di Panoramica e progetti. Inoltre, hanno accesso solo ai progetti a cui vengono 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 potrebbero 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.

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, a livello di progetto e le risorse della pipeline a livello di raccolta.
• Il ruolo di amministratore del team Gli amministratori del team sono in grado di gestire tutti gli strumenti del team.

Per altre informazioni, vedere Informazioni sui ruoli di sicurezza.

L'immagine seguente illustra il modo in cui i gruppi di sicurezza definiti a livello di progetto e raccolta possono assegnare autorizzazioni a oggetti, progetti e organizzazione.

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

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 Deny potrebbe 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.

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
• Informazioni di riferimento su autorizzazioni e gruppi
• Strumenti di gestione della sicurezza e delle autorizzazioni
• Aggiungere e gestire gruppi di sicurezza