Sdílet prostřednictvím

Osvědčené postupy zabezpečení

  • Článek

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Při práci s informacemi a daty, zejména v cloudovém řešení, jako je Azure DevOps Services, by stanovení priority zabezpečení mělo být vždy vaším hlavním zájmem. I když Microsoft udržuje zabezpečení základní cloudové infrastruktury, je vaší zodpovědností nakonfigurovat zabezpečení v Azure DevOps.

I když to není povinné, začlenění osvědčených postupů při používání Azure DevOps může vylepšit vaše prostředí a zvýšit jeho zabezpečení. Následující osvědčené postupy se zaměřují na zabezpečení prostředí Azure DevOps:

Zabezpečení prostředí Azure DevOps

Odebrání uživatelů

  • Pokud vaše organizace používá účty MSA, odeberte neaktivní uživatele přímo z organizace, protože nemáte žádný jiný způsob, jak zabránit přístupu. Když to uděláte, nemůžete vytvořit dotaz na pracovní položky přiřazené k odebranému uživatelskému účtu. Další informace najdete v tématu Odstranění uživatelů z Azure DevOps.
  • Pokud je vaše organizace připojená k MICROSOFT Entra ID, můžete zakázat nebo odstranit uživatelský účet Microsoft Entra a ponechat svůj uživatelský účet Azure DevOps aktivní. Tímto způsobem můžete pokračovat v dotazování historie pracovních položek pomocí ID uživatele Azure DevOps.
  • Odvolat paty uživatelů.
  • Odvolat všechna zvláštní oprávnění udělená jednotlivým uživatelským účtům.
  • Znovu přiřaďte práci uživatelům, které odebíráte aktuálním členům týmu.

Použití ID Microsoft Entra

Integrujte Azure DevOps s Microsoft Entra ID, abyste měli jednu rovinu identity. Konzistence a jeden autoritativní zdroj zvyšuje přehlednost a snižuje rizika zabezpečení z lidských chyb a složitosti konfigurace. Klíčem k ukončení zásad správného řízení je mít více přiřazení rolí (s různými definicemi rolí a různými obory prostředků pro stejné skupiny Microsoft Entra). Bez MICROSOFT Entra ID zodpovídáte výhradně za řízení přístupu k organizaci.

Použití Microsoft Entra ID také umožňuje přístup k jiným funkcím zabezpečení, jako je vícefaktorové ověřování nebo jiné zásady podmíněného přístupu.

Další informace najdete v následujících článcích:

Kontrola událostí auditování

Jakmile máte organizaci podporovanou společností Microsoft Entra, můžete v zásadách zabezpečení zapnout auditování. Pravidelně kontrolujte události auditu, abyste mohli monitorovat neočekávané vzory použití správců a dalších uživatelů a reagovat na ně.

Zabezpečení vaší sítě

Několik způsobů, jak to udělat, může zahrnovat:

  • Nastavte seznam povolených pro omezení konkrétních IP adres.
  • Vždy používejte šifrování.
  • Ověřte certifikáty.
  • Implementujte firewally webových aplikací (WAF), aby mohly filtrovat, monitorovat a blokovat veškerý škodlivý webový provoz do a z Azure DevOps.
  • Další informace najdete v těchto doprovodných materiálech k osvědčeným postupům správy aplikací.

Oprávnění s vymezeným oborem

Systém spravuje oprávnění na různých úrovních – jednotlivé, kolekce, projekt a objekty – a ve výchozím nastavení je přiřadí k jedné nebo více předdefinovaných skupinám.

Oprávnění na úrovni projektu

  • Omezte přístup k projektům a úložišťm, abyste snížili riziko úniku citlivých informací a nasadí nezabezpečený kód do produkčního prostředí.
  • Ke správě oprávnění použijte předdefinované skupiny zabezpečení nebo vlastní skupiny zabezpečení. Další informace naleznete v tématu Udělení nebo omezení oprávnění k výběru úkolů.
  • V nastavení zásad vaší organizace zakažte možnost Povolit veřejné projekty , abyste zabránili všem uživatelům organizace v vytváření veřejného projektu. Azure DevOps Services umožňuje změnit viditelnost projektů z veřejného na privátní a naopak. Pokud se uživatelé nepřihlásili do vaší organizace, mají k vašim veřejným projektům přístup jen pro čtení. Pokud se uživatelé přihlásili, můžou jim být udělen přístup k soukromým projektům a provádět v nich jakékoli povolené změny.
  • Nepovolujte uživatelům vytvářet nové projekty.

