Introduzione a autorizzazioni, accesso e gruppi di sicurezza

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

Quando si accede a una funzionalità Azure DevOps, è utile comprendere i concetti chiave seguenti.

  • Tutti gli utenti aggiunti a Azure DevOps vengono in genere aggiunti a uno o più gruppi di sicurezza.
  • Ai gruppi di sicurezza vengono assegnate autorizzazioni che consentono o negano l'accesso a una funzionalità.
  • I membri del gruppo di sicurezza ereditano le autorizzazioni assegnate al gruppo.
  • A ogni utente viene inoltre assegnato un livello di accesso che concede o limita l'accesso a funzionalità del portale Web selezionate.
  • Le autorizzazioni vengono impostate a vari livelli per la maggior parte degli oggetti, ad esempio repository, pipeline, percorsi di area e così via.
  • Altre autorizzazioni vengono gestite tramite assegnazioni basate sui ruoli, ad esempio il ruolo di amministratore del team, il ruolo di gestione delle estensioni e vari ruoli delle risorse della pipeline.
  • Infine, con l'introduzione di nuove funzionalità potrebbe essere necessario abilitare il flag di funzionalità per accedervi.

Ad esempio, i singoli collaboratori vengono aggiunti al gruppo di sicurezza Collaboratori che fornisce l'accesso in lettura e scrittura ai repository, al rilevamento del lavoro, alle pipeline e altro ancora. Inoltre, ai collaboratori viene concesso principalmente l'accesso Basic. Se è necessario l'accesso ai servizi di test, è possibile concedere loro l'accesso Avanzato o Basic Test Plans accesso. Le autorizzazioni possono essere applicate a uno o più oggetti specifici all'interno del progetto, ad esempio repository Git, rami, pipeline, percorsi di area e altro ancora. In caso contrario, possono essere applicate a un'intera organizzazione o raccolta. Ogni area funzionale usa i gruppi di sicurezza per semplificare la gestione nella distribuzione.

Gli amministratori gestiscono i gruppi di sicurezza e le autorizzazioni dal contesto di amministrazione del portale Web. I collaboratori gestiscono le autorizzazioni per gli oggetti creati o di cui sono proprietari anche dal portale Web. Le autorizzazioni vengono impostate automaticamente in base al gruppo a cui si aggiungono utenti o in base all'oggetto, al progetto, alla raccolta o a livello di server a cui si aggiungono utenti o gruppi.

Per altre informazioni, vedere le informazioni fornite in questo articolo e gli articoli seguenti:

Gruppi di sicurezza e appartenenza

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

  • Quando si aggiunge un gruppo di sicurezza personalizzato. È possibile creare gruppi di sicurezza personalizzati ai livelli seguenti:
    • A livello di oggetto, ad esempio per pipeline, repository, percorsi di area e altro ancora
    • A livello di progetto
    • Livello di organizzazione o raccolta
    • A livello di server (solo locale)
  • Quando si aggiunge un team, viene creato un gruppo di sicurezza del team

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

  • La gestione delle appartenenze supporta l'aggiunta di singoli account utente e gruppi ai gruppi di sicurezza predefiniti. Ogni gruppo predefinito è 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, una raccolta o un'organizzazione.

  • La gestione delle autorizzazioni controlla l'accesso ad attività funzionali specifiche 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 delle autorizzazioni corrispondono a Allow, Deny, Inherited allow, Inherited Deny e Not set. Per altre informazioni sull'ereditarietà, vedere Ereditarietà delle autorizzazioni e gruppi di sicurezza più avanti in questo articolo.

  • La gestione del livello di accesso controlla l'accesso alle funzionalità fornite tramite il portale Web, l'applicazione Web per Azure DevOps. In base a quanto acquistato per un utente, gli amministratori impostano il livello di accesso dell'utente su Basic, Basic + Test, VS Enterprise (in precedenza Avanzate) o Stakeholder.

Ogni area funzionale usa i gruppi di sicurezza per semplificare la gestione nella distribuzione. È possibile aggiungere utenti e gruppi tramite il contesto di amministrazione Web. Le autorizzazioni vengono impostate automaticamente in base al gruppo di sicurezza a cui si aggiungono utenti o in base all'oggetto, al progetto, alla raccolta o al livello di server a cui si aggiungono gruppi.

I membri del gruppo di sicurezza possono essere una combinazione di utenti, altri gruppi e Azure Active Directory gruppi.

I membri del gruppo di sicurezza possono essere una combinazione di utenti, altri gruppi e gruppi di Active Directory o un gruppo di lavoro.

È possibile creare gruppi locali o gruppi di Active Directory (AD) per gestire gli utenti. Se si decide di usare i gruppi, assicurarsi che l'appartenenza a tali gruppi sia limitata a utenti validi. Poiché l'appartenenza ai gruppi può essere modificata dai proprietari in qualsiasi momento, se tali proprietari non hanno Azure DevOps Server considerazione l'accesso al momento della creazione di tali gruppi, le modifiche apportate all'appartenenza possono causare effetti collaterali indesiderati all'interno del server.

