Beskyt dine lagre og pipelines

  • 8 minutter

Når du bruger automatisering til at udrulle din infrastruktur, bliver din pipeline og dit lager effektivt og vigtigt. Da de nu repræsenterer den eneste måde, ændringer anvendes på dine styrede miljøer på.

Mange dele af din Azure DevOps-organisation, GitHub-lager og pipelines skal beskyttes. Følgende tabel indeholder nogle af de vigtigste elementer, der skal beskyttes, sammen med eksempler på sikkerhedsrisici, der kan opstå, hvis du ikke beskytter disse elementer tilstrækkeligt.

Element, der skal beskyttes Eksempel på sikkerhedsrisiko
Din Azure DevOps-organisation eller GitHub-lager, herunder hvem der har adgang til den, og hvad de har tilladelse til at gøre. En utilfreds ex-medarbejder sletter dit kodelager.
Vigtige forgreninger i dit lager, og hvad der skal ske for at ændre koden på disse forgreninger. Nogen sender ved et uheld en ikke-sikker Bicep-kode til lagerets hovedforgrening.
Koden i dit lager, herunder dine infrastrukturdefinitioner, test og programkode. Nogen glemmer at teste den kode, de har skrevet, og det virker ikke korrekt, når den frigives til produktion.
Pipelinedefinitionen. Nogen tilføjer utilsigtet et pipelinetrin, der skriver en databaseforbindelsesstreng i pipelinens log.
De agenter eller løbere, der kører din pipeline. En pipeline, der kører mod en kladde til en pullanmodning, installerer en sikkerhedsrisiko på agenten, som senere bruges til en produktionsinstallation.
Eventuelle tredjepartsopgaver eller -komponenter, der kan køre i din pipeline. En pipelineopgave fra tredjepart sender legitimationsoplysningerne for din tjenesteprincipal til et skadeligt websted.
De tjenesteprincipaler, som din pipeline bruger til at få adgang til Azure. En tjenesteprincipal, der ikke producerer, foretager ved et uheld en ændring af produktionsmiljøet.
De hemmeligheder, som din pipeline bruger til at få adgang til eksterne systemer. Et teammedlem skriver en ny pipelinedefinitionsfil til en prototype og opretter ved et uheld forbindelse til dit produktionsmiljø.

Lad os nu få mere at vide om nogle af de metoder, du kan bruge til at anvende styring og kontrolelementer omkring dit kodelager og udrulningspipelines i Azure DevOps og GitHub.

Administrer brugere og tilladelser

Overvej, hvordan du giver adgang til din Azure DevOps-organisation eller GitHub-lager. Tænk på, hvem der har adgang, og hvad de kan gøre.

Det er en god idé at bruge din organisations Microsoft Entra-forekomst som din pipelines identitetsudbyder. På den måde kan du sikre, at når nogen tilmelder sig eller forlader din organisation, tildeles eller tilbagekaldes adgangen til din pipeline automatisk. Ved hjælp af Microsoft Entra ID kan du også nemt implementere beskyttelse, f.eks. betinget adgang og multifaktorgodkendelse.

Seddel

Hvis du vil bruge Microsoft Entra-integration med GitHub, skal din organisation have en GitHub Enterprise-licens.

Du kan også oprette teams (i GitHub) eller grupper (i Azure DevOps), som repræsenterer sæt af brugere, der kan tildeles tilladelser sammen. På den måde behøver du ikke at tildele tilladelser enkeltvist. Det er nemt at ændre brugernes tilladelser ved at føje dem til og fjerne dem fra et team eller en gruppe.

Drikkepenge

Azure DevOps bruger en mindste rettighed tilladelsesmodel, som er forskellig fra den model, som Azure bruger. I Azure DevOps afvise tilladelser tilsidesætte tillade tilladelser. Det betyder, at hvis du er tildelt til flere grupper med forskellige sæt tilladelser, har du kun tilladelse til at udføre de handlinger, der er tilladt af alle grupper.

Sørg for, at du forstår, hvordan tilladelser tildeles, især til grupper.

Beskyt vigtige kodegrene

