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 zpracování informací a dat, zejména v cloudovém řešení, jako je Azure DevOps Services, by mělo být zabezpečení vaší nejvyšší prioritou. I když Microsoft zajišťuje zabezpečení základní cloudové infrastruktury, konfigurace zabezpečení v Rámci Azure DevOps je vaší zodpovědností.

I když to není povinné, začlenění osvědčených postupů může výrazně zlepšit vaše prostředí a posílit zabezpečení. Následující doporučení jsou navržená tak, aby vám pomohla udržovat zabezpečené prostředí Azure DevOps.

Zabezpečení prostředí Azure DevOps

Při odebírání uživatelů, kontrole událostí auditu a integraci s ID Microsoft Entra použijte následující osvědčené postupy.

Odebrání uživatelů

  • Odebrání neaktivních uživatelů z účtů Microsoft (MSA):Pokud používáte účty MSA, odeberte přímo neaktivní uživatele z vaší organizace . Nemůžete vytvářet dotazy na pracovní položky přiřazené k odebraným účtům MSA.
  • Zakažte nebo odstraňte uživatelské účty Microsoft Entra: Pokud jste připojení k ID Microsoft Entra, zakažte nebo odstraňte uživatelský účet Microsoft Entra a přitom ponechte uživatelský účet Azure DevOps aktivní. Tato akce umožňuje pokračovat v dotazování historie pracovních položek pomocí ID uživatele Azure DevOps.
  • Odvolání patů uživatelů: Pravidelně kontrolujte a odvolejte všechny stávající paty uživatelů, abyste zajistili zabezpečenou správu těchto důležitých ověřovacích tokenů.
  • Odvolání zvláštních oprávnění udělených jednotlivým uživatelům: Auditujte a odvolejte všechna zvláštní oprávnění udělená jednotlivým uživatelům, abyste zajistili soulad se zásadou nejnižších oprávnění.
  • Změna přiřazení práce odebraných uživatelů: Před odebráním uživatelů znovu přiřaďte pracovní položky aktuálním členům týmu, aby zatížení efektivně distribuovali.

Použití ID Microsoft Entra

  • Vytvoření sjednoceného systému identit: Připojte Azure DevOps k ID Microsoft Entra a vytvořte jednu rovinu identity. Tato konzistence snižuje nejasnosti a minimalizuje rizika zabezpečení z chyb ruční konfigurace.
  • Implementujte jemně odstupňované zásady správného řízení: Pomocí ID Microsoft Entra přiřaďte různé role a oprávnění konkrétním skupinám napříč různými obory prostředků. Tato akce zajišťuje řízený přístup a odpovídá osvědčeným postupům zabezpečení.
  • Vylepšení funkcí zabezpečení: Povolte další funkce zabezpečení pomocí MICROSOFT Entra ID, například:
    • Vícefaktorové ověřování (MFA): Vyžaduje více faktorů, jako je ověření hesla a telefonu pro ověřování uživatelů. Zásady podmíněného přístupu: Definujte pravidla přístupu na základě podmínek, jako je umístění, zařízení nebo úroveň rizika.

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

Kontrola událostí auditování

Pokud je vaše organizace připojená k Microsoft Entra, proveďte následující úlohy, které vylepšují vzorce zabezpečení a monitorování využití:

Zabezpečení vaší sítě

Následující funkce představují efektivní způsoby, jak zvýšit zabezpečení sítě při práci s Azure DevOps.

  • Nastavení seznamu povolených IP adres: Omezte přístup na konkrétní IP adresy a povolte provoz jenom z důvěryhodných zdrojů, což snižuje prostor pro útoky.
  • Používejte šifrování: Vždy šifrovat přenášená data a neaktivní uložená data. Zabezpečené komunikační kanály pomocí protokolů, jako je HTTPS.
  • Ověření certifikátů: Ujistěte se, že při vytváření připojení jsou certifikáty platné a vydané důvěryhodnými autoritou.
  • Implementace firewallů webových aplikací (WAF): Filtrování, monitorování a blokování škodlivého webového provozu pomocí WAF pro další vrstvu ochrany před běžnými útoky.

