Skydda dina lagringsplatser och pipelines

8 minuter

När du använder automatisering för att distribuera infrastrukturen blir din pipeline och lagringsplats kraftfull och viktig. Eftersom de nu representerar det enda sättet som ändringar tillämpas på dina kontrollerade miljöer.

Många delar av din Azure DevOps-organisation, GitHub-lagringsplats och pipelines måste skyddas. Följande tabell innehåller några av de viktigaste elementen att skydda, tillsammans med exempel på sårbarheter som kan uppstå om du inte skyddar dessa element tillräckligt.

Element som ska skyddas	Exempel på sårbarhet
Din Azure DevOps-organisation eller GitHub-lagringsplats, inklusive vem som har åtkomst till den och vad de får göra.	En missnöjd före detta anställd tar bort din kodlagringsplats.
Viktiga grenar på lagringsplatsen och vad som behöver hända för att ändra koden på dessa grenar.	Någon av misstag checkar in viss Bicep-kod på lagringsplatsens huvudgren .
Koden i lagringsplatsen, inklusive infrastrukturdefinitioner, tester och programkod.	Någon glömmer att testa koden som de har skrivit, och den fungerar inte korrekt när den släpps till produktion.
Pipelinedefinitionen.	Någon lägger oavsiktligt till ett pipelinesteg som skriver en databas anslutningssträng i pipelinens logg.
De agenter eller löpare som kör din pipeline.	En pipeline som körs mot ett utkast till pull-begäran installerar en säkerhetsrisk på agenten, som senare används för en produktionsdistribution.
Alla uppgifter eller komponenter från tredje part som kan köras i din pipeline.	En pipelineaktivitet från tredje part skickar autentiseringsuppgifterna för tjänstens huvudnamn till en skadlig webbplats.
Tjänstens huvudnamn som pipelinen använder för att få åtkomst till Azure.	Ett huvudnamn för en icke-produktionstjänst gör av misstag en ändring i produktionsmiljön.
Hemligheterna som pipelinen använder för att komma åt externa system.	En teammedlem skriver en ny pipelinedefinitionsfil för en prototyp och ansluter den av misstag till din produktionsmiljö.

Nu ska vi lära oss mer om några av de metoder som du kan använda för att tillämpa styrning och kontroller runt din kodlagringsplats och distributionspipelines, i Azure DevOps och GitHub.

Hantera användare och behörigheter

Fundera på hur du beviljar åtkomst till din Azure DevOps-organisation eller GitHub-lagringsplats. Tänk på vem som har åtkomst och vad de kan göra.

Det är en bra idé att använda din organisations Microsoft Entra-instans som din pipelines identitetsprovider. På så sätt kan du se till att åtkomst till din pipeline beviljas eller återkallas automatiskt när någon ansluter till eller lämnar organisationen. Genom att använda Microsoft Entra-ID kan du också enkelt implementera skydd som villkorlig åtkomst och multifaktorautentisering.

Kommentar

Om du vill använda Microsoft Entra-integrering med GitHub behöver din organisation en GitHub Enterprise-licens.

Du kan också skapa team (i GitHub) eller grupper (i Azure DevOps), som representerar uppsättningar användare som kan beviljas behörigheter tillsammans. På så sätt behöver du inte tilldela behörigheter individuellt. Det är enkelt att ändra användarnas behörigheter genom att lägga till dem i och ta bort dem från ett team eller en grupp.

Dricks

Azure DevOps använder en modell med minst behörighet , vilket skiljer sig från den modell som Azure använder. Neka behörigheter åsidosätt tillåtna behörigheter i Azure DevOps. Det innebär att om du har tilldelats flera grupper med olika uppsättningar behörigheter får du endast utföra de åtgärder som tillåts av alla grupper.

Se till att du förstår hur behörigheter tilldelas, särskilt till grupper.

Skydda viktiga kodgrenar

