Andra säkerhetsöverväganden för Azure Pipelines

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

När det gäller att skydda Azure Pipelines finns det flera andra saker att tänka på, som att skydda delad infrastruktur, lagringsplatser, projekt med mera.

Skydda delad infrastruktur

Skyddade resurser i Azure Pipelines är en abstraktion av verklig infrastruktur. Följ dessa rekommendationer för att skydda den underliggande infrastrukturen.

Använda Microsoft-värdbaserade pooler

Microsoft-värdbaserade pooler erbjuder isolering och en ren virtuell dator för varje körning av en pipeline. Använd om möjligt Microsoft-värdbaserade pooler i stället för pooler med egen värd.

Separata agenter för varje projekt

En agent kan endast associeras med en enda pool. Du kan dela agenter mellan projekt genom att associera poolen med flera projekt. I praktiken kan flera projekt använda samma agent i följd. Även om det är kostnadseffektivt kan den här metoden medföra risker för lateral förflyttning.

För att minimera lateral förflyttning och förhindra korskontaminering mellan projekt, underhålla separata agentpooler, var och en dedikerad till ett specifikt projekt.

Använda lågprivilegierade konton för att köra agenter

Även om du är frestad kan det vara riskabelt att köra agenten under en identitet med direkt åtkomst till Azure DevOps-resurser. Den här konfigurationen är vanlig i organisationer som använder Microsoft Entra-ID men utgör risker. Om du kör agenten under en identitet som backas upp av Microsoft Entra-ID kan den komma åt Azure DevOps-API:er direkt utan att förlita sig på jobbets åtkomsttoken. För bättre säkerhet bör du överväga att köra agenten med ett lokalt konto som inte är privilegierat, till exempel Nätverkstjänst.

Viktigt!

I Azure DevOps finns det en grupp som heter Project Collection Service-konton, vilket kan vara missvisande. Efter arv betraktas medlemmar i Project Collection Service-konton också som medlemmar i Projektsamlingsadministratörer. Vissa kunder kör sina byggagenter med hjälp av en identitet som backas upp av Microsoft Entra-ID, och dessa identiteter kan ingå i Project Collection Service-konton. Men om angripare kör en pipeline på en av dessa byggagenter kan de potentiellt få kontroll över hela Azure DevOps-organisationen.

Det finns instanser där lokalt installerade agenter fungerar under konton med hög behörighet. Dessa agenter använder ofta dessa privilegierade konton för att få åtkomst till hemligheter eller produktionsmiljöer. Men om angripare kör en komprometterad pipeline på en av dessa byggagenter får de åtkomst till dessa hemligheter. Sedan kan angripare gå i sidled genom andra system som är tillgängliga via dessa konton.

För att förbättra systemsäkerheten rekommenderar vi att du använder det lägsta privilegierade kontot för att köra lokalt installerade agenter. Överväg till exempel att använda ditt datorkonto eller en hanterad tjänstidentitet. Ge även Azure Pipelines behörighet att hantera åtkomst till hemligheter och miljöer.

Minimera omfattningen för tjänstanslutningar

Se till att tjänstanslutningar endast har åtkomst till nödvändiga resurser. När det är möjligt bör du överväga att använda arbetsbelastningsidentitetsfederation i stället för ett huvudnamn för tjänsten för din Azure-tjänstanslutning. Arbetsbelastningsidentitetsfederation använder Open ID Connect (OIDC), en branschstandardteknik, för att underlätta autentisering mellan Azure och Azure DevOps utan att förlita sig på hemligheter.

Se till att azure-tjänstanslutningen är begränsad för att endast komma åt nödvändiga resurser. Undvik att bevilja breda deltagarrättigheter för hela Azure-prenumerationen till användare.

När du skapar en ny Azure Resource Manager-tjänstanslutning väljer du alltid en specifik resursgrupp. Kontrollera att resursgruppen endast innehåller de virtuella datorer eller resurser som krävs för bygget. När du konfigurerar GitHub-appen beviljar du på samma sätt endast åtkomst till de lagringsplatser som du tänker skapa med Hjälp av Azure Pipelines.

Skydda projekt