Dine pipelines og automatisering skal være baseret på identifikation af bestemte kodegrene, f.eks. primære. Der er typisk tillid til kode på disse angivne forgreninger, og den må udrulles i dine produktionsmiljøer. Anvend kontrolelementer for at sikre, at den kode, der er på dine vigtige forgreninger, er blevet bekræftet og gennemset.

Overvej at bruge regler for beskyttelse af forgreninger (i GitHub) eller forgreningspolitikker (i Azure Repos) for at forhindre direkte bekræftelse af vigtige kodeforgreninger. Derefter kan du kræve, at dit team bruger pullanmodninger til at flette eventuelle ændringer. Du kan anvende automatiserede kontroller og manuelle korrekturprocesser for at bekræfte, at ændringerne er gyldige, før de flettes.

Test og gennemse din kode

Sørg for, at dit team forstår dine forventninger til gennemsyn og test af al kode, herunder dine infrastrukturdefinitioner.

Dine pipelinedefinitioner er YAML-filer, så de er en form for kode. Ændringer af dine pipelinedefinitioner skal gennemses og evalueres. Ellers kan nogen ved et uheld eller ondsindet oprette et pipelinetrin, der lækker legitimationsoplysningerne for din tjenesteprincipal eller foretager en farlig ændring af din Azure-ejendom.

Eventuelle ændringer af pipelinedefinitionsfiler skal gennemses grundigt. Sørg for, at alle i dit team forstår, at pipelines er meget privilegerede og kræver særlig opmærksomhed.

Beskyt dine pipelineagenter og løbere

Din pipeline kører på agenter (til Azure Pipelines) eller løbere (til GitHub-handlinger). Du kan tænke på agenter og løbere som virtuelle maskiner. Din pipelinedefinition styrer de virtuelle maskiner ved at køre de opgaver og scripts, du har angivet.

Både Azure Pipelines og GitHub Actions leverer hostede agenter og løbere, som Microsoft eller GitHub konfigurerer og vedligeholder. Ejeren af platformen konfigurerer maskinerne til at overholde de anbefalede sikkerhedspraksisser. Platformens ejers ansvar omfatter programrettelse af operativsystemets sikkerhedsrisici.

Du kan i stedet vælge at bruge dine egne fysiske eller virtuelle maskiner til dine agenter og løbere. Maskiner af denne type kaldes selv hostede agenter og løbere. Hvis du bruger selv hostede agenter og løbere, er du ansvarlig for at sikre, at maskinerne er konfigureret korrekt og beskyttet mod trusler.

Microsoft-hostede agenter og GitHub-hostede løbere er ephemerale. Alle filer eller konfigurationsændringer af en agent eller løber ødelægges, når en pipelines kørsel slutter. Hvis du selv hoster din agent eller løber, vil den samme maskine sandsynligvis blive brugt til flere separate pipelines eller miljøer, herunder produktions- og ikke-produktionsmiljøer. Lad os antage, at nogen opretter en pipelinedefinition, der ændrer nogle vigtige filer i agentens operativsystem og kører pipelinen fra en pullanmodning. Næste gang en udrulning kører i dit produktionsmiljø, kan den genbruge agenten. Nu kan du ikke forudsige, hvilken indvirkning den beskadigede fil kan have på produktionsmiljøet.

Af disse årsager er det en god idé at bruge Microsoft-hostede agenter og GitHub-hostede løbere, når du kan. Hvis du skal bruge selv hostede løbere, skal du nøje evaluere de risici, der er forbundet med deres konfiguration og brug.

Vurder tredjepartskomponenter, der kører i din pipeline

Hvis du bruger GitHub-handlinger eller Azure DevOps-udvidelser med community-funktionalitet, skal du forstå, hvem der har bygget dem, og hvad de gør. Tredjepartspipelinekomponenter kan have adgang til din tjenesteprincipals legitimationsoplysninger og derfor hele dit miljø i Azure.

I Azure DevOps godkender organisationsadministratoren typisk alle udvidelser, før de kan bruges. Hvis du er administrator for din organisation, skal du overveje den sikkerhedsrisiko, der er involveret i hver komponent, du bruger. Du er ansvarlig for at bekræfte, at de er pålidelige og sikre.