Externí přístup hosta

  • Zablokujte přístup externího hosta úplně tak, že zakážete zásadu Povolit odesílání pozvánek do jakékoli domény. Je vhodné to udělat, pokud to není potřeba.
  • Pro osobní a firemní účty použijte jiný hlavní název uživatele (UPN), i když je povolený. Tato akce eliminuje výzvu nejednoznačnosti mezi vašimi obchodními a osobními účty, když je e-mail nebo hlavní název uživatele (UPN) stejný.
  • Umístěte všechny externí uživatele typu host do jedné skupiny Microsoft Entra a odpovídajícím způsobem spravujte oprávnění této skupiny. Tímto způsobem můžete snadno spravovat a auditovat.
    • Odeberte přímá přiřazení, aby pravidla skupiny platila pro tyto uživatele. Další informace najdete v tématu Přidání pravidla skupiny pro přiřazení úrovní přístupu.
    • Pravidla pravidelně vyhodnotujte na kartě Pravidla skupiny na stránce Uživatelé. Zpřehledněte, jestli změny členství ve skupině v ID Microsoft Entra můžou mít vliv na vaši organizaci. Aktualizace dynamického členství ve skupinách může trvat až 24 hodin. Každých 24 hodin a kdykoli se změní pravidlo skupiny, pravidla se automaticky znovu zhodnotí v systému.
  • Další informace naleznete v tématu B2B hosty v Microsoft Entra ID.

Správa skupin zabezpečení

Zabezpečení a skupiny uživatelů

Podívejte se na následující doporučení pro přiřazování oprávnění skupinám zabezpečení a skupinám uživatelů.

Do Ne
Skupiny zabezpečení Microsoft Entra, Active Directory nebo Windows používejte při správě velkého počtu uživatelů. Neměňte výchozí oprávnění pro skupinu Platné uživatele projektu. Tato skupina má přístup k informacím o projektu a zobrazit je.
Při přidávání týmů zvažte, jaká oprávnění chcete přiřadit členům týmu, kteří potřebují vytvářet a upravovat cesty oblastí, iterační cesty a dotazy. Nepřidávejte uživatele do více skupin zabezpečení, které obsahují různé úrovně oprávnění. V některých případech může úroveň oprávnění Odepřít přepsání úrovně oprávnění Povolit .
Když přidáváte mnoho týmů, zvažte vytvoření vlastní skupiny Team Správa istrators, ve které přidělíte podmnožinu oprávnění dostupných pro Project Správa istrátory. Neměňte výchozí přiřazení provedená ve skupinách Platné uživatele projektu. Pokud odeberete nebo nastavíte možnost Zobrazit informace na úrovni instance pro některou ze skupin Project Valid Users, nebudou mít žádní uživatelé ve skupině přístup k projektu, kolekci nebo nasazení, na které jste nastavili oprávnění.
Zvažte udělení oprávnění k udělení složek dotazů pracovních položek uživatelům nebo skupinám, kteří vyžadují možnost vytvářet a sdílet dotazy na pracovní položky pro projekt. Nepřiřazovat oprávnění, která jsou uvedena jako Přiřadit pouze účtům služeb uživatelským účtům .
Udržujte skupiny co nejmenší. Přístup by měl být omezený a skupiny by se měly často auditovat.
Využijte předdefinované role a výchozí nastavení přispěvatele pro vývojáře. Správa se přiřadí ke skupině zabezpečení Project Správa istrator pro zvýšená oprávnění, což jim umožní konfigurovat oprávnění zabezpečení.

Další informace najdete v tématu Platné skupiny uživatelů.

Přístup za běhu pro skupiny správců

Konfiguraci organizace nebo projektu můžete změnit, pokud máte přístup ke kolekci projektů Správa istrator a Project Správa istrator. Pokud chcete chránit přístup k těmto předdefinovaným skupinám správců, potřebujete přístup za běhu pomocí skupiny Microsoft Entra Privileged Identity Management (PIM).

Konfigurace přístupu

  1. Vytvořte skupinu s možností přiřazení role v ID Microsoft Entra.
  2. Přidejte skupinu Microsoft Entra do skupiny Azure DevOps.

Poznámka:

Ujistěte se, že každý uživatel se zvýšeným přístupem pomocí skupiny PIM má také standardní přístup k organizaci, aby mohl zobrazit stránku a aktualizovat svá oprávnění.

Použití přístupu

  1. Aktivujte přístup.
  2. Aktualizujte svá oprávnění v Azure DevOps.
  3. Proveďte akci vyžadující přístup správce.

Poznámka:

Uživatelé mají v Azure DevOps zvýšený přístup až 1 hodinu po deaktivaci přístupu ke skupině PIM.