Utöver enskilda resurser är det viktigt att överväga resursgrupper i Azure DevOps. Resurser organiseras av teamprojekt och det är viktigt att förstå vad din pipeline kan komma åt baserat på projektinställningar och inneslutning.

Varje jobb i pipelinen tar emot en åtkomsttoken med behörighet att läsa öppna resurser. I vissa fall kan pipelines också uppdatera dessa resurser. Det innebär att även om ditt användarkonto kanske inte har direkt åtkomst till en specifik resurs, kan skript och uppgifter som körs i din pipeline fortfarande komma åt den. Dessutom ger Azure DevOps säkerhetsmodell åtkomst till dessa resurser från andra projekt i organisationen. Om du bestämmer dig för att begränsa pipelineåtkomsten till vissa resurser gäller det här beslutet för alla pipelines i ett projekt – specifika pipelines kan inte beviljas selektiv åtkomst till öppna resurser.

Separata projekt

Med tanke på de öppna resursernas natur bör du överväga att hantera varje produkt och team i separata projekt. Genom att göra det förhindrar du att pipelines från en produkt oavsiktligt kommer åt öppna resurser från en annan produkt, vilket minimerar lateral exponering. Men när flera team eller produkter delar ett projekt blir granulär isolering av deras resurser utmanande.

Om din Azure DevOps-organisation skapades före augusti 2019 kan körningar fortfarande ha åtkomst till öppna resurser i alla organisationens projekt. Organisationsadministratören bör granska en kritisk säkerhetsinställning i Azure Pipelines som möjliggör projektisolering för pipelines.

Du hittar den här inställningen i Inställningar för organisationsinställningar>Pipelines>, eller direkt: . https://dev.azure.com/Organization_Name/_settings/pipelinessettings

Skydda lagringsplatser

I lagringsplatser för versionskontroll kan du lagra källkod, pipelinens YAML-fil och nödvändiga skript och verktyg. För att säkerställa säkra ändringar i koden och pipelinen är det viktigt att tillämpa behörigheter och grenprinciper. Överväg också att lägga till pipelinebehörigheter och kontroller till lagringsplatser.

Granska dessutom standardinställningarna för åtkomstkontroll för dina lagringsplatser.

Kom ihåg att Gits design innebär att skyddet på avdelningsnivå har begränsningar. Användare med push-åtkomst till en lagringsplats kan vanligtvis skapa nya grenar. Om du arbetar med GitHub-projekt med öppen källkod kan alla med ett GitHub-konto förgrena din lagringsplats och föreslå bidrag. Eftersom pipelines är associerade med en lagringsplats (inte specifika grenar) är det viktigt att behandla kod- och YAML-filer som potentiellt obetrodda.

Gafflar

När du arbetar med offentliga lagringsplatser från GitHub är det viktigt att du noga överväger din metod för förgreningsversioner. Förgreningar, som kommer från utanför organisationen, utgör särskilda risker. Ta hänsyn till följande rekommendationer för att skydda dina produkter från potentiellt ej betrodd kod

Kommentar

Dessa rekommendationer gäller främst för att skapa offentliga lagringsplatser från GitHub.

Ange inte hemligheter för förgreningsversioner

Som standard är dina pipelines konfigurerade för att skapa förgreningar, men hemligheter och skyddade resurser exponeras inte automatiskt för jobben i dessa pipelines. Det är viktigt att inte inaktivera det här skyddet för att upprätthålla säkerheten.

Kommentar

När du aktiverar förgreningsversioner för åtkomst till hemligheter begränsar Azure Pipelines den åtkomsttoken som används som standard. Den här token har begränsad åtkomst till öppna resurser jämfört med en vanlig åtkomsttoken. Om du vill bevilja förgreningsversioner samma behörigheter som vanliga versioner aktiverar du inställningen Skapa förgreningsversioner med samma behörigheter som vanliga versioner .

Överväg att utlösa förgreningsversioner manuellt

Du kan inaktivera automatiska förgreningsversioner och i stället använda pull-begärandekommenter som ett sätt att skapa dessa bidrag manuellt. Den här inställningen ger dig möjlighet att granska koden innan du utlöser en version.

Använda Microsoft-värdbaserade agenter för förgreningsversioner

