Zabezpečení úložišť a kanálů

Dokončeno

Když k nasazení infrastruktury použijete automatizaci, kanál a úložiště se stanou výkonnými a důležitými. Vzhledem k tomu, že teď představují jediný způsob, jak se změny použijí ve vašich kontrolovaných prostředích.

Je potřeba chránit mnoho částí vaší organizace Azure DevOps, úložiště GitHub a kanálů. Následující tabulka obsahuje některé z nejdůležitějších prvků, které je třeba chránit, spolu s příklady ohrožení zabezpečení, ke kterým může dojít v případě, že tyto prvky dostatečně neochráníte.

Element pro ochranu	Příklad ohrožení zabezpečení
Vaše organizace Azure DevOps nebo úložiště GitHub, včetně toho, kdo k němu má přístup a co může dělat.	Nespokojený bývalý zaměstnanec odstraní úložiště kódu.
Důležité větve ve vašem úložišti a to, co se musí stát, když chcete změnit kód v těchto větvích.	Někdo omylem potvrdí nějaký nezabezpečený kód Bicep do hlavní větve vašeho úložiště.
Kód uvnitř úložiště, včetně definic infrastruktury, testů a kódu aplikace.	Někdo zapomene testovat kód, který napsal, a když se uvolní do produkčního prostředí, nefunguje správně.
Definice kanálu.	Někdo neúmyslně přidá krok kanálu, který zapíše databázi připojovací řetězec do protokolu kanálu.
Agenti nebo spouštěčé, kteří spouští váš kanál.	Kanál spuštěný proti konceptu žádosti o přijetí změn nainstaluje do agenta ohrožení zabezpečení, které se později použije pro produkční nasazení.
Všechny úlohy nebo komponenty třetích stran, které se můžou spouštět v rámci vašeho kanálu.	Úloha kanálu třetí strany odešle přihlašovací údaje instančního objektu na škodlivý web.
Instanční objekty, které váš kanál používá pro přístup k Azure.	Neprodukční instanční objekt omylem provede změnu v produkčním prostředí.
Tajné kódy, které váš kanál používá pro přístup k externím systémům.	Člen týmu zapíše nový definiční soubor kanálu pro prototyp a omylem ho připojí k produkčnímu prostředí.

Teď se seznámíme s některými přístupy, které můžete použít k použití zásad správného řízení a ovládacích prvků v úložišti kódu a kanálech nasazení v Azure DevOps a GitHubu.

Správa uživatelů a oprávnění

Zvažte, jak udělit přístup k organizaci Azure DevOps nebo úložišti GitHub. Zamyslete se nad tím, kdo má přístup a co může dělat.

Jako zprostředkovatele identity kanálu je vhodné použít instanci Microsoft Entra vaší organizace. Tímto způsobem můžete zajistit, že kdykoli se někdo připojí nebo opustí vaši organizaci, přístup ke kanálu se automaticky udělí nebo odvolá. Pomocí Id Microsoft Entra můžete také snadno implementovat ochranu, jako je podmíněný přístup a vícefaktorové ověřování.

Poznámka:

K použití integrace Microsoft Entra s GitHubem potřebuje vaše organizace licenci GitHub Enterprise.

Můžete také vytvářet týmy (v GitHubu) nebo skupiny (v Azure DevOps), které představují sady uživatelů, kteří můžou mít udělená oprávnění společně. Tímto způsobem nemusíte oprávnění přiřazovat jednotlivě. Oprávnění uživatelů můžete snadno změnit tak, že je přidáte do týmu nebo skupiny a odeberete je.

Tip

Azure DevOps používá model oprávnění s nejnižšími oprávněními , který se liší od modelu, který Azure používá. V Azure DevOps odepřít oprávnění přepsání povolených oprávnění. To znamená, že pokud jste přiřazeni k více skupinám s různými sadami oprávnění, budete moct provádět jenom akce povolené všemi skupinami.

Ujistěte se, že rozumíte způsobu přiřazení oprávnění, zejména ke skupinám.

