Metodtips för säkerhet

Artikel
07/16/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 MSA-konton:
- Om din organisation använder MSA-konton tar du bort inaktiva användare direkt från organisationen.
- Tyvärr finns det inget annat sätt att förhindra åtkomst för dessa användare.
- Tänk på att du inte kan skapa frågor för arbetsobjekt som har tilldelats till borttagna MSA-konton.
Inaktivera eller ta bort Microsoft Entra-användarkonton:
- Om din organisation är ansluten till Microsoft Entra-ID kan du inaktivera eller ta bort Microsoft Entra-användarkontot samtidigt som Azure DevOps-användarkontot är aktivt.
- Med den här metoden kan du fortsätta köra frågor mot arbetsobjekthistoriken med hjälp av ditt Azure DevOps-användar-ID.
Återkalla användar-PAT:
- Granska och återkalla alla befintliga användar-PAT:er regelbundet.
- PAT:er är kritiska autentiseringstoken, och det är viktigt att hantera dem på ett säkert sätt.
Återkalla särskilda behörigheter som beviljats enskilda användare:
- Granska och återkalla eventuella särskilda behörigheter som beviljats enskilda användarkonton.
- Se till att behörigheterna överensstämmer med principen om lägsta behörighet.
Tilldela om arbete från borttagna användare:
- Innan du tar bort användare, omtilldela eventuella arbetsobjekt som de hanterade.
- Distribuera arbetsbelastningen mellan aktuella teammedlemmar.

Använda Microsoft Entra-ID

Enskilt plan för identitet:
- Genom att ansluta Azure DevOps till Microsoft Entra ID skapar du ett enhetligt identitetssystem.
- Konsekvens mellan tjänster minskar förvirringen och minimerar säkerhetsrisker som uppstår vid manuella konfigurationsfel.
Styrning från slutpunkt till slutpunkt:
- Genom att använda Microsoft Entra-ID kan du implementera detaljerad styrning.
- Tilldela olika roller och behörigheter till specifika Microsoft Entra-grupper i olika resursomfattningar.
- Den här metoden säkerställer kontrollerad åtkomst och överensstämmer med bästa praxis för säkerhet.
Säkerhetsfunktioner:
- Microsoft Entra-ID möjliggör ytterligare säkerhetsfunktioner, till exempel:
  - Multifaktorautentisering (MFA): Förbättra användarautentiseringen genom att kräva flera faktorer (t.ex. lösenords- och telefonverifiering).
  - Principer för villkorlig åtkomst: Definiera åtkomstregler baserat på villkor (t.ex. plats, enhet eller risknivå).

Mer information finns i följande artiklar:

Granska granskningshändelser

När din organisation har backats upp av Microsoft Entra utför du följande uppgifter för att förbättra säkerheten och övervaka användningsmönster:

Aktivera granskning:
- Aktivera granskning i dina säkerhetsprinciper.
- Granskning hjälper till att spåra och logga händelser som rör användaråtgärder, behörigheter och ändringar.
Granska granskningshändelser regelbundet:
- Granska granskningsloggen med jämna mellanrum.
- 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.

IP-tillåtna listor:
- Konfigurera en allowlist för att begränsa åtkomsten till specifika IP-adresser.
- Tillåt endast trafik från betrodda källor, vilket minskar attackytan.
Kryptering:
- Använd alltid kryptering för data under överföring och i vila.
- Skydda kommunikationskanaler med protokoll som HTTPS.
Certifikatverifiering:
- Verifiera certifikat när du upprättar anslutningar.
- Kontrollera att certifikaten är giltiga och utfärdade av betrodda myndigheter.
Brandväggar för webbprogram (WAFs):
- Implementera WAFs för att filtrera, övervaka och blockera skadlig webbaserad trafik.
- WAF:er ger ytterligare ett skyddslager mot vanliga attacker.

Mer information finns i Metodtips för programhantering.

Begränsade behö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 minimal åtkomst: 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:
- För att minska risken för att känslig information läcker och distribuera osäker kod till produktion begränsar du åtkomsten till projekt och lagringsplatser.
- 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 till specifika uppgifter.
Inaktivera "Tillåt offentliga projekt":
- I organisationens principinställningar inaktiverar du alternativet för att skapa offentliga projekt.
- Med Azure DevOps Services kan du växla projektsynlighet från offentlig till privat (och vice versa).
- Användare som inte har loggat in i din organisation har skrivskyddad åtkomst till offentliga projekt.
- Inloggade användare kan beviljas åtkomst till privata projekt och göra tillåtna ändringar.
Begränsa skapande av projekt:
- Hindra användare från att skapa 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.
- Tänk på det här steget om det inte finns något affärsbehov för externa gäster.
Använd ett annat e-postmeddelande eller UPN för dina personliga konton och företagskonton:
- Även om det är tillåtet använder du distinkta e-postadresser eller användarhuvudnamn (UPN) för personliga konton och företagskonton.
- Den här metoden eliminerar tvetydighet vid tvetydighet mellan dina personliga och arbetsrelaterade konton.
Gruppera externa gästanvändare:
- Placera alla externa gästanvändare i en enda Microsoft Entra-grupp.
- Hantera behörigheter för den här gruppen på rätt sätt.
- Ta bort direkttilldelningar för att säkerställa 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. Ö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. Regler omvä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.
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

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

