Sdílet prostřednictvím

Zabezpečení kanálu a pracovního postupu CI/CD

  • Článek

Tento článek popisuje, jak zabezpečit kanály a pracovní postupy CI/CD.

Automatizace a agilní metodologie umožňují týmům rychleji dodávat, ale také zvyšuje složitost zabezpečení, protože pracovní postup se rozšiřuje na samotné vývojářské týmy.

Následující diagram znázorňuje základní pracovní postup CI/CD. Červená ikona konfigurace označuje oprávnění zabezpečení, která musí nakonfigurovat zákazník. To se řídí modelem sdílené odpovědnosti, kde Azure a další dodavatelé poskytují oprávnění, která musí zákazník nakonfigurovat podle modelu zásad správného řízení a obchodních požadavků.

Typický pracovní postup CI/CD, který ukazuje, jak změny kódu v úložišti Git ovlivní vaše cloudové prostředky.

Pojďme se podívat na jednotlivé fáze tohoto typického pracovního postupu, abychom vám pomohli pochopit, jak často konfigurace vzájemně závisejí. Váš pracovní postup může mít více fází. Následující koncepty vám pomůžou porozumět CI/CD a pomohou vám navrhnout pracovní postup pro zabezpečení.

Fáze 1: Pracovní postup Gitu

Změny kódu, nejen pro software, ale také kanál jako kód a infrastrukturu jako kód, se ukládají a spravují v Gitu. Git je distribuovaný software pro správu zdrojového kódu. Když se kód nasdílí z místních počítačů na centralizovaný server Git, je možné před přijetím použít obchodní pravidla.

Žádosti o přijetí změn a spolupráce

Standardní pracovní postup odvětví bez ohledu na dodavatele softwaru pro správu konfigurace softwaru (SCM) jako služby (SaaS) je použít žádosti o přijetí změn, které můžou fungovat jako automatizovaný vrátný i krok ručního schválení před přijetím zdrojového kódu.

