Rekommendationer för att skydda delad infrastruktur i Azure Pipelines

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

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 bara bindas till en pool. Du kanske vill dela agenter mellan projekt genom att dela poolen med flera projekt. Med andra ord kan flera projekt köra jobb på samma agent, en efter en. Även om den här metoden sparar infrastrukturkostnader kan den tillåta lateral förflyttning.

Om du vill eliminera den formen av lateral förflyttning och förhindra att ett projekt "förgiftar" en agent för ett annat projekt ska du ha separata agentpooler med separata agenter för varje projekt.

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

Det är frestande men farligt att köra agenten under en identitet som har direkt åtkomst till Azure DevOps-resurser. Den här problematiska konfigurationen är vanlig i organisationer som använder Microsoft Entra-ID. 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 använda jobbets åtkomsttoken. Du bör i stället köra agenten som ett icke-privilegierat lokalt konto, till exempel Nätverkstjänst.

Azure DevOps har en grupp som felaktigt heter Project Collection Service Accounts. Efter arv är medlemmar i Project Collection Service-konton också medlemmar i Projektsamlingsadministratörer. Kunder kör ibland sina byggagenter med hjälp av en identitet som backas upp av Microsoft Entra-ID och som är medlem i Project Collection Service-konton. Om angripare kör en pipeline på en av dessa byggagenter kan de ta över hela Azure DevOps-organisationen.

Vi har också sett lokalt installerade agenter köras under konton med hög behörighet. Dessa agenter använder ofta 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 kan de komma åt dessa hemligheter. Sedan kan angripare gå i sidled genom andra system som är tillgängliga via dessa konton.

Om du vill skydda dina system använder du det lägsta privilegierade kontot för att köra lokalt installerade agenter. Använd till exempel ditt datorkonto eller en hanterad tjänstidentitet. Låt Azure Pipelines hantera åtkomst till hemligheter och miljöer.

Minimera omfattningen för tjänstanslutningar

Tjänstanslutningar måste bara kunna komma åt de resurser som de behöver. Använd om möjligt arbetsbelastningsidentitetsfederation i stället för ett huvudnamn för tjänsten för din Azure-tjänstanslutning. Arbetsbelastningsidentitetsfederationen använder en branschstandardteknik, Open ID Anslut (OIDC), för att underlätta autentisering mellan Azure och Azure DevOps och använder inte hemligheter.

Din Azure-tjänstanslutning bör begränsas till de resurser som du är tjänstanslutningen behöver för åtkomst. Användare bör inte ha breda deltagarrättigheter för hela Azure-prenumerationen.

När du skapar en ny Azure Resource Manager-tjänstanslutning väljer du alltid en resursgrupp. Se till 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 vill skapa med hjälp av Azure Pipelines.

Nästa steg

Överväg några allmänna rekommendationer för säkerhet.