Styrningsöverväganden för säker distribution i Azure

  • Använd principen om minsta behörighet när du tilldelar roller och behörigheter. Endast användare som ansvarar för produktionsutgåren bör starta processen och endast utvecklare bör komma åt källkoden.

    En pipeline bör använda ett eller flera huvudnamn för tjänsten. De bör helst vara hanterade identiteter och levereras av plattformen och aldrig definieras direkt i en pipeline. Identiteten bör bara ha de Azure RBAC-behörigheter som krävs för att utföra uppgiften. Alla tjänstens huvudnamn ska vara bundna till den pipelinen och inte delas mellan pipelines.

    Hur definierar du CI/CD-roller och behörigheter?


    Azure DevOps erbjuder inbyggda roller som kan tilldelas enskilda användare av grupper. Om de inbyggda rollerna inte är tillräckliga för att definiera minsta behörighet för en pipeline kan du överväga att skapa anpassade Azure RBAC-roller. Se till att dessa roller överensstämmer med åtgärden och organisationens team och ansvarsområden.

    För att stödja säkerheten för dina pipelineåtgärder kan du lägga till användare i en inbyggd säkerhetsgrupp, ange enskilda behörigheter för en användare eller grupp eller lägga till användare i fördefinierade roller. Du hanterar säkerheten för följande objekt från Azure Pipelines i webbportalen, antingen från användar- eller administratörskontexten.

    Mer information finns i Kom igång med behörigheter, åtkomst och säkerhetsgrupper.

  • För behörigheter beviljar eller begränsar du behörigheter genom att ange behörighetstillståndet till Tillåt eller Neka, antingen för en säkerhetsgrupp eller en enskild användare. För en roll lägger du till en användare eller grupp i rollen.

  • Använd separata pipelineidentiteter mellan förproduktions- och produktionsmiljöer. Om det är tillgängligt kan du dra nytta av pipelinefunktioner som miljöer för att kapsla in autentisering på sista milen utanför den körande pipelinen.

  • Om pipelinen körs sällan och har hög behörighet kan du överväga att ta bort stående behörigheter för den identiteten. Använd JIT-rolltilldelningar (just-in-time), tidsbaserad och godkännandebaserad rollaktivering. Den här strategin minskar riskerna för överdriven, onödig eller missbruk av åtkomstbehörigheter för viktiga resurser. Azure AD Privileged Identity Management har stöd för alla dessa aktiveringslägen.

  • Granska organisationens CI/CD-pipeline och förfina rolltilldelningen för att skapa en tydlig avgränsare mellan utvecklings- och produktionsansvar.

Läs mer

Mer information om pipelinebehörigheter och säkerhetsroller finns i Ange olika nivåer av pipelinebehörigheter.

Körningsomfång

När det är praktiskt begränsar du körningsomfånget i pipelines.

Överväg att skapa en pipeline i flera steg. Dela upp arbetet i diskreta enheter som kan isoleras i en separat pipeline. Begränsa identiteterna till omfånget för enheten så att den har minsta möjliga behörighet för att kunna göra åtgärden. Du kan till exempel ha två enheter, en att distribuera och en annan som skapar källkod. Tillåt endast att distributionsenheten har åtkomst till identiteten, inte byggenheten. Om byggenheten komprometteras kan den börja manipulera infrastrukturen.

Process för gated-godkännande

Har du versionsportgodkännanden som konfigurerats i DevOps-lanseringsprocessen?


Pull-begäranden och kodgranskningar fungerar som den första raden med godkännanden under utvecklingscykeln. Innan du släpper en uppdatering till produktion måste du kräva en process som kräver säkerhetsgranskning och godkännande.

Se till att du involverar säkerhetsteamet i planerings-, design- och DevOps-processen. Det här samarbetet hjälper dem att implementera processer för säkerhetskontroller, granskning och svar.

Används förgreningsprinciper i källkontrollhanteringen av den här arbetsbelastningen? Hur konfigureras de?


Upprätta förgreningsprinciper som ger en extra nivå av kontroll över den kod som används för lagringsplatsen. Brist på säker förgreningsprincip kan tillåta att dålig, falsk eller bruten kod checkas in och distribueras. Det är vanligt att neka push-meddelanden till huvudgrenen om ändringen inte godkänns. Du kan till exempel kräva pull-begäran (PR) med kodgranskning innan du sammanfogar ändringarna med minst en granskare, förutom ändringsförfattaren.

Vi rekommenderar att du har flera grenar där varje gren har ett syfte och en åtkomstnivå. Till exempel skapas funktionsgrenar av utvecklare och är öppna för push-meddelanden. Integreringsgrenen kräver PR och kodgranskning. Produktionsgrenen kräver ytterligare ett godkännande från teamchefen innan sammanslagningen.

Föreslagna åtgärder

  • Konfigurera godkännanden av kvalitetsgrindar i DevOps-lanseringsprocessen.
  • Följ riktlinjerna i de länkade artiklarna för att distribuera och implementera en förgreningsstrategi.

Läs mer

Nästa

Gå tillbaka huvudartikeln: Säker distribution och testning i Azure

Processerna för automatisk kontinuerlig integrering, kontinuerlig leverans (CI/CD) måste ha inbyggd styrning som auktoriserar och autentiserar identiteterna för att utföra uppgifterna inom ett definierat omfång.

Huvudpunkter

  • Definiera tydligt CI/CD-roller och behörigheter.
  • Implementera just-in-time-hantering av privilegierad åtkomst.
  • Begränsa långvarig skrivåtkomst till produktionsmiljöer.
  • Begränsa körningsomfånget i pipelines.
  • Konfigurera godkännanden av kvalitetsgrindar i DevOps-lanseringsprocessen.

Minimera åtkomst

Minimera antalet personer som har åtkomst till säker information eller resurser. Den här strategin minskar risken för att en obehörig aktör får åtkomst eller att en behörig användare oavsiktligt påverkar en känslig resurs. Här är några saker att tänka på: