Metodtips för säkerhet

Artikel
08/14/2024

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

När du hanterar information och data, särskilt i en molnbaserad lösning som Azure DevOps Services, bör säkerheten ha högsta prioritet. Microsoft säkerställer säkerheten för den underliggande molninfrastrukturen, men det är ditt ansvar att konfigurera säkerhet i Azure DevOps.

Även om det inte är obligatoriskt kan införandet av bästa praxis avsevärt förbättra din upplevelse och stärka säkerheten. Följande rekommendationer är utformade för att hjälpa dig att upprätthålla en säker Azure DevOps-miljö.

Skydda din Azure DevOps-miljö

Använd följande metodtips för att ta bort användare, granska granskningshändelser och integrera med Microsoft Entra-ID.

Ta bort användare

Ta bort inaktiva användare från Microsoft-konton (MSA: Ta bort inaktiva användare direkt från din organisation om du använder MSA:er. Du kan inte skapa frågor för arbetsobjekt som tilldelats till borttagna MSA-konton.
Inaktivera eller ta bort Microsoft Entra-användarkonton: Om du är ansluten till Microsoft Entra-ID inaktiverar eller tar du bort Microsoft Entra-användarkontot samtidigt som Azure DevOps-användarkontot är aktivt. Med den här åtgärden kan du fortsätta köra frågor mot arbetsobjekthistoriken med hjälp av ditt Användar-ID för Azure DevOps.
Återkalla användar-PAT: Granska och återkalla alla befintliga användar-PAT:er regelbundet för att säkerställa säker hantering av dessa kritiska autentiseringstoken.
Återkalla särskilda behörigheter som beviljats enskilda användare: Granska och återkalla eventuella särskilda behörigheter som beviljas enskilda användare för att säkerställa anpassning till principen om minsta behörighet.
Omtilldela arbete från borttagna användare: Innan du tar bort användare, omtilldela deras arbetsobjekt till aktuella teammedlemmar för att distribuera belastningen effektivt.

Använda Microsoft Entra-ID

Upprätta ett enhetligt identitetssystem: Anslut Azure DevOps till Microsoft Entra-ID för att skapa ett enda identitetsplan. Den här konsekvensen minskar förvirringen och minimerar säkerhetsrisker från manuella konfigurationsfel.
Implementera detaljerad styrning: Använd Microsoft Entra-ID för att tilldela olika roller och behörigheter till specifika grupper i olika resursomfattningar. Den här åtgärden säkerställer kontrollerad åtkomst och överensstämmer med bästa praxis för säkerhet.
Förbättra säkerhetsfunktioner: Aktivera andra säkerhetsfunktioner med Microsoft Entra-ID, till exempel:
- Multifaktorautentisering (MFA): Kräv flera faktorer som lösenords- och telefonverifiering för användarautentisering. Principer för villkorlig åtkomst: Definiera åtkomstregler baserat på villkor som plats, enhet eller risknivå.

Mer information finns i följande artiklar:

Granska granskningshändelser

Med din organisation ansluten till Microsoft Entra utför du följande uppgifter för att förbättra säkerheten och övervaka användningsmönster:

Aktivera granskning: Spåra och visa händelser som rör användaråtgärder, behörigheter och ändringar.
Granska granskningshändelser regelbundet: Leta efter oväntade användningsmönster, särskilt av administratörer och andra användare.

Skydda ditt nätverk

Följande funktioner är effektiva sätt att förbättra säkerheten i nätverket när du arbetar med Azure DevOps.

Konfigurera IP-tillåtna listor: Begränsa åtkomsten till specifika IP-adresser så att endast trafik tillåts från betrodda källor, vilket minskar attackytan.
Använd kryptering: Kryptera alltid data under överföring och i vila. Skydda kommunikationskanaler med protokoll som HTTPS.
Verifiera certifikat: Kontrollera att certifikaten är giltiga och utfärdade av betrodda myndigheter när anslutningar upprättas.
Implementera brandväggar för webbprogram (WAFs): Filtrera, övervaka och blockera skadlig webbaserad trafik med WAF:er för ett extra skydd mot vanliga attacker.

Mer information finns i Metodtips för programhantering.

Omfångsbehörigheter

Systemet hanterar behörigheter på olika nivåer – individuell, samling, projekt och objekt – och tilldelar dem som standard till en eller flera inbyggda grupper. Utför följande åtgärder för att förbättra säkerheten:

Ge åtkomst med minst behörighet: Ge användare och tjänster den minsta nödvändiga åtkomsten för att utföra sina affärsfunktioner.
Inaktivera arv: Inaktivera arv när det är möjligt. Arv kan oavsiktligt bevilja åtkomst eller behörigheter till oväntade användare på grund av dess tillåtna som standard. Mer information finns i avsnittet om arv av behörigheter

Mer information om behörigheter finns i följande artiklar:

Behörigheter på projektnivå

Begränsa åtkomsten till projekt och lagringsplatser: Minska risken för att känslig information läcker och distribuera osäker kod genom att begränsa åtkomsten till projekt och lagringsplatser. Använd inbyggda eller anpassade säkerhetsgrupper som hanterar behörigheter.
Inaktivera "Tillåt offentliga projekt": Inaktivera alternativet för att skapa offentliga projekt i organisationens principinställningar. Växla projektsynlighet från offentlig till privat efter behov. Användare som inte har loggat in har skrivskyddad åtkomst till offentliga projekt, medan inloggade användare kan beviljas åtkomst till privata projekt och göra tillåtna ändringar.
Begränsa skapandet av projekt: Förhindra att användare skapar nya projekt för att behålla kontrollen över din miljö.

Extern gäståtkomst

Blockera extern gäståtkomst: Inaktivera principen "Tillåt att inbjudningar skickas till valfri domän" för att förhindra extern gäståtkomst om det inte finns något affärsbehov för den.
Använd distinkta e-postmeddelanden eller UPN:er: Använd olika e-postadresser eller användarnamn (UPN) för personliga konton och företagskonton för att eliminera tvetydighet mellan personliga och arbetsrelaterade konton.
Gruppera externa gästanvändare: Placera alla externa gästanvändare i en enda Microsoft Entra-grupp och hantera behörigheter för den här gruppen på lämpligt sätt. Ta bort direkttilldelningar för att säkerställa att gruppreglerna gäller för dessa användare.
Utvärdera regler regelbundet: Granska reglerna regelbundet på fliken Gruppregler på sidan Användare. Överväg eventuella gruppmedlemskapsändringar i Microsoft Entra-ID som kan påverka din organisation. Microsoft Entra-ID kan ta upp till 24 timmar att uppdatera dynamiskt gruppmedlemskap och reglerna utvärderas automatiskt var 24:e timme och när en gruppregel ändras.

Mer information finns i B2B-gäster i Microsoft Entra-ID:t.

Hantera säkerhetsgrupper

Säkerhets- och användargrupper

I följande tabell visas 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. Mer information finns i Giltiga användargrupper.
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 . Anta till exempel att du har två säkerhetsgrupper i ditt Azure DevOps-projekt: Utvecklare och testare. Gruppen Utvecklare har behörighet att redigera arbetsobjekt som är inställda på Tillåt. Men se till att vissa känsliga arbetsobjekt inte redigeras av någon annan än några viktiga personer. Det gör du genom att skapa en ny säkerhetsgrupp med namnet Redigerare för känsliga objekt och ange behörighet att redigera arbetsobjekt till Neka för den här gruppen. Om en användare är medlem i både gruppen Utvecklare och gruppen Redigerare för känsliga objekt har behörigheten Neka från gruppen Redigerare för känsliga objekt företräde framför behörigheten Tillåt från gruppen Utvecklare . Därför kan den här användaren inte redigera känsliga arbetsobjekt, även om de har behörigheten Tillåt i gruppen Utvecklare . Det här beteendet säkerställer att neka-behörigheter tillämpas strikt, vilket ger en högre säkerhetsnivå och kontroll över känsliga åtgärder i Din Azure DevOps-miljö.
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.

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

Om du har administratörs- och projektadministratörsåtkomst för projektsamlingen kan du ändra konfigurationen för din organisation eller ditt projekt. Om du vill förbättra säkerheten för dessa inbyggda administratörsgrupper kan du överväga att implementera just-in-time-åtkomst med hjälp av en PIM-grupp (Microsoft Entra Privileged Identity Management). Med den här metoden kan du endast bevilja utökade behörigheter när det behövs, vilket minskar risken för permanent åtkomst.

Konfigurera åtkomst

Kommentar

När du konfigurerar just-in-time-åtkomst med hjälp av en PIM-grupp (Microsoft Entra Privileged Identity Management) ser du till att alla användare med förhöjd åtkomst också behåller standardåtkomsten till organisationen. På så sätt kan de visa de sidor som behövs och uppdatera sina behörigheter efter behov.

Använda åtkomst

Aktivera din åtkomst.
Uppdatera dina behörigheter i Azure DevOps.
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

Skapa tjänstkonton för en enda användning: Varje tjänst bör ha sitt dedikerade konto för att minimera risken. Undvik att använda vanliga användarkonton som tjänstkonton.
Följ namngivnings- och dokumentationskonventionerna: Använd tydliga, beskrivande namn för tjänstkonton och dokumentera deras syfte och tillhörande tjänster.
Identifiera och inaktivera oanvända tjänstkonton: Granska och identifiera konton som inte längre används. Inaktivera oanvända konton innan du överväger att ta bort.
Begränsa behörigheter: Begränsa tjänstkontoprivilegier till det minimum som krävs. Undvik interaktiva inloggningsrättigheter för tjänstkonton.
Använd separata identiteter för rapportläsare: Om du använder domänkonton för tjänstkonton använder du en annan identitet för rapportläsare för att isolera behörigheter och förhindra onödig åtkomst.
Använd lokala konton för arbetsgruppsinstallationer: När du installerar komponenter i en arbetsgrupp använder du lokala konton för användarkonton. Undvik domänkonton i det här scenariot.
Utnyttja tjänstanslutningar: Använd tjänstanslutningar när det är möjligt för att på ett säkert sätt ansluta till tjänster utan att skicka hemliga variabler direkt till byggen. Begränsa anslutningar till specifika användningsfall.
Övervaka aktivitet för tjänstkonto: Implementera granskning och skapa granskningsströmmar för att övervaka tjänstkontoaktivitet.

Mer information finns i Common Service-anslutningstyper.

Omfångstjänstanslutningar

Omfångstjänstanslutningar: Begränsa åtkomsten genom att omfångsbegränsa dina Azure Resource Manager-tjänstanslutningar till specifika resurser och grupper. Undvik att bevilja breda deltagarrättigheter i hela Azure-prenumerationen.
Använd identitetsfederation för arbetsbelastning: Autentisera med Azure-resurser med hjälp av OpenID Connect (OIDC) utan hemligheter. Skapa identitetsfederation för arbetsbelastning automatiskt eller manuellt om du har rollen Ägare för din Azure-prenumeration, inte ansluter till Azure Stack- eller Azure US Government-miljöer och eventuella Uppgifter för Marketplace-tillägg som du använder stöder det.
Omfångsresursgrupper: Se till att resursgrupper endast innehåller de virtuella datorer (VM) eller resurser som behövs för byggprocessen.
Undvik klassiska tjänstanslutningar: Välj moderna Azure Resource Manager-tjänstanslutningar i stället för klassiska anslutningar, som saknar omfångsalternativ.
Använd specifika teamtjänstkonton: Autentisera tjänstanslutningar med hjälp av specifika teamtjänstkonton för att upprätthålla säkerhet och kontroll.

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 och hanterade identiteter
Använd personliga åtkomsttoken (PAT) sparsamt

Överväg tjänstens huvudnamn

Utforska alternativ som tjänstens huvudnamn och hanterade identiteter:

Använd tjänstens huvudnamn: Representera säkerhetsobjekt i ett Microsoft Entra-program. Definiera vad ett program kan göra i en viss klientorganisation. Konfigurera under programregistreringen i Azure Portal. Konfigurera för åtkomst till Azure-resurser, inklusive Azure DevOps. Användbart för appar som behöver specifik åtkomst och kontroll.
Använd hanterade identiteter: Liknar ett programs huvudnamn för tjänsten. Ange identiteter för Azure-resurser. Tillåt att tjänster som stöder Microsoft Entra-autentisering delar autentiseringsuppgifter. Azure hanterar hantering och rotation av autentiseringsuppgifter automatiskt. Perfekt för sömlös hantering av inloggningsinformation.

Använd PAT sparsamt

Omfångs-PAT:er för specifika roller: Tilldela endast DE PAT:er som krävs för specifika uppgifter. Undvik att ge global åtkomst till flera organisationer eller lagringsplatser för att minimera risken för oavsiktligt missbruk.
Undvik att skriva eller hantera behörigheter för versioner och versioner: PAT:er bör inte ha skriv- eller hanteringsbehörigheter för versioner, versioner eller andra kritiska resurser. Om du begränsar dessa behörigheter kan du förhindra oavsiktliga åtgärder som kan påverka dina pipelines eller distributioner.
Ange förfallodatum och håll PAT:er hemliga: Ange alltid ett förfallodatum för PAT:er. Granska och förnya dem regelbundet efter behov. Behandla PAT:er som kritiska som lösenord, håll dem konfidentiella och undvik offentlig delning eller hårdkodning i programkoden.
Undvik hårdkodning av PAT:er i programkod: I stället för att bädda in PAT direkt i koden använder du säkra konfigurationsfiler eller miljövariabler för att lagra och hämta PAT dynamiskt. dynamiskt.
Granska och återkalla oanvända PAT:er regelbundet: Administratörer bör regelbundet granska alla PAT:er med hjälp av REST-API:erna. Återkalla alla PAT:er som inte längre behövs eller som inte uppfyller de rekommenderade kriterierna.

Mer information finns i Hantera PAT med principer – för administratörer och Använda PAT.

Skydda Azure Artifacts

Se till att du förstår skillnaden mellan feeds, projekt och projektsamlingsadministratörer. Mer information finns i Konfigurera Azure Artifacts-inställningar.
Ange feedbehörigheter.

Skydda Azure Boards

Konfigurera och anpassa Azure Boards innan du anpassar en process.
Ange behörigheter för arbetsspårning och plan
Lär dig standardbehörigheter och åtkomst till Azure Boards
Ange frågebehörigheter

Skydda Azure Pipelines

Policyer

Kräv externa granskare: Se till att minst en granskare utanför den ursprungliga beställaren för en grundlig granskningsprocess. Godkännaren delar medägarskapet för ändringarna och ansvarsskyldigheten för eventuella effekter.
Kräv att CI-kompileringen godkänns: Upprätta en baslinje för kodkvalitet genom att kräva att ci-versionen (Continuous Integration) godkänns innan en PR slås samman. CI-kontroller omfattar kodlintning, enhetstester och säkerhetsgenomsökningar.
Tillåt inte självgodkännande: Förhindra att den ursprungliga PR-beställaren godkänner sina egna ändringar för att säkerställa en opartisk granskningsprocess och undvika intressekonflikter.
Tillåt inte PR-slutförande med "vänta" eller "avvisa" röster: Förhindra PR-slutförande även om vissa granskare röstar för att vänta eller avvisa, vilket uppmuntrar till att ta itu med all feedback innan de slås samman.
Återställ granskarröster om ändringar: Återställ granskarröster när de senaste ändringarna skickas till PR för att säkerställa att granskarna omvärderar den uppdaterade koden.
Lås versionspipelines: Begränsa versionspipelines till specifika grenar (vanligtvis produktion eller huvud) för att undvika oavsiktliga distributioner från andra grenar.
Framtvinga inställningsbara variabler vid kötid: Aktivera alternativet "Framtvinga inställningsbar vid kötid" för pipelinevariabler för att förhindra att användare åsidosätter variabelvärden under pipelinekörningen.
Tillåt inte variabel åsidosättningar i redigeraren: För variabler som anges i pipelineredigeraren kan du inte tillåta åsidosättningar av användare för att upprätthålla konsekvens och förhindra oavsiktliga ändringar.

Handläggare

Bevilja behörigheter sparsamt: Begränsa behörigheter till den minsta nödvändiga uppsättningen konton för att minska attackytan.
Konfigurera restriktiva brandväggar för agenter: Konfigurera brandväggar så att de är så restriktiva som möjligt samtidigt som agenter kan fungera, balansera säkerhet och användbarhet.
Uppdatera agentpooler regelbundet: Håll din agentflotta uppdaterad genom att regelbundet uppdatera agenter för att säkerställa att sårbar kod inte körs, vilket minskar risken för utnyttjande.
Använd en separat agentpool för produktionsartefakter: Isolera produktionsartefakter med hjälp av en distinkt agentpool, vilket förhindrar oavsiktliga distributioner från icke-produktionsgrenar.
Segmentkänsliga pooler: Skapa separata pooler för känsliga och meningslösa arbetsbelastningar. Tillåt endast autentiseringsuppgifter i versionsdefinitioner som är associerade med lämplig pool.

Definitioner

Använd YAML för pipelinedefinitioner: Definiera pipelines med yaml (ännu ett markupspråk) för bättre spårning och efterlevnad av riktlinjer för godkännande och metoder för versionskontroll.
Begränsa redigeringsåtkomsten till pipelinedefinitioner: Begränsa åtkomsten till redigering av pipelinedefinitioner till det minsta antal konton som krävs för att minska risken för oavsiktliga eller obehöriga ändringar.

Indata

Inkludera kontroller för variabler i byggskript: Implementera kontroller i byggskripten för att minimera potentiella kommandoinmatningsattacker via inställbara variabler. Verifiera indatavärden och förhindra oavsiktliga eller skadliga kommandon.
Begränsa versionsvariabler för "settable at release time": Minimera antalet versionsvariabler som kan anges vid lanseringstiden för att minska attackytan och förenkla konfigurationshanteringen.

Uppgifter

Undvik fjärrhämtning av resurser: Undvik att hämta resurser från externa URL:er när det är möjligt under byggprocessen. Om fjärrresurser behövs kan du använda versionshantering och hashkontroll för att säkerställa integriteten.
Undvik loggning av hemligheter: Logga aldrig känslig information, till exempel hemligheter eller autentiseringsuppgifter, i byggloggarna för att förhindra oavsiktlig exponering och kompromettera säkerheten.
Använd Azure Key Vault för hemligheter: I stället för att lagra hemligheter direkt i pipelinevariabler använder du Azure Key Vault för att hantera och hämta hemligheter på ett säkert sätt.
Begränsa körningsversioner mot godtyckliga grenar eller taggar: För säkerhetskritiska pipelines begränsar du användare från att köra byggen mot någon gren eller tagg. Definiera specifika auktoriserade grenar eller taggar för att förhindra oavsiktliga eller obehöriga körningar.
Inaktivera arv för pipelinebehörigheter: Ärvda behörigheter kan vara alltför breda och kanske inte korrekt återspeglar dina behov. Inaktivera arv och ange behörigheter explicit så att de överensstämmer med dina säkerhetskrav.
Begränsa omfången för jobbauktorisering: Begränsa alltid jobbauktoriseringsomfången till det minimum som krävs. Finjustera behörigheter baserat på de specifika uppgifter som utförs av varje jobb.

Lagringsplatser och grenar

Kräv ett minsta antal granskare: Aktivera principen för att säkerställa att varje pull-begäran tar emot granskningar från minst två godkännare, vilket främjar noggrann kodgranskning och ansvarsskyldighet.
Konfigurera lagringsplatsspecifika säkerhetsprinciper: Skräddarsy säkerhetsprinciper för varje lagringsplats eller gren i stället för projektomfattande principer för att minska risken, tillämpa ändringshanteringsstandarder och förbättra kodkvaliteten.
Isolera produktionshemligheter i ett separat nyckelvalv: Lagra produktionshemligheter separat i ett Azure Key Vault och begränsa åtkomsten till ett kunskapsbehov för att upprätthålla separation från icke-produktionsversioner.
Separera testmiljöer från produktion: Undvik att blanda testmiljöer med produktion för att säkerställa att autentiseringsuppgifter och hemligheter inte används i icke-produktionskontexter.
Inaktivera förgrening: Om du inaktiverar förgrening kan du hantera säkerheten genom att förhindra spridning av gafflar, vilket gör det enklare att spåra säkerheten i alla kopior.
Undvik att ange hemligheter för förgreningsversioner: Avstå från att dela hemligheter med förgrenade versioner för att hålla dem konfidentiella och inte exponerade för gafflar.
Överväg att utlösa förgreningsversioner manuellt: Utlösa byggen för gafflar manuellt i stället för att låta automatiska utlösare ge bättre kontroll över säkerhetskontroller.
Använd Microsoft-värdbaserade agenter för förgreningsversioner: Använd Microsoft-värdbaserade agenter för förgrenade versioner när de underhålls och skyddas.
Sök igenom produktionsversionsdefinitioner i Git-lagringsplatser: Kontrollera regelbundet produktionsversionsdefinitioner som lagras i projektets Git-lagringsplats för eventuella autentiseringsuppgifter eller känslig information.
Konfigurera grenkontrollkontroller för produktionskontext: Konfigurera grenkontrollkontroller för att begränsa användningen av känsliga anslutningar (till exempel prod-anslutning) till pipelines som körs i kontexten för produktionsgrenen, vilket säkerställer korrekt auktorisering och förhindrar oavsiktligt missbruk.

Mer information finns i Andra säkerhetsöverväganden.

Skydda Azure-lagringsplatser

Säkra Azure-testplaner

Skydda GitHub-integreringar

Använd OAuth-flöde i stället för PAT: Inaktivera PAT-baserad autentisering för GitHub-tjänstanslutningar och välj OAuth-flöde för bättre säkerhet och integrering.
Undvik administratörs- eller ägaridentiteter: Autentisera aldrig GitHub-tjänstanslutningar med hjälp av en identitet som är administratör eller ägare av några lagringsplatser. Begränsa behörigheter till den nivå som krävs.
Undvik github-PAT:er med fullständig omfattning: Avstå från att använda en GitHub PAT med fullständig omfattning för att autentisera tjänstanslutningar. Använd token med den minsta behörighet som krävs.
Undvik personliga GitHub-konton som tjänstanslutningar: Använd inte personliga GitHub-konton som tjänstanslutningar i Azure DevOps. Skapa i stället dedikerade tjänstkonton eller använd konton på organisationsnivå.

Dela via