La maggior parte degli utenti viene assegnata al gruppo Collaboratori per un progetto per fornire loro l'accesso alle funzionalità a cui devono accedere. Gli amministratori devono essere aggiunti al gruppo Project Collection Administrators o Project Administrators.

Active Directory e gruppi Azure Active Directory sicurezza

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

Se è necessario gestire solo un piccolo set di utenti, è possibile ignorare questo passaggio. Tuttavia, se si prevede che l'organizzazione può aumentare, è possibile configurare AD o Azure AD. Inoltre, se si prevede di pagare per servizi aggiuntivi, è necessario configurare Azure AD per l'uso con Azure DevOps per supportare la fatturazione.

Nota

Senza Azure AD, tutti Azure DevOps utenti devono accedere usando gli account Microsoft ed è necessario gestire l'accesso all'account da 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 le Azure Active Directory da usare con Azure DevOps Services, vedere configurare Connessione'organizzazione per Azure Active Directory.

Nota

Quando l'organizzazione è connessa Azure Active Directory, esistono diversi 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 aziendale Azure AD, vedere gli articoli seguenti:

Per configurare Active Directory per l'uso con Azure DevOps Server, vedere gli articoli seguenti:

In genere, è consigliabile installare Active Directory prima di installare Azure DevOps Server.

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.

  • Project Raccolta di utenti validi: tutti i membri aggiunti a gruppi a livello di organizzazione.
  • Project Utenti validi: tutti i membri aggiunti a un gruppo a livello di progetto.
  • Server \ Azure DevOps Utenti validi: tutti i membri aggiunti ai gruppi a livello di server.
  • ProjectCollectionName \ Project Utenti validi della raccolta: tutti i membri aggiunti ai gruppi a livello di raccolta.
  • NomeProgetto \ Project Utenti validi: tutti i membri aggiunti ai gruppi a livello di progetto.
  • Server \ Utenti validi di Team Foundation: tutti i membri aggiunti ai gruppi a livello di server.
  • ProjectCollectionName \ Project Utenti validi della raccolta: tutti i membri aggiunti ai gruppi a livello di raccolta.
  • NomeProgetto \ Project Utenti validi: tutti i membri aggiunti ai gruppi a livello di progetto.

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

Ciò significa che 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 di utenti validi, nessun membro del gruppo può accedere al progetto, alla raccolta o alla distribuzione, a seconda del gruppo impostato.

Project utente con ambito locale

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

Per limitare gli utenti selezionati, ad esempio stakeholder, Azure Active Directory utenti guest o membri di un gruppo di sicurezza specifico, è possibile abilitare la funzionalità Limita visibilità utente per i progetti in anteprima per l'organizzazione. Una volta abilitato, qualsiasi utente o gruppo aggiunto al gruppo utenti con ambito Project è limitato all'accesso alle pagine Impostazioni dell'organizzazione, ad eccezione di Panoramica e Progetti. e sono limitati all'accesso solo ai progetti a cui sono stati aggiunti.

Per abilitare questa funzionalità, vedere Gestire o abilitare le funzionalità.

Nota

Tutti i gruppi di sicurezza sono entità a livello di organizzazione, anche i gruppi che hanno solo autorizzazioni per un progetto specifico. Dal portale Web gli utenti che non hanno accesso a un progetto non possono visualizzare i gruppi che dispongono solo delle autorizzazioni per un progetto specifico. È tuttavia possibile individuare i nomi di tutti i gruppi in un'organizzazione usando 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 quali funzionalità sono visibili agli utenti nel portale Web e dipendono dalle licenze utente. le autorizzazioni controllano la capacità di un utente di connettersi Azure DevOps e usare le funzionalità in Azure DevOps. Se si sta tentando di concedere a un utente l'accesso alle funzionalità di gestione del portfolio Agile o test case, è necessario modificare i livelli di accesso enon le autorizzazioni.

L'impostazione del livello di accesso per utenti o gruppi non consente loro di accedere 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 abbiano sia le autorizzazioni che il livello di accesso necessari. A tale scopo, assicurarsi che siano aggiunti al progetto o a un team.

Autorizzazioni

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

Mapping delle immagini concettuali dei gruppi di sicurezza predefiniti ai livelli di autorizzazione, cloud

Come illustrato nell'immagine seguente, i gruppi di sicurezza definiti a livello di progetto e di raccolta possono essere assegnati alle autorizzazioni assegnate a livello di oggetto, progetto e raccolta. È possibile definire solo gruppi di sicurezza a livello di server per le autorizzazioni a livello di server.

Mapping delle immagini concettuali dei gruppi di sicurezza predefiniti ai livelli di autorizzazione, in locale

Immagine concettuale dei gruppi di sicurezza e dei livelli di autorizzazione, TFS-2018 e versioni precedenti

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

Stati di autorizzazione

A un'autorizzazione possono essere effettuate cinque assegnazioni. Concedono o limitano l'accesso come indicato.

  • L'utente o il gruppo dispone delle autorizzazioni per eseguire un'attività:
    • Consentito
    • Consenti ereditato
  • L'utente o il gruppo non dispone dell'autorizzazione per eseguire un'attività:
    • Nega
    • Rifiuta ereditato
    • Non impostato