Når du bruger en handling eller opgave fra tredjepart, angiver du versionen. Overvej at angive den nøjagtige version, du har gennemgået. Hvis pipelinen automatisk kan bruge en senere version, kan det medføre en risiko for, at du ikke har gennemset den.

Beskyt din pipelines tjenesteprincipaler

Pipelines bruger tjenesteprincipaler til at få adgang til Azure og andre tjenester. Det er vigtigt at beskytte dine tjenesteprincipaler og sikre, at deres legitimationsoplysninger ikke kan bruges forkert. Overvej at anvende flere beskyttelseslag.

Først kan du overveje at beskytte legitimationsoplysningerne for dine tjenesteprincipaler:

  • Når det er muligt, kan du bruge administrerede identiteter eller arbejdsbelastningsidentiteter for at undgå at gemme legitimationsoplysningerne helt. Selvom du ikke kan bruge administrerede identiteter eller arbejdsbelastningsidentiteter med alle pipelines, er det en god idé at gøre det, når du kan.
  • Planlæg, hvordan du ændrer eller roterer, dine tjenesteprincipalens legitimationsoplysninger regelmæssigt. Din organisation kan f.eks. have en politik om at rotere legitimationsoplysninger hver 90. eller 120. dag. Overvej, hvem der er ansvarlig for rotationen, og hvordan du opdaterer alle de steder, hvor legitimationsoplysningerne bruges.
  • Overvej at udpege en hemmelig vogter, hvis rolle er at administrere hemmeligheder, nøgler og certifikater, så de ikke vises for andre dele af organisationen.

Tænk derefter på de tilladelser, du tildeler tjenesteprincipaler:

  • Anvend microsoft Entra-politikker for betinget adgang på din pipelines tjenesteprincipaler. Disse politikker hjælper med at identificere risikable logons og funktionsmåder. Hvis dine pipelinetjenesteprincipaler f.eks. altid logger på fra ét geografisk område, kan Betinget adgang registrere og forhindre logon fra uventede placeringer, hvilket kan indikere, at legitimationsoplysningerne er blevet kompromitteret.
  • Overvej nøje de tilladelser, du tildeler til hver tjenesteprincipal. Lad os f.eks. antage, at du har en tjenesteprincipal, som du bruger til at læse konfigurationen af en delt ressource. Overvej, om du kun kan give Reader adgang til denne tjenesteprincipal, fordi tjenesteprincipalen ikke behøver at foretage sig noget, der kræver flere rettigheder.
  • Brug minimumområdet for hver tilladelse, du tildeler til en tjenesteprincipal. Hvis din tjenesteprincipal f.eks. kun skal udrulle til en enkelt ressourcegruppe, skal rolletildelingen begrænses til den pågældende ressourcegruppe i stedet for til hele abonnementet.
  • Brug separate tjenesteprincipaler for hvert af dine miljøer. På den måde kan en sikkerhedskonto ikke få adgang til andre miljøer, selvom en sikkerhedskontos legitimationsoplysninger er kompromitteret, eller hvis nogen får adgang til ét miljø.

Beskyt dine tjenesteforbindelser og -hemmeligheder

En tjenesteforbindelse (i Azure Pipelines) eller hemmelige (i GitHub) indeholder legitimationsoplysningerne for den tjenesteprincipal, som pipelinen bruger til at få adgang til dit Azure-miljø. Det er vigtigt, at du beskytter dine tjenesteforbindelser og -hemmeligheder, og at du styrer, hvilke pipelines der bruger hver tjenesteforbindelse og -hemmelighed. Ellers kan du ved et uheld aktivere et ikke-produktionsmiljø for at bruge en tjenesteprincipal, der har adgang til produktionsressourcer.

Når du opretter en tjenesteforbindelse i Azure DevOps, kan du konfigurere den til at kræve din godkendelse, før en ny pipeline eller et nyt miljø kan bruge den.

Azure DevOps giver dig også mulighed for at knytte kontroller til bestemte tjenesteforbindelser. Kontroller tilføjer et ekstra beskyttelseslag. Du kan f.eks. konfigurere en kontrol af en produktionstjenesteforbindelse for at bekræfte, at den kun bruges på kode fra lagerets primære forgrening. Denne kontrol hjælper med at forhindre, at uautoriseret kode udrulles i dit produktionsmiljø.