Další informace najdete v tématu Osvědčené postupy správy aplikací.

Oprávnění oboru

Systém zpracovává 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. Pokud chcete zvýšit zabezpečení, proveďte následující akce:

  • Poskytnutí přístupu s nejnižšími oprávněními: Udělte uživatelům a službám minimální potřebný přístup k provádění svých obchodních funkcí.
  • Zakázat dědičnost: Kdykoli je to možné, zakažte dědičnost. Dědičnost může neúmyslně udělit přístup nebo oprávnění neočekávaným uživatelům kvůli výchozí povaze povolení. Další informace najdete v části o dědičnosti oprávnění.

Další informace o oprávněních najdete v následujících článcích:

Oprávnění na úrovni projektu

  • Omezit přístup k projektům a úložištím: Snižte riziko úniku citlivých informací a nasazení nezabezpečeného kódu omezením přístupu k projektům a úložištím. Použijte předdefinované nebo vlastní skupiny zabezpečení spravujte oprávnění.
  • Zakažte možnost Povolit veřejné projekty: V nastavení zásad vaší organizace zakažte možnost vytvářet veřejné projekty. Podle potřeby přepněte viditelnost projektu z veřejného na privátní. Uživatelé, kteří se nepřihlásili, mají přístup jen pro čtení k veřejným projektům, zatímco přihlášeným uživatelům je možné udělit přístup k soukromým projektům a provádět povolené změny.
  • Omezit vytváření projektu: Zabrání uživatelům v vytváření nových projektů, aby zachovali kontrolu nad vaším prostředím.

Externí přístup hosta

  • Blokovat přístup externího hosta: Zakažte zásadu Povolit odesílání pozvánek do jakékoli domény, abyste zabránili externímu přístupu hosta, pokud pro něj není potřeba žádný podnik.
  • Používejte odlišné e-maily nebo hlavní názvy uživatelů( UPN): K odstranění nejednoznačnosti mezi osobními a pracovními účty používejte různé e-mailové adresy nebo hlavní názvy uživatelů (UPN).
  • Seskupit externí uživatele typu host: Všechny externí uživatele typu host umístěte do jedné skupiny Microsoft Entra a odpovídajícím způsobem spravujte oprávnění pro tuto skupinu. Odeberte přímá přiřazení, abyste zajistili, že pravidla skupiny budou platit pro tyto uživatele.
  • Pravidelně vyhodnotujte pravidla: Pravidla pravidelně kontrolujte na kartě Pravidla skupiny na stránce Uživatelé. Zvažte všechny změny členství ve skupinách v ID Microsoft Entra, které by mohly ovlivnit vaši organizaci. Aktualizace dynamického členství ve skupinách může trvat až 24 hodin a pravidla se automaticky znovu zhodnotí každých 24 hodin a pokaždé, když se změní pravidlo skupiny.

Další informace naleznete v tématu B2B hosty v Microsoft Entra ID.

Správa skupin zabezpečení

Zabezpečení a skupiny uživatelů

Následující tabulka uvádí doporučení pro přiřazení oprávnění skupinám zabezpečení a skupinám uživatelů.