Förstå tjä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.
- 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änstkontobehörigheter till det minsta 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.
- Isolera behörigheter för att förhindra onödig åtkomst. Mer information finns i Tjänstkonton och beroenden.
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. Mer information finns i Krav för tjänstkonton.
Utnyttja tjänstanslutningar:
- Använd tjänstanslutningar när det är möjligt.
- De ger ett säkert sätt att 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.

Mer information finns i Common Service-anslutningstyper.

Omfångstjänstanslutningar

Omfång för Azure Resource Manager-tjänstanslutningar :
- Begränsa åtkomsten genom att begränsa tjänstanslutningarna till specifika resurser och grupper. Undvik att bevilja breda deltagarrättigheter i hela Azure-prenumerationen.
- Använd arbetsbelastningsidentitetsfederation för autentisering. Detta möjliggör hemliga tjänstanslutningar i Azure Pipelines.
Använd identitetsfederation för arbetsbelastning:
- Arbetsbelastningsidentitetsfederation använder OpenID Connect (OIDC) för att autentisera med Azure-resurser utan att använda hemligheter.
- Du kan skapa arbetsbelastningsidentitetsfederation automatiskt eller manuellt. Tänk på den här metoden om:
  - Du har rollen Ägare för din Azure-prenumeration.
  - Du ansluter inte till Azure Stack- eller Azure US Government-miljöer.
  - Alla Uppgifter för Marketplace-tillägg som du använder stöder arbetsbelastningsidentitetsfederation1.
Omfång för resursgrupp:
- Se till att resursgruppen endast innehåller de virtuella datorer (VM) eller resurser som behövs för byggprocessen.
Undvik klassiska Azure-tjänstanslutningar:
- Klassiska tjänstanslutningar saknar omfångsalternativ. Välj moderna Azure Resource Manager-tjänstanslutningar i stället.
Använd användningsspecifika 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:

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-portalen.
- Konfigurerad för åtkomst till Azure-resurser, inklusive Azure DevOps.
- Användbart för appar som behöver specifik åtkomst och kontroll.
Hanterade identiteter:
- Liknar programmets 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 när du vill ha sömlös hantering av inloggningsinformation.

Använd PAT sparsamt

Omfångs-PAT:ar för specifika roller:
- Tilldela endast PAT de behörigheter som krävs för specifika uppgifter. Undvik att bevilja global åtkomst till flera organisationer eller lagringsplatser.
- Omfångs-PAT:er säkerställer att de har de minimiprivilegier som krävs, vilket minskar 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:erna hemliga:
- Ange alltid ett förfallodatum för PATs. Granska och förnya dem regelbundet efter behov.
- Behandla PAT:er som kritiska som lösenord. Håll dem konfidentiella och undvik att dela dem offentligt eller hårdkoda dem i programkoden.
Undvik hårdkodning av PAT i programkod:
- Även om det kan verka praktiskt bör du undvika att bädda in PAT:er direkt i koden.
- Använd i stället säkra konfigurationsfiler eller miljövariabler för att lagra och hämta PAT 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 följande artiklar:

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 granskare utanför den ursprungliga beställaren:
- Att ha minst en granskare utanför den ursprungliga beställaren garanterar en mer grundlig granskningsprocess.
- Godkännaren delar medägarskapet för ändringarna och bör hållas lika ansvarig för eventuella effekter.
Kräv ATT CI-kompilering godkänns:
- Om du kräver att CI-versionen (Continuous Integration) godkänns innan en pr slås samman upprättas en baslinje för kodkvalitet.
- CI-kontroller omfattar kodlintning, enhetstester och säkerhetsgenomsökningar (till exempel virus- och autentiseringsuppgifter).
Tillåt inte självgodkännande av den ursprungliga beställaren:
- Förhindra att den ursprungliga PR-begäranden godkänner sina egna ändringar.
- Den här åtgärden säkerställer en opartisk granskningsprocess och undviker potentiella intressekonflikter.
Tillåt inte att PR slutförs även med "vänta" eller "avvisa" röster:
- Även om vissa granskare röstar för att vänta eller avvisa, förhindra PR-slutförande.
- Den här åtgärden uppmuntrar till att ta itu med all feedback innan den slås samman.
Återställ röster för kodgranskare vid push-överförda ändringar:
- När de senaste ändringarna skickas till PR återställer du granskarens röster.
- Den här åtgärden säkerställer att granskarna utvärderar den uppdaterade koden igen.
Lås versionspipelines till specifika produktionsgrenar:
- Begränsa versionspipelines till specifika grenar (vanligtvis produktion eller huvudgrenar).
- Undvik oavsiktliga distributioner från andra grenar.
Framtvinga inställbara variabler vid kötid:
- Aktivera alternativet "Framtvinga inställbar vid kötid" för pipelinevariabler.
- Den här åtgärden hindrar användare från att åsidosätta variabelvärden under pipelinekörningen.
Tillåt inte variabel åsidosättningar i redigeraren:
- Tillåt inte åsidosättningar för användare för variabler som anges i pipelineredigeraren.
- Den här åtgärden upprätthåller konsekvens och förhindrar oavsiktliga ändringar.

