Om behörigheter och säkerhetsgrupper

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

I den här artikeln får du lära dig mer om åtkomstnivåer och behörigheter via arv, säkerhetsgrupper, roller med mera i Azure DevOps.

En översikt över standardbehörigheter finns i Snabbreferens för standardbehörigheter. En beskrivning av varje standardsäkerhetsgrupp finns i Säkerhetsgrupper, tjänstkonton och behörighetsreferens.

Åtkomstnivåer

Alla användare som läggs till i Azure DevOps tilldelas en åtkomstnivå som ger eller begränsar åtkomsten till att välja webbportalfunktioner.

Det finns tre huvudsakliga åtkomstnivåer: Intressent-, Basic- och Basic + Test-planer. Intressentåtkomst ger kostnadsfri åtkomst till ett obegränsat antal användare till en begränsad uppsättning funktioner. Mer information finns i Snabbreferens för intressentåtkomst.

Om du vill ge en användare åtkomst till funktioner för agil portföljhantering eller hantering av testfall ändrar du åtkomstnivåer, inte behörigheter. Mer information finns i Om åtkomstnivåer.

Behörigheter

Alla användare som läggs till i Azure DevOps läggs till i en eller flera standardsäkerhetsgrupper. Säkerhetsgrupper tilldelas behörigheter som antingen tillåter eller nekar åtkomst till en funktion eller uppgift.

• Medlemmar i en säkerhetsgrupp ärver de behörigheter som tilldelats gruppen.
• Behörigheter definieras på olika nivåer: organisation/samling, projekt eller objekt.
• Andra behörigheter hanteras via rollbaserade tilldelningar, till exempel teamadministratör, tilläggshantering och olika pipelineresursroller.
• Administratörer kan definiera anpassade säkerhetsgrupper för att hantera behörigheter för olika funktionella områden.

När det gäller att hantera behörigheter i Azure DevOps finns det två viktiga grupper: Projektsamlingsadministratörer och projektadministratörer. Låt oss gå igenom detaljerna:

Projektsamlingsadministratörer:

• Dessa individer har den högsta behörighetsnivån inom en organisation eller projektsamling.
• De kan utföra alla åtgärder för hela samlingen.
• Deras ansvarsområden omfattar hantering av inställningar, principer och processer för organisationen.
• Dessutom kan de skapa och hantera alla projekt och tillägg i organisationen.

Projektadministratörer:

• Projektadministratörer arbetar på projektnivå.
• De hanterar säkerhetsgrupper och behörigheter främst från webbportalens Project-inställningar.
• Deltagare hanterar å andra sidan behörigheter för specifika objekt som de skapar i projektet.

Behörighetstillstånd

Du kan tilldela behörigheter på följande sätt, bevilja eller begränsa åtkomst enligt beskrivningen.

Användare eller grupp har behörighet att utföra en uppgift:

• Tillåt
• Tillåt (ärvt)
• Tillåt (system)

Användare eller grupp har inte behörighet att utföra en uppgift:

• Deny (Neka)
• Neka (ärvd)
• Neka (system)
• Inte inställt

Behörighetstillstånd	beskrivning
Tillåt	Uttryckligen ger användarna behörighet att utföra specifika uppgifter och ärvs inte från gruppmedlemskap.
Tillåt (ärvt)	Ger gruppmedlemmar behörighet att utföra specifika uppgifter.
Tillåt (system)	Beviljar behörighet som har företräde framför användarbehörigheter. Ej redigerbar och lagrad i en konfigurationsdatabas, osynlig för användare.
Deny (Neka)	Begränsar uttryckligen användare från att utföra specifika uppgifter och ärvs inte från gruppmedlemskap. För de flesta grupper och nästan alla behörigheter åsidosätter Neka Tillåt. Om en användare tillhör två grupper och en av dem har en specifik behörighet inställd på Neka, kan användaren inte utföra uppgifter som kräver den behörigheten även om de tillhör en grupp som har den behörigheten inställd på Tillåt.
Neka (ärvd)	Begränsar gruppmedlemmar från att utföra specifika uppgifter. Åsidosätter en explicit Tillåt.
Neka (system)	Begränsar behörighet som har företräde framför användarbehörigheter. Ej redigerbar och lagrad i en konfigurationsdatabas, osynlig för användare.
Inte inställt	Nekar implicit användarna möjligheten att utföra uppgifter som kräver den behörigheten, men tillåter medlemskap i en grupp som har den behörigheten att ha företräde, även kallat Tillåt (ärvd) eller Neka (ärvd).

