Vytvořit služební objekt a klíč
Teď, když rozumíte konceptu principálu služby, může vás zajímat, jak prokáže svou identitu v Microsoft Entra ID. V této jednotce se dozvíte o procesu ověřování a přihlašovacích údajích pro služební identity. Dozvíte se také, jak vytvořit služební účet a přiřadit mu klíč.
Porozumět tomu, jak jsou služební principály ověřovány
Když aplikační objekt potřebuje komunikovat s Azure, přihlásí se do Microsoft Entra ID. Poté co Microsoft Entra ID ověří identitu služebního principála, vydá token , který klientská aplikace ukládá a používá při provádění jakýchkoliv požadavků na Azure.
Obecně řečeno, tento proces je podobný tomu, jak to funguje, když se přihlásíte k Azure sami jako uživatel. Ve srovnání s uživateli ale instanční objekty mají trochu jiný typ přihlašovacích údajů, aby se prokázala jejich identita. Instanční objekty používají dvě hlavní přihlašovací údaje: klíče a certifikáty.
Poznámka
Mějte na paměti, že spravované identity jsou speciální služební identity, které fungují v Azure. Mají jiný typ procesu ověřování, který nevyžaduje, abyste znali nebo zpracovávali přihlašovací údaje vůbec.
Klíče
Klíče jsou podobné heslům. Klíče jsou ale mnohem delší a složitější. Ve většině situací vygeneruje ID Microsoft Entra klíče, aby se zajistilo, že:
- Klíče jsou kryptograficky náhodné. To znamená, že je velmi těžké odhadnout.
- Lidé nechtěně nepoužívají slabá hesla jako klíče.
Přihlašovací údaje služby často mají vysoce privilegovaná oprávnění, takže je nezbytné, aby byly zabezpečené. Klíč je obvykle potřeba zpracovat jen krátce při první konfiguraci služebního účtu a vašeho potrubí. Klíč proto nemusí být zapamatovatelný ani snadné napsat.
Jeden služba principal může mít současně více klíčů, ale uživatelé nemohou mít více hesel. Podobně jako hesla mají klíče datum vypršení platnosti. Brzy se o tom dozvíte víc.
Poznámka
Klíče si můžete představit jako velmi důležitá hesla, podobně jako klíče účtu úložiště. Měli byste s nimi zacházet se stejnou úrovní zabezpečení a péče.
Certifikáty
Certifikáty jsou dalším způsobem ověřování služebních principálů. Jsou velmi zabezpečené, ale může být obtížné spravovat. Některé organizace vyžadují použití certifikátů pro určité typy služebních principálů.
V tomto modulu nebudeme probírat certifikáty. Pokud ale pracujete s instančním objektem, který používá ověřování certifikátů, funguje v podstatě stejně jako jakýkoli jiný instanční objekt, pokud jde o jeho správu a udělení oprávnění pro váš kanál.
Poznámka
Certifikáty jsou dobrou volbou, když je můžete použít. Útočníkům je těžší ukrást. Je také obtížnější zachycovat a upravovat požadavky, které používají certifikáty. Certifikáty však vyžadují větší infrastrukturu a mají určité průběžné režijní náklady na údržbu.
Práce s klíči pro instanční objekty
Při vytváření principálu služby obvykle požádáte Azure o vytvoření klíče současně. Azure obvykle vygeneruje náhodný klíč za vás.
Poznámka
Vzpomínáte si na naši dřívější diskuzi o tom, jak fungují služební vlastníci? Klíče se ukládají jako součást objektu registrace aplikace. Pokud otevřete Azure Portal, podívejte se do konfigurace Microsoft Entra a pak přejděte k registracím aplikací, můžete tam také vytvořit a odstranit klíče.
Azure vám při vytváření služebního principála ukáže klíč. To je jediný čas, kdy vám Azure ukáže klíč. Potom už ho nemůžete získat zpět. Je důležité, abyste klíč bezpečně zkopírovali, abyste ho mohli použít při konfiguraci kanálu. Nesdílejte klíč e-mailem ani jiným nezabezpečením způsobem. Pokud klíč ztratíte, musíte ho odstranit a vytvořit nový.
Správa služebních identit pro Azure Pipelines
Když vytvoříte klíč pro instanční objekt kanálu, je vhodné klíč okamžitě zkopírovat do konfigurace kanálu. Tímto způsobem se vyhnete zbytečnému ukládání nebo přenosu klíče.
Pipeline nástroje zahrnují zabezpečené způsoby určení ID aplikace a klíče služby principal. Nikdy neukládejte přihlašovací údaje jakéhokoli druhu ve správě zdrojového kódu. Místo toho při práci se službou Azure Pipelines používejte připojení služby . V tomto modulu diskutujeme, jak vytvořit službu principal a klíč. V pozdějším modulu se dozvíte, jak nakonfigurovat kanál s klíčem.
Spropitné
Azure Pipelines může automaticky vytvářet služební identity. V tomto modulu manuálně vytvoříte a budete spravovat služební identity, abyste lépe porozuměli probíhajícím procesům. V jiných modulech použijete metodu automatického vytváření pro zjednodušení.
Vytvoření služby principal a jejího klíče
Pomocí Azure CLI můžete vytvářet a spravovat služební principály.
Poznámka
Vytváření a úprava služebních identit vyžaduje, abyste měli související oprávnění v Microsoft Entra ID. V některých organizacích může být potřeba, aby správce provedl tyto kroky za vás.
K vytvoření služebního principálu a klíče použijte příkaz az ad sp create-for-rbac. Tento příkaz přijímá několik argumentů a volitelně může k instančnímu objektu přiřadit role. O tomto tématu se dozvíte později v tomto modulu. Zatím tady je příklad, který ukazuje, jak vytvořit objekt hlavní služby bez jakéhokoliv přiřazení rolí Azure:
az ad sp create-for-rbac --name MyPipeline
Když spustíte tento příkaz, Azure CLI vrátí odpověď JSON s vlastností password. Tato vlastnost je klíčem hlavního služby. Tento klíč už nemůžete získat, proto ho nezapomeňte okamžitě použít nebo ho bezpečně uložit.
Poznámka
Příkaz az ad sp create-for-rbac vytvoří registraci aplikace v Microsoft Entra ID, přidá službový objekt do vašeho tenanta Microsoft Entra a vytvoří klíč pro registraci aplikace. Jiný příkaz, az ad sp create, vytvoří pouze instanční objekt ve vašem tenantovi (nikoli registraci aplikace). Při vytváření servisních účtů pro kanály je obvykle nejvhodnějším příkazem az ad sp create-for-rbac.
K vytváření a správě služebních principálů můžete použít cmdlety Azure PowerShell.
Poznámka
Vytváření a úpravy služebních objektů vyžaduje, abyste měli související oprávnění v Microsoft Entra ID. V některých organizacích může být potřeba, aby správce provedl tyto kroky za vás.
K vytvoření hlavního objektu služby a klíče použijte rutinu New-AzADServicePrincipal. Tento cmdlet přijímá několik argumentů a může volitelně přiřadit role servisnímu principálu. O tomto tématu se dozvíte později v tomto modulu. Tady je příklad, který ukazuje, jak vytvořit instanční objekt bez přiřazení rolí Azure:
$servicePrincipal = New-AzADServicePrincipal -DisplayName MyPipeline
Když spustíte tento příkaz, Azure PowerShell naplní proměnnou servicePrincipal informacemi o instančním objektu, včetně klíče:
$servicePrincipalKey = $servicePrincipal.PasswordCredentials.SecretText
Tento klíč už nemůžete získat, proto ho nezapomeňte okamžitě použít nebo ho uložit někam bezpečně.
Poznámka
Cmdlet New-AzADServicePrincipal vytvoří registraci aplikace v Microsoft Entra ID, přidá service principal do vašeho tenanta Microsoft Entra a vytvoří klíč pro registraci aplikace.
Identifikujte službu principal
Služební principály mají několik identifikátorů a názvů, které používáte k jejich identifikaci a práci s nimi. Identifikátory, které používáte nejvíce, jsou:
- ID aplikace: Registrace aplikace má jedinečný identifikátor, který se často označuje jako ID aplikace nebo někdy ID klienta. Obvykle ho používáte jako uživatelské jméno při přihlášení služebního principála do Azure.
- ID objektu: Registrace aplikace a instanční objekt mají vlastní samostatná ID objektů, což jsou jedinečné identifikátory přiřazené Microsoft Entra ID. V některých případech budete muset při správě služebního objektu použít tato ID objektů.
- zobrazovaný název: Jedná se o snadno čitelný název, který popisuje hlavní službu.
Spropitné
Pro službu principalu použijte jasný a popisný název pro zobrazení. Je důležité pomoci týmu pochopit účel služebního zástupce, aby ho nikdo omylem neodstranil nebo nezměnil jeho oprávnění.
Opatrnost
Zobrazovaný název není jedinečný. Stejný zobrazovaný název může sdílet několik služebních identit. Při udělování oprávnění instančnímu objektu pomocí jeho zobrazovaného názvu buďte opatrní při jeho identifikaci. Omylem můžete udělit oprávnění nesprávnému služebnímu principálu. Místo toho je vhodné použít ID aplikace.
Při vytváření hlavního účtu služby obvykle nastavíte pouze zobrazovaný název. Azure automaticky přiřadí ostatní názvy a identifikátory.
Zpracování klíčů s vypršenou platností
Služební účty nevyprší, ale jejich klíče ano. Když vytvoříte klíč, můžete nakonfigurovat jeho čas vypršení platnosti. Ve výchozím nastavení je doba vypršení platnosti nastavená na jeden rok. Po uplynutí této doby vypršení platnosti klíč přestane fungovat a pipeline se nemůže přihlásit k Microsoft Entra ID. Klíče musíte pravidelně obnovovat nebo obměňovat.
Opatrnost
Může být lákavé nastavit dlouhou dobu vypršení platnosti klíčů, ale neměli byste to udělat. Služební principály jsou chráněny pouze jejich přihlašovacími údaji. Pokud útočník získá klíč služebního principála, může způsobit značné škody. Nejlepším přístupem k minimalizaci doby, po kterou může útok trvat, je pravidelné změny klíčů. Klíče byste také měli odstranit a znovu vytvořit, pokud máte podezření, že došlo k úniku.
Pokud chcete resetovat klíč aplikačního objektu, použijte příkaz az ad sp s ID aplikace, jako v tomto příkladu:
az ad sp credential reset --id "b585b740-942d-44e9-9126-f1181c95d497"
Klíč instančního objektu služby můžete také odebrat a znovu vytvořit ve dvou samostatných krocích pomocí příkazu az ad sp credential delete a následně příkazu az ad sp credential reset --append.
Pokud chcete resetovat klíč služebního hlavního objektu, nejprve pomocí rutiny Remove-AzADServicePrincipalCredential odeberte existující přihlašovací údaje. Potom pomocí rutiny New-AzADServicePrincipalCredential přidejte nové přihlašovací údaje. Obě tyto rutiny používají ID objektu hlavního objektu služby k identifikaci služby. Před použitím rutin potřebujete získat toto ID z ID aplikace:
$applicationId = APPLICATION_ID
$servicePrincipalObjectId = (Get-AzADServicePrincipal -ApplicationId $applicationId).Id
Remove-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newCredential = New-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newKey = $newCredential.SecretText
Spropitné
Jeden služební principál může mít více klíčů. Aplikaci můžete bezpečně aktualizovat tak, aby používala nový klíč, zatímco starý klíč je stále platný, a potom starý klíč odstranit, když už se nepoužívá. Tato technika zabraňuje výpadkům z vypršení platnosti klíče.
Správa životního cyklu objektu služby principal
Je důležité zvážit celý životní cyklus každého koncového uživatele služby, kterého vytvoříte. Když vytvoříte instanční objekt pro kanál, co se stane, když se kanál nakonec odstraní nebo se už nepoužívá?
Principály služeb se neodebírají automaticky, proto je třeba provést audit a odebrat staré. Je důležité odebrat staré instanční objekty ze stejného důvodu, proč odstraňujete staré uživatelské účty: útočníci můžou získat přístup ke svým klíčům. Nejlepší není mít přihlašovací údaje, které se aktivně nepoužívají.
Je vhodné zdokumentovat objekty služeb na místě, kde k nim máte vy a váš tým snadný přístup. Pro každý služební hlavní objekt byste měli zahrnout následující informace:
- Základní identifikační informace, včetně názvu a ID aplikace.
- Účel služebního účtu.
- Kdo ho vytvořil, kdo je zodpovědný za správu a jeho klíče a kdo by mohl mít odpovědi, pokud dojde k problému.
- Oprávnění, která potřebuje, a jasné odůvodnění, proč je potřebuje.
- Jaká je očekávaná životnost.
Pravidelně byste měli auditovat principály služby, abyste měli jistotu, že se stále používají a že jejich přiřazená oprávnění jsou stále správná.