Zabezpečení agentů, projektů a kontejnerů

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

Při zabezpečení Služby Azure Pipelines zvažte ochranu sdílené infrastruktury, úložišť, projektů a dalších možností.

Tento článek je součástí série, která vám pomůže implementovat bezpečnostní opatření pro Azure Pipelines. Další informace najdete v tématu Zabezpečení služby Azure Pipelines.

Požadavky

Kategorie	Požadavky
Azure DevOps	– Implementujte doporučení v Jak zabezpečit Azure DevOps a Zabezpečení Azure Pipelines. – Základní znalost YAML a Azure Pipelines. Další informace najdete v tématu Vytvoření prvního pipeline.
Oprávnění	- Úprava oprávnění kanálů: Člen skupiny Správci projektu. - Chcete-li upravit oprávnění organizace, musíte být členem skupiny Správci kolekce projektů.

Ochrana sdílené infrastruktury

Chráněné prostředky v Azure Pipelines představují abstrakci skutečné infrastruktury. Pokud chcete chránit základní infrastrukturu, postupujte podle těchto doporučení.

Použití fondů hostovaných Microsoftem

Fondy hostované společností Microsoft poskytují izolaci a čistý virtuální počítač pro každé spuštění pipeliny. Pokud je to možné, místo fondů hostovaných v místním prostředí používejte fondy hostované Microsoftem.

Samostatné agenty pro každý projekt

Agent může být přidružen pouze k jednomu poolu. Agenty můžete sdílet mezi projekty tím, že fond přidružujete k více projektům. V praxi může několik projektů používat stejného agenta po sobě. I když je tento přístup nákladově efektivní, může tento přístup představovat rizika laterálního pohybu.

Chcete-li snížit laterální pohyb a zabránit křížové kontaminaci mezi projekty, udržujte samostatné fondy agentů, které jsou vyhrazeny pro konkrétní projekt.

Použití účtů s nízkým oprávněním ke spouštění agentů

Spuštění agenta pod identitou s přímým přístupem k prostředkům Azure DevOps může být rizikové. V organizacích používajících Microsoft Entra ID je toto riziko časté.

Proč na tomto riziku záleží:

• Pokud agenta spustíte pod identitou, která je založená na ID Entra, může přímo přistupovat k rozhraním API Azure DevOps bez nutnosti spoléhat se na přístupový token úlohy.
• Útočníci, kteří na těchto agentech sestavení spouštějí kompromitovaný kanál, mohou potenciálně získat kontrolu nad celou organizací Azure DevOps.

Doporučení: Spusťte agenta pomocí neprivilegovaného místního účtu:

• Agenti Windows: Použijte síťovou službu (NT AUTHORITY\NETWORK SERVICE), místní službu nebo účet spravované služby skupiny (gMSA).
• Agenti Linuxu a agenti macOS: Vytvořte vyhrazený účet uživatele, který není root (například svc_azuredevops). Pro zajištění maximálního zabezpečení by tento účet neměl mít přístup sudo ani sudoers.

Důležité

V Azure DevOps může být skupina účtů služby Kolekce projektů zavádějící. Díky dědičnosti jsou členy účtů služby Kolekce projektů také členy správců kolekcí projektů. Někteří zákazníci spouštějí agenty sestavení pomocí identity založené na ID Entra a tyto identity můžou být součástí účtů služby Kolekce projektů.

Rizika vysoce privilegovaných agentů:

Samohostovaní agenti někdy pracují s vysoce privilegovanými účty pro přístup k tajným informacím nebo produkčním prostředím. Pokud útočníci spustí ohrožený kanál na jednom z těchto agentů sestavení, mohou:

• Získání přístupu k těmto tajným kódům
• Přechod mezi dalšími systémy dostupnými prostřednictvím těchto účtů

Osvědčené postupy pro zabezpečení agentů:

• Pro spouštění agentů v místním prostředí použijte nejspodnější možný účet.
• Zvažte použití účtu počítače nebo identity spravované služby.
• Umožňuje službě Azure Pipelines spravovat přístup k tajným kódům a prostředím.

Minimalizace rozsahu připojení služeb

Připojení služeb by mělo přistupovat pouze k potřebným prostředkům.

Doporučení pro ověřování:

• Pokud je to možné, použijte federaci pracovních identit místo servisního principálu pro připojení služby Azure.
• Federace identit úloh využívá Open ID Connect (OIDC), což je standardní technologie, která usnadňuje ověřování mezi Azure a Azure DevOps bez nutnosti spoléhat se na tajné kódy.

Doporučení k rozsahu:

