Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Tento článek vám jako vývojář pomůže zabezpečit vývojové prostředí, abyste mohli implementovat principy nulové důvěryhodnosti (ověřte explicitně použití přístupu s nejnižšími oprávněními, předpokládejme porušení zabezpečení). Obsahuje obsah z našeho eBooku Zabezpečení prostředí Enterprise DevOps a zdůrazňuje osvědčené postupy pro zabezpečení větví a důvěru k nástrojům, rozšířením a integracím.
Rychlost vývojářů závisí na vaší schopnosti pracovat na tom, jak a kde chcete maximalizovat obchodní výsledky. Chcete výkonné, přizpůsobitelné počítače s přístupem uživatele root nebo správce. Požadavky vývojářů však můžou být v rozporu s předpisy o dodržování a potřebou auditovat a řídit přístup k soukromému zaměstnaneckému prostředí a úložištím.
Nespravované počítače, které se připojují k síti organizace, představují výzvu pro bezpečnostní týmy, oddělení zadávání zakázek a radu pro správu. V nejlepším případě poskytování vývojářům výchozího a posíleného prostředí zaměstnanců vyvolává pohrdání na obou stranách. Když se zaměstnanci připojí odkudkoli, ohrožené Wi-Fi sítě jsou otevřenými dveřmi pro kybernetický útok. Krádež hardwaru a ztráta jsou zásadními obavami.
Ohrožení zabezpečení se rozšiřují o integrace vývojového prostředí. Vývojové nástroje, které mají bohatou rozšiřitelnost, můžou mít na svých trzích neudržované integrace. Škodlivá rozšíření můžou ohrozit vývojářské nástroje a způsobit narušení celé společnosti.
V následujícím diagramu si všimněte, jak se vývojářské prostředí připojuje k prostředí nástrojů DevOps, aby ovlivnilo větve Gitu. Rozšiřuje plochu prostředí prostřednictvím připojení k opensourcovým balíčkům a rozšířením aplikací. Rozšíření představují slabiny v zabezpečení, a to jak v závislostech, tak i v samotných rozšířeních aplikací.
Zajištění flexibility a řízení členů týmu DevOps při prevenci škodlivých útoků je zásadní výzvou pro bezpečnostní kanceláře. DevOps může řídit vývojářské prostředí pomocí cloudového prostředí (viz Důvěryhodná spuštění pro virtuální počítače Azure a dokumentace ke cloudu GitHub Enterprise) a zabezpečit vývojové prostředí pomocí kontejnerů (viz dokumentace ke Službě GitHub Codespaces).
Vývojáři navíc můžou implementovat následující míry nulové důvěryhodnosti, které pomáhají zabezpečit vývojářské prostředí:
- Nakonfigurujte nejnižší oprávnění.
- Omezte, kdo může měnit a schvalovat kód pomocí zabezpečení větve.
- Přijměte pouze důvěryhodné nástroje, rozšíření a integrace.
Osvědčené postupy pro nejnižší oprávnění
Vývojáři se často domnívají, že můžou ve svých prostředích zachytit malware, phishing a porušení zabezpečení. Díky hrozbám pro velké vývojářské prostředí je pro vývojáře nereálné udržovat všudypřítomné systémové znalosti. Organizace ztratí drahocenný čas na nápravu, pokud zjistí narušení po útoku, který ohrozí vývojářské prostředí, jež má administrátorský přístup ke všem systémům.
Pokud chcete napravit potenciální přístupové příležitosti, které způsobují, že by se špatní aktéři mohli zaměřit na roli vývojáře softwaru, zvažte následující osvědčené postupy zabezpečení s minimálními oprávněními nulové důvěry (Zero Trust) pro aplikace.
- Implementujte nejnižší oprávnění a přístup za běhu pro DevOps. Ujistěte se, že členové týmu udržují pouze minimální přístup k prostředím na nejkratší požadovanou dobu. Umístěte zásady tak, aby zahrnovaly přístupová práva správce na hlavních zařízeních, nástrojích DevOps, kanálech verzí, úložištích kódu, prostředích, úložištích tajných kódů a databázích. Pro týmy DevOps je základním požadavkem připojení k úložišti identit organizace. Federování identit použijte k integraci s prostředími SaaS, abyste se vyhnuli duplikaci identit na platformách jiných společností než Microsoft a snížili riziko ohrožení.
- Nepoužívejte osobní přístupové tokeny pro přístup ke zdrojovému kódu. Mezi zabezpečené postupy pro týmy DevOps patří přístup k nástrojům DevOps založeným na SaaS, úložištím kódu (přes SSH, HTTPS nebo osobní přístupový token). V případě přístupu k prostředí založenému na SaaS máte jasné pokyny, jak zásady přístupu určují, kdo může stahovat (klonovat) úložiště kódu a ze kterých zařízení (místní, cloud a kontejner). OneDrive může například blokovat nebo omezit nespravovaný přístup k zařízením.
- Standardizace a synchronizace uživatelských účtů spravovaného uživatele GitHub Enterprise (EMU) s podnikovými identitami Pomocí podnikových spravovaných uživatelů můžete řídit uživatelské účty vašich podnikových členů prostřednictvím zprostředkovatele identity (IDP). V úložišti identit vaší organizace explicitně definujte uživatelská jména, e-maily a zobrazované názvy GitHubu. Uživatelé pak snadno identifikují spolupracovníky.
- Pro tři způsoby, jak se vývojář může připojit k prostředí SaaS (HTTPS s identitou, osobním přístupovým tokenem, připojením pomocí klíče SSH), vytvořit připojení k úložišti identit organizace. S GitHubem (s výjimkou účtů GitHub EMU) je vaše identita vždy vaší veřejnou identitou. Řízený přístup přes jednotné přihlašování (SSO) vyžaduje připojení k úložišti identit organizace.
- Pomocí certifikační autority SSH (CA) můžete členům poskytnout podepsané certifikáty SSH, aby mohli bezpečně přistupovat k prostředkům pomocí Gitu. Certifikát SSH je mechanismus pro jeden klíč SSH, který podepíše jiný klíč SSH. GitHub Enterprise Cloud podporuje certifikáty SSH, které organizacím poskytují větší kontrolu nad tím, jak členové přistupují k úložištím. Správci můžou nahrát svůj veřejný klíč certifikační autority SSH a vydávat certifikáty, které můžou členové používat k ověřování Gitu. Certifikáty mají přístup pouze k úložištím, která patří do organizace. Správci můžou vyžadovat, aby členové při přístupu ke svým úložištím používali certifikáty.
- Pomocí správce přihlašovacích údajů Gitu můžete posílit přístup k vašemu kódu. Nástroje, jako je Visual Studio (VS), mají integrovanou podporu identit. VS Code spoléhá na Git správce přihlašovacích údajů.
Osvědčené postupy pro zabezpečení větví
Když zlý aktéři získají přístup k úložišti kódu, můžou studovat zabezpečení systému a upravovat kód bez toho, aby si týmy hlídaly. Pokud chcete zabránit neoprávněnému přístupu k úložišti kódu, implementujte strategii větvení pro vytvoření kontroly nad změnami kódu (viz příklad znázorněný v následujícím diagramu).
Pokud chcete napravit potenciální příležitosti pro přístup k úložišti, zvažte následující osvědčené postupy zabezpečení větví.
- Chraňte větve pomocí kontrol kódu, abyste týmům DevOps poskytli kontrolu nad změnami kódu a pokroky v auditování. Strategie větvení v předchozím diagramu vyjadřuje řízený tok změn, který poskytuje jasný řetězec příkazů a podrobný plán pro adresování změn kódu. Z různých přístupů k strategii větvení je jedna společná věc, že chráněné větve slouží jako zdroj pro nové vydání do produkce.
- Nechte správce úložišť Git řídit autorizace schválení. Řídicí mechanismus strategií větvení je v pracovním postupu schvalování. Chráněné větve před přijetím změn vyžadují ověření, revize a schválení. Jednou z možností je vytvořit pravidlo ochrany branch, aby se vynucovaly pracovní postupy. Například pro všechny pull requesty sloučené do chráněné větve je vyžadováno schválení nebo kontrola stavu. Zásady větví pomáhají týmům chránit důležité větve vývoje. Zásady prosazují standardy kvality kódu a řízení změn vašeho týmu.
Osvědčené postupy pro důvěryhodné nástroje, rozšíření a integrace
Rozšiřitelnost v integrovaných vývojových prostředích (IDE) je tak produktivní, že je to v podstatě povinná funkce. Při návrhu optimálního pracovního prostředí spoléháte na možnost použití a kurátorování rozšíření na marketplace konkrétního integrovaného vývojového prostředí( IDE).
Při nápravě zabezpečených IDE zvažte následující osvědčené postupy pro nástroje, rozšíření a integraci.
- Ujistěte se, že integrujete pouze nástroje z důvěryhodných marketplace i vydavatelů. Například marketplace VS Code má tisíce rozšíření, která vám usnadní život. Pokud ale vaše týmy přijmou nové nástroje nebo rozšíření, nejdůležitější aspekt může být ověření důvěryhodnosti vydavatele.
- Nastavte zabezpečené postupy pro řízení použití rozšíření, abyste omezili prostor pro útoky vývojářských prostředí. Většina rozšíření IDE vyžaduje schválení určitých oprávnění k fungování, často jako soubor s oprávněními ke čtení v systému k analýze kódu. Rozšíření vyžadují připojení ke cloudovým prostředím, aby fungovala (běžné v nástrojích metrik). Schválení dalších funkcí nad integrovaném vývojovém prostředí (IDE) otevírá organizacím další hrozby.
- Na vývojářských počítačích sledujte počet a vyspělost použitých rozšíření, abyste porozuměli potenciálnímu prostoru pro útoky. Začleňujte pouze rozšíření marketplace VS Code od ověřených vydavatelů. Při instalaci rozšíření aplikací pomocí nástroje VS Code pravidelně kontrolujte rozšíření, která spouštíte pomocí příkazového řádku, kódu
--list-extensions --show-versions. Dobře porozumněte rozšiřitelným komponentám, které používáte ve svém vývojářském prostředí.
Další kroky
- Vložení zabezpečení nulové důvěry (Zero Trust) do pracovního postupu vývojáře vám pomůže rychle a bezpečně inovovat.
- Zabezpečení prostředí platformy DevOps pomáhá implementovat principy nulové důvěryhodnosti ve vašem prostředí platformy DevOps a zdůrazňuje osvědčené postupy pro správu tajných kódů a certifikátů.
- Zabezpečení prostředí DevOps pro nulovou důvěru popisuje osvědčené postupy pro zabezpečení prostředí DevOps pomocí přístupu nulové důvěryhodnosti, který brání škodlivým hercům v ohrožení vývojářských polí, infikování kanálů verzí se škodlivými skripty a získání přístupu k produkčním datům prostřednictvím testovacích prostředí.
- Urychlete a zabezpečte kód pomocí Azure DevOps pomocí nástrojů, které vývojářům poskytují nejrychlejší a nejbezpečnější kód pro cloudové prostředí.
- Nakonfigurujte Azure tak, aby důvěřovala OIDC GitHubu jako federovaná identita. OpenID Connect (OIDC) umožňuje pracovním postupům GitHub Actions přistupovat k prostředkům v Azure, aniž by bylo nutné ukládat přihlašovací údaje Azure jako dlouhodobé tajné kódy GitHubu.