Share via

Metodtips för säkerhet

  • Artikel

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

När du arbetar med information och data, särskilt i en molnbaserad lösning som Azure DevOps Services, bör det alltid vara ditt primära problem att prioritera säkerhet. Microsoft upprätthåller säkerheten för den underliggande molninfrastrukturen, men det är ditt ansvar att konfigurera säkerheten i Azure DevOps.

Även om det inte är obligatoriskt kan du förbättra din upplevelse genom att använda metodtips när du använder Azure DevOps och göra det säkrare. Vi har sammanställt följande metodtips som syftar till att skydda din Azure DevOps-miljö:

Skydda Azure DevOps-miljön

Ta bort användare

  • Om din organisation använder MSA-konton tar du bort inaktiva användare direkt från organisationen eftersom du inte har något annat sätt att förhindra åtkomst. När du gör det kan du inte skapa en fråga för arbetsobjekt som tilldelats det borttagna användarkontot. Mer information finns i Ta bort användare från Azure DevOps.
  • Om din organisation är ansluten till Microsoft Entra-ID kan du inaktivera eller ta bort Microsoft Entra-användarkontot och lämna ditt Azure DevOps-användarkonto aktivt. På så sätt kan du fortsätta att köra frågor mot arbetsobjekthistoriken med hjälp av ditt Azure DevOps-användar-ID.
  • Återkalla användar-PAT: er.
  • Återkalla alla särskilda behörigheter som kan ha beviljats enskilda användarkonton.
  • Omtilldela arbete från användare som du tar bort till aktuella gruppmedlemmar.

Använda Microsoft Entra-ID

Integrera Azure DevOps med Microsoft Entra-ID för att ha ett enda identitetsplan. Konsekvens och en enda auktoritativ källa ökar tydligheten och minskar säkerhetsriskerna med mänskliga fel och konfigurationskomplexitet. Nyckeln till slutstyrning är att ha flera rolltilldelningar (med olika rolldefinitioner och olika resursomfattningar till samma Microsoft Entra-grupper). Utan Microsoft Entra-ID är du ensam ansvarig för att kontrollera organisationens åtkomst.

Med Microsoft Entra-ID kan du också komma åt andra säkerhetsfunktioner, till exempel multifaktorautentisering eller andra principer för villkorlig åtkomst.

Mer information finns i följande artiklar:

Granska granskningshändelser

När du har en Microsoft Entra-stödd organisation kan du aktivera Granskning i dina säkerhetsprinciper. Granska granskningshändelser regelbundet för att övervaka och reagera på oväntade användningsmönster av administratörer och andra användare.

Skydda ditt nätverk

Några sätt att göra detta kan vara:

  • Konfigurera en lista över tillåtna för att begränsa specifika IP-adresser.
  • Använd alltid kryptering.
  • Verifiera certifikat.
  • Implementera brandväggar för webbprogram så att de kan filtrera, övervaka och blockera skadlig webbaserad trafik till och från Azure DevOps.
  • Mer information finns i den här vägledningen om metodtips för programhantering

Begränsade behörigheter

Systemet hanterar behörigheter på olika nivåer – individ, samling, projekt och objekt – och tilldelar dem till en eller flera inbyggda grupper som standard.

Behörigheter på projektnivå

  • Begränsa åtkomsten till projekt och lagringsplatser för att minska risken för att känslig information läcker och distribuera osäker kod till produktion.
  • Använd antingen de inbyggda säkerhetsgrupperna eller anpassade säkerhetsgrupper för att hantera behörigheter. Mer information finns i Bevilja eller begränsa behörigheter för att välja aktiviteter.
  • Inaktivera "Tillåt offentliga projekt" i organisationens principinställningar för att förhindra att alla organisationsanvändare skapar ett offentligt projekt. Med Azure DevOps Services kan du ändra synligheten för dina projekt från offentlig till privat och vice versa. Om användarna inte har loggat in i din organisation har de skrivskyddad åtkomst till dina offentliga projekt. Om användarna har loggat in kan de beviljas åtkomst till privata projekt och göra eventuella tillåtna ändringar i dem.
  • Tillåt inte att användare skapar nya projekt.