Rozsah účtů služby

  • Ujistěte se, že účty služeb mají nulová interaktivní přihlašovací práva.
  • Omezte oprávnění účtu služby na minimální nezbytné minimum.
  • Pro účet čtenáře sestav použijte jinou identitu, pokud pro účty služeb používáte účty domény. Další informace najdete v tématu Účty služeb a závislosti.
  • Pokud instalujete komponentu v pracovní skupině, použijte místní účty pro uživatelské účty. Další informace najdete v tématu Požadavky na účet služby.
  • Pokud je to možné, použijte připojení služeb. Připojení služeb poskytují zabezpečený mechanismus pro připojení k seřazeným službám, aniž by bylo nutné předávat tajné proměnné sestavení přímo. – Omezte tato připojení na konkrétní místo, kde by se měly používat, a nic dalšího.
  • Monitorujte aktivitu účtu služby a vytvořte streamování auditu. Auditování umožňuje detekovat podezřelé přihlášení a aktivity a reagovat na ně.
  • Další informace najdete v tématu Typy připojení služby Common Service.

Rozsah připojení služby

  • Rozsah Azure Resource Manageru a dalších připojení služeb pouze k prostředkům a skupinám, ke kterým potřebují přístup. Připojení služeb by neměla mít široká práva přispěvatele pro celé předplatné Azure.
  • Pro připojení ke službě Azure Resource Manager (ARM) použijte federaci identit úloh. Federace identit úloh umožňuje vytvářet připojení služby bez tajných kódů v Azure Pipelines k Azure.
  • Neudělujte uživatelům obecná nebo široká práva přispěvatele k předplatnému Azure.
  • Nepoužívejte připojení služby Azure Classic, protože neexistuje způsob, jak oprávnění vymezit.
  • Ujistěte se, že skupina prostředků obsahuje jenom virtuální počítače nebo prostředky, ke kterým sestavení potřebuje přístup.
  • K ověření připojení služby použijte účet týmové služby pro konkrétní účel.
  • Další informace najdete v tématu Typy připojení služby Common Service.

Volba vhodné metody ověřování

Vyberte metody ověřování z následujících zdrojů:

Zvažte instanční objekty.

Prozkoumejte alternativy, jako jsou instanční objekty a spravované identity , které umožňují používat tokeny Microsoft Entra pro přístup k prostředkům Azure DevOps. Tyto tokeny mají v porovnání s paty méně rizika a obsahují výhody, jako je snadná správa přihlašovacích údajů.

Používejte paty střídmě

Pokud je to možné, doporučujeme vždy používat služby identit pro ověřování místo kryptografických klíčů, protože správa klíčů bezpečně pomocí kódu aplikace je náročná a může vést k chybám, jako je náhodné publikování citlivých přístupových klíčů do úložišť veřejného kódu, jako je GitHub. Pokud ale musíte používat tokeny PAT (Personal Access Tokens), zvažte následující pokyny:

  • PaTs by vždy měly být vymezeny na konkrétní role.

  • Pracovní stanice s privilegovaným přístupem by neměly poskytovat globální přístup k více organizacím.

  • Pracovní stanice s privilegovaným přístupem by neměly udělovat oprávnění k zápisu nebo správě oprávnění k sestavením nebo vydaným verzím.

  • PaT by měly mít datum vypršení platnosti a být tajné, protože jsou tak kritické jako hesla.

  • PaT by nikdy neměly být pevně zakódované v kódu aplikace, i když je to lákavé, aby se kód zjednodušil.

  • Správa istrátory by měly pravidelně auditovat všechny paty pomocí Rozhraní REST API a odvolávání všech, které nesplňují výše uvedená kritéria.

  • Udržujte své paty tajným kódem. Vaše tokeny jsou stejně důležité jako hesla.

  • Ukládejte tokeny na bezpečném místě.

  • Tokeny kódu v aplikacích nevytěžujte. Může být lákavé zjednodušit kód pro získání tokenu po dlouhou dobu a uložit ho do vaší aplikace, ale nedělat to.

  • Udělte tokenům datum vypršení platnosti.

  • Další informace najdete v následujících článcích:

Zabezpečení artefaktů Azure

  • Ujistěte se, že rozumíte rozdílu mezi informačními kanály, projektem a správci kolekcí projektů. Další informace najdete v tématu Konfigurace nastavení Azure Artifacts.
  • Další informace najdete v tématu Nastavení oprávnění informačního kanálu.

Zabezpečení Azure Boards

Zabezpečení služby Azure Pipelines

Zásady

  • Vyžadovat alespoň jednoho revidujícíma mimo původního žadatele. Schvalovatel sdílí spoluvlastnictví změn a měl by být stejně zodpovědný za případné dopady.
  • Vyžadovat předání sestavení CI. Tento požadavek je užitečný pro vytvoření základní kvality kódu prostřednictvím lintování kódu, testů jednotek a kontrol zabezpečení, jako jsou kontroly virů a přihlašovacích údajů.
  • Ujistěte se, že původní žadatel o přijetí změn nemůže změnu schválit.
  • Zakázání dokončení žádosti o přijetí změn (žádost o přijetí změn), i když někteří revidujícím hlasují, aby čekali nebo odmítli.
  • Resetujte hlasy revidujících kódu, když se nasdílí nedávné změny.
  • Zamkněte kanály verze tak, že je spustíte jenom na konkrétních produkčních větvích.
  • V nastavení kanálu vaší organizace povolte možnost Vynutit nastavení v době fronty pro proměnné.
  • Nepovolujte možnost "Umožnit uživatelům přepsat tuto hodnotu při spuštění tohoto kanálu" pro proměnné nastavené v editoru.