Ochrana důležitých větví kódu

Vaše kanály a automatizace by měly být založené na identifikaci konkrétních větví kódu, jako je hlavní. Kód na těchto určených větvích je obvykle důvěryhodný a může být nasazen do produkčních prostředí. Pomocí ovládacích prvků ověřte a zkontrolujte kód, který je ve vašich důležitých větvích.

Zvažte použití pravidel ochrany větví (na GitHubu) nebo zásad větví (v Azure Repos), abyste zabránili přímým potvrzením do důležitých větví kódu. Potom můžete vyžadovat, aby váš tým ke sloučení změn použil žádosti o přijetí změn. Můžete použít automatizované kontroly a ruční procesy kontroly a ověřit, zda jsou změny platné před jejich sloučením.

Testování a kontrola kódu

Ujistěte se, že váš tým rozumí vašim očekáváním při kontrole a testování veškerého kódu, včetně definic infrastruktury.

Definice kanálu jsou soubory YAML, takže představují formu kódu. Změny definic kanálu je potřeba zkontrolovat a vyhodnotit. Jinak může někdo omylem nebo zlými úmysly vytvořit krok kanálu, který nevrací přihlašovací údaje vašeho instančního objektu nebo provede nebezpečnou změnu vašeho majetku Azure.

Všechny změny definičních souborů kanálu je potřeba důkladně zkontrolovat. Zajistěte, aby všichni členové vašeho týmu pochopili, že kanály jsou vysoce privilegované a potřebují zvláštní pozornost.

Ochrana agentů a spouštěčů kanálů

Kanál běží na agentech (pro Azure Pipelines) nebo spouštěčích (pro GitHub Actions). Agenty a spouštěče si můžete představit jako virtuální počítače. Definice kanálu řídí tyto virtuální počítače spuštěním úloh a skriptů, které jste zadali.

Azure Pipelines i GitHub Actions poskytují hostované agenty a spouštěče, které Microsoft nebo GitHub konfiguruje a udržuje. Vlastník platformy nakonfiguruje počítače tak, aby vyhovovaly doporučeným postupům zabezpečení. Odpovědnost vlastníka platformy zahrnuje opravy ohrožení zabezpečení operačního systému.

Místo toho můžete pro agenty a spouštěče použít vlastní fyzické nebo virtuální počítače. Počítače tohoto typu se nazývají agenti a spouštěče v místním prostředí . Pokud používáte agenty a spouštěče v místním prostředí, zodpovídáte za to, že jsou počítače správně nakonfigurované a chráněné před hrozbami.

Agenti hostovaní Microsoftem a spouštěčé hostované na GitHubu jsou dočasné. Všechny soubory nebo změny konfigurace agenta nebo spouštěče se zničí při ukončení spuštění kanálu. Pokud agenta nebo spouštěče hostujete sami, pravděpodobně se stejný počítač použije pro několik samostatných kanálů nebo prostředí, včetně produkčních a neprodukčních prostředí. Předpokládejme, že někdo vytvoří definici kanálu, která upraví některé důležité soubory v operačním systému agenta a spustí kanál z žádosti o přijetí změn. Při příštím spuštění nasazení v produkčním prostředí může agent znovu použít. Nyní nemáte způsob, jak předpovědět, jaký dopad může mít poškozený soubor na vaše produkční prostředí.

Z těchto důvodů je vhodné používat agenty hostované Microsoftem a spouštěče hostované GitHubem, kdykoli je to možné. Pokud potřebujete používat spouštěče v místním prostředí, pečlivě vyhodnoťte rizika spojená s jejich konfigurací a použitím.

Posouzení komponent třetích stran, které běží v rámci vašeho kanálu

Pokud používáte rozšíření GitHub Actions poskytovaná komunitou nebo Rozšíření Azure DevOps, seznamte se s tím, kdo je vytvořil a co dělají. Komponenty kanálu třetích stran můžou mít přístup k přihlašovacím údajům vašeho instančního objektu, a proto k celému prostředí v Azure.

