Informazioni su sicurezza, autenticazione e autorizzazione

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

Azure DevOps usa una serie di concetti di sicurezza per garantire l'accesso solo a coloro che devono avere accesso a funzionalità, funzioni e dati. Gli account ottengono l'Azure DevOps tramite l'autenticazione delle credenziali di sicurezza e l'autorizzazione dei diritti dell'account per accedere a una funzionalità o a una funzione.

Questo articolo si basa sulle informazioni fornite in Introduzione alle autorizzazioni, all'accesso e ai gruppi di sicurezza. Gli amministratori traggono vantaggio dalla comprensione dei tipi di account, dei metodi di autenticazione, dei metodi di autorizzazione e dei criteri usati per Azure DevOps.


Tipi di account

  • Utenti
  • Proprietario dell'organizzazione
  • Account di servizio
  • Entità servizio
  • Agenti di processo

autenticazione

  • Credenziali dell'utente
  • Autenticazione di Windows
  • Autenticazione a due fattori (2FA)
  • Autenticazione con chiave SSH
  • Token di accesso personali
  • Configurazione Oauth
  • Libreria di autenticazione di Active Directory

Autorizzazione

  • Appartenenza al gruppo di sicurezza
  • Controllo degli accessi in base al ruolo
  • Livelli di accesso
  • Flag di funzionalità
  • Spazi dei nomi di & autorizzazioni

Criteri

  • URL dell'informativa sulla privacy
  • Criteri di sicurezza e connessione dell'applicazione
  • Criteri utente
  • Criteri del repository Git e dei rami

'::': moniker range="< azure-devops"

Tipi di account

  • Utenti
  • Account di servizio
  • Entità servizio
  • Agenti di processo

autenticazione

  • Credenziali dell'utente
  • Autenticazione di Windows
  • Autenticazione a due fattori (2FA)
  • Autenticazione con chiave SSH
  • Token di accesso personali
  • Configurazione Oauth
  • Libreria di autenticazione di Active Directory

Autorizzazione

  • Appartenenza al gruppo di sicurezza
  • Autorizzazioni basate sui ruoli
  • Livelli di accesso
  • Flag di funzionalità
  • Spazi dei nomi di & autorizzazioni

Criteri

  • Criteri del repository Git e dei rami

Importante

Azure DevOps supporta più l'autenticazione con credenziali alternative dall'inizio del 2 marzo 2020. Se si usano ancora credenziali alternative, è consigliabile passare a un metodo di autenticazione più sicuro, ad esempio i token di accesso personali. Altre informazioni

Sia il servizio cloud, Azure DevOps Services e il server locale, Azure DevOps Server, supportano i progetti di sviluppo software, dalla pianificazione alla distribuzione. Azure DevOps usa l'infrastruttura Platform as a Service di Microsoft Azure e molti dei servizi di Azure, inclusi i database di Azure SQL, per offrire un servizio affidabile e disponibile a livello globale per i progetti di sviluppo.

Per altre informazioni sui passaggi che Microsoft deve eseguire per mantenere i progetti in Azure DevOps Services sicuro, disponibile, sicuro e privato, vedere white paper, Azure DevOps Services Data Protection Overview.

Account

Mentre i tipi principali di account di interesse sono gli account utente aggiunti all'organizzazione o al progetto, Azure DevOps supporta altri tipi di account per eseguire varie operazioni. Sono inclusi i tipi di account seguenti.

  • Proprietario dell'organizzazione: autore di un'Azure DevOps Services o di un proprietario assegnato. Per informazioni su chi è il proprietario dell'organizzazione, vedere Aumentare le autorizzazioni; trovare un amministratore.
  • Account del servizio: account Azure DevOps usati per supportare un servizio specifico, ad esempio servizio del pool di agenti, PipelinesSDK. Per le descrizioni degli account del servizio, vedere Gruppi di sicurezza, account del servizio e autorizzazioni.
  • Entità servizio: account Azure DevOps interni per supportare le operazioni interne.
  • Agenti di processo: account interni usati per eseguire processi specifici in base a una pianificazione regolare.
  • Account di terze parti: account che richiedono l'accesso per supportare web hook, connessioni al servizio o altre applicazioni di terze parti.
  • Account del servizio: account Azure DevOps usati per supportare un servizio specifico, ad esempio servizio del pool di agenti, PipelinesSDK. Per le descrizioni degli account del servizio, vedere Gruppi di sicurezza, account del servizio e autorizzazioni.
  • Entità servizio: account Azure DevOps interni per supportare le operazioni interne.
  • Agenti di processo: account interni usati per eseguire processi specifici in base a una pianificazione regolare.
  • Account di terze parti: account che richiedono l'accesso per supportare web hook, connessioni al servizio o altre applicazioni di terze parti.

Il modo più efficace per gestire gli account è aggiungerli ai gruppi di sicurezza.