Extern gäståtkomst

  • Blockera extern gäståtkomst helt genom att inaktivera principen Tillåt att inbjudningar skickas till valfri domän. Det är en bra idé att göra det om det inte finns något affärsbehov för det.
  • Använd ett annat e-post- eller användarhuvudnamn (UPN) för dina personliga konton och företagskonton, även om det är tillåtet. Den här åtgärden eliminerar utmaningen att skilja mellan dina företagskonton och personliga konton när e-postmeddelandet/UPN är detsamma.
  • Placera alla externa gästanvändare i en enda Microsoft Entra-grupp och hantera behörigheterna för den gruppen på rätt sätt. Du kan enkelt hantera och granska på det här sättet.
    • Ta bort direkttilldelningar så att gruppreglerna gäller för dessa användare. Mer information finns i Lägga till en gruppregel för att tilldela åtkomstnivåer.
    • Utvärdera regler regelbundet på fliken Gruppregler på sidan Användare. Klargöra om ändringar av gruppmedlemskap i Microsoft Entra-ID kan påverka din organisation. Microsoft Entra-ID kan ta upp till 24 timmar att uppdatera dynamiskt gruppmedlemskap. Var 24:e timme och när en gruppregel ändras omvärderas reglerna automatiskt i systemet.
  • Mer information finns i B2B-gäster i Microsoft Entra-ID:t.

Hantera säkerhetsgrupper

Säkerhets- och användargrupper

Se följande rekommendationer för att tilldela behörigheter till säkerhetsgrupper och användargrupper.

Göra Gör inte
Använd Microsoft Entra-ID, Active Directory eller Windows-säkerhetsgrupper när du hanterar många användare. Ändra inte standardbehörigheterna för gruppen Projekt giltiga användare . Den här gruppen kan komma åt och visa projektinformation.
När du lägger till team bör du överväga vilka behörigheter du vill tilldela till teammedlemmar som behöver skapa och ändra områdessökvägar, iterationssökvägar och frågor. 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 .
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 allokerar en delmängd av de behörigheter som är tillgängliga för projektadministratörer. Ändra inte standardtilldelningarna som görs i grupperna Project Valid Users . Om du tar bort eller anger Visa information på instansnivå till Neka för någon av grupperna Project Valid Users kan inga användare i gruppen komma åt det projekt, den samling eller den distribution som du anger behörigheten för.
Överväg att ge arbetsobjektets frågemappar Behörighet att bidra till användare eller grupper som behöver möjlighet att skapa och dela frågor om arbetsobjekt för projektet. Tilldela inte behörigheter som anges som Tilldela endast till tjänstkonton till användarkonton.
Håll grupperna så små som möjligt. Åtkomsten bör begränsas och grupperna bör granskas ofta.
Dra nytta av inbyggda roller och som standard deltagare för utvecklare. Administratörer tilldelas till säkerhetsgruppen Projektadministratör för utökade behörigheter, så att de kan konfigurera säkerhetsbehörigheter.

Mer information finns i Giltiga användargrupper.

Just-in-time-åtkomst för administratörsgrupper

Du kan ändra konfigurationen av din organisation eller ditt projekt om du har administratörs- och projektadministratörsåtkomst för projektsamlingen. För att skydda åtkomsten till dessa inbyggda administratörsgrupper behöver du just-in-time-åtkomst med hjälp av en PiM-grupp (Microsoft Entra Privileged Identity Management).

Konfigurera åtkomst

  1. Skapa en rolltilldelningsbar grupp i Microsoft Entra-ID.
  2. Lägg till din Microsoft Entra-grupp i Azure DevOps-gruppen.

Kommentar

Kontrollera att alla användare med förhöjd åtkomst med hjälp av en PIM-grupp också har standardåtkomst till organisationen, så att de kan visa sidan för att uppdatera sina behörigheter.

Använda åtkomst

  1. Aktivera din åtkomst.
  2. Uppdatera dina behörigheter i Azure DevOps.
  3. Vidta åtgärden som kräver administratörsåtkomst.

Kommentar

Användare har förhöjd åtkomst i Azure DevOps i upp till 1 timme efter att deras PIM-gruppåtkomst har inaktiverats.

