Optimera behörigheter för prestanda

Azure DevOps-tjänster

Behörighetskontroller ingår i många Azure DevOps Services-åtgärder. I stor skala kan många explicita behörighetstilldelningar, undantag på resursnivå och gruppmedlemskap sakta ned utvärdering och uppdateringar av behörigheter. Stora åtkomstkontrollistor kräver också att tjänsten hämtar och löser fler behörighetsdata och identiteter.

Använd rekommendationerna i den här artikeln för att minska mängden behörighetsdata som Azure DevOps Services-processer.

Begränsningar för mjuka prestanda

Använd följande gränser som planeringsmål för stora organisationer. Azure DevOps Services tillämpar inte dessa begränsningar eller blockerar behörighetsändringar som överskrider dem. Om du överskrider dem ökar dock risken för långsamma behörighetsfrågor, utvärderingar och medlemskapsuppdateringar.

En åtkomstkontrollpost (ACE) lagrar de behörigheter som tilldelats till en användare eller grupp. För kapslade grupper bör du överväga det totala effektiva medlemskapet när du använder riktlinjen för gruppstorlek.

Rekommenderade metoder

Tilldela behörigheter till grupper

Använd inbyggda eller anpassade Azure DevOps säkerhetsgrupper för att representera roller, team och åtkomstkohorter. När du tilldelar en behörighet till en grupp skapas ett ACE. Om du tilldelar samma behörighet direkt till många användare skapas ett ACE för varje användare.

• Föredrar inbyggda grupper som läsare, deltagare och Project administratörer när deras behörigheter matchar den åtkomst som krävs.
• Skapa en anpassad grupp när en inbyggd grupp inte matchar den åtkomst som krävs.
• Ersätt inte en grupp med hundratals eller tusentals direkta användartilldelningar.

Använd det bredaste matchande omfånget och arvet

Ange en behörighet en gång med det högsta omfång som stöds som matchar åtkomstkravet. Låt underordnade resurser ärva behörigheten och behåll arv aktiverat om inte en underordnad resurs kräver annan åtkomst.

Ett exempel:

Undvik att ange identiska behörigheter separat på varje lagringsplats, gren, pipeline eller annan underordnad resurs. För Git-lagringsplatser ärver enskilda lagringsplatser behörigheter från git-lagringsplatser på den översta nivån.

Inaktivera endast arv när en resurs behöver annan åtkomst än dess överordnade. Att inaktivera arv över många resurser kräver vanligtvis mer explicita tilldelningar.

Använd Deny endast för undantag

Ge åtkomst via en grupp, och lämna behörigheten som Inte angivet för identiteter som inte ska få åtkomsten. I stället för att bevilja bred åtkomst och sedan lägga till många Neka-poster skapar du en grupp med de exakta behörigheter som krävs.

Använd Neka endast när du måste åsidosätta en ärvd Tillåt för ett specifikt undantag. En enskild Deny-post är inte i sig ett prestandaproblem. Många undantag lägger dock till ACL:er och kräver ofta fler behörighetstilldelningar på objektnivå.

Använda identitetsgrupper med rätt storlek

Använd grupper som överensstämmer med åtkomstkraven, till exempel en affärsenhet, ett projekt, en produkt eller en jobbfunktion. Varken Entra-grupper eller Azure DevOps grupper ger bättre prestanda. Tillämpa samma riktlinjer för storlek och nästning på båda grupptyperna.

• Undvik att lägga till en klient- eller företagsomfattande grupp, till exempel en grupp med alla anställda .
• Undvik djupt kapslade eller ofta föränderliga gruppstrukturer när en enklare grupp ger samma åtkomst.
• Dela upp en mycket stor grupp i mindre åtkomstkohorter när dess medlemmar inte alla kräver samma åtkomst.
• Om varje medlem behöver samma åtkomst tilldelar du en grupp i ett ärvt överordnat omfång i stället för att använda enskilda tilldelningar eller duplicerade grupper.

Grupper med fler än 10 000 medlemmar är en prestandarisk. Nästlade grupper, frekventa ändringar i medlemskap och åtkomst till många behörighetsstyrda resurser kan öka effekten. Minska onödigt medlemskap och dela upp gruppen i mindre åtkomstkohorter där det är praktiskt.

Balansera resurser mellan projekt och organisationer

Undvik att koncentrera tusentals lagringsplatser och de flesta behörighetsskyddade resurser i ett projekt medan andra projekt bara innehåller några få. Åtgärder som identifierar tillgängliga resurser kan behöva utvärdera behörigheter i hela uppsättningen.

Distribuera stora uppsättningar lagringsplatser och andra resurser mellan projekt innan för många resurser ackumuleras i ett projekt. Skapa inte ett projekt per lagringsplats. projektantalet har också praktiska prestandagränser.

I extrem företagsskala kan flera mindre organisationer prestera bättre än en organisation som innehåller de flesta företagsresurser och behörighetsdata. Dela upp organisationer längs stabila produkt- eller affärsgränser för att distribuera resurs- och behörighetsbelastning. Använd endast den här metoden när skalningsförmånen väger tyngre än kostnaderna för att hantera resurser i separata organisationer.

Minska förändringstakten i automatiseringen av behörigheter

Om du hanterar behörigheter via skript, REST-API:er eller arbetsflöden för konfiguration som kod:

• Använd endast de ändringar som krävs för att nå det avsedda tillståndet. Rensa och återskapa inte oförändrade behörighetstilldelningar vid varje körning.
• Ange behörigheter på en överordnad nivå i stället för att generera motsvarande poster för varje underresurs.
• Använd batchändringar när det stöds och följ bästa praxis för Azure DevOps REST API.
• Undvik loopar för högfrekvent behörighetsavstämning.
• Undvik att rutinmässigt skapa och ta bort ett stort antal projekt eller resurser med behörighet.
• Ta bort föråldrade explicita tilldelningar för att minska åtkomstkontrollistan (ACL) och ACE-volymen.

Se även

• Om behörigheter och säkerhetsgrupper
• Om projekt och skalning av din organisation
• Arbetsspårning, processer och projektgränser
• metodtips för Azure DevOps REST API