I vissa fall kan medlemmar i grupperna Projektsamlingsadministratörer eller Team Foundation-administratörer alltid få behörigheten även om de nekas behörigheten i en annan grupp. I andra fall, till exempel borttagning av arbetsobjekt eller pipelines, går det inte att kringgå neka behörigheter som angetts någon annanstans om du är medlem i gruppen Administratörer för projektsamling.

Varning

När du ändrar en behörighet för en grupp påverkas alla användare i gruppen. Även en enskild behörighetsändring kan påverka hundratals användare, så det är viktigt att överväga de potentiella effekterna innan du gör några justeringar.

Behörighetsarv

Behörigheter följer en hierarki som tillåter arv från en överordnad eller genom att åsidosätta.

• Grupparv: Användare ärver behörigheter från de grupper som de tillhör. Om en användare har behörigheten Tillåt direkt eller via gruppmedlemskap, men även har behörigheten Neka via en annan grupp, har behörigheten Neka företräde. Medlemmar i Projektsamlingsadministratörer eller Team Foundation-administratörer behåller dock de flesta tillåtna behörigheterna, även om de tillhör andra grupper som nekar dessa behörigheter (förutom åtgärder för arbetsobjekt).
• Arv på objektnivå: Behörigheter på objektnivå (tilldelade till noder som områden, iterationer, versionskontrollmappar och arbetsobjektsfrågemappar) ärvs ned i hierarkin.

Låt oss till exempel dela upp behörighetsarvet och specificitetsreglerna och komma ihåg att explicita behörigheter alltid har företräde framför ärvda:

• När en användares behörigheter anges på en nod på högre nivå (area-1) ärvs dessa behörigheter av alla undernoder (area-1/sub-area-1) om de inte uttryckligen åsidosätts.
• Om en behörighet inte uttryckligen tillåts eller nekas för en undernod ärver den behörigheten från dess överordnade.
• Men om en behörighet uttryckligen anges för en undernod (area-1/sub-area-1) ärvs inte den överordnade behörigheten, oavsett om den tillåts eller nekas. Specificitet:
• I objekthierarkin trumfar specificiteten arv. Det innebär att om det finns behörigheter i konflikt har den mest specifika behörigheten företräde.
• Tänk dig till exempel en användare:
  • Neka uttryckligen på "area-1" (överordnad nod).
  • Tillåt uttryckligen för "area-1/sub-area-1" (underordnad nod).
• I det här fallet får användaren en Tillåt på "area-1/sub-area-1", vilket åsidosätter den ärvda neka från den överordnade noden.

För att förstå varför en behörighet ärvs kan du pausa över en behörighetsinställning och sedan välja Varför? Information om hur du öppnar en säkerhetssida finns i Visa behörigheter.

Kommentar

Information om hur du aktiverar sidan Förhandsgranskningssida för projektbehörigheter finns i Aktivera förhandsgranskningsfunktioner.

Förhandsgranskningssida

En ny dialogruta öppnas som visar arvsinformationen för den behörigheten.

Aktuell sida

Ett nytt fönster visar arvsinformationen för den behörigheten.

Säkerhetsgrupper och medlemskap

Säkerhetsgrupper tilldelar specifika behörigheter till sina medlemmar.

När du skapar en organisation, samling eller ett projekt skapar Azure DevOps en uppsättning standardsäkerhetsgrupper som automatiskt tilldelas standardbehörigheter. Fler säkerhetsgrupper definieras med följande åtgärder:

• När du skapar anpassade säkerhetsgrupper på följande nivåer:
  • Projektnivå
  • Organisations- eller samlingsnivå
  • Servernivå (endast lokalt)
• När du lägger till ett team skapas en gruppsäkerhetsgrupp

Du kan inte skapa en säkerhetsgrupp på objektnivå, men du kan tilldela en anpassad grupp till en objektnivå och tilldela behörigheter till den nivån. Mer information finns i Ange behörigheter på objektnivå.