Dělat 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. Další informace najdete v tématu Platné skupiny uživatelů.
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 . Představte si například, že máte v projektu Azure DevOps dvě skupiny zabezpečení: vývojáři a testery. Skupina Vývojáři má oprávnění k úpravě pracovních položek nastavených na Povolit. Ale zajistěte, aby některé citlivé pracovní položky nikdo kromě několika klíčových jednotlivců neupravoval. Uděláte to tak, že vytvoříte novou skupinu zabezpečení s názvem Editory citlivých položek a nastavíte oprávnění k úpravě pracovních položek na Odepřít pro tuto skupinu. Pokud je uživatel členem skupiny Vývojáři i editory citlivých položek, má oprávnění Odepřít skupině Editory citlivých položek přednost před oprávněním Povolit ze skupiny Vývojáři . V důsledku toho nemůže tento uživatel upravovat citlivé pracovní položky, i když má oprávnění Povolit ve skupině Vývojáři . Toto chování zajišťuje, že se oprávnění odepřít vynucují výhradně a poskytují vyšší úroveň zabezpečení a kontrolu nad citlivými akcemi v rámci vašeho prostředí Azure DevOps.
Při přidávání mnoha týmů zvažte vytvoření vlastní skupiny Správci týmu, ve které přidělíte podmnožinu oprávnění dostupných správcům projektů. 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ávci se přiřadí ke skupině zabezpečení Správce projektu pro zvýšená oprávnění, což jim umožní konfigurovat oprávnění zabezpečení.

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

Pokud máte přístup správce kolekce projektů a správce projektu, můžete upravit konfiguraci organizace nebo projektu. Pokud chcete zvýšit zabezpečení těchto předdefinovaných skupin správců, zvažte implementaci přístupu za běhu pomocí skupiny Microsoft Entra Privileged Identity Management (PIM). Tento přístup umožňuje udělit zvýšená oprávnění pouze v případě potřeby, což snižuje riziko spojené s trvalým přístupem.

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:

Pokud konfigurujete přístup za běhu pomocí skupiny Microsoft Entra Privileged Identity Management (PIM), ujistěte se, že každý uživatel se zvýšeným přístupem zachová standardní přístup k organizaci. Tímto způsobem si můžou zobrazit potřebné stránky a podle potřeby 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

  • Vytvoření účtů jednoúčelových služeb: Každá služba by měla mít svůj vyhrazený účet, aby se minimalizovalo riziko. Nepoužívejte běžné uživatelské účty jako účty služeb.
  • Postupujte podle konvencí pojmenování a dokumentace: Používejte jasné popisné názvy účtů služeb a zdokumentování jejich účelu a přidružených služeb.
  • Identifikace a zakázání nepoužívaných účtů služeb: Pravidelně kontrolujte a identifikujte účty, které se už nepoužívají. Před zvážením odstranění zakažte nepoužívané účty.
  • Omezit oprávnění: Omezte oprávnění účtu služby na minimum potřebnou. Vyhněte se interaktivním přihlašovacím právům pro účty služeb.
  • Pro čtenáře sestav použijte samostatné identity: Pokud používáte účty domén pro účty služeb, použijte pro čtenáře sestav jinou identitu, abyste izolovali oprávnění a zabránili zbytečnému přístupu.
  • Používejte místní účty pro instalace pracovní skupiny: Při instalaci komponent v pracovní skupině použijte místní účty pro uživatelské účty. V tomto scénáři se vyhněte účtům domény.
  • Využití připojení služeb: Připojení služeb používejte vždy, když je to možné, abyste se mohli bezpečně připojit ke službám bez předávání tajných proměnných přímo do sestavení. Omezte připojení na konkrétní případy použití.
  • Monitorování aktivity účtu služby: Implementujte auditování a vytvořte streamy auditu pro monitorování aktivity účtu služby.

Další informace najdete v tématu Typy připojení služby Common Service.

