Om säkerhet, autentisering och auktorisering

  • Artikel

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

Azure DevOps använder många säkerhetskoncept för att säkerställa att endast de användare som ska ha åtkomst till funktioner, funktioner och data har åtkomst. Konton får åtkomst till Azure DevOps genom autentisering av sina säkerhetsautentiseringsuppgifter och auktorisering av sina kontorättigheter för att få åtkomst till en funktion eller funktion.

Den här artikeln bygger på informationen i Kom igång med behörigheter, åtkomst och säkerhetsgrupper. Administratörer har nytta av att förstå kontotyper, autentiseringsmetoder, auktoriseringsmetoder och principer som används för att skydda Azure DevOps.

Kontotyper

  • Användare
  • Organisationsägare
  • Tjänstkonton
  • Tjänstens huvudnamn eller hanterade identiteter
  • Jobbagenter

Autentisering

  • Användarautentiseringsuppgifter
  • Windows-autentisering
  • Tvåfaktorsautentisering (2FA)
  • SSH-nyckelautentisering
  • Personliga åtkomsttoken
  • Oauth-konfiguration
  • Active Directory-autentiseringsbibliotek

Auktorisering

  • Medlemskap i säkerhetsgrupp
  • Rollbaserad åtkomstkontroll
  • Åtkomstnivåer
  • Funktionsflaggor
  • Säkerhetsnamnområden och behörigheter

Principer

  • URL för sekretesspolicy
  • Anslutnings- och säkerhetsprinciper för program
  • Användarprinciper
  • Git-lagringsplats och grenprinciper

Kontotyper

  • Användare
  • Tjänstkonton
  • Tjänstens huvudnamn eller hanterade identiteter
  • Jobbagenter

Autentisering

  • Användarautentiseringsuppgifter
  • Windows-autentisering
  • Tvåfaktorsautentisering (2FA)
  • SSH-nyckelautentisering
  • Personliga åtkomsttoken
  • Oauth-konfiguration
  • Active Directory-autentiseringsbibliotek

Auktorisering

  • Medlemskap i säkerhetsgrupp
  • Rollbaserade behörigheter
  • Åtkomstnivåer
  • Funktionsflaggor
  • Säkerhetsnamnområden och behörigheter

Principer

  • Git-lagringsplats och grenprinciper

Viktigt!

Azure DevOps har inte längre stöd för autentisering med alternativa autentiseringsuppgifter sedan början av den 2 mars 2020. Om du fortfarande använder alternativa autentiseringsuppgifter rekommenderar vi starkt att du byter till en säkrare autentiseringsmetod (till exempel personliga åtkomsttoken). Läs mer.

Både vår molntjänst, Azure DevOps Services och den lokala servern, Azure DevOps Server, stöder programutvecklingsprojekt, från planering till distribution. Azure DevOps använder Microsoft Azures plattform som en tjänstinfrastruktur och många av Azures tjänster, inklusive Azure SQL-databaser, för att leverera en tillförlitlig, globalt tillgänglig tjänst för dina utvecklingsprojekt.

Mer information om de steg Som Microsoft vidtar för att skydda dina projekt i Azure DevOps Services, som är tillgängliga, säkra och privata, finns i det här vitboken, Översikt över Azure DevOps Services-dataskydd.

Accounts

De viktigaste typerna av konton av intresse är de mänskliga användarkonton som du lägger till i din organisation eller ditt projekt, men Azure DevOps stöder andra typer av konton för att utföra olika åtgärder. Dessa inkluderar följande kontotyper.

  • Organisationsägare: Skaparen av en Azure DevOps Services-organisation eller tilldelad ägare. Information om vem som är organisationsägare för din organisation finns i Leta upp organisationens ägare.
  • Tjänstkonton: Interna Azure DevOps-konton som används för att stödja en specifik tjänst, till exempel Agent Pool Service, PipelinesSDK. Beskrivningar av tjänstkonton finns i Säkerhetsgrupper, tjänstkonton och behörigheter.
  • Tjänstens huvudnamn eller hanterade identiteter: Microsoft Entra-program eller hanterade identiteter som har lagts till i din organisation för att utföra åtgärder för ett program från tredje part. Vissa tjänsthuvudnamn refererar till interna Azure DevOps-konton för att stödja interna åtgärder.
  • Jobbagenter: Interna konton som används för att köra specifika jobb enligt ett vanligt schema.
  • Konton från tredje part: Konton som kräver åtkomst för att stödja webbkrokar, tjänstanslutningar eller andra program från tredje part.