Standardsäkerhetsgrupper

De flesta Azure DevOps-användare läggs till i säkerhetsgruppen Deltagare och beviljas grundläggande åtkomstnivå. Gruppen Deltagare ger läs- och skrivåtkomst till lagringsplatser, arbetsspårning, pipelines med mera. Grundläggande åtkomst ger åtkomst till alla funktioner och uppgifter för att använda Azure Boards, Azure Repos, Azure Pipelines och Azure Artifacts. Användare som behöver åtkomst för att hantera Azure-testplaner måste beviljas grundläggande och testplaner eller avancerad åtkomst.

Följande säkerhetsgrupper definieras som standard för varje projekt och organisation. Du lägger vanligtvis till användare eller grupper i grupperna Läsare, Deltagare eller Projektadministratörer .

Project	Organisation eller samling
– Skapa administratörer -Bidragsgivare – Projektadministratörer – Projekt giltiga användare -Läsare – Versionsadministratörer - TeamName-teamet	– Projektsamlingsadministratörer – Byggadministratörer för projektsamling – Skapa tjänstkonton för Projektsamling – Proxytjänstkonton för projektsamling – Tjänstkonton för projektsamling – Testtjänstkonton för projektsamling – Giltiga användare i projektsamlingen – Projektomfattande användare – Säkerhetstjänstgrupp

En beskrivning av var och en av dessa grupper finns i Säkerhetsgrupper, tjänstkonton och behörigheter. För standardbehörighetstilldelningar som görs till de vanligaste standardsäkerhetsgrupperna, se Standardbehörigheter och åtkomst.

För användare som har till uppgift att hantera funktioner på projektnivå – till exempel team, områdes- och iterationssökvägar, lagringsplatser, tjänstkrokar och tjänstslutpunkter – lägger du till dem i gruppen Projektadministratörer .

För användare som har till uppgift att hantera funktioner på organisations- eller samlingsnivå– till exempel projekt, principer, processer, kvarhållningsprinciper, agent- och distributionspooler och tillägg – lägger du till dem i gruppen Administratörer för projektsamling. Mer information finns i Om inställningar på användar-, team-, projekt- och organisationsnivå.

Hantering av medlemskap, behörighet och åtkomstnivå

Azure DevOps styr åtkomsten via dessa tre sammankopplade funktionella områden:

• Medlemskapshantering stöder tillägg av enskilda användarkonton och grupper i standardsäkerhetsgrupper. Varje standardgrupp är associerad med en uppsättning standardbehörigheter. Alla användare som läggs till i en säkerhetsgrupp läggs till i gruppen Giltiga användare. En giltig användare är någon som kan ansluta till ett projekt, en samling eller en organisation.
• Behörighetshantering styr åtkomsten till specifika funktionella uppgifter på olika nivåer i systemet. Behörigheter på objektnivå anger behörigheter för en fil, mapp, bygg-pipeline eller en delad fråga. Behörighetsinställningarna motsvarar Tillåt, Neka, Ärvd tillåt, Ärvd neka, System tillåt, System neka och Inte inställd.
• Åtkomstnivåhantering styr åtkomsten till webbportalfunktioner. Baserat på inköpt för en användare anger administratörer användarens åtkomstnivå till Intressent, Grundläggande, Grundläggande + Test eller Visual Studio Enterprise (tidigare Avancerat).

Varje funktionsområde använder säkerhetsgrupper för att förenkla hanteringen i hela distributionen. Du lägger till användare och grupper genom webbadministrationskontexten. Behörigheter anges automatiskt baserat på den säkerhetsgrupp som du lägger till användare i. Eller behörigheter baseras på objekt-, projekt-, samlings- eller servernivå som du lägger till grupper till.

Medlemmar i säkerhetsgrupper kan vara en kombination av användare, andra grupper och Microsoft Entra-grupper.

Active Directory- och Microsoft Entra-säkerhetsgrupper

Du kan fylla i säkerhetsgrupper genom att lägga till enskilda användare. Men för enkel hantering är det mer effektivt att fylla i dessa grupper med hjälp av Microsoft Entra-ID för Azure DevOps Services och Active Directory (AD) eller Windows-användargrupper för Azure DevOps Server. Med den här metoden kan du hantera gruppmedlemskap och behörigheter mer effektivt på flera datorer.