Dina pipelines och automatisering bör baseras på att identifiera specifika kodgrenar, till exempel main. Kod på dessa avsedda grenar är vanligtvis betrodd och kan distribueras till dina produktionsmiljöer. Använd kontroller för att säkerställa att koden som finns på dina viktiga grenar har verifierats och granskats.

Överväg att använda grenskyddsregler (i GitHub) eller grenprinciper (i Azure Repos) för att förhindra direkta incheckningar till viktiga kodgrenar. Sedan kan du kräva att ditt team använder pull-begäranden för att sammanfoga eventuella ändringar. Du kan använda automatiserade kontroller och manuella granskningsprocesser för att kontrollera att ändringarna är giltiga innan de sammanfogas.

Testa och granska din kod

Se till att ditt team förstår dina förväntningar på att granska och testa all kod, inklusive dina infrastrukturdefinitioner.

Dina pipelinedefinitioner är YAML-filer, så de är en form av kod. Ändringar i dina pipelinedefinitioner måste granskas och utvärderas. Annars kan någon oavsiktligt eller skadligt skapa ett pipelinesteg som läcker autentiseringsuppgifterna för tjänstens huvudnamn eller gör en farlig ändring av din Azure-egendom.

Alla ändringar av pipelinedefinitionsfiler måste granskas noggrant. Se till att alla i ditt team förstår att pipelines är mycket privilegierade och behöver särskild uppmärksamhet.

Skydda dina pipelineagenter och löpare

Din pipeline körs på agenter (för Azure Pipelines) eller löpare (för GitHub Actions). Du kan se agenter och löpare som virtuella datorer. Din pipelinedefinition styr de virtuella datorerna genom att köra de uppgifter och skript som du har angett.

Både Azure Pipelines och GitHub Actions tillhandahåller värdbaserade agenter och löpare, som Microsoft eller GitHub konfigurerar och underhåller. Plattformsägaren konfigurerar datorerna så att de är kompatibla med rekommenderade säkerhetsrutiner. Plattformsägarens ansvarsområden omfattar korrigering av säkerhetsproblem i operativsystemet.

Du kan i stället välja att använda dina egna fysiska eller virtuella datorer för dina agenter och löpare. Datorer av den här typen kallas lokalt installerade agenter och löpare. Om du använder lokalt installerade agenter och löpare ansvarar du för att se till att datorerna är korrekt konfigurerade och skyddade mot hot.

Microsoft-värdbaserade agenter och GitHub-värdbaserade löpare är tillfälliga. Alla filer eller konfigurationsändringar i en agent eller löpare förstörs när en pipelines körning avslutas. Om du själv är värd för din agent eller löpare används förmodligen samma dator för flera separata pipelines eller miljöer, inklusive produktions- och icke-produktionsmiljöer. Anta att någon skapar en pipelinedefinition som ändrar vissa viktiga filer i agentens operativsystem och kör pipelinen från en pull-begäran. Nästa gång en distribution körs mot din produktionsmiljö kan den återanvända agenten. Nu kan du inte förutsäga vilken inverkan den skadade filen kan ha på produktionsmiljön.

Därför är det bra att använda Microsoft-värdbaserade agenter och GitHub-värdbaserade löpare när du kan. Om du måste använda lokalt installerade löpare bör du noggrant utvärdera riskerna med deras konfiguration och användning.

Utvärdera komponenter från tredje part som körs i din pipeline

Om du använder GitHub Actions eller Azure DevOps-tillägg från communityn kan du förstå vem som har skapat dem och vad de gör. Pipelinekomponenter från tredje part kan ha åtkomst till tjänstens huvudnamns autentiseringsuppgifter och därmed hela din miljö i Azure.

I Azure DevOps godkänner organisationsadministratören vanligtvis varje tillägg innan det kan användas. Om du är administratör för din organisation bör du överväga den säkerhetsrisk som ingår i varje komponent som du använder. Du ansvarar för att kontrollera att de är tillförlitliga och säkra.