I GitHub kan du konfigurere miljøspecifikke hemmeligheder, så når arbejdsprocessen for GitHub-handlinger arbejder med det pågældende miljø, giver den kun den hemmelige værdi. Når du bruger miljøspecifikke hemmeligheder og miljøkontrolelementer, f.eks. godkendelser, kan du reducere risikoen for, at en ikke-produktionsudrulning bruges til at udrulle til dit produktionsmiljø. Du kan også bruge arbejdsbelastningsidentiteter for at undgå at bruge legitimationsoplysninger i dine arbejdsprocesser i GitHub-handlinger og fjerne muligheden for, at legitimationsoplysninger kan blive vist.

Brug GitHub-sikkerhedsfunktioner

GitHub indeholder sikkerhedsfunktioner, som du skal evaluere og bruge. Disse funktioner omfatter:

  • Dependabot, som scanner din kildekodes afhængigheder for kendte sikkerhedsrisici.
  • Secret scanning, som identificerer tekst i dit lager, der ligner nøgler eller legitimationsoplysninger. Det er en dårlig praksis at gemme hemmeligheder i et lager. Hvis du får besked om en hemmelighed i dit lager, skal du overveje, om hemmelighedens værdi er kompromitteret, og derefter tilbagekalde eller ændre den.
  • Overvågningfor at forstå, hvem der har foretaget ændringer af din GitHub-konfiguration.
  • Oversigt over sikkerhed, som konsoliderer alle dine sikkerhedsbeskeder på tværs af organisationens lagre.

Brug Azure DevOps-overvågningslogge

Azure DevOps indeholder overvågningslogge for at hjælpe dig med at forstå, hvem der har foretaget ændringer af dine pipelines, forgreningspolitikker, lagre og andre ressourcer. Det er en god idé at aktivere overvågning og gennemse overvågningsloggene regelmæssigt.

Beskyt dit lager og din pipeline

Vi har diskuteret de vigtige kontrolelementer, som du kan anvende på dit lager og din pipeline. Lad os nu overveje, hvilke kontrolelementer du kan bruge til at beskytte hvert af de vigtige elementer, vi har angivet tidligere i dette undermodul:

Element, der skal beskyttes Kontrolelementer, der skal anvendes
Din Azure DevOps-organisation eller GitHub-lager, herunder hvem der har adgang til den, og hvad de har tilladelse til at gøre.
  • Brug Microsoft Entra-id til godkendelse.
  • Brug teams og grupper til at tildele tilladelser.
  • Aktivér logføring af overvågning, og gennemse overvågningslogge regelmæssigt.
Vigtige forgreninger i dit lager, og hvad der skal ske for at ændre koden på disse forgreninger. Anvend regler for beskyttelse af forgreninger eller forgreningspolitikker.
Koden i dit lager, herunder dine infrastrukturdefinitioner, test og programkode.
  • Gennemtving krav til gennemsyn af kode.
  • Tilføj automatiserede eller manuelle test.
  • På GitHub skal du bruge Dependabot og hemmelig scanning.
Pipelinedefinitionen. Gennemtving krav til gennemsyn af kode.
De agenter eller løbere, der kører din pipeline.
  • Brug Microsoft-hostede agenter på Azure Pipelines.
  • På GitHub Actions skal du bruge GitHub-hostede løbere.
Eventuelle tredjepartsopgaver eller -komponenter, der kan køre i din pipeline. Gennemse den sikkerhedsrisiko, der er knyttet til alle udvidelser og opgaver fra tredjepart.
De tjenesteprincipaler, som din pipeline bruger til at få adgang til Azure.
  • Brug arbejdsbelastningsidentiteter i GitHub-handlinger. For Azure Pipelines skal du bruge tjenesteprincipaler og regelmæssigt rotere deres legitimationsoplysninger.
  • Brug separate tjenesteprincipaler for hvert miljø.
  • Anvend politikker for betinget adgang.
De hemmeligheder, som din pipeline bruger til at få adgang til eksterne systemer.
  • På Azure DevOps skal du bruge godkendelser og kontrol af tjenesteforbindelser.
  • Brug miljøspecifikke hemmeligheder og arbejdsbelastningsidentiteter på GitHub.