V Azure DevOps správce organizace obvykle schválí každé rozšíření, než bude možné ho použít. Pokud jste správcem vaší organizace, zvažte bezpečnostní riziko spojené s jednotlivými komponentami, které používáte. Zodpovídáte za ověření, že jsou důvěryhodné a bezpečné.

Kdykoli použijete akci nebo úlohu třetí strany, zadáte verzi. Zvažte určení přesné verze, kterou jste zkontrolovali. Povolení automatického používání novější verze kanálu může představovat riziko, že jste neprostudovali.

Ochrana instančních objektů kanálu

Kanály používají instanční objekty pro přístup k Azure a dalším službám. Je důležité chránit instanční objekty a zajistit, aby se jejich přihlašovací údaje nedají použít nevhodně. Zvažte použití více vrstev ochrany.

Nejprve můžete zvážit ochranu přihlašovacích údajů pro instanční objekty:

• Pokud je to možné, používejte spravované identity nebo identity úloh, abyste se vyhnuli celému ukládání přihlašovacích údajů. I když nemůžete používat spravované identity ani identity úloh se všemi kanály, je vhodné to udělat, když to jde.
• Naplánujte, jak budete pravidelně měnit nebo obměňovat přihlašovací údaje instančního objektu. Vaše organizace může mít například zásadu pro obměna přihlašovacích údajů každých 90 nebo 120 dnů. Zvažte, kdo bude zodpovědný za obměnu a jak budete aktualizovat všechna místa, kde se přihlašovací údaje používají.
• Zvažte určení tajného správce , jehož rolí je správa tajných kódů, klíčů a certifikátů, aby nebyly vystavené jiným částem organizace.

Dále se zamyslete nad oprávněními, která udělíte instančním objektům:

• Použijte zásady podmíněného přístupu Microsoft Entra na instanční objekty vašeho kanálu. Tyto zásady pomáhají identifikovat rizikové přihlášení a chování. Pokud se například instanční objekty kanálu vždy přihlašují z jedné geografické oblasti, může podmíněný přístup rozpoznat a zabránit přihlášení z neočekávaných umístění, což může znamenat, že došlo k ohrožení přihlašovacích údajů.
• Pečlivě zvažte oprávnění, která udělíte každému instančnímu objektu. Předpokládejme například, že máte instanční objekt, který používáte ke čtení konfigurace sdíleného prostředku. Zvažte, jestli k danému instančnímu objektu můžete udělit přístup jen čtenáře , protože instanční objekt nemusí dělat nic, co vyžaduje více oprávnění.
• Pro každé oprávnění, které přiřadíte instančnímu objektu, použijte minimální rozsah . Pokud například instanční objekt musí být nasazen pouze do jedné skupiny prostředků, využte přiřazení role této skupině prostředků místo k celému předplatnému.
• Pro každé prostředí používejte samostatné instanční objekty. To znamená, že i když dojde k ohrožení přihlašovacích údajů instančního objektu nebo když někdo získá přístup k jednomu prostředí, nebude mít přístup k jiným prostředím.

Ochrana připojení služeb a tajných kódů

Připojení služby (v Azure Pipelines) nebo tajný klíč (na GitHubu) obsahuje přihlašovací údaje pro instanční objekt, který kanál používá pro přístup k vašemu prostředí Azure. Je důležité chránit připojení služeb a tajné kódy a řídit, které kanály používají každé připojení služby a tajný klíč. Jinak můžete omylem povolit neprodukční prostředí, aby používalo instanční objekt, který má přístup k produkčním prostředkům.

Když v Azure DevOps vytvoříte připojení ke službě, můžete ho nakonfigurovat tak, aby vyžadovalo schválení předtím, než ho bude moct nový kanál nebo prostředí použít.

Azure DevOps také umožňuje přidružit kontroly ke konkrétním připojením služeb. Kontroly přidávají další vrstvu ochrany. Můžete například nakonfigurovat kontrolu připojení produkční služby, abyste ověřili, že se používá jenom u kódu z hlavní větve úložiště. Tato kontrola pomáhá zabránit nasazení neoprávněného kódu do produkčního prostředí.