Handläggare

Bevilja behörigheter sparsamt:
- Begränsa behörigheter till den minsta nödvändiga uppsättningen konton.
- Undvik alltför tillåtande åtkomst, vilket minskar attackytan.
Restriktiva brandväggar för användbara agenter:
- Konfigurera brandväggar så att de är så restriktiva som möjligt samtidigt som agenter kan fungera.
- Hitta en balans mellan säkerhet och användbarhet.
Uppdatera agentpooler regelbundet:
- Håll din agentflotta uppdaterad genom att regelbundet uppdatera agenter.
- Den här åtgärden säkerställer att sårbar kod inte körs, vilket minskar risken för utnyttjande.
Separat agentpool för produktionsartefakter:
- Använd en distinkt agentpool för att skapa artefakter som är avsedda för produktion.
- Genom att isolera produktionsartefakter kan du förhindra 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:
- YAML (Yet Another Markup Language) är den rekommenderade metoden för att definiera pipelines.
- Det ger spårning för ändringar, vilket gör det enklare att spåra ändringar över tid.
- Dessutom kan YAML-pipelines följa riktlinjerna för godkännande och metoder för versionskontroll.
Begränsa redigeringsåtkomsten till pipelinedefinitioner:
- Begränsa åtkomsten till redigering av pipelinedefinitioner till de minsta nödvändiga kontona.
- Genom att göra det minskar du risken för oavsiktliga eller obehöriga ändringar.

Indata

Inkludera sanity-kontroller för variabler i byggskript:
- Implementera sanitetskontroller i byggskripten för att minimera potentiella kommandoinmatningsattacker via inställbara variabler.
- Dessa kontroller kan verifiera indatavärden och förhindra oavsiktliga eller skadliga kommandon.
Begränsa antalet "settable at release time"-versionsvariabler:
- Ange så få byggvariabler som möjligt så att de kan "ställas in vid lanseringstillfället".
- Att minimera antalet sådana variabler minskar attackytan och förenklar 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 loggningshemligheter:
- Logga aldrig känslig information, till exempel hemligheter eller autentiseringsuppgifter, i dina byggloggar.
- Loggningshemligheter kan exponera dem oavsiktligt och äventyra säkerheten.
Använda Azure Key Vault för hemligheter:
- I stället för att lagra hemligheter direkt i pipelinevariabler använder du Azure Key Vault.
- Key Vault är ett säkert sätt att hantera och hämta hemligheter centralt.
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ång för jobbauktorisering:
- Begränsa alltid omfången för jobbauktorisering 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 "Kräv ett minsta antal granskare" för att säkerställa att varje pull-begäran tar emot granskningar från minst två godkännare.
- Detta främjar noggrann kodgranskning och ansvarstagande.
Konfigurera lagringsplatsspecifika säkerhetsprinciper:
- I stället för projektomfattande principer skräddarsyr du säkerhetsprinciper för varje lagringsplats eller gren.
- Anpassade principer minskar risken, tillämpar ändringshanteringsstandarder och förbättrar kodkvaliteten.
Isolera produktionshemligheter i ett separat nyckelvalv:
- Lagra produktionshemligheter separat i ett Azure Key Vault.
- Begränsa åtkomsten till en kunskapsbehovsbas för att upprätthålla separation från icke-produktionsversioner.
Separera testmiljöer från produktion:
- Undvik att blanda testmiljöer med produktion.
- Kontrollera att autentiseringsuppgifter och hemligheter inte används i icke-produktionskontexter.
Inaktivera förgrening:
- Om du inaktiverar förgrening kan du hantera säkerheten.
- Gafflar kan spridas, vilket gör det svårt 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.
- Hemligheter bör förbli konfidentiella och inte exponeras för gafflarna.
Överväg att utlösa förgreningsversioner manuellt:
- Manuellt utlöser byggen för gafflar i stället för att tillåta automatiska utlösare.
- Detta ger bättre kontroll över säkerhetskontroller.
Använd Microsoft-värdbaserade agenter för förgreningsversioner:
- Utnyttja Microsoft-värdbaserade agenter för förgrenade versioner.
- Dessa agenter underhålls och skyddas.
Genomsöka produktionsversionsdefinitioner i Git-lagringsplatser:
- Kontrollera regelbundet produktionsversionsdefinitioner som lagras på projektets Git-lagringsplats.
- Sök efter autentiseringsuppgifter eller känslig information.
Konfigurera grenkontrollkontroller för produktionskontext:
- Konfigurera grenkontrollkontroller för att begränsa användningen av känsliga anslutningar (t.ex. prod-anslutning) till pipelines som körs i kontexten för produktionsgrenen.
- Detta 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.
- Välj OAuth-flöde, vilket ger 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