Om du bara behöver hantera en liten uppsättning användare kan du hoppa över det här steget. Men om du förväntar dig att din organisation kan växa kan du överväga att konfigurera Active Directory eller Microsoft Entra-ID. Om du planerar att använda extra tjänster är det också viktigt att konfigurera Microsoft Entra-ID för användning med Azure DevOps för att stödja fakturering.

Kommentar

Utan Microsoft Entra-ID måste alla Azure DevOps-användare logga in med Microsoft-konton och du måste hantera kontoåtkomst för enskilda användarkonton. Även om du hanterar kontoåtkomst med hjälp av Microsoft-konton konfigurerar du en Azure-prenumeration för att hantera fakturering.

Information om hur du konfigurerar Microsoft Entra-ID för användning med Azure DevOps Services finns i Anslut din organisation till Microsoft Entra-ID.

När din organisation är ansluten till Microsoft Entra-ID kan du definiera och hantera olika organisationsprinciper för att förbättra säkerheten och effektivisera åtkomsten till program. Mer information finns i Om säkerhet, säkerhetsprinciper.

Information om hur du hanterar organisationsåtkomst med Microsoft Entra-ID finns i följande artiklar:

• Lägga till eller ta bort användare med Microsoft Entra ID
• Felsöka åtkomst med Microsoft Entra-ID

Azure DevOps registrerar de ändringar som görs i en Microsoft Entra-grupp inom en timme efter ändringen i Microsoft Entra ID. Alla ärvda behörigheter via gruppmedlemskap uppdateras. Om du vill uppdatera ditt Microsoft Entra-medlemskap och ärvda behörigheter i Azure DevOps loggar du ut och loggar sedan in igen eller utlöser en uppdatering för att omvärdera din behörighet.

Giltiga användargrupper

När du lägger till konton för användare direkt i en säkerhetsgrupp läggs de automatiskt till i någon av följande giltiga användargrupper.

• Giltiga användare för projektsamling: Alla medlemmar har lagts till i en grupp på organisationsnivå.
• Giltiga projektanvändare: Alla medlemmar har lagts till i en grupp på projektnivå.

Standardbehörigheterna som tilldelas dessa grupper ger främst läsåtkomst, till exempel Visa byggresurser, Visa information på projektnivå och Visa information på samlingsnivå.

Alla användare som du lägger till i ett projekt kan visa objekten i andra projekt i en samling. Om du vill begränsa visningsåtkomsten kan du ange begränsningar via noden för områdessökväg.

Om du tar bort eller nekar behörigheten Visa information på instansnivå för någon av grupperna Giltiga användare kan inga medlemmar i gruppen komma åt projektet, samlingen eller distributionen, beroende på vilken grupp du har angett.

Grupp med projektomfattningsanvändare

Som standard kan användare som läggs till i en organisation visa all information och inställningar för organisationen och projektet. De här inställningarna omfattar listan över användare, listan över projekt, faktureringsinformation, användningsdata med mera, som du kan komma åt via organisationsinställningar.

Viktigt!

• Funktionerna för begränsad synlighet som beskrivs i det här avsnittet gäller endast interaktioner via webbportalen. Med REST-API:er eller azure devops CLI-kommandon kan projektmedlemmar komma åt begränsade data.
• Gästanvändare som är medlemmar i den begränsade gruppen med standardåtkomst i Microsoft Entra-ID kan inte söka efter användare med personväljaren. När förhandsgranskningsfunktionen är inaktiveradför organisationen, eller när gästanvändare inte är medlemmar i den begränsade gruppen, kan gästanvändare som förväntat söka i alla Microsoft Entra-användare.

Om du vill begränsa specifika användare, till exempel Intressenter, Microsoft Entra-gästanvändare eller medlemmar i en viss säkerhetsgrupp, kan du aktivera funktionen Begränsa användarnas synlighet och samarbete till specifika projekts förhandsversion för organisationen. När den är aktiverad begränsas alla användare eller grupper som läggs till i gruppen Project-begränsade användare från att komma åt sidorna Organisationsinställningar, förutom översikt och projekt. Dessutom har de bara åtkomst till de projekt som de läggs till i.