Ecco cosa occorre sapere sulle impostazioni delle autorizzazioni:

  • Consenti o Nega concede o impedisce in modo esplicito agli utenti di eseguire attività specifiche e in genere vengono ereditate dall'appartenenza a gruppi.

  • Non impostata nega in modo implicito agli utenti la possibilità di eseguire attività che richiedono tale autorizzazione, ma consente l'appartenenza a un gruppo che dispone di tale autorizzazione impostata per avere la precedenza, nota anche come Consenti (ereditato) o Consenti ereditato e Nega (ereditato) o Nega ereditato.

  • Per la maggior parte dei gruppi e quasi tutte le autorizzazioni, Nega sostituisce Consenti. Se un utente appartiene a due gruppi e uno di essi dispone di un'autorizzazione specifica impostata su Nega, tale utente non è in grado di eseguire attività che richiedono tale autorizzazione anche se appartiene a un gruppo con tale autorizzazione impostata su Consenti.

    In alcuni casi, i membri dei gruppi Project Collection Administrators o Team Foundation Administrators possono sempre ottenere l'autorizzazione anche se l'autorizzazione viene negata in un gruppo diverso. In altri casi, ad esempio l'eliminazione di elementi di lavoro o le pipeline, l'essere un membro degli amministratori della raccolta di progetti non ignora le autorizzazioni negate impostate altrove.

  • La modifica di un'autorizzazione per un gruppo modifica tale autorizzazione per tutti gli utenti membri di tale gruppo. In altre parole, a seconda della dimensione del gruppo, è possibile influire sulla capacità di centinaia di utenti di eseguire i processi modificando semplicemente un'autorizzazione. Pertanto assicurarsi di conoscerne l'impatto 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 sottoposte a override. I gruppi di sicurezza assegnano un set di autorizzazioni ai membri del gruppo. Ad esempio, ai membri del gruppo Contributors o Project Administrators vengono assegnate le autorizzazioni impostate come Consentite per tali gruppi.

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

  • Gli utenti ereditano le autorizzazioni dai gruppi a cui appartengono. Quando un'autorizzazione è consentita per un utente direttamente o tramite l'appartenenza a un gruppo che dispone di tale autorizzazione e viene negata, direttamente o tramite l'appartenenza al gruppo, l'autorizzazione viene negata.

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

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

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

Nota

Per abilitare la nuova interfaccia utente per la pagina Project autorizzazioni Impostazioni, vedere Abilitare le funzionalità di anteprima.

Finestra di dialogo Autorizzazioni, pagina di anteprima, collegamento Why annotato.

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

L'interfaccia utente di anteprima per la pagina Project autorizzazioni Impostazioni non è disponibile per Azure DevOps Server 2020 e versioni precedenti.

Quando si assegnano le autorizzazioni

Fare:

  • Usare Azure Active Directory, Active Directory o Windows di sicurezza quando si gestiscono molti utenti.
  • Durante l'aggiunta di team, considerare le autorizzazioni da assegnare a responsabili del team, scrum master e altri membri del team che possono avere la necessità di creare e modificare percorsi area, percorsi e iterazione e query.
  • Quando si aggiungono molti team, è consigliabile creare un gruppo personalizzato Amministratori del team in cui si alloca un subset delle autorizzazioni disponibili per Project amministratori .
  • Valutare la possibilità di concedere alle cartelle di query degli elementi di lavoro l'autorizzazione Collaborazione a utenti o gruppi che richiedono la possibilità di creare e condividere query elemento di lavoro per il progetto.

Non:

  • Non assegnare un'autorizzazione Nega al gruppo Project Collection Administrators o Project Administrators a qualsiasi livello
  • 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 di utenti validi. Se si rimuove o si imposta l'autorizzazione Visualizza informazioni a livello di istanza su Nega per uno dei gruppi Utenti validi, nessun utente del gruppo sarà in grado di accedere al progetto, alla raccolta o alla distribuzione, a seconda del gruppo impostato.
  • Non assegnare autorizzazioni con il nome "Assegna solo agli account del servizio" agli account utente.

Autorizzazioni basate sui ruoli

Con le autorizzazioni basate sui ruoli, gli account utente vengono assegnati a un ruolo e a ogni ruolo vengono assegnate una o più autorizzazioni. Ecco i ruoli principali e i collegamenti per altre informazioni.

Flag di funzionalità

Accesso da selezionare. Le nuove funzionalità sono controllate dai flag di funzionalità. Periodicamente, Azure DevOps Services introduce nuove funzionalità posizionandole dietro un flag di funzionalità. Le funzionalità in un'anteprima privata richiedono che il proprietario dell'organizzazione richieda che la funzionalità sia attivata. Altre funzionalità possono essere introdotte come funzionalità di anteprima che gli utenti generici possono abilitare o disabilitare.

Per altre informazioni, vedere Gestire o abilitare le funzionalità.

Passaggi successivi