Omfångstjänstkonton

  • Se till att tjänstkonton inte har några interaktiva inloggningsrättigheter.
  • Begränsa behörigheter för tjänstkonton till det minsta som krävs.
  • Använd en annan identitet för rapportläsarkontot om du använder domänkonton för dina tjänstkonton. Mer information finns i Tjänstkonton och beroenden.
  • Använd lokala konton för användarkonton om du installerar en komponent i en arbetsgrupp. Mer information finns i Krav för tjänstkonton.
  • Använd tjänstanslutningar när det är möjligt. Tjänstanslutningar ger en säker mekanism för att ansluta till olika tjänster utan att behöva skicka in hemliga variabler till bygget direkt. – Begränsa dessa anslutningar till den specifika plats där de ska användas och inget mer.
  • Övervaka tjänstkontoaktivitet och skapa granskningsströmning. Med granskning kan du identifiera och reagera på misstänkta inloggningar och aktiviteter.
  • Mer information finns i Common Service-anslutningstyper.

Omfångstjänstanslutningar

  • Omfång för Azure Resource Manager och andra tjänstanslutningar, endast till de resurser och grupper som de behöver åtkomst till. Tjänstanslutningar bör inte ha breda deltagarrättigheter för hela Azure-prenumerationen.
  • Använd arbetsbelastningsidentitetsfederation för dina ARM-tjänstanslutningar (Azure Resource Manager). Med arbetsbelastningsidentitetsfederation kan du skapa hemliga tjänstanslutningar i Azure Pipelines till Azure.
  • Ge inte användarna allmänna eller breda deltagarrättigheter för Azure-prenumerationen.
  • Använd inte klassiska Azure-tjänstanslutningar eftersom det inte finns något sätt att begränsa behörigheterna.
  • Kontrollera att resursgruppen endast innehåller virtuella datorer eller resurser som bygget behöver åtkomst till.
  • Använd ett specifikt teamtjänstkonto för att autentisera en tjänstanslutning.
  • Mer information finns i Common Service-anslutningstyper.

Välja rätt autentiseringsmetod

Välj dina autentiseringsmetoder från följande källor:

Överväg tjänstens huvudnamn

Utforska alternativ som tjänstens huvudnamn och hanterade identiteter som gör att du kan använda Microsoft Entra-token för att få åtkomst till Azure DevOps-resurser. Sådana token medför mindre risk vid läckage jämfört med PAT och innehåller fördelar som enkel hantering av autentiseringsuppgifter.

Använd PAT sparsamt

Om möjligt rekommenderar vi att du alltid använder identitetstjänster för autentisering i stället för kryptografiska nycklar eftersom det är svårt att hantera nycklar säkert med programkod och kan leda till misstag som att oavsiktligt publicera känsliga åtkomstnycklar till offentliga kodlagringsplatser som GitHub. Men om du måste använda personliga åtkomsttoken (PAT) bör du överväga följande riktlinjer:

  • PAT:er bör alltid begränsas till specifika roller.

  • PAT:er bör inte ge global åtkomst till flera organisationer.

  • PAT:er bör inte bevilja skriv- eller hanteringsbehörigheter för versioner eller versioner.

  • PAT:er bör ha ett förfallodatum och hållas hemliga eftersom de är lika viktiga som lösenord.

  • PAT bör aldrig hårdkodas i programkoden, även om det är frestande att göra det för att förenkla koden.

  • Administratörer bör regelbundet granska alla PAT:er med hjälp av REST-API:erna och återkalla alla som inte uppfyller ovanstående kriterier.

  • Håll dina PATs hemliga. Dina token är lika viktiga som lösenord.

  • Lagra dina token på en säker plats.

  • Hårdkoda inte token i program. Det kan vara frestande att förenkla koden för att få en token under en längre tid och lagra den i ditt program, men gör inte det.

  • Ge token ett förfallodatum.

  • Mer information finns i följande artiklar:

Skydda Azure Artifacts

Skydda Azure Boards

Skydda Azure Pipelines

Principer

  • Kräv minst en granskare utanför den ursprungliga beställaren. Godkännaren delar medägaren av ändringarna och bör hållas lika ansvarig för eventuella effekter.
  • Kräv ATT CI-kompilering godkänns. Det här kravet är användbart för att fastställa kodkvaliteten för baslinjen, genom kodlintning, enhetstester och säkerhetskontroller, till exempel genomsökningar av virus och autentiseringsuppgifter.
  • Kontrollera att den ursprungliga pull-beställaren inte kan godkänna ändringen.
  • Tillåt inte slutförande av en PR (pull-begäran), även om vissa granskare röstar för att vänta eller avvisa.
  • Återställ kodgranskarens röster när de senaste ändringarna skickas.
  • Lås versionspipelines genom att endast köra dem på specifika produktionsgrenar.
  • Aktivera "Framtvinga inställningsbar vid kötid för variabler" i organisationens pipelineinställningar.
  • Tillåt inte "Låt användare åsidosätta det här värdet när de kör den här pipelinen" för variabler som anges i redigeraren.