Varning

När funktionen Begränsa användarens synlighet och samarbete för specifika projektförhandsgranskning är aktiverad för organisationen kan användare med projektomfattning inte söka efter användare som har lagts till i organisationen via Microsoft Entra-gruppmedlemskap, i stället för via en explicit användarinbjudan. Detta är ett oväntat beteende och en lösning bearbetas. Om du vill lösa problemet själv inaktiverar du funktionen Begränsa användarens synlighet och samarbete till specifika projektförhandsgranskning för organisationen.

Mer information finns i Hantera förhandsgranskningsfunktioner.

Kommentar

Säkerhetsgrupper tillhör organisationsnivån, även om de bara har åtkomst till ett visst projekt. Vissa grupper kan vara dolda i webbportalen beroende på användarbehörigheter. Du hittar alla gruppnamn i en organisation med cli-verktyget azure devops eller våra REST-API:er. Mer information finns i Lägga till och hantera säkerhetsgrupper.

Rollbaserade behörigheter

Med rollbaserade behörigheter tilldelar du användarkonton eller säkerhetsgrupper till en roll, med varje roll tilldelad en eller flera behörigheter. Här är de primära rollerna och länkarna till mer information.

• Säkerhetsroller för artefakt eller paketflöde: Roller stöder olika behörighetsnivåer för att redigera och hantera paketflöden.
• Roll för Marketplace-tilläggshanteraren: Medlemmar i managerrollen kan installera tillägg och svara på begäranden om att tillägg ska installeras.
• Säkerhetsroller för pipeline: Flera roller används för att hantera biblioteksresurser, pipelineresurser på projektnivå och samlingsnivå.
• Teamadministratörsroll Teamadministratörer kan hantera alla teamverktyg.

Mer information finns i Om säkerhetsroller.

Följande bild visar hur säkerhetsgrupper som definierats på projekt- och samlingsnivå kan tilldela behörigheter till objekt, projekt och organisationen.

Medlemmar i grupperna Projektadministratörer eller Projektsamlingsadministratörer kan hantera alla teamverktyg för alla team.

Metodtips för behörigheter

Göra:

• Använd Microsoft Entra-ID, Active Directory eller Windows-säkerhetsgrupper när du hanterar många användare.
• När du lägger till ett team bör du överväga vilka behörigheter du vill tilldela till teamledare, scrum-huvudservrar och andra teammedlemmar. Överväg vem som skapar och ändrar områdessökvägar, iterationssökvägar och frågor.
• När du lägger till många team bör du överväga att skapa en anpassad grupp för teamadministratörer där du kan allokera en delmängd av de behörigheter som är tillgängliga för projektadministratörer.
• Överväg att ge arbetsobjektets frågemappar Behörighet att bidra till användare eller grupper som kräver möjligheten att skapa och dela frågor om arbetsobjekt för projektet.

Gör inte:

• Lägg inte till användare i flera säkerhetsgrupper, som innehåller olika behörighetsnivåer. I vissa fall kan behörighetsnivån Neka åsidosätta behörighetsnivån Tillåt .
• Ändra inte standardtilldelningarna som görs i grupperna Giltiga användare. Om du tar bort eller anger behörigheten Visa information på instansnivå till Neka för någon av grupperna Giltiga användare kan inga användare i gruppen komma åt projektet, samlingen eller distributionen, beroende på vilken grupp du har angett.
• Tilldela inte behörigheter som anges som "Tilldela endast till tjänstkonton" till användarkonton.

Förhandsfunktioner

Funktionsflaggor styr åtkomsten för att välja nya funktioner. Med jämna mellanrum introducerar Azure DevOps nya funktioner genom att placera dem bakom en funktionsflagga. Projektmedlemmar och organisationsägare kan aktivera eller inaktivera förhandsversionsfunktioner. Mer information finns i Hantera eller aktivera funktioner.

Nästa steg

Standardbehörigheter och åtkomst

Relaterade artiklar

• Felsöka problem med åtkomst och behörigheter
• Om säkerhet, autentisering och auktorisering
• Referens för behörigheter och grupper
• Verktyg för säkerhets- och behörighetshantering
• Lägga till och hantera säkerhetsgrupper