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 altre informazioni, vedere Procedure consigliate per la sicurezza.

Livelli di accesso

Tutti gli utenti di Azure DevOps hanno un livello di accesso, che concede o limita l'accesso a funzionalità specifiche 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 in Azure DevOps appartengono a uno o più gruppi di sicurezza predefiniti. I gruppi di sicurezza ottengono autorizzazioni assegnate che consentono o negano l'accesso alle funzionalità o alle attività.

• I membri ereditano le autorizzazioni assegnate al proprio gruppo di sicurezza.
• Le autorizzazioni vengono definite a livelli diversi: organizzazione/raccolta, progetto o oggetto.
• Alcune autorizzazioni vengono gestite tramite assegnazioni basate su ruoli( ad esempio, amministratore del team, gestione delle estensioni o ruoli delle risorse della pipeline).
• Gli amministratori possono definire gruppi di sicurezza personalizzati per gestire le autorizzazioni per aree funzionali diverse.

Per altre informazioni, vedere Procedure consigliate per la sicurezza, sicurezza e gruppi di utenti.

La gestione delle autorizzazioni in Azure DevOps prevede due gruppi chiave: Amministratori raccolta progetti e Amministratori progetto.

Amministratori raccolta progetti:

• Conservare l'autorità più alta all'interno di un'organizzazione o di una raccolta di progetti.
• Eseguire tutte le operazioni per l'intera raccolta.
• Gestire impostazioni, criteri e processi per l'organizzazione.
• Creare e gestire tutti i progetti e le estensioni.

Amministratori progetto:

• Operare a livello di progetto.
• Gestire gruppi di sicurezza e autorizzazioni dalle impostazioni di Project nel portale Web.
• I collaboratori gestiscono le autorizzazioni per oggetti specifici creati all'interno del progetto.

Stati dell'autorizzazione

Assegnare autorizzazioni per concedere o limitare l'accesso:

L'utente o il gruppo dispone dell'autorizzazione:

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

L'utente o il gruppo non dispone dell'autorizzazione:

• 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).

I membri dei gruppi Amministratori raccolta progetti o Amministratori di Team Foundation possono sempre ricevere autorizzazioni anche se negate in un altro gruppo. Gli esempi seguenti illustrano ulteriormente questo scenario:

• Un utente potrebbe comunque accedere alle impostazioni del progetto o gestire gli utenti. Tuttavia, per le attività come l'eliminazione degli elementi di lavoro o la gestione della pipeline, l'appartenenza al gruppo Amministratori raccolta progetti non esegue l'override delle autorizzazioni Nega impostate altrove.
• Se un utente ha negato l'autorizzazione per eliminare gli elementi di lavoro in un progetto specifico, non può eliminare elementi di lavoro anche se fanno parte del gruppo Project Collection Administrators. Analogamente, se le autorizzazioni della pipeline vengono negate, non possono gestire o eseguire pipeline nonostante il proprio ruolo amministrativo.

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 nodo padre o 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 Deny tramite un altro gruppo, l'autorizzazione Deny ha la precedenza.
• I membri degli amministratori della raccolta di progetti o degli amministratori di Team Foundation 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.

Regole di ereditarietà e specificità delle autorizzazioni:

• Le autorizzazioni esplicite hanno sempre la precedenza su quelle ereditate.
• Le autorizzazioni impostate in un nodo di livello superiore vengono ereditate da tutti i sottonodi, a meno che non venga eseguito l'override esplicito.
• Se un'autorizzazione non è consentita o negata in modo esplicito per un sottonodo, eredita l'autorizzazione dal relativo elemento padre.
• Se un'autorizzazione viene impostata in modo esplicito per un sottonodo, 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à. L'autorizzazione più specifica ha la precedenza se esistono autorizzazioni in conflitto.

Esempio:

• 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 selezionare 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 Lettori, Collaboratori o Amministratori progetto.

Project	Organizzazione o raccolta
- Amministratori di compilazione -Contributori - Amministratori progetto - Utenti validi del progetto -Lettori - Release Administrators - TeamName Team	- Amministratori raccolta progetti - Amministratori compilazione raccolta 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 con attività di 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 Amministratori progetto.

Per gli utenti a cui viene richiesto di gestire le funzionalità a livello di organizzazione o raccolta, ad esempio progetti, criteri, processi, criteri di conservazione, pool di agente e distribuzione e estensioni, aggiungerle al gruppo Amministratori raccolta 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 Connettere l'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 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

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.

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

Nota

I gruppi di sicurezza vengono gestiti a livello di organizzazione, anche se vengono usati per progetti specifici. A seconda delle autorizzazioni utente, alcuni gruppi potrebbero essere nascosti nel portale Web. Per visualizzare tutti i nomi di gruppo all'interno di un'organizzazione, è possibile usare 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 Administrators o Project Collection Administrators possono gestire tutti gli strumenti del team per tutti i team.

Funzionalità di anteprima

I flag di funzionalità controllano l'accesso alle nuove funzionalità. Azure DevOps introduce periodicamente nuove funzionalità 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 sulla sicurezza, l'autenticazione e l'autorizzazione
• Autorizzazioni e gruppi di riferimento
• Aggiungere e gestire gruppi di sicurezza