Ottimizzare le autorizzazioni per le prestazioni

Servizi di Azure DevOps

I controlli delle autorizzazioni fanno parte di molte operazioni Azure DevOps Services. Su larga scala, molte assegnazioni esplicite di autorizzazioni, eccezioni a livello di risorsa e appartenenze ai gruppi possono rallentare la valutazione e gli aggiornamenti delle autorizzazioni. Gli elenchi di controllo di accesso di grandi dimensioni richiedono anche al servizio di recuperare e risolvere più dati e identità di autorizzazione.

Usare le raccomandazioni contenute in questo articolo per ridurre la quantità di dati di autorizzazione che Azure DevOps Servizi elabora.

Limiti di prestazioni flessibili

Usare i limiti seguenti come obiettivi di pianificazione per organizzazioni di grandi dimensioni. Azure DevOps Servizi non applica questi limiti o blocca le modifiche alle autorizzazioni che le superano. Tuttavia, superarli aumenta il rischio di lentezza di query, valutazioni e aggiornamenti delle appartenenze.

Una voce di controllo di accesso (ACE) archivia le autorizzazioni assegnate a un utente o a un gruppo. Per i gruppi nidificati, considera il numero totale effettivo di membri quando applichi le linee guida sulle dimensioni dei gruppi.

Procedure consigliate

Assegnare autorizzazioni ai gruppi

Usare gruppi di sicurezza predefiniti o personalizzati Azure DevOps per rappresentare ruoli, team e coorti di accesso. L'assegnazione di un permesso a un gruppo crea un ACE. L'attribuzione della stessa autorizzazione direttamente a più utenti crea un ACE per ogni utente.

• Preferisce gruppi predefiniti, ad esempio lettori, collaboratori e amministratori Project quando le autorizzazioni corrispondono all'accesso richiesto.
• Creare un gruppo personalizzato quando un gruppo predefinito non corrisponde all'accesso necessario.
• Non sostituire un gruppo con centinaia o migliaia di assegnazioni utente dirette.

Usare l'ambito applicabile e l'ereditarietà più ampi

Impostare un'autorizzazione una sola volta nell'ambito supportato più alto che corrisponda al requisito di accesso. Consentire alle risorse figlie di ereditare il permesso e mantenere attiva l'ereditarietà, a meno che una risorsa figlia non richieda un accesso diverso.

Per esempio:

Evitare di impostare autorizzazioni identiche separatamente in ogni repository, ramo, pipeline o qualsiasi altra risorsa figlia. Per i repository Git, i singoli repository ereditano le autorizzazioni dalla voce dei repository Git di primo livello.

Disabilitare l'ereditarietà solo quando una risorsa necessita di accesso diverso dall'elemento padre. La disabilitazione dell'ereditarietà tra molte risorse richiede in genere assegnazioni più esplicite.

Usa Nega solo in caso di eccezioni

Concedi l'accesso tramite un gruppo e lascia le autorizzazioni su Non impostato per le identità che non devono ricevere l'autorizzazione. Invece di concedere l'accesso generale e quindi aggiungere molte voci Nega , creare un gruppo con le autorizzazioni esatte necessarie.

Usare Deny solo quando è necessario eseguire l'override di un'eccezione ereditata Consenti per un'eccezione specifica. Una singola voce Deny non è intrinsecamente un problema di prestazioni. Tuttavia, molte eccezioni aggiungono ACL e spesso richiedono più assegnazioni di autorizzazioni a livello di oggetto.

Usare i gruppi di identità di dimensioni appropriate

Usare gruppi allineati ai requisiti di accesso, ad esempio una business unit, un progetto, un prodotto o una funzione di processo. Né i gruppi Entra né i gruppi Azure DevOps offrono prestazioni migliori. Applicare le stesse dimensioni e linee guida per l'annidamento a entrambi i tipi di gruppo.

• Evitare di aggiungere un gruppo a livello di tenant o aziendale, ad esempio un gruppo Tutti i dipendenti .
• Evitare strutture di gruppo molto annidate o soggette a modifiche frequenti quando un gruppo più semplice fornisce lo stesso accesso.
• Suddividere un gruppo molto grande in coorti di accesso più piccoli quando i membri non richiedono tutti lo stesso accesso.
• Se ogni membro necessita dello stesso accesso, assegnare un gruppo a un ambito padre ereditato anziché usare singole assegnazioni o gruppi duplicati.

I gruppi con più di 10.000 membri rappresentano un rischio per le prestazioni. Nidificazione, frequenti cambi di appartenenza e accesso a molte risorse soggette ad autorizzazioni possono aumentare l'impatto. Ridurre il numero di membri non necessari e suddividere il gruppo in gruppi di accesso più piccoli, ove possibile.

Bilanciare le risorse tra progetti e organizzazioni

Evitare di concentrare migliaia di repository e la maggior parte delle risorse protette dalle autorizzazioni in un progetto, mentre altri progetti contengono solo alcuni. Le operazioni che individuano risorse accessibili potrebbero dover valutare le autorizzazioni nell'intero set.

Distribuire grandi set di repository e altre risorse tra progetti prima di accumulare troppe risorse in un unico progetto. Non creare un progetto per repository; il conteggio dei progetti presenta anche limiti pratici per le prestazioni.

A livello aziendale estremo, più organizzazioni più piccole possono offrire prestazioni migliori rispetto a un'organizzazione che contiene la maggior parte delle risorse aziendali e i dati delle autorizzazioni. Suddividere le organizzazioni in base a confini stabili di prodotto o aziendali per distribuire il carico di risorse e autorizzazioni. Usare questo approccio solo quando il vantaggio di scalabilità supera il sovraccarico della gestione delle risorse in organizzazioni separate.

Ridurre l'instabilità nell'automazione delle autorizzazioni

Se si gestiscono le autorizzazioni tramite script, API REST o flussi di lavoro di configurazione come codice:

• Applicare solo le modifiche necessarie per raggiungere lo stato previsto. Non eliminare e ricreare le assegnazioni di autorizzazioni invariate a ogni esecuzione.
• Impostare le autorizzazioni in un ambito padre anziché generare voci equivalenti per ogni risorsa figlio.
• Apportare modifiche in blocco laddove supportate e seguire le procedure consigliate per l'API REST di Azure DevOps.
• Evitare cicli di riconciliazione delle autorizzazioni ad alta frequenza.
• Evitare di creare ed eliminare regolarmente un numero elevato di progetti o risorse autorizzate.
• Rimuovere le assegnazioni esplicite obsolete per ridurre l'elenco di controllo di accesso (ACL) e il volume ACE.

Vedere anche

• Informazioni su autorizzazioni e gruppi di sicurezza
• Informazioni sui progetti e sul ridimensionamento dell'organizzazione
• Monitoraggio del lavoro, limiti dei processi e dei progetti
• Procedure consigliate per l'API REST Azure DevOps