Na GitHubu můžete nakonfigurovat tajné kódy specifické pro prostředí, aby při práci s tímto prostředím pracovní postup GitHub Actions poskytoval pouze hodnotu tajného kódu. Pomocí tajných kódů specifických pro prostředí a ovládacích prvků prostředí, jako jsou schválení, můžete snížit riziko, že se k nasazení do produkčního prostředí používá neprodukční nasazení. Identity úloh můžete použít také k tomu, abyste se vyhnuli používání přihlašovacích údajů v pracovních postupech GitHub Actions a eliminovali možnost, že se přihlašovací údaje můžou vystavit.

Použití funkcí zabezpečení GitHubu

GitHub poskytuje funkce zabezpečení, které byste měli vyhodnotit a použít. Patří k nim:

• Dependabot, který kontroluje závislosti zdrojového kódu na známé chyby zabezpečení.
• Kontrola tajných kódů, která identifikuje text v úložišti, který vypadá jako klíče nebo přihlašovací údaje. Je to špatný postup ukládání tajných kódů do úložiště. Pokud jste v úložišti upozorněni na tajný klíč, měli byste zvážit ohrožení hodnoty tajného kódu a pak ho odvolat nebo změnit.
• Auditování, abyste pochopili, kdo provedl změny v konfiguraci GitHubu.
• Přehled zabezpečení, který konsoliduje všechny výstrahy zabezpečení v úložištích vaší organizace.

Použití protokolů auditu Azure DevOps

Azure DevOps poskytuje protokoly auditu, které vám pomůžou pochopit, kdo provedl změny vašich kanálů, zásad větví, úložišť a dalších prostředků. Je vhodné povolit auditování a pravidelně kontrolovat protokoly auditu.

Ochrana úložiště a kanálu

Probrali jsme důležité ovládací prvky, které můžete použít pro vaše úložiště a kanál. Teď se podíváme na to, které ovládací prvky můžete použít k ochraně všech důležitých prvků, které jsme uvedli dříve v této lekci:

Element pro ochranu	Ovládací prvky, které se mají použít
Vaše organizace Azure DevOps nebo úložiště GitHub, včetně toho, kdo k němu má přístup a co může dělat.	Pro ověřování použijte ID Microsoft Entra. K přiřazení oprávnění použijte týmy a skupiny. Povolte protokolování auditu a pravidelně kontrolujte protokoly auditu.
Důležité větve ve vašem úložišti a to, co se musí stát, když chcete změnit kód v těchto větvích.	Použijte pravidla ochrany větví nebo zásady větví.
Kód uvnitř úložiště, včetně definic infrastruktury, testů a kódu aplikace.	Vynucujte požadavky na kontrolu kódu. Přidání automatizovaných nebo ručních testů Na GitHubu použijte Dependabot a kontrolu tajných kódů.
Definice kanálu.	Vynucujte požadavky na kontrolu kódu.
Agenti nebo spouštěčé, kteří spouští váš kanál.	V Azure Pipelines použijte agenty hostované Microsoftem. V GitHub Actions použijte spouštěče hostované na GitHubu.
Všechny úlohy nebo komponenty třetích stran, které se můžou spouštět v rámci vašeho kanálu.	Zkontrolujte bezpečnostní riziko spojené se všemi rozšířeními a úlohami třetích stran.
Instanční objekty, které váš kanál používá pro přístup k Azure.	Používejte identity úloh v GitHub Actions. Pro Azure Pipelines používejte instanční objekty a pravidelně obměňujte přihlašovací údaje. Pro každé prostředí používejte samostatné instanční objekty. Použijte zásady podmíněného přístupu.
Tajné kódy, které váš kanál používá pro přístup k externím systémům.	V Azure DevOps použijte schválení a kontroly připojení služeb. Na GitHubu použijte tajné kódy specifické pro prostředí a identity úloh.