• Nastavte obor připojení služby Azure tak, aby přistupoval jenom k potřebným prostředkům.
• Vyhněte se udělení širokých práv přispěvatelů pro celé předplatné Azure.
• Při vytváření nového připojení služby Azure Resource Manager vždy zvolte konkrétní skupinu prostředků.
• Ujistěte se, že skupina prostředků obsahuje pouze potřebné virtuální počítače nebo prostředky potřebné pro sestavení.
• Při konfiguraci aplikace GitHub udělte přístup pouze k úložištím, která chcete sestavit.

Ochrana projektů

Kromě jednotlivých prostředků je důležité zvážit skupiny prostředků v Azure DevOps. Zdroje jsou uspořádané podle týmových projektů a potřebujete pochopit, k čemu má váš kanál přístup na základě nastavení a omezení projektu.

Každá úloha v kanálu obdrží přístupový token s oprávněními ke čtení otevřených prostředků. V některých případech můžou kanály také tyto prostředky aktualizovat. Tento model oprávnění znamená, že i když váš uživatelský účet nemusí mít přímý přístup ke konkrétnímu prostředku, skripty a úlohy spuštěné v kanálu k němu stále mohou mít přístup. Kromě toho model zabezpečení Azure DevOps umožňuje přístup k těmto prostředkům z jiných projektů v organizaci. Pokud se rozhodnete omezit přístup kanálu k určitým prostředkům, toto rozhodnutí platí pro všechny kanály v rámci projektu – konkrétní kanály se nedají selektivně udělit přístup k otevřeným prostředkům.

Samostatné projekty

Vzhledem k povaze otevřených zdrojů zvažte správu jednotlivých produktů a týmů v samostatných projektech. Tímto způsobem zabráníte kanálům z jednoho produktu neúmyslně přistupovat k otevřeným prostředkům z jiného produktu, čímž minimalizujete laterální vystavení. Když ale projekt sdílí více týmů nebo produktů, bude podrobná izolace jejich prostředků náročná.

Pokud byla vaše organizace Azure DevOps vytvořená před srpnem 2019, můžou mít spuštění stále přístup k otevřeným prostředkům napříč všemi projekty vaší organizace. Správce vaší organizace by měl zkontrolovat důležité nastavení zabezpečení v Azure Pipelines, které umožňuje izolaci projektů pro kanály.

Toto nastavení najdete v Nastavení organizace>Pipeline>Nastavení nebo přímo: https://dev.azure.com/Organization_Name/_settings/pipelinessettings.

Ochrana úložišť

V úložištích správy verzí můžete uložit zdrojový kód, soubor YAML kanálu a nezbytné skripty a nástroje. Aby se zajistily bezpečné změny kódu a kanálu, je nezbytné použít zásady oprávnění a větví. Kromě toho zvažte přidání oprávnění a kontrol pro pipeline do úložišť.

Kromě toho zkontrolujte výchozí nastavení řízení přístupu pro vaše úložiště.

Mějte na paměti, že návrh Gitu znamená, že ochrana na úrovni větví má omezení. Uživatelé s nabízeným přístupem do úložiště můžou obvykle vytvářet nové větve. Pokud pracujete s opensourcovými projekty GitHubu, může každý, kdo má účet GitHubu, vytvořit fork úložiště a navrhnout příspěvky. Vzhledem k tomu, že kanály jsou přidružené k úložišti (ne ke konkrétním větvím), je nezbytné zacházet s kódem a soubory YAML jako s potenciálně nedůvěryhodnými.

Forky

Při práci s veřejnými úložišti z GitHubu pečlivě zvažte přístup k sestavením forku. Forky, které pocházejí mimo vaši organizaci, představují konkrétní rizika. Pokud chcete chránit produkty před potenciálně nedůvěryhodným kódem, postupujte podle těchto doporučení.

Poznámka:

Tato doporučení se primárně týkají vytváření veřejných úložišť z GitHubu.

Nezadávejte tajné kódy pro sestavení forku

Ve výchozím nastavení vaše kanály vytvářejí forky, ale nezpřístupňují pro úlohy v těchto kanálech tajné kódy a chráněné prostředky. Nezakažte tuto ochranu, abyste zachovali zabezpečení.

Poznámka:

Když povolíte sestavení forku pro přístup k tajným kódům, Azure Pipelines ve výchozím nastavení omezí přístupový token používaný. Tento token má omezený přístup k otevřeným prostředkům v porovnání s běžným přístupovým tokenem. Chcete-li forkovým buildům udělit stejná oprávnění jako běžným buildům, povolte nastavení Make fork builds have the same permissions as regular builds.

Zvažte ruční aktivaci sestavení forku.

Vypněte automatické sestavení forku a místo toho použijte komentáře k žádostem o přijetí změn jako způsob, jak tyto příspěvky vytvořit ručně. Toto nastavení vám dává příležitost zkontrolovat kód před aktivací sestavení.

