Skydda pipelinen och CI/CD-arbetsflödet
Den här artikeln beskriver hur du skyddar dina CI/CD-pipelines och arbetsflöden.
Automatisering och agil metodik gör det möjligt för team att leverera snabbare, men även öka komplexiteten i säkerheten eftersom arbetsflödet sträcker sig till utvecklarteamen själva.
Följande diagram illustrerar ett CI/CD-baslinjearbetsflöde. Den röda konfigurationsikonen 
anger säkerhetsbehörigheter som måste konfigureras av kunden. Detta följer modellen för delat ansvar, där Azure och andra leverantörer tillhandahåller behörigheter, som måste konfigureras av kunden enligt deras styrningsmodell och affärskrav.
Nu ska vi undersöka varje steg i det här typiska arbetsflödet för att hjälpa dig att förstå hur konfigurationerna ofta är beroende av varandra. Arbetsflödet kan ha fler steg. Följande begrepp hjälper dig att förstå CI/CD och hjälpa dig att utforma ditt arbetsflöde för säkerhet.
Steg 1: Git-arbetsflöde
Kodändringar, inte bara till programvara, utan även pipeline som kod och infrastruktur som kod, sparas och hanteras i Git. Git är en distribuerad programvara för källkodshantering. När kod skickas från lokala datorer till den centraliserade Git-servern kan affärsregler tillämpas innan den godkänns.
Pull-begäranden och samarbete
Branschstandardarbetsflödet, oavsett din saaS-leverantör (Software Configuration Management) (SCM), är att använda pull-begäranden, vilket kan fungera både som en automatisk gatekeeper av hög kvalitet och ett steg för manuellt godkännande innan källkoden godkänns.
Arbetsflödet för pull-begäranden är utformat för att införa felfri friktion, varför det bara ska tillämpas på säkra specifika Git-grenar. Särskilt de grenar som utlöser automatiserade arbetsflöden som kan distribuera, konfigurera eller på något annat sätt påverka dina molnresurser. Dessa grenar kallas för skyddade grenar och följer vanligtvis namngivningskonventioner som production eller releases/*.
Det är vanligt att pull-begäranden kräver:
- Peer-granskningar
- Skicka CI-versioner (Continuous Integration)
- Manuellt godkännande
Om kraven uppfylls godkänns kodändringarna och kan sammanfogas.
Begränsa åtkomsten till skyddade grenar
Arbetsflödet för pull-begäran används tillsammans med kontroller för begränsad åtkomst. Arbetsflödet för pull-begäran kan dock inte tillämpas, såvida inte servern har konfigurerats för att avvisa direkta ändringar i skyddade grenar.
En utvecklare kan inte skicka direkt till grenen production , utan måste i stället skapa en pull-begäran som riktar sig mot den skyddade grenen. Varje SCM-leverantör har en annan smak för att uppnå begränsad åtkomst till skyddade grenar. Med GitHub är den här funktionen till exempel endast tillgänglig för organisationer som använder GitHub-teamet eller GitHub Enterprise-molnet.
Dokumentera din Git-åtkomstmodell
Eftersom samarbetsmodellen är komplex och har många rörliga delar är det bra att skapa en tabell som dokumenterar alla möjliga sätt som kodändringar kan utlösa distributioner på, till exempel:
| Namn på gren | Kräver PR? | Distribuerar? | Utvecklaråtkomst | Administratörsåtkomst |
|---|---|---|---|---|
feat/* |
Nej | Nej | Skrivskydd | Skrivskydd |
main |
Ja | Mellanlagring | Lästa | Skrivskydd |
production |
Ja, endast från main |
Produktion | Lästa | Skrivskydd |
Det här exemplet på Git-åtkomsttabellen är översimplifierat för att illustrera dess syfte. I praktiken finns det ofta fler aktörer, fler distributionsmål och flera pipelines som körs för olika användningsfall. Tabellstrukturen kan skilja sig beroende på kraven i din organisation och dina arbetsbelastningar.
Tabellen bör hjälpa dig att besvara frågor som:
- Om en utvecklare push-överför kodändringar till gren X, kommer den att distribueras? I så fall, till vilken miljö?
- Vid vilken tidpunkt i programkodslivscykeln görs en sårbarhetsgenomsökning?
- Hur många kodtryckningar och godkännanden krävs om en säkerhetsrisk hittas innan den hamnar i produktion?
Den här tabellen är inte bara användbar för felsökning och statisk dokumentation, utan även för teamsamarbete. Det är transparent för utvecklare där felfri friktion har introducerats i arbetsflödet för att prioritera kodkvalitet och säkerhet. Ännu viktigare är att den visar utvecklaren den förväntade sökvägen för att kodändringar ska nå produktion.
Eftersom DevOps är en resa är din Git-åtkomstmodell inte statisk. Det kommer att förändras och utvecklas när teamen hittar sina egna rytmer och mognar. Därför är det viktigt att lagra den här dokumentationen så nära koden som möjligt, till exempel i Git-lagringsplatserna.
Mer information om pull-begäranden och skyddade grenar finns i:
- Konfigurera grenbehörigheter
- Skapa, visa och hantera pull-begäranden
- Förbättra kodkvaliteten med grenprinciper
- Om pull-begäranden
- Om skyddade grenar
Steg 2: Pipelines som kod
Pipeline-as-code-rörelsen påskyndade automatiseringsimplementeringen och distributionerna genom att flytta pipelinedefinitioner och konfigurationer från CI-leverantören till utvecklarna, vilket förde bygg- och distributionslogik närmare motsvarande programlogik. Den större flexibiliteten här medför också ett större ansvar.
RBAC-kontroller i en UI-driven pipeline kan hindra enskilda användare från att göra destruktiva ändringar. Pipelines som kod körs dock ofta med privilegierade identiteter och kan förstöra dina arbetsbelastningar om de uppmanas att göra det.
Steg 3: Skydda dina autentiseringsuppgifter för distribution
Pipelines och kodlagringsplatser bör inte innehålla hårdkodade autentiseringsuppgifter och hemligheter. Autentiseringsuppgifter och hemligheter bör lagras någon annanstans och använda CI-leverantörsfunktioner för säkerhet. Eftersom pipelines körs som huvudlösa agenter bör de aldrig använda en individs lösenord. Pipelines bör köras med huvudlösa säkerhetsobjekt i stället, till exempel tjänstens huvudnamn eller hanterade identiteter. Åtkomst till säkerhetsobjektets autentiseringsuppgifter, databas niska veze och API-nycklar från tredje part bör också hanteras på ett säkert sätt på CI-plattformen.
Hur en autentiseringsuppgift skyddas, portar och godkännanden är leverantörsspecifika funktioner. När du väljer en CI-plattform kontrollerar du att den har stöd för alla funktioner som du behöver.
Azure Pipelines är en lösning för kontinuerlig integrering i företagsskala där autentiseringsuppgifter lagras som tjänstanslutningar, där du kan konfigurera godkännanden och kontroller. Den här konfigurationen omfattar manuellt godkännande och specifika gren- eller pipelineauktoriseringar.
Azure Key Vault
Om din CI-plattform stöder det kan du överväga att lagra autentiseringsuppgifter i ett dedikerat hemligt arkiv, till exempel Azure Key Vault. Autentiseringsuppgifter hämtas vid körning av byggagenten och attackytan minskas.
Steg 4: Skydda dina Azure-resurser
Dina Azure-resurser bör skyddas enligt principen om lägsta behörighet som tillämpas på både behörigheter och omfång.
Mer information finns i:
Skapa anpassade roller för byggagenter
CI/CD-automatisering gäller inte bara för program, utan även för infrastruktur. IaC-mallar (Infrastruktur som kod) säkerställer konsekventa distributioner och hjälper centraliserade molnplattformsteam att skala.
Det är viktigt att förstå att IaC-automatisering kan gå fel. Den kan felkonfigurera och i värsta fall ta bort infrastrukturen permanent. När du planerar din molnresa kan du i förväg identifiera vilka åtgärder som är affärskritiska och kräva mänsklig inblandning.
Det går till exempel inte att ta bort hanteringslås, kan tillämpas på affärskritiska resurser som data. För att förhindra att detta händer kan du ta bort Microsoft.Authorization/*/Delete behörigheter från ett huvudnamn för tjänsten som används i CI-automatisering. I det här exemplet och användningsfallet kan tjänstens huvudnamn skapa hanteringslåset, men inte ta bort det.
Vi rekommenderar att du skapar en anpassad roll för dina CI-agenter. Kom ihåg att byggagenter körs huvudlösa och huvudlösa agenter är hjärnlösa. Välj dina behörigheter noggrant.
Mer information finns i:
Resurser
- Plattformsautomatisering och DevOps
- Genomgång av pipelinesäkerhet
- Säkerhet via mallar
- DevSecOps i GitHub
Nästa steg
Nu när du förstår hur du skyddar DevOps kan du lära dig mer om styrning från slutpunkt till slutpunkt från DevOps till Azure.