När du använder en åtgärd eller uppgift från tredje part anger du versionen. Överväg att ange den exakta versionen som du har granskat. Om du tillåter att pipelinen automatiskt använder en senare version kan det medföra en risk som du inte har granskat.

Skydda pipelinens tjänsthuvudnamn

Pipelines använder tjänstens huvudnamn för att få åtkomst till Azure och andra tjänster. Det är viktigt att skydda tjänstens huvudnamn och se till att deras autentiseringsuppgifter inte kan användas på ett olämpligt sätt. Överväg att använda flera skyddslager.

Först kan du överväga att skydda autentiseringsuppgifterna för tjänstens huvudnamn:

Använd hanterade identiteter eller arbetsbelastningsidentiteter när det är möjligt för att undvika att lagra autentiseringsuppgifter helt och hållet. Även om du inte kan använda hanterade identiteter eller arbetsbelastningsidentiteter med alla pipelines är det en bra idé att göra det när du kan.
Planera hur du regelbundet ändrar eller roterar tjänstens huvudnamns autentiseringsuppgifter. Din organisation kan till exempel ha en princip för att rotera autentiseringsuppgifter var 90:e eller 120:e dag. Överväg vem som ansvarar för rotationen och hur du uppdaterar alla platser där autentiseringsuppgifterna används.
Överväg att utse en hemlig förmyndare vars roll är att hantera hemligheter, nycklar och certifikat så att de inte exponeras för andra delar av organisationen.

Tänk sedan på de behörigheter som du beviljar tjänstens huvudnamn:

Tillämpa principer för villkorsstyrd åtkomst i Microsoft Entra på pipelinens tjänsthuvudnamn. Dessa principer hjälper dig att identifiera riskfyllda inloggningar och beteenden. Om pipelinetjänstens huvudnamn till exempel alltid loggar in från en geografisk region kan villkorlig åtkomst identifiera och förhindra inloggningar från oväntade platser, vilket kan tyda på att autentiseringsuppgifterna har komprometterats.
Överväg noggrant de behörigheter som du beviljar till varje huvudnamn för tjänsten. Anta till exempel att du har ett huvudnamn för tjänsten som du använder för att läsa konfigurationen av en delad resurs. Fundera på om du bara kan ge läsare åtkomst till tjänstens huvudnamn, eftersom tjänstens huvudnamn inte behöver göra något som kräver mer behörighet.
Använd det minsta omfånget för varje behörighet som du tilldelar till ett huvudnamn för tjänsten. Om tjänstens huvudnamn till exempel bara behöver distribueras till en enskild resursgrupp kan du omfångsbegränsa rolltilldelningen till den resursgruppen i stället för till hela prenumerationen.
Använd separata tjänsthuvudnamn för var och en av dina miljöer. Det gör att även om ett huvudnamns autentiseringsuppgifter komprometteras eller om någon får åtkomst till en miljö kan de inte komma åt andra miljöer.

Skydda dina tjänstanslutningar och hemligheter

En tjänstanslutning (i Azure Pipelines) eller hemlighet (i GitHub) innehåller autentiseringsuppgifterna för tjänstens huvudnamn som pipelinen använder för att komma åt din Azure-miljö. Det är viktigt att du skyddar dina tjänstanslutningar och hemligheter och att du styr vilka pipelines som använder varje tjänstanslutning och hemlighet. Annars kan du av misstag aktivera en icke-produktionsmiljö för att använda ett huvudnamn för tjänsten som har åtkomst till produktionsresurser.

När du skapar en tjänstanslutning i Azure DevOps kan du konfigurera den så att den kräver ditt godkännande innan en ny pipeline eller miljö kan använda den.

Med Azure DevOps kan du också associera kontroller med specifika tjänstanslutningar. Kontroller lägger till ytterligare ett skyddslager. Du kan till exempel konfigurera en kontroll av en produktionstjänstanslutning för att kontrollera att den endast används på kod från lagringsplatsens huvudgren . Den här kontrollen hjälper till att förhindra att obehörig kod distribueras till produktionsmiljön.