Nota

Al proprietario dell'organizzazione e ai membri del gruppo Project Collection Administrators viene concesso l'accesso completo alla maggior parte di tutte le funzionalità e funzioni.

Authentication

L'autenticazione verifica l'identità di un account in base alle credenziali fornite al momento dell'accesso Azure DevOps. Questi sistemi si integrano con e si basano sulle funzionalità di sicurezza fornite da questi sistemi aggiuntivi:

  • Azure Active Directory (Azure AD)
  • account Microsoft (MSA)
  • Active Directory (AD)

Azure AD e msa supportano l'autenticazione cloud. È consigliabile Azure AD quando è necessario gestire un gruppo di utenti di grandi dimensioni. In caso contrario, se si dispone di una piccola base di utenti che accede all'organizzazione in Azure DevOps, è possibile usare gli account Microsoft. Per altre informazioni, vedere Informazioni sull'accesso Azure DevOps con Azure Active Directory (Azure AD).

Per le distribuzioni locali, è consigliabile ad Active Directory quando si gestisce un gruppo di utenti di grandi dimensioni. Per altre informazioni, vedere Configurare i gruppi per l'uso nelle distribuzioni locali.

Metodi di autenticazione, integrazione con altri servizi e app

Altre applicazioni e servizi possono integrarsi con servizi e risorse in Azure DevOps. Per accedere all'account senza chiedere più volte le credenziali utente, le app possono usare i metodi di autenticazione seguenti.

  • Token di accesso personali per generare i token per:

    • Accesso a risorse o attività specifiche, ad esempio compilazioni o elementi di lavoro
    • Client come Xcode e NuGet che richiedono nomi utente e password come credenziali di base e non supportano le funzionalità account Microsoft e Azure Active Directory come l'autenticazione a più fattori
    • Accesso Azure DevOps API REST
  • OAuth per generare i token per l'accesso alle API REST. Le API account e profili supportano solo OAuth.

  • Autenticazione SSH per generare chiavi di crittografia quando si usa Linux, macOS o Windows che esegue Git per Windows e non è possibile usare gestori di credenziali Git o token di accesso personali per l'autenticazione HTTPS.

Per impostazione predefinita, l'account o la raccolta consente l'accesso per tutti i metodi di autenticazione. È possibile limitare l'accesso, ma è necessario limitare in modo specifico l'accesso per ogni metodo. Quando si nega l'accesso a un metodo di autenticazione, nessuna app può usare tale metodo per accedere all'account. Qualsiasi app che in precedenza aveva accesso riceve un errore di autenticazione e non può accedere all'account.

Per altre informazioni su come archiviare le credenziali, vedere Archivio credenziali per Azure DevOps.

Per altre informazioni su come scegliere il meccanismo di autenticazione giusto, vedere Linee guida per l'autenticazione.

Autorizzazione

L'autorizzazione verifica che l'identità che sta tentando di connettersi abbia le autorizzazioni necessarie per accedere a un servizio, una funzionalità, una funzione, un oggetto o un metodo. L'autorizzazione viene sempre eseguita dopo la riuscita dell'autenticazione. Se una connessione non viene autenticata, viene negata prima della verifica dell'autorizzazione. Se l'autenticazione di una connessione ha esito positivo, un'azione specifica potrebbe comunque non essere consentita perché l'utente o il gruppo non dispone dell'autorizzazione per eseguire tale azione.

L'autorizzazione dipende dalle autorizzazioni assegnate all'account. Le autorizzazioni vengono concesse direttamente a un account o tramite l'appartenenza a un gruppo di sicurezza o a un ruolo di sicurezza. I livelli di accesso e i flag di funzionalità possono anche concedere o limitare l'accesso a una funzionalità. Per altre informazioni su questi metodi di autorizzazione, vedere Introduzione a autorizzazioni, accesso e gruppi di sicurezza.

Spazi dei nomi e autorizzazioni di sicurezza

Gli spazi dei nomi di sicurezza archiviano i dati che determinano il livello di accesso Azure DevOps account devono eseguire un'azione specifica su una risorsa specifica. Ogni famiglia di risorse, ad esempio elementi di lavoro o repository Git, è protetta tramite uno spazio dei nomi univoco. Ogni spazio dei nomi di sicurezza contiene zero o più elenchi di controllo di accesso (ACL). Ogni ACL contiene un token, un flag inherit e un set di zero o più voci di controllo di accesso (ACE). Ogni ACE contiene un descrittore di identità, una maschera di bit delle autorizzazioni consentite e una maschera di bit per le autorizzazioni negate.

Per altre informazioni, vedere Spazi dei nomi di sicurezza e informazioni di riferimento sulle autorizzazioni.

Criteri di sicurezza