Undvik att köra versioner från gafflar på lokalt installerade agenter. Det kan göra det möjligt för externa organisationer att köra extern kod på datorer i företagets nätverk. När det är möjligt använder du Microsoft-värdbaserade agenter. För lokalt installerade agenter implementerar du nätverksisolering och ser till att agenterna inte bevarar sitt tillstånd mellan jobb.

Granska kodändringar

Innan du kör pipelinen på en förgrenad pull-begäran bör du noggrant granska de föreslagna ändringarna och se till att du är bekväm med att köra den.

Den version av YAML-pipelinen som du kör är den från pull-begäran. Var därför särskilt uppmärksam på ändringar i YAML-koden och den kod som körs när pipelinen körs, till exempel kommandoradsskript eller enhetstester.

Begränsning av GitHub-tokenomfång

När du skapar en GitHub-förgrenad pull-begäran ser Azure Pipelines till att pipelinen inte kan ändra något GitHub-lagringsplatsinnehåll. Den här begränsningen gäller endast om du använder GitHub-appen Azure Pipelines för att integrera med GitHub. Om du använder andra former av GitHub-integrering, till exempel OAuth-appen, tillämpas inte begränsningen.

Användargrenar

Användare i din organisation med rätt behörigheter kan skapa nya grenar som innehåller ny eller uppdaterad kod. Den här koden kan köras via samma pipeline som dina skyddade grenar. Om YAML-filen i den nya grenen ändras används den uppdaterade YAML för att köra pipelinen. Även om den här designen ger stor flexibilitet och självbetjäning är inte alla ändringar säkra (oavsett om de görs skadligt eller inte).

Om din pipeline använder källkod eller definieras i Azure Repos måste du helt förstå behörighetsmodellen för Azure Repos. I synnerhet kan en användare med behörigheten Skapa gren på lagringsplatsnivå introducera kod till lagringsplatsen även om användaren saknar Behörighet att bidra .

Andra säkerhetsöverväganden

Det finns följande handfull andra saker du bör tänka på när du skyddar pipelines.

Förlita dig på PATH

Det är farligt att förlita sig på agentens PATH inställning. Det kanske inte pekar där du tror att det gör, eftersom det eventuellt har ändrats av ett tidigare skript eller verktyg. För säkerhetskritiska skript och binärfiler använder du alltid en fullständigt kvalificerad sökväg till programmet.

Logghemligheter

Azure Pipelines försöker rensa hemligheter från loggar där det är möjligt. Den här filtreringen är på bästa sätt och kan inte fånga alla sätt som hemligheter kan läcka. Undvik att upprepa hemligheter för konsolen, använda dem i kommandoradsparametrar eller logga dem till filer.

Låsa containrar

Containrar har några systembaserade volymmonteringar som mappas i uppgifter, arbetsytan och externa komponenter som krävs för att kommunicera med värdagenten. Du kan markera alla eller alla dessa volymer skrivskyddade.

resources:
  containers:
  - container: example
    image: ubuntu:22.04
    mountReadOnly:
      externals: true
      tasks: true
      tools: true
      work: false  # the default; shown here for completeness

Vanligtvis bör de flesta ange de tre första katalogerna som skrivskyddade och lämna work som skrivskyddade. Om du inte skriver till work katalogen i ett visst jobb eller steg kan du också göra work skrivskyddad. Men om dina pipelineuppgifter innebär självändring kan du behöva behålla tasks som skrivskyddad.

Kontrollera tillgängliga uppgifter

Du kan inaktivera möjligheten att installera och köra uppgifter från Marketplace, vilket ger dig större kontroll över koden som körs i en pipeline. Du kan också inaktivera alla in-the-box-uppgifter (förutom Checkout, vilket är en särskild åtgärd för agenten). Vi rekommenderar att du inte inaktiverar in-the-box-uppgifter under de flesta omständigheter.

Uppgifter som är direkt installerade med tfx är alltid tillgängliga. Med båda dessa funktioner aktiverade är endast dessa uppgifter tillgängliga.

Använda granskningstjänsten

Många pipelinehändelser registreras i granskningstjänsten. Granska granskningsloggen regelbundet för att se till att inga skadliga ändringar halkade förbi. Besök https://dev.azure.com/ORG-NAME/_settings/audit för att komma igång.

Nästa steg

Granska säkerhetsöversikten