Použití agentů hostovaných Microsoftem pro sestavení forku

Vyhněte se spouštění sestavení z forků na agentech v místním prostředí. Pokud používáte agenty v místním prostředí, můžou externí organizace spouštět externí kód na počítačích v podnikové síti. Kdykoli je to možné, použijte agenty hostované Microsoftem. U agentů v místním prostředí implementujte izolaci sítě a ujistěte se, že agenti neuchovávají svůj stav mezi úlohami.

Kontrola změn kódu

Před spuštěním pipeline na forked pull request pečlivě zkontrolujte navrhované změny a ujistěte se, že jste s ním spokojeni.

Verze kanálu YAML, který spustíte, je verze z žádosti o přijetí změn. Věnujte zvláštní pozornost změnám v YAML kódu a kódu, který se aktivuje při běhu pipeline, jako jsou skripty příkazového řádku nebo jednotkové testy.

Omezení rozsahu tokenů GitHubu

Když vytvoříte forkovanou žádost o přijetí změn GitHubu, Azure Pipelines zajistí, že kanál nemůže změnit žádný obsah úložiště GitHub. Toto omezení platí pouze v případě, že k integraci s GitHubem používáte aplikaci Azure Pipelines GitHub. Pokud používáte jiné formy integrace GitHubu, jako je aplikace OAuth, omezení se nevynutí.

Větve uživatelů

Uživatelé ve vaší organizaci se správnými oprávněními mohou vytvářet nové větve obsahující nový nebo aktualizovaný kód. Tento kód může běžet přes stejný kanál jako vaše chráněné větve. Pokud se změní soubor YAML v nové větvi, aktualizovaný YAML spustí kanál. I když tento návrh nabízí velkou flexibilitu a samoobslužnou službu, ne všechny změny jsou bezpečné (bez ohledu na to, jestli se udělaly zlými úmysly nebo ne).

Pokud váš kanál využívá zdrojový kód nebo je definovaný v Azure Repos, musíte plně porozumět modelu oprávnění Azure Repos. Konkrétně uživatel s oprávněním Vytvořit větev na úrovni úložiště může do úložiště zavést kód, i když tento uživatel nemá oprávnění Přispívat .

Další aspekty zabezpečení

Při zabezpečení kanálů zvažte následující aspekty zabezpečení.

Spoléhat se na PATH

Spoléhání na nastavení agenta PATH je nebezpečné. Nemusí ukazovat na to, kde si myslíte, že ano, protože předchozí skript nebo nástroj ho potenciálně změnil. Pro skripty a binární soubory kritické pro zabezpečení vždy používejte plně kvalifikovanou cestu k programu.

Protokolovat tajné kódy

Azure Pipelines se pokouší odebrat tajné kódy z protokolů, kdykoli je to možné. Toto filtrování je na základě nejlepšího úsilí a nemůže zachytit všechny způsoby, jak může dojít k úniku tajných kódů. Vyhněte se opakování tajných kódů v konzole, jejich použití v parametrech příkazového řádku nebo jejich protokolování do souborů.

Uzamčení kontejnerů

Kontejnery mají v úlohách, pracovním prostoru a externích komponentách potřebných ke komunikaci s hostitelským agentem několik systémových připojení svazků. Všechny tyto svazky můžete označit jako jen pro čtení.

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

Většina uživatelů obvykle nastaví první tři adresáře jako jen pro čtení a ponechá work ji jako pro čtení i zápis. Pokud do adresáře nezapisujete work v konkrétní úloze nebo kroku, můžete také nastavit work jen pro čtení. Pokud ale úlohy kanálu zahrnují vlastní úpravy, budete možná muset zachovat tasks čtení i zápis.

Řízení dostupných úkolů

Můžete zakázat možnost instalace a spouštění úloh z Marketplace. Tento přístup vám dává větší kontrolu nad kódem, který běží v pipeline. Můžete také zakázat všechny přednastavené úlohy s výjimkou úlohy Checkout, což je speciální akce na agentovi. Ve většině případů nezakazujte přednastavené úkoly.

Úlohy, které instalujete přímo pomocí, tfx jsou vždy dostupné. Když povolíte obě tyto funkce, budou k dispozici pouze tyto úlohy.

Použití služby Auditování

Služba auditování zaznamenává mnoho událostí kanálu. Pravidelně zkontrolujte protokol auditu, abyste se ujistili, že se v minulosti neproklouzly žádné škodlivé změny. Začněte tím, že navštívíte https://dev.azure.com/ORG-NAME/_settings/audit.

Další kroky

Přehled zabezpečení