I GitHub kan du konfigurera miljöspecifika hemligheter, så att när GitHub Actions-arbetsflödet fungerar med den miljön ger det bara det hemliga värdet. Genom att använda miljöspecifika hemligheter och miljökontroller som godkännanden kan du minska risken för att en icke-produktionsdistribution används för att distribuera till produktionsmiljön. Du kan också använda arbetsbelastningsidentiteter för att undvika att använda autentiseringsuppgifter i dina GitHub Actions-arbetsflöden och eliminera möjligheten att autentiseringsuppgifter kan exponeras.

Använda GitHub-säkerhetsfunktioner

GitHub tillhandahåller säkerhetsfunktioner som du bör utvärdera och använda. Dessa funktioner omfattar bland annat:

Dependabot, som söker igenom källkodens beroenden efter kända säkerhetsrisker.
Hemlig genomsökning, som identifierar text på lagringsplatsen som ser ut som nycklar eller autentiseringsuppgifter. Det är en dålig idé att lagra hemligheter på en lagringsplats. Om du varnas för en hemlighet på lagringsplatsen bör du överväga att hemlighetens värde komprometteras och sedan återkalla eller ändra den.
Granskning för att förstå vem som har gjort ändringar i din GitHub-konfiguration.
Säkerhetsöversikt, som konsoliderar alla dina säkerhetsaviseringar i organisationens lagringsplatser.

Använda Azure DevOps-granskningsloggar

Azure DevOps tillhandahåller granskningsloggar som hjälper dig att förstå vem som har gjort ändringar i dina pipelines, avdelningsprinciper, lagringsplatser och andra resurser. Det är en bra idé att aktivera granskning och granska granskningsloggarna regelbundet.

Skydda din lagringsplats och pipeline

Vi har diskuterat de viktiga kontroller som du kan tillämpa på din lagringsplats och pipeline. Nu ska vi överväga vilka kontroller du kan använda för att skydda vart och ett av de viktiga element som vi listade tidigare i den här lektionen:

Element som ska skyddas	Kontroller som ska tillämpas
Din Azure DevOps-organisation eller GitHub-lagringsplats, inklusive vem som har åtkomst till den och vad de får göra.	Använd Microsoft Entra-ID för autentisering. Använd team och grupper för att tilldela behörigheter. Aktivera granskningsloggning och granska granskningsloggar regelbundet.
Viktiga grenar på lagringsplatsen och vad som behöver hända för att ändra koden på dessa grenar.	Tillämpa regler för grenskydd eller grenprinciper.
Koden i lagringsplatsen, inklusive infrastrukturdefinitioner, tester och programkod.	Framtvinga krav för kodgranskning. Lägg till automatiserade eller manuella tester. På GitHub använder du Dependabot och hemlig genomsökning.
Pipelinedefinitionen.	Framtvinga krav för kodgranskning.
De agenter eller löpare som kör din pipeline.	I Azure Pipelines använder du Microsoft-värdbaserade agenter. På GitHub Actions använder du GitHub-värdbaserade löpare.
Alla uppgifter eller komponenter från tredje part som kan köras i din pipeline.	Granska säkerhetsrisken som är kopplad till alla tillägg och uppgifter från tredje part.
Tjänstens huvudnamn som pipelinen använder för att få åtkomst till Azure.	Använd arbetsbelastningsidentiteter i GitHub Actions. För Azure Pipelines använder du tjänstens huvudnamn och roterar regelbundet sina autentiseringsuppgifter. Använd separata tjänsthuvudnamn för varje miljö. Tillämpa principer för villkorlig åtkomst.
Hemligheterna som pipelinen använder för att komma åt externa system.	I Azure DevOps använder du godkännanden och kontroller av tjänstanslutningar. På GitHub använder du miljöspecifika hemligheter och arbetsbelastningsidentiteter.