Rozsah připojení služby

  • Rozsah připojení služeb: Omezte přístup nastavením připojení služby Azure Resource Manager na konkrétní prostředky a skupiny. Vyhněte se udělení širokých práv přispěvatelů v celém předplatném Azure.
  • Použití federace identit úloh: Ověřování pomocí prostředků Azure pomocí OpenID Connect (OIDC) bez tajných kódů Vytvořte federaci identit úloh automaticky nebo ručně, pokud máte roli Vlastník pro vaše předplatné Azure, nepřipojujte se k prostředím Azure Stack nebo Azure US Government a všechny úlohy rozšíření Marketplace, které používáte.
  • Skupiny prostředků oboru: Zajistěte, aby skupiny prostředků obsahovaly pouze virtuální počítače nebo prostředky potřebné pro proces sestavení.
  • Vyhněte se klasickým připojením služeb: Zvolte moderní připojení služeb Azure Resource Manageru místo klasického připojení, která nemají možnosti rozsahu.
  • Používejte účty týmových služeb specifické pro účely: Ověřování připojení služeb pomocí účtů týmových služeb specifických pro účely pro zajištění zabezpečení a řízení.

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:

  • Použití instančních objektů: Představuje objekty zabezpečení v rámci aplikace Microsoft Entra. Definujte, co může aplikace v daném tenantovi dělat. Nastavení během registrace aplikace na webu Azure Portal Nakonfigurujte přístup k prostředkům Azure, včetně Azure DevOps. Užitečné pro aplikace, které potřebují konkrétní přístup a řízení.
  • Použití spravovaných identit: Podobá se instančnímu objektu aplikace. Zadejte identity pro prostředky Azure. Povolte službám podporujícím ověřování Microsoft Entra sdílení přihlašovacích údajů. Azure zpracovává správu a obměnu přihlašovacích údajů automaticky. Ideální pro bezproblémovou správu podrobností přihlašování.

Používejte paty střídmě

  • Určení rozsahu pat na konkrétní role: Přiřaďte pats pouze potřebná oprávnění pro konkrétní úlohy. Vyhněte se udělení globálního přístupu více organizacím nebo úložištím, abyste minimalizovali riziko náhodného zneužití.
  • Vyhněte se zápisu nebo správě oprávnění k sestavením a vydaným verzím: PaT by neměly mít oprávnění k zápisu ani správě oprávnění k sestavením, vydaným verzím nebo jiným důležitým prostředkům. Omezení těchto oprávnění pomáhá zabránit nezamýšleným akcím, které by mohly ovlivnit vaše kanály nebo nasazení.
  • Nastavte data vypršení platnosti a udržujte tajný klíč pats: Vždy nastavte datum vypršení platnosti pro paty. Pravidelně je kontrolujte a obnovujte podle potřeby. Zacházejte s paty jako s klíčovými hesly a udržujte je v tajnosti a vyhněte se veřejnému sdílení nebo pevnému kódování v kódu aplikace.
  • Vyhněte se pevně zakódování pat v kódu aplikace: Místo vkládání patů přímo do kódu používejte zabezpečené konfigurační soubory nebo proměnné prostředí k dynamickému ukládání a načítání PAT. dynamicky.
  • Auditování a odvolávání nepoužívaných patů pravidelně: Správci by měli pravidelně kontrolovat všechny paty pomocí rozhraní REST API. Odvolejte všechny paty, které už nepotřebujete nebo nesplňují doporučená kritéria.

Další informace najdete v tématu Správa patů pomocí zásad – pro správce a použití PAT.

Zabezpečení artefaktů Azure

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

Zabezpečení Azure Boards

Zabezpečení služby Azure Pipelines