Handläggare

  • Bevilja behörigheter till det minsta möjliga antalet konton.
  • Ha den mest restriktiva brandväggen som lämnar dina agenter användbara.
  • Uppdatera pooler regelbundet för att säkerställa att byggflottan inte kör sårbar kod som en skadlig aktör kan utnyttja.
  • Använd en separat agentpool för att skapa artefakter som levereras eller distribueras till produktion.
  • Segmentera "känslig" pool från meningslösa pooler och tillåt endast användning av autentiseringsuppgifter i versionsdefinitioner som är låsta till poolen.

Definitioner

  • Hantera pipelinedefinitioner med YAML (ännu ett markeringsspråk). YAML är den bästa metoden för att hantera pipelinedefinitioner, eftersom det ger spårbarhet för ändringar och kan följa riktlinjerna för godkännande.
  • Skydda pipelinedefinitionen Redigera åtkomst till det minsta antalet konton.

Indata

  • Inkludera sanity-kontroller för variabler i byggskript. En sanity-kontroll kan minimera en kommandoinmatningsattack via de inställbara variablerna.
  • Ange så få byggvariabler som möjligt till "Settable at release time".

Uppgifter

  • Undvik fjärrhämtning av resurser, men använd vid behov versionshantering och hashkontroll.
  • Logga inte hemligheter.
  • Lagra inte hemligheter i pipelinevariabler, använd Azure Key Vault. Genomsök regelbundet dina byggpipelines för att säkerställa att hemligheter inte lagras i pipelinevariabler för bygget.
  • Låt inte användare köra byggen mot godtyckliga grenar eller taggar på säkerhetskritiska pipelines.
  • Inaktivera arv i pipelinen eftersom ärvda behörigheter är breda och inte korrekt återspeglar dina behörighetsbehov.
  • Begränsa jobbauktoriseringsomfång i alla fall.

Lagringsplatser och grenar

  • Ange principen "Kräv ett minsta antal granskare" till på så att varje pull-begäran granskas av minst två godkännare.
  • Konfigurera säkerhetsprinciper som är specifika för varje lagringsplats eller gren, i stället för hela projektet. Säkerhetsprinciper minskar risken, tillämpar ändringshanteringsstandarder och förbättrar teamets kodkvalitet.
  • Lagra produktionshemligheter i ett separat Key Vault och se till att åtkomst endast beviljas på behovsbasis för att hålla icke-produktionsversioner åtskilda.
  • Blanda inte testmiljöer med produktion, inklusive användning av autentiseringsuppgifter.
  • Inaktivera förgrening. Ju fler gafflarna finns, desto svårare är det att hålla reda på varje förgrenings säkerhet. Dessutom kan en användare enkelt förgrena en kopia av en lagringsplats till sitt eget privata konto.
  • Ange inte hemligheter för förgreningsversioner.
  • Överväg att utlösa förgreningsversioner manuellt.
  • Använd Microsoft-värdbaserade agenter för förgreningsversioner.
  • För Git kontrollerar du dina produktionsversionsdefinitioner på projektets git-lagringsplats så att de kan genomsökas efter autentiseringsuppgifter.
  • Konfigurera en kontroll av grenkontroll så att endast pipelines som körs i grenens production kontext kan använda prod-connection.
  • Mer information finns i Andra säkerhetsöverväganden.

Skydda Azure-lagringsplatser

Säkra Azure-testplaner

Skydda GitHub-integreringar

  • Inaktivera personlig åtkomsttoken (PAT)-baserad autentisering, så att OAuth-flödet används med GitHub-tjänstanslutningen.
  • Autentisera aldrig GitHub-tjänstanslutningar som en identitet som är administratör eller ägare av några lagringsplatser.
  • Använd aldrig en GitHub PAT med fullständig omfattning (personlig åtkomsttoken) för att autentisera GitHub-tjänstanslutningar.
  • Använd inte ett personligt GitHub-konto som en tjänstanslutning med Azure DevOps.