I dessa dokument kan användarna referera till alla identiteter som har lagts till i användarhubben, som kan omfatta mänskliga användare och tjänstens huvudnamn.

  • Tjänstkonton: Interna Azure DevOps-konton som används för att stödja en specifik tjänst, till exempel Agent Pool Service, PipelinesSDK. Beskrivningar av tjänstkonton finns i Säkerhetsgrupper, tjänstkonton och behörigheter.
  • Tjänstens huvudnamn eller hanterade identiteter: Microsoft Entra-program eller hanterade identiteter som har lagts till i din organisation för att utföra åtgärder för ett program från tredje part. Vissa tjänsthuvudnamn refererar till interna Azure DevOps-konton för att stödja interna åtgärder.
  • Jobbagenter: Interna konton som används för att köra specifika jobb enligt ett vanligt schema.
  • Konton från tredje part: Konton som kräver åtkomst för att stödja webbkrokar, tjänstanslutningar eller andra program från tredje part.

Det mest effektiva sättet att hantera konton är genom att lägga till dem i säkerhetsgrupper.

Kommentar

Organisationens ägare och medlemmar i gruppen Projektsamlingsadministratörer beviljas fullständig åtkomst till de flesta funktioner och funktioner.

Autentisering

Autentisering verifierar en kontoidentitet baserat på de autentiseringsuppgifter som anges när de loggar in på Azure DevOps. Dessa system integreras med och förlitar sig på de säkerhetsfunktioner som tillhandahålls av dessa andra system:

  • Microsoft Entra ID
  • Microsoft-konto (MSA)
  • Active Directory (AD)

Microsoft Entra ID och MSA stöder molnautentisering. Vi rekommenderar Microsoft Entra-ID när du behöver hantera en stor grupp användare. Annars kan du använda Microsoft-konton om du har en liten användarbas som har åtkomst till din organisation i Azure DevOps. Mer information finns i Om åtkomst till Azure DevOps med Microsoft Entra-ID.

För lokala distributioner rekommenderas AD när du hanterar en stor grupp användare. Mer information finns i Konfigurera grupper för användning i lokala distributioner.

Autentiseringsmetoder och integrering med andra tjänster och appar

Andra program och tjänster kan integreras med tjänster och resurser i Azure DevOps. Appar kan använda följande autentiseringsmetoder för att komma åt ditt konto utan att be om autentiseringsuppgifter för användare flera gånger.

  • Personliga åtkomsttoken för att generera token åt dig själv för:

    • Åtkomst till specifika resurser eller aktiviteter, till exempel byggen eller arbetsobjekt
    • Klienter såsom Xcode och NuGet, som kräver användarnamn och lösenord eftersom grundläggande autentiseringsuppgifter och inte stöder Microsoft-konto- och Microsoft Entra-funktioner, exempelvis multifaktorautentisering
    • Åtkomst till Azure DevOps REST-API:er

  • Azure DevOps OAuth för att generera token för användares räkning för åtkomst till REST-API:er. API:erna för konton och profiler stöder endast OAuth.

  • SSH-autentisering för att generera krypteringsnycklar åt dig själv vid användning av Linux, macOS eller Windows som kör Git för Windows och inte kan använda Git-autentiseringshanterare eller personliga åtkomsttoken för HTTPS-autentisering.

  • Tjänstens huvudnamn eller hanterade identiteter för att generera Microsoft Entra-token för ett program eller en tjänst, som vanligtvis automatiserar vissa arbetsflöden som behöver åtkomst till Azure DevOps-resurser. De flesta åtgärder som traditionellt utförs av ett tjänstkonto och en PAT kan utföras med hjälp av tjänstens huvudnamn eller hanterad identitet.

Som standard tillåter ditt konto eller din samling åtkomst för alla autentiseringsmetoder. Du kan begränsa åtkomsten, men du måste specifikt begränsa åtkomsten för varje metod. När du nekar åtkomst till en autentiseringsmetod kan ingen app använda den metoden för att komma åt ditt konto. Alla appar som tidigare hade åtkomst får ett autentiseringsfel och kan inte komma åt ditt konto.

Mer information om hur vi lagrar dina autentiseringsuppgifter finns i Lagring av autentiseringsuppgifter för Azure DevOps.

Mer information om hur du väljer rätt autentiseringsmekanism finns i Vägledning för autentisering.

Auktorisering

Auktorisering verifierar att den identitet som försöker ansluta har de behörigheter som krävs för att få åtkomst till en tjänst, funktion, ett objekt eller en metod. Auktorisering sker alltid efter lyckad autentisering. Om en anslutning inte autentiseras misslyckas den innan någon auktoriseringskontroll utförs. Om autentiseringen av en anslutning lyckas kan en specifik åtgärd fortfarande vara otillåten eftersom användaren eller gruppen inte hade behörighet att utföra åtgärden.