Zásady

  • Vyžadovat externí kontrolory: Ujistěte se, že alespoň jeden kontrolor mimo původní žadatele vyžaduje důkladnou kontrolu. Schvalovatel sdílí spoluvlastnictví změn a odpovědnost za případné účinky.
  • Vyžadovat předání sestavení CI: Vytvořte směrný plán pro kvalitu kódu tím, že před sloučením žádosti o přijetí změn vyžaduje sestavení kontinuální integrace (CI). Kontroly CI zahrnují lintování kódu, testy jednotek a kontroly zabezpečení.
  • Zakázat samoschvalování: Zabrání původnímu žadateli o přijetí změn schválení vlastních změn, aby zajistil nestranný proces kontroly a zabránil konfliktům zájmů.
  • Zakázat dokončení žádosti o přijetí změn s hlasy "wait" nebo "reject" hlasy: Zabránit dokončení žádosti o přijetí změn, i když někteří revidující hlasují na čekání nebo odmítnutí, povzbuzovat řešení všech názorů před sloučením.
  • Resetovat hlasy revidujících o změnách: Resetujte hlasy revidujících, když se do žádosti o přijetí změn nasdílí nedávné změny, aby revidujícím znovu vyhodnotili aktualizovaný kód.
  • Uzamknout kanály verze: Omezte kanály verze na konkrétní větve (obvykle produkční nebo hlavní), abyste se vyhnuli náhodným nasazením z jiných větví.
  • Vynucení nastavených proměnných v době fronty: Povolte možnost Vynutit settable v době fronty pro proměnné kanálu, aby uživatelé nemohli přepisovat hodnoty proměnných během provádění kanálu.
  • Zakázat přepsání proměnných v editoru: U proměnných nastavených v editoru kanálů zakážete přepsání uživatelů za účelem zachování konzistence a zabránění nezamýšleným změnám.

Agenti

  • Udělte oprávnění střídmě: Omezte oprávnění na nejmenší potřebnou sadu účtů, abyste snížili prostor pro útoky.
  • Nakonfigurujte omezující brány firewall pro agenty: Nastavte brány firewall tak, aby byly co nejvíce omezující a zároveň umožňovaly agentům fungovat, vyvážit zabezpečení a použitelnost.
  • Pravidelně aktualizovat fondy agentů: Udržujte váš fond agentů aktuální tím, že pravidelně aktualizujete agenty, aby se zajistilo, že ohrožený kód není spuštěný, což snižuje riziko zneužití.
  • Pro produkční artefakty použijte samostatný fond agentů: Izolujte produkční artefakty pomocí jedinečného fondu agentů, což brání náhodnému nasazení z neprodukčních větví.
  • Segmentovat citlivé fondy: Vytvořte samostatné fondy pro citlivé a nesmyslné úlohy. Povolte přihlašovací údaje pouze v definicích sestavení přidružených k příslušnému fondu.

Definice

  • Použijte YAML pro definice kanálů: Definujte kanály pomocí YAML (Ještě jiný jazyk značek), abyste mohli lépe sledovat a dodržovat pokyny ke schválení a postupy správy verzí.
  • Omezit přístup k úpravám definic kanálů: Omezte přístup k úpravám definic kanálů na minimum potřebných účtů, abyste snížili riziko náhodných nebo neoprávněných změn.

Vstup

  • Zahrnout kontroly proměnných ve skriptech sestavení: Implementujte kontroly v rámci skriptů sestavení, abyste zmírnit potenciální útoky prostřednictvím injektáže příkazů prostřednictvím nastavených proměnných. Ověřte vstupní hodnoty a zabraňte nechtěným nebo škodlivým příkazům.
  • Omezte proměnné sestavení "settable at release time" (nastavitelné v době vydání): Minimalizujte počet proměnných sestavení nastavených v době vydání, abyste snížili prostor pro útoky a zjednodušili správu konfigurace.

Úlohy

  • Vyhněte se vzdáleným načítání prostředků: Kdykoli je to možné, vyhněte se načítání prostředků z externích adres URL během procesu sestavení. Pokud jsou potřeba vzdálené prostředky, použijte kontrolu verzí a hash k zajištění integrity.
  • Vyhněte se protokolování tajných kódů: Nikdy do protokolů sestavení nezaznamujte citlivé informace, jako jsou tajné kódy nebo přihlašovací údaje, abyste zabránili neúmyslnému vystavení a ohrožení zabezpečení.
  • Azure Key Vault používejte pro tajné kódy: Místo ukládání tajných kódů přímo do proměnných kanálu používejte Azure Key Vault ke správě a bezpečnému načítání tajných kódů.
  • Omezit spouštění sestavení na libovolných větvích nebo značkách: U kanálů kritických pro zabezpečení omezte spouštění buildů pro libovolnou větev nebo značku. Definujte konkrétní autorizované větve nebo značky, abyste zabránili náhodným nebo neoprávněným spuštěním.
  • Zakázat dědičnost oprávnění kanálu: Zděděná oprávnění můžou být příliš široká a nemusí přesně odrážet vaše potřeby. Zakažte dědičnost a nastavte oprávnění explicitně tak, aby odpovídala vašim požadavkům na zabezpečení.
  • Omezit rozsahy autorizace úloh: Vždy omezte rozsahy autorizace úloh na minimum potřebné. Jemně vylaďte oprávnění na základě konkrétních úloh prováděných jednotlivými úlohami.

