Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
servizi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Gestire chi può accedere ai repository Git e quali azioni possono eseguire. Impostare le autorizzazioni a livello di Tutti i repository per applicarle a ogni repository Git in un progetto o impostare le autorizzazioni per un singolo repository. I singoli repository ereditano le autorizzazioni dalla voce dei repository Git a livello di progetto.
Nota
I rami ereditano un subset di autorizzazioni dalle assegnazioni effettuate a livello di repository. Per le autorizzazioni e i criteri dei rami, vedere Impostare le autorizzazioni per i rami e Migliorare la qualità del codice con i criteri dei rami.
Per una guida completa alla sicurezza relativa alle autorizzazioni del repository, ai criteri di ramo, alla firma di commit e agli scenari di implementazione reali, vedere Proteggere i repository e le richieste pull.
Per indicazioni su chi fornire livelli di autorizzazione maggiori, vedere Gestire l'accesso usando le autorizzazioni.
Prerequisiti
| Categoria | Requisiti |
|---|---|
| Accesso al progetto | Appartenenza a un progetto di Azure DevOps. |
| Autorizzazioni | Gestire le autorizzazioni per la voce dei repository Git a livello di progetto per gestire ogni repository nel progetto o Gestire le autorizzazioni per un singolo repository per gestire tale repository. I membri del gruppo administrators Project dispongono di questa autorizzazione per impostazione predefinita. Per altre informazioni, vedere Informazioni di riferimento su autorizzazioni e gruppi. |
| Servizi | Azure Repos abilitata. |
Esaminare le autorizzazioni predefinite del repository
Per impostazione predefinita, i membri del gruppo Collaboratori del progetto dispongono delle autorizzazioni per contribuire a un repository. Questo livello di autorizzazione include la possibilità di creare rami, creare tag e gestire le note. Per una descrizione di ogni gruppo di sicurezza e livello di autorizzazione, vedere Informazioni di riferimento su autorizzazioni e gruppi.
Autorizzazione
Lettori
Collaboratori
Amministratori di compilazione
Amministratori del progetto
Lettura (clonazione, recupero ed esplorazione del contenuto di un repository); inoltre, può creare, commentare, votare e contribuire alle richieste pull
✔️
✔️
✔️
✔️
Contribuire, creare rami, creare tag e gestire le note
✔️
✔️
✔️
Creare repository, eliminare repository e rinominare il repository
✔️
Modificare i criteri, gestire le autorizzazioni, rimuovere i blocchi di altri utenti
✔️
Ignorare i criteri quando si completano le richieste pull, ignorare i criteri durante il push, Effettuare un push forzato (riscrivere la cronologia, eliminare branch e tag)
(non impostato per alcun gruppo di sicurezza)
A partire da Azure DevOps sprint 224, gli autori di rami non ottengono automaticamente l'autorizzazione Modifica criteri. Questa autorizzazione non viene concessa anche se l'impostazione Gestione autorizzazioni è attivata per il repository. Concedere criteri di modifica in modo esplicito tramite ereditarietà, appartenenza a gruppi o assegnazione diretta.
In Azure DevOps Server 2022.1 e versioni successive, gli autori di rami non ottengono automaticamente l'autorizzazione Modifica criteri. Questa autorizzazione non viene concessa anche se l'impostazione Gestione autorizzazioni è attivata per il repository. Concedere criteri di modifica in modo esplicito tramite ereditarietà, appartenenza a gruppi o assegnazione diretta. Per altre informazioni, vedere Azure DevOps Server note sulla versione dell'aggiornamento 1 2022.
Informazioni sugli stati di autorizzazione
Prima di modificare un'autorizzazione, esaminare il modo in cui Azure DevOps valuta gli stati di autorizzazione:
- Non impostato non concede o nega l'autorizzazione. Le autorizzazioni assegnate tramite un altro gruppo o ereditate da un ambito padre possono comunque essere applicate.
- Consenti concede l'autorizzazione a meno che non ne venga eseguito l'override di un elemento Deny più specifico o applicabile.
- Nega in genere esegue l'override di Consenti, incluse le autorizzazioni ereditate o concesse tramite un altro gruppo. Quando si nega un'autorizzazione per un gruppo, la negazione influisce su tutti i membri del gruppo.
Esaminare l'appartenenza al gruppo e le autorizzazioni ereditate prima di assegnare Nega. Per altre informazioni, vedere Informazioni su autorizzazioni e gruppi.
Aprire la sicurezza del repository
Impostare le autorizzazioni del repository Git da Project impostazioni>Repository.
Aprire il portale Web e selezionare il progetto in cui si desidera aggiungere utenti o gruppi. Per selezionare un altro progetto, vedere Cambiare progetto, repository, team.
Seleziona Impostazioni del progetto>Repository.
Per impostare le autorizzazioni per ogni repository Git nel progetto, selezionare Sicurezza tutti i repository>.
Per impostare le autorizzazioni per un repository specifico, selezionare il repository e quindi selezionare Sicurezza.
Impostare le autorizzazioni del repository Git da Project impostazioni>Repository.
Aprire il portale Web e selezionare il progetto in cui si vogliono gestire le autorizzazioni. Per selezionare un altro progetto, vedere Cambiare progetto, repository, team.
Seleziona Impostazioni del progetto>Repository.
Per impostare le autorizzazioni per ogni repository Git nel progetto, selezionare Repository Git e quindi selezionare l'utente o il gruppo di sicurezza le cui autorizzazioni si desidera gestire.
Per visualizzare l'immagine completa, fare clic sull'immagine da espandere. Scegli l'icona
per chiudere.
In caso contrario, selezionare un repository specifico e quindi selezionare l'utente o il gruppo di sicurezza le cui autorizzazioni si desidera gestire.
Modificare le autorizzazioni e quindi selezionare Salva modifiche.
Verificare che ogni autorizzazione modificata mantenga il nuovo stato.
Modificare le autorizzazioni per un gruppo
Per impostare le autorizzazioni per un gruppo di sicurezza personalizzato, definire prima di tutto il gruppo. Per altre informazioni, vedere Change project-level permissions.
Selezionare il gruppo per impostare le autorizzazioni. Ad esempio, selezionare Collaboratori.
Modificare una o più autorizzazioni. Per concedere un'autorizzazione, selezionare Consenti. Per rimuovere un'assegnazione esplicita e usare autorizzazioni ereditate o di gruppo, selezionare Non impostato. Selezionare Nega solo quando è necessario eseguire l'override di un consenti applicabile.
Le modifiche alle autorizzazioni vengono salvate automaticamente. Verificare che ogni autorizzazione modificata visualizzi lo stato previsto.
Modificare le autorizzazioni per un utente
Immettere il nome dell'utente nel filtro di ricerca e selezionare tra le identità visualizzate per impostare le autorizzazioni per un utente specifico.
Modificare una o più autorizzazioni per l'utente selezionato.
Nota
Potrebbe non essere possibile trovare un utente da una pagina di autorizzazioni o da un campo di identità se l'utente non è stato aggiunto al progetto aggiungendolo a un gruppo di sicurezza o a un team di progetto. Inoltre, quando un utente viene aggiunto a Microsoft Entra ID o Active Directory, può verificarsi un ritardo tra il momento in cui vengono aggiunti al progetto e quando è possibile eseguire la ricerca da un campo identity. Il ritardo può essere compreso tra 5 minuti e 7 giorni.
Le modifiche alle autorizzazioni vengono salvate automaticamente per l'utente selezionato. Verificare che ogni autorizzazione modificata visualizzi lo stato previsto.
È possibile aggiungere un utente o un gruppo e non modificare le autorizzazioni per tale utente o gruppo. Dopo l'aggiornamento della pagina delle autorizzazioni, l'utente o il gruppo non viene più visualizzato.
Configurare l'ereditarietà per un repository
Prima di modificare l'ereditarietà, registrare l'impostazione corrente ed esaminare le autorizzazioni esplicite e ereditate del repository. Quando si disattiva l'ereditarietà, le autorizzazioni dalla voce dei repository Git a livello di progetto non passano più al repository. Verificare che le assegnazioni rimanenti forniscano l'accesso previsto prima di continuare.
Per abilitare o disabilitare l'ereditarietà per un repository specifico, selezionare il repository e quindi impostare Ereditarietà su Sì o No.
Dopo aver modificato l'ereditarietà, verificare le assegnazioni di autorizzazioni del repository con un utente interessato da un rappresentante. Se il risultato non è corretto, ripristinare l'impostazione precedente e gli stati di autorizzazione. Per informazioni sull'ereditarietà, vedere Informazioni su autorizzazioni e gruppi.
Configurare le autorizzazioni di bypass dei criteri
Esistono molti scenari in cui si ha la necessità occasionale di ignorare un criterio di ramo. Alcuni esempi sono quando si ripristina una modifica che ha causato un'interruzione di compilazione o si applica un hotfix durante la notte.
In precedenza, l'autorizzazione esente dall'applicazione delle politiche ha consentito ai team di gestire gli utenti a cui è stata concessa la possibilità di ignorare le politiche di ramo al termine di una pull request. Tuttavia, tale autorizzazione ha anche concesso agli utenti la possibilità di fare il push direttamente nel ramo e ignorare completamente il processo di pull request.
Le due autorizzazioni seguenti sostituiscono esentate dall'imposizione dei criteri e forniscono un controllo più granulare:
- Ignorare i criteri durante il completamento delle richieste pull: gli utenti con questa autorizzazione possono usare l'esperienza di override per le richieste pull.
- Ignorare le politiche durante il push: gli utenti con questa autorizzazione possono eseguire il push direttamente sui branch con le politiche necessarie configurate.
Per consentire a un utente di ignorare i criteri solo quando si completano le richieste pull, impostare Ignora criteri quando si completano le richieste pull su Consenti. Lasciare ignora i criteri quando si esegue il push come Non impostato se l'utente non riceve Consenti tramite un'altra assegnazione. Impostarla su Nega solo quando è necessario eseguire l'override di un consenti applicabile.
Nota
Gli utenti che in precedenza avevano esentato dall'imposizione dei criteri impostati su Consenti ricevuti Consenti per entrambe le autorizzazioni di sostituzione. Esaminare queste assegnazioni e impostare Criteri di bypass quando si esegue il push su Non impostato quando gli utenti non devono eseguire il push direttamente nei rami protetti e nessun'altra assegnazione concede l'autorizzazione.
Risolvere i problemi relativi alle modifiche alle autorizzazioni
Usare le indicazioni seguenti quando una modifica delle autorizzazioni non ha il risultato previsto:
| Problema | Resolution |
|---|---|
| Non è possibile modificare un'autorizzazione | Verificare di disporre delle autorizzazioni Di gestione nella voce dei repository Git a livello di progetto o nel repository selezionato. |
| Un utente o un gruppo non viene visualizzato nella ricerca | Aggiungere l'identità al progetto tramite un team o un gruppo di sicurezza. Le modifiche all'identità possono richiedere tempo per essere visualizzate nella ricerca. |
| Un elemento Allow non concede l'accesso | Controllare le appartenenze ai gruppi dell'utente e ambiti più specifici per un elemento Deny applicabile. |
| Un'autorizzazione influisce sui repository errati | Verificare se sono stati modificati tutti i repository o un singolo repository. |
| Dopo aver selezionato Non impostato, viene restituita un'autorizzazione | Controllare se l'autorizzazione viene ereditata o concessa tramite un altro gruppo. |
| La disabilitazione dell'ereditarietà rimuove l'accesso | Ripristinare l'impostazione di ereditarietà precedente o le assegnazioni di autorizzazioni esplicite registrate prima della modifica. |
Dopo aver risolto il problema, chiedere a un rappresentante di verificare l'azione del repository desiderata.
Suggerimento
È possibile usare l'intelligenza artificiale per facilitare le attività di Azure DevOps. Per iniziare, vedere Abilitare l'assistenza AI con Azure DevOps MCP Server.