Auktorisering beror på de behörigheter som tilldelats kontot. Behörigheter beviljas antingen direkt till ett konto eller genom medlemskap i en säkerhetsgrupp eller säkerhetsroll. Åtkomstnivåer och funktionsflaggor kan också bevilja eller begränsa åtkomsten till en funktion. Mer information om dessa auktoriseringsmetoder finns i Komma igång med behörigheter, åtkomst och säkerhetsgrupper.

Säkerhetsnamnområden och behörigheter

Säkerhetsnamnområden lagrar data som avgör vilken åtkomstnivå som Azure DevOps-konton måste utföra en specifik åtgärd på en specifik resurs. Varje resursfamilj, till exempel arbetsobjekt eller Git-lagringsplatser, skyddas via ett unikt namnområde. Varje säkerhetsnamnområde innehåller noll eller fler åtkomstkontrollistor (ACL:er). Varje ACL innehåller en token, en ärv flagga och en uppsättning med noll eller fler åtkomstkontrollposter (ACL). Varje ACE innehåller en identitetsbeskrivning, en tillåten behörighetsbitmask och en bitmask för nekad behörighet.

Mer information finns i Säkerhetsnamnområden och behörighetsreferens.

Säkerhetsprinciper

För att skydda din organisation och kod kan du ange många principer. Mer specifikt kan du aktivera eller inaktivera följande principer:

Allmänt

Anslutnings- och säkerhetsprinciper för program

Använd Microsoft Entra-klientprincipen för att begränsa skapandet av nya organisationer till önskade användare. Den här principen är inaktiverad som standard och gäller endast när organisationen är ansluten till Microsoft Entra-ID. Mer information finns i Begränsa skapandet av organisationen.

Följande principer avgör vilken åtkomst du vill ge användare och program till dina organisationer:

Användarprinciper

  • Extern gäståtkomst (Endast giltig när organisationen är ansluten till Microsoft Entra-ID.): När det är aktiverat kan inbjudningar skickas till e-postkonton för användare som inte är medlemmar i klientorganisationens Microsoft Entra-ID via sidan Användare . Mer information finns i Lägga till externa användare i din organisation.
  • Tillåt team- och projektadministratörer att bjuda in nya användare: Gäller endast när organisationen är ansluten till Microsoft Entra-ID. När det är aktiverat kan team- och projektadministratörer lägga till användare via sidan Användare . Mer information finns i Begränsa nya användarinbjudningar från projekt- och teamadministratörer.
  • Begär åtkomst: Endast giltig när organisationen är ansluten till Microsoft Entra-ID. När det är aktiverat kan användarna begära åtkomst till en resurs. En begäran resulterar i ett e-postmeddelande till administratörerna som ber om granskning och åtkomst efter behov. Mer information finns i Lägga till externa användare i din organisation.
  • Bjud in GitHub-användare: Endast giltigt när organisationen inte är ansluten till Microsoft Entra-ID. När det är aktiverat kan administratörer lägga till användare baserat på sina GitHub-användarkonton från sidan Användare . Mer information finns i Autentisera och bjuda in Vanliga frågor och svar om GitHub-användare.

Gruppen Project-Scoped Users (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. Detta inkluderar visningslista över användare, lista över projekt, faktureringsinformation, användningsdata med mera som nås via Organisationens Instä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 utvalda 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 det är aktiverat begränsas alla användare eller grupper som läggs till i gruppen Project-Scoped Users på följande sätt:

  • Kan bara komma åt sidorna Översikt och Projekt i Organisations Inställningar.
  • Kan bara ansluta och visa de projekt som de har lagts till i explicit (se Lägga till användare i ett projekt eller team.
  • Kan bara välja användar- och gruppidentiteter som uttryckligen har lagts till i projektet som de är anslutna till.

Mer information finns i Hantera din organisation, Begränsa användarnas synlighet för projekt och fler och Hantera förhandsgranskningsfunktioner.

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.

Git-lagringsplats och grenprinciper

För att skydda koden kan du ange många Git-lagringsplatser och grenprinciper. Mer information finns i följande artiklar.

Säkerhet för Azure Repos och Azure Pipelines

Eftersom lagringsplatser och bygg- och versionspipelines utgör unika säkerhetsutmaningar används andra funktioner utöver de funktioner som beskrivs i den här artikeln. Mer information finns i följande artiklar.

Nästa steg

Referens för behörigheter och grupper