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

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.

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.

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 .

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.

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.

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.

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.

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.

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

Articoli correlati