Agenti

  • Udělte oprávnění nejmenšímu možnému počtu účtů.
  • Mít nejvíce omezující bránu firewall, která ponechá vaše agenty použitelné.
  • Pravidelně aktualizujte fondy, aby se zajistilo, že flotila sestavení nespouštět ohrožený kód, který může zneužít škodlivý aktér.
  • Pro artefakty sestavení, které se odesílají nebo nasazují do produkčního prostředí, použijte samostatný fond agentů.
  • Segmentujte "citlivý" fond z nesmyslných fondů a povolte pouze použití přihlašovacích údajů v definicích sestavení, které jsou pro tento fond uzamčeny.

Definice

  • Správa definic kanálů pomocí YAML (ještě jiného jazyka značek) YAML je upřednostňovanou metodou správy definic kanálů, protože poskytuje sledovatelnost změn a může postupovat podle pokynů ke schválení.
  • Zabezpečte přístup pro úpravu definice kanálu k minimálnímu počtu účtů.

Vstup

  • Do skriptů sestavení zahrňte kontroly sanitity proměnných. Kontrola sanity může zmírnit útok prostřednictvím injektáže příkazů prostřednictvím nastavených proměnných.
  • Nastavte co nejméně proměnných sestavení na hodnotu Settable at release time (Nastavit v době vydání).

Úlohy

  • Vyhněte se vzdálenému načítání prostředků, ale v případě potřeby použijte kontrolu verzí a hodnot hash.
  • Neukládejte tajné kódy.
  • Neukládejte tajné kódy do proměnných kanálu. Použijte Azure Key Vault. Pravidelně kontrolujte kanály buildu, abyste měli jistotu, že tajné kódy nejsou uložené v proměnných kanálu buildu.
  • Nenechte uživatele spouštět buildy na libovolných větvích nebo značkách v kanálech kritických pro zabezpečení.
  • Zakažte dědičnost kanálu, protože zděděná oprávnění jsou široká a přesně neodráží vaše potřeby pro oprávnění.
  • Omezte rozsahy autorizace úloh ve všech případech.

Úložiště a větve

  • Nastavte zásadu "Vyžadovat minimální počet revidujících", aby každá žádost o přijetí změn byla zkontrolována alespoň dvěma schvalovateli.
  • Nakonfigurujte zásady zabezpečení specifické pro každé úložiště nebo větev, nikoli pro celou řadu projektů. Zásady zabezpečení snižují riziko, vynucují standardy správy změn a zlepšují kvalitu kódu vašeho týmu.
  • Ukládejte produkční tajné kódy do samostatné služby Key Vault a zajistěte, aby byl přístup udělen pouze na základě potřeby, aby se neprodukční sestavení oddělily.
  • Nekombinujte testovací prostředí s produkčním prostředím, včetně použití přihlašovacích údajů.
  • Zakažte fork. Čím více forků je, tím těžší je sledovat zabezpečení jednotlivých forků. Uživatel může také snadno vytvořit fork kopie úložiště do svého vlastního privátního účtu.
  • Nezadávejte tajné kódy pro sestavení forku.
  • Zvažte ruční aktivaci sestavení forku.
  • Používejte agenty hostované Microsoftem pro sestavení forku.
  • V případě Gitu zkontrolujte definice produkčního sestavení v úložišti Git projektu, aby je bylo možné vyhledat přihlašovací údaje.
  • Nakonfigurujte kontrolu ovládacího prvku větve tak, aby mohly používat prod-connectionpouze kanály spuštěné v kontextu production větve .
  • Další informace najdete v tématu Další aspekty zabezpečení.

Zabezpečení Azure Repos

Zabezpečení testovacích plánů Azure

Zabezpečení integrací GitHubu

  • Zakažte ověřování založené na tokenu PAT (Personal Access Token), aby se tok OAuth používal s připojením ke službě GitHub.
  • Nikdy neověřujte připojení služby GitHub jako identitu, která je správcem nebo vlastníkem jakéhokoli úložiště.
  • Nikdy nepoužívejte k ověřování připojení služby GitHub PAT (Personal Access Token) s úplným rozsahem.
  • Nepoužívejte osobní účet GitHubu jako připojení služby k Azure DevOps.