Další aspekty zabezpečení pro Azure Pipelines

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

Pokud jde o zabezpečení služby Azure Pipelines, je potřeba vzít v úvahu několik dalších aspektů, jako je ochrana sdílené infrastruktury, úložišť, projektů a dalších aspektů.

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é Microsoftem nabízejí izolaci a čistý virtuální počítač pro každý provoz kanálu. Pokud je to možné, používejte fondy hostované Microsoftem místo fondů hostovaných v místním prostředí.

Samostatné agenty pro každý projekt

Agenta je možné přidružit pouze k jednomu fondu. 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ů využí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 zmírnit 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ů

I když můžete být lákaví, spuštění agenta pod identitou s přímým přístupem k prostředkům Azure DevOps může být rizikové. Toto nastavení je v organizacích, které používají ID Microsoft Entra, ale představují rizika. Pokud agenta spustíte pod identitou zálohovanou ID Microsoft Entra, může přímo přistupovat k rozhraním API Azure DevOps bez nutnosti spoléhat se na přístupový token úlohy. Pokud chcete zlepšit zabezpečení, zvažte spuštění agenta pomocí neprivilegovaného místního účtu, jako je síťová služba.

Důležité

V Azure DevOps existuje skupina s názvem Účty služby Kolekce projektů, které můžou být zavádějící. Díky dědičnosti jsou členové účtů služby Kolekce projektů také považováni za členy správců kolekcí projektů. Někteří zákazníci spouštějí agenty sestavení pomocí identity založené na ID Microsoft Entra a tyto identity můžou být součástí účtů služby Kolekce projektů. Pokud ale nežádoucí uživatelé spustí kanál na jednom z těchto agentů sestavení, můžou potenciálně získat kontrolu nad celou organizací Azure DevOps.

Existují instance, ve kterých agenti v místním prostředí pracují s vysoce privilegovanými účty. Tito agenti často využívají tyto privilegované účty pro přístup k tajným kódům nebo produkčním prostředím. Pokud ale nežádoucí osoby na jednom z těchto agentů sestavení spustí ohrožený kanál, získají přístup k těmto tajným kódům. Nežádoucí osoba se pak můžou později pohybovat prostřednictvím jiných systémů přístupných prostřednictvím těchto účtů.

Pokud chcete zvýšit zabezpečení systému, doporučujeme pro spouštění agentů v místním prostředí používat nejnižší privilegovaný účet. Zvažte například použití účtu počítače nebo identity spravované služby. Také svěřte Azure Pipelines správě přístupu k tajným kódům a prostředím.

Minimalizace rozsahu připojení služeb

Ujistěte se, že připojení služeb mají přístup pouze k potřebným prostředkům. Kdykoli je to možné, zvažte použití federace identit úloh místo instančního objektu 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.

Ujistěte se, že je vaše připojení ke službě Azure omezené na přístup pouze k potřebným prostředkům. Vyhněte se udělení širokých práv přispěvatelů pro celé předplatné Azure uživatelům.

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í. Podobně když nakonfigurujete aplikaci GitHub, udělte přístup pouze k úložištím, která chcete sestavit pomocí Azure Pipelines.

Ochrana projektů

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

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. To znamená, že i když váš uživatelský účet nemusí mít přímý přístup ke konkrétnímu prostředku, skriptům a úlohám spuštěným v kanálu, budou k němu 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í>kanálů> organizace 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í kanálu a kontrol 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 je důležité pečlivě zvážit váš přístup k vytváření forků. Forky pocházející z mimo vaši organizaci představují konkrétní rizika. Pokud chcete chránit produkty před potenciálně nedůvěryhodným kódem, vezměte v úvahu následující 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í jsou vaše kanály nakonfigurované tak, aby se vytvořily forky, ale tajné kódy a chráněné prostředky nejsou automaticky vystaveny úlohám v těchto kanálech. Je nezbytné nezakazovat tuto ochranu, aby se zachovalo 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. Pokud chcete forku udělit stejná oprávnění jako běžná sestavení, povolte sestavení Make fork se stejnými oprávněními jako běžná nastavení sestavení .

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

Automatické sestavení forku můžete vypnout a místo toho použít komentáře k žádostem o přijetí změn jako způsob ručního vytváření těchto příspěvků. 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í. To by mohlo externím organizacím umožnit spouštění externího kódu 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 kanálu na rozvětvované žádosti o přijetí změn pečlivě zkontrolujte navrhované změny a ujistěte se, že jste s ním spokojení.

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

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í jenom v případě, že k integraci s GitHubem s GitHubem používáte aplikaci Azure Pipelines. Pokud používáte jiné formy integrace GitHubu, například aplikaci 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 soubor YAML v nové větvi změní, použije se aktualizovaný YAML ke spuštění kanálu. I když tento návrh umožňuje skvělou 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ů byste měli zvážit následující několik dalších věcí.

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 byl potenciálně změněn předchozím skriptem nebo nástrojem. 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ší vyčisit 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ů. Můžete označit libovolný nebo všechny tyto svazky 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ů by obvykle měla nastavit první tři adresáře jako jen pro čtení a ponechat 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, což vám umožní větší kontrolu nad kódem, který se spouští v kanálu. Můžete také zakázat všechny úkoly v poli (s výjimkou rezervace, což je zvláštní akce u agenta). Ve většině okolností doporučujeme nezakazovat úkoly v rámečku.

Úkoly, které jsou přímo nainstalovány, tfx jsou vždy k dispozici. Pokud jsou obě tyto funkce povolené, jsou k dispozici pouze tyto úlohy.

Použití služby Auditování

Mnoho událostí kanálu se zaznamenává ve službě auditování. Pravidelně zkontrolujte protokol auditu, abyste se ujistili, že se v minulosti neproklouzly žádné škodlivé změny. Navštivte https://dev.azure.com/ORG-NAME/_settings/audit , abyste mohli začít.

Další kroky

Přehled zabezpečení