Úložiště a větve

  • Vyžadovat minimální počet kontrolorů: Povolte zásadu, aby každá žádost o přijetí změn přijímala kontroly od alespoň dvou schvalovatelů a podporovala důkladnou kontrolu kódu a odpovědnost.
  • Konfigurace zásad zabezpečení specifických pro úložiště: Přizpůsobte zásady zabezpečení jednotlivým úložištím nebo větvím místo zásad pro celý projekt, abyste snížili riziko, vynucovali standardy správy změn a zvýšili kvalitu kódu.
  • Izolace produkčních tajných kódů v samostatném trezoru klíčů: Ukládejte produkční tajné kódy samostatně ve službě Azure Key Vault a omezte přístup k základu potřebného k udržení oddělení od neprodukčních sestavení.
  • Oddělení testovacích prostředí z produkčního prostředí: Vyhněte se kombinování testovacích prostředí s produkčním prostředím, abyste zajistili, že se přihlašovací údaje a tajné kódy nepoužívají v neprodukčních kontextech.
  • Zakázání forku: Zakázání forku pomáhá spravovat zabezpečení tím, že brání šíření forků, což usnadňuje sledování zabezpečení napříč všemi kopiemi.
  • Vyhněte se poskytování tajných kódů pro vytváření forků: Vyhněte se sdílení tajných kódů s forkem buildů, aby byly důvěrné a nebyly vystaveny forkům.
  • Zvažte ruční aktivaci sestavení forku: Ruční aktivace sestavení forků místo povolení automatických triggerů zajistit lepší kontrolu nad kontrolami zabezpečení.
  • Používejte agenty hostované Microsoftem pro sestavení forku: Používejte agenty hostované Microsoftem pro forkované buildy při jejich údržbě a zabezpečení.
  • Prohledat definice produkčního sestavení v úložištích Git: Pravidelně kontrolujte definice produkčního sestavení uložené v úložišti Git vašeho projektu pro všechny přihlašovací údaje nebo citlivé informace.
  • Konfigurace kontrol řízení větví pro produkční kontext: Nastavte kontroly řízení větví tak, aby omezovaly používání citlivých připojení (například prod-connection) na kanály spuštěné v kontextu produkční větve, aby se zajistila správná autorizace a zabránila náhodnému zneužití.

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

  • Místo patů používejte tok OAuth: Zakažte ověřování na základě PAT pro připojení ke službě GitHub a vyvolte tok OAuth pro lepší zabezpečení a integraci.
  • Vyhněte se identitám správce nebo vlastníka: Nikdy neověřujte připojení služeb GitHub pomocí identity, která je správcem nebo vlastníkem libovolného úložiště. Omezte oprávnění na potřebnou úroveň.
  • Vyhněte se úplným rozsahu patů GitHubu: Nepoužívejte k ověřování připojení služeb plně vymezený pat GitHubu. Používejte tokeny s minimálními požadovanými oprávněními.
  • Vyhněte se osobním účtům GitHubu jako připojení služeb: Nepoužívejte osobní účty GitHubu jako připojení služeb v Azure DevOps. Místo toho vytvořte vyhrazené účty služeb nebo použijte účty na úrovni organizace.