Per proteggere l'organizzazione e il codice, è possibile impostare diversi criteri. In particolare, è possibile abilitare o disabilitare i criteri seguenti:

Generale

Criteri di sicurezza e connessione dell'applicazione

  • Accesso alle applicazioni di terze parti tramite OAuth: se abilitato, consente alle applicazioni di terze parti di connettersi tramite OAuth. Per altre informazioni, vedere Modificare la connessione dell'applicazione & criteri di sicurezza per l'organizzazione.
  • Accesso con autenticazione SSH: se abilitato, consente alle applicazioni di connettersi usando l'autenticazione SSH. Per altre informazioni, vedere Modificare la connessione dell'applicazione & criteri di sicurezza per l'organizzazione.
  • Consenti progetti pubblici: se abilitati, gli utenti possono creare progetti pubblici che consentono ai non membri di un progetto e agli utenti che non hanno eseguito l'accesso in sola lettura l'accesso limitato agli elementi e ai servizi del progetto. Per altre informazioni, vedere Rendere pubblico il progetto e Abilitare l'accesso anonimo ai progetti per l'organizzazione.
  • Limita la creazione dell'organizzazione tramite criteri tenant Azure AD (valido solo quando l'organizzazione è supportata da Azure Active Directory.): Se abilitata, impedisce agli utenti di creare altre organizzazioni Azure DevOps che verrebbero automaticamente supportate dal Azure AD. Per informazioni su come abilitare, vedere Limitare la creazione dell'organizzazione tramite Azure AD tenant.
  • Abilitare Azure Active Directory (Azure AD) la convalida dei criteri di accesso condizionale (CAP) (valido solo quando l'organizzazione è supportata da Azure Active Directory.): Se abilitata, consente di impostare condizioni aggiuntive per l'accesso all'organizzazione. A seconda delle condizioni soddisfatte dall'utente, è possibile richiedere l'autenticazione a più fattori, ulteriori controlli o bloccare l'accesso. Questo criterio è impostato su disattivato per impostazione predefinita e si applica solo a credenziali alternative. Questo criterio non si applica ai CAP impostati in Azure AD, indipendentemente le impostazioni in Azure DevOps. Per altre informazioni, vedere Modificare la connessione dell'applicazione & criteri di sicurezza per l'organizzazione.

Criteri utente

  • Accesso guest esterno (valido solo quando l'organizzazione è supportata da Azure Active Directory.): Se abilitato, gli inviti possono essere inviati agli account di posta elettronica degli utenti che non sono membri del Azure Active Directory tenant tramite la pagina Utenti. Per altre informazioni, vedere Aggiungere utenti esterni all'organizzazione.
  • Consenti agli amministratori di team e di progetto di invitare nuovi utenti: valido solo quando l'organizzazione è supportata da Azure Active Directory. Se abilitata, gli amministratori del team e del progetto possono aggiungere utenti tramite la pagina Utenti. Per altre informazioni, vedere Limitare gli inviti a nuovi utenti Project e amministratori del team.
  • Richiedi accesso: valido solo quando l'organizzazione è supportata da Azure Active Directory. Se abilitati, gli utenti possono richiedere l'accesso a una risorsa. Una richiesta comporta una notifica tramite posta elettronica agli amministratori che richiedono la revisione e l'accesso, in base alle esigenze. Per altre informazioni, vedere Aggiungere utenti esterni all'organizzazione.
  • Invita GitHub utenti: valido solo quando l'organizzazione non è supportata da Azure Active Directory. Se abilitati, gli amministratori possono aggiungere utenti in base GitHub account utente dalla pagina Utenti. Per altre informazioni, vedere Domande frequenti sull'autenticazione & GitHub utenti.

Project-Scoped gruppo Users

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 Project-Scoped Users è limitato nei modi seguenti:

  • Può accedere solo alle pagine Panoramica e Progetti di Organization Impostazioni.
  • Può connettersi e visualizzare solo i progetti a cui sono stati aggiunti in modo esplicito (vedere Aggiungere utenti a un progetto o a un team).
  • È possibile selezionare solo le identità di utenti e gruppi aggiunte in modo esplicito al progetto a cui sono connesse.

Per altre informazioni su Limita visibilità utente per i progetti, vedere Informazioni sui progetti, Limitare la visibilità utente per i progetti. Per abilitare la funzionalità, vedere Gestire o abilitare le funzionalità.

Criteri del repository Git e dei rami

Per proteggere il codice, è possibile impostare una serie di criteri del repository Git e del ramo. Per altre informazioni, vedere gli articoli seguenti.

Azure Repos e Azure Pipelines sicurezza

Poiché i repository e le pipeline di compilazione e rilascio pongono problemi di sicurezza univoci, vengono utilizzate funzionalità aggiuntive oltre a quelle descritte in questo articolo. Per altre informazioni, vedere gli articoli seguenti.

Passaggi successivi