Pracovní postup žádosti o přijetí změn je navržený tak, aby zavedl bezproblémové tření, a proto by se měl použít pouze pro zabezpečení konkrétních větví Gitu. Zejména větve, které aktivují automatizované pracovní postupy, které můžou nasazovat, konfigurovat nebo jinými způsoby ovlivnit vaše cloudové prostředky. Tyto větve se nazývají chráněné větve a obvykle se řídí konvencemi vytváření názvů, jako production jsou nebo releases/*.

Žádosti o přijetí změn se běžně vyžadují:

  • Partnerské recenze
  • Předávání sestavení kontinuální integrace (CI)
  • Ruční schválení

Pokud jsou splněny požadavky, změny kódu se přijmou a dají se sloučit.

Omezení přístupu k chráněným větvím

Pracovní postup žádosti o přijetí změn se používá společně s omezenými řízeními přístupu. Pracovní postup žádosti o přijetí změn se ale nedá vynutit, pokud není server nakonfigurovaný tak, aby odmítl přímé změny chráněných větví.

Vývojář nemůže odeslat přímo do production větve, ale musí vytvořit žádost o přijetí změn, která cílí na chráněnou větev. Každý dodavatel SCM má jinou variantu pro dosažení omezeného přístupu k chráněným větvím. Například u GitHubu je tato funkce dostupná jenom pro organizace, které používají tým GitHubu nebo cloud GitHub Enterprise.

Zdokumentování modelu přístupu Git

Vzhledem k tomu, že model spolupráce je složitý a má mnoho pohyblivých částí, je užitečné vytvořit tabulku, která dokumentuje všechny možné způsoby, jak můžou změny kódu aktivovat nasazení, například:

Název větve Vyžaduje žádost o přijetí změn? Nasadí? Přístup pro vývojáře Přístup správce
feat/* No Ne Čtení/zápis Čtení/zápis
main Ano Příprava Čteno Čtení/zápis
production Ano, pouze z main Výroba Čteno Čtení/zápis

Tento příklad accessové tabulky Gitu je zjednodušen, aby ilustroval jeho účel. V praxi je často více herců, více cílů nasazení a více kanálů, které běží pro různé případy použití. Vaše struktura tabulky se může lišit v závislosti na požadavcích vaší organizace a úloh.

Tabulka by vám měla pomoct zodpovědět otázky, jako jsou:

  • Pokud vývojář odešle změny kódu do větve X, nasadí ho? Pokud ano, do kterého prostředí?
  • V jakém okamžiku v životním cyklu kódu aplikace se provádí kontrola ohrožení zabezpečení?
  • Pokud se najde ohrožení zabezpečení, kolik nabízených změn a schválení kódu se vyžaduje před tím, než se objeví v produkčním prostředí?

Tato tabulka je užitečná nejen pro ladění a statickou dokumentaci, ale také pro týmovou spolupráci. Vývojářům je transparentní, když se do pracovního postupu zavedlo zdravé tření, aby upřednostnily kvalitu kódu a zabezpečení. Důležitější je, že vývojáři ukazují očekávanou cestu ke změnám kódu v produkčním prostředí.

Vzhledem k tomu, že DevOps je cesta, váš přístupový model Gitu není statický. Bude se měnit a vyvíjet, jak týmy najdou své vlastní rytmy a zralé. Proto je důležité uložit tuto dokumentaci co nejblíže kódu, například v úložištích Git.

Další informace o žádostech o přijetí změn a chráněných větvích najdete tady:

Fáze 2: Kanály jako kód

Přesun kódu jako kódu urychlil přijetí a nasazení automatizace přesunutím definic a konfigurací kanálu od dodavatele CI vývojářům, čímž se logika sestavení a nasazení přibližuje odpovídající aplikační logice. Větší flexibilita zde také přináší větší zodpovědnost.

Řízení přístupu na základě role v kanálu řízeném uživatelským rozhraním může zabránit jednotlivým uživatelům v provádění destruktivních změn. Kanály jako kód se ale často spouštějí s privilegovanými identitami a můžou v případě pokynu k tomu zničit úlohy.

Fáze 3: Zabezpečení přihlašovacích údajů pro nasazení

Kanály a úložiště kódu by neměly obsahovat pevně zakódované přihlašovací údaje a tajné kódy. Přihlašovací údaje a tajné kódy by se měly ukládat jinde a používat funkce dodavatele CI pro zabezpečení. Protože kanály běží jako bezobezční agenti, neměli by nikdy používat heslo jednotlivce. Kanály by se měly spouštět pomocí bezobslužných objektů zabezpečení, jako jsou instanční objekty nebo spravované identity. Přístup k přihlašovacím údajům tohoto objektu zabezpečení, databázovým připojovací řetězec a klíčům rozhraní API třetích stran by se měl bezpečně spravovat také na platformě CI.

Způsob zabezpečení přihlašovacích údajů, bran a schválení jsou funkce specifické pro dodavatele. Při výběru platformy CI se ujistěte, že podporuje všechny požadované funkce.

Azure Pipelines je řešení kontinuální integrace na podnikové úrovni, ve kterém se přihlašovací údaje ukládají jako připojení služeb, při kterých můžete nakonfigurovat schválení a kontroly. Tato konfigurace zahrnuje ruční schválení a konkrétní autorizaci větví nebo kanálů.

Azure Key Vault

Pokud ji vaše platforma CI podporuje, zvažte uložení přihlašovacích údajů ve vyhrazeném úložišti tajných kódů, například ve službě Azure Key Vault. Přihlašovací údaje se načítají za běhu agentem sestavení a vaše prostor pro útoky se zmenší.

Fáze 4: Zabezpečení prostředků Azure

Vaše prostředky Azure by měly být zabezpečené podle principu nejnižších oprávnění, které se použijí na oprávnění i obor.

Další informace naleznete v tématu:

Vytvoření vlastních rolí pro agenty sestavení

Automatizace CI/CD se vztahuje nejen na aplikace, ale také na infrastrukturu. Šablony infrastruktury jako kódu (IaC) zajišťují konzistentní nasazení a pomáhají centralizovaným týmům cloudové platformy škálovat.

Je důležité si uvědomit, že automatizace IaC se může pokazit. Může chybně nakonfigurovat a v nejhorších případech trvale odstranit infrastrukturu. Při plánování cesty ke cloudu určete, které operace jsou důležité pro firmu, a vyžadují lidský zásah.

Zámky správy se například nedají odstranit u důležitých obchodních prostředků, jako jsou data. Abyste tomu zabránili, můžete odebrat Microsoft.Authorization/*/Delete oprávnění z instančního objektu používaného v automatizaci CI. V tomto příkladu a použití může instanční objekt vytvořit zámek správy, ale ne odstranit.

Doporučujeme vytvořit vlastní roli pro vaše agenty CI. Nezapomeňte, že agenti sestavení běží bez hlavy a bezobstřední agenti jsou bez mozku. Pečlivě zvolte svá oprávnění.

Další informace najdete v následujících tématech:

Zdroje informací

Další kroky

Teď, když rozumíte zabezpečení DevOps, přečtěte si další informace o komplexních zásadách správného řízení z DevOps do Azure.

Komplexní zásady správného řízení z DevOps do Azure