Metody ověřování podporované službou Azure OpenAI
Azure OpenAI podporuje několik metod ověřování, které zajišťují zabezpečený a řízený přístup k prostředkům. Primární metody jsou:
- Klíče rozhraní API: Azure OpenAI podporuje také ověřování založené na klíčích rozhraní API. Klíče rozhraní API se generují na webu Azure Portal a dají se použít k ověřování požadavků ve službě Azure OpenAI. Tato metoda ověřování se nedoporučuje z hlediska zabezpečení a měla by se používat jenom jako poslední možnost. Pokud je nutné použít tuto metodu ověřování, je důležité bezpečně zpracovávat klíče rozhraní API a pravidelně je otáčet, aby se snížilo riziko neoprávněného přístupu.
- Microsoft Entra ID: Tato metoda využívá robustní možnosti správy identit a přístupu společnosti Microsoft Entra. Uživatelé a aplikace se ověřují pomocí identit Microsoft Entra, což můžou být tradiční uživatelské účty nebo spravované identity. Tato metoda zajišťuje, že k prostředkům Azure OpenAI mají přístup jenom ověření a autorizovaní uživatelé.
- Spravované identity Entra: Spravované identity pro prostředky Azure poskytují automaticky spravovanou identitu v Microsoft Entra pro aplikace, které se mají použít při připojování k prostředkům, které podporují ověřování Microsoft Entra. Tyto identity můžou být přiřazené systémem, což znamená, že jsou svázané s konkrétním prostředkem Azure nebo přiřazeným uživatelem, což umožňuje sdílení jedné identity napříč několika prostředky. Spravované identity zjednodušují správu přihlašovacích údajů a zlepšují zabezpečení tím, že eliminují potřebu pevně zakódovaných přihlašovacích údajů v kódu aplikace.
Proč jsou spravované identity bezpečnější než klíče rozhraní API
Spravované identity v Microsoft Azure nabízejí bezpečnější alternativu ke klíčům rozhraní API z několika důvodů:
- Spravované identity eliminují potřebu vývojářů zpracovávat přihlašovací údaje přímo, což snižuje riziko náhodného vystavení nebo zneužití.
- Při použití klíčů rozhraní API musí vývojáři tyto klíče vložit do kódu aplikace nebo konfiguračních souborů.
Klíče rozhraní API je možné neúmyslně zpřístupnit prostřednictvím úložišť zdrojového kódu, protokolů nebo jiných prostředků. Tato expozice může vést k neoprávněnému přístupu a potenciálním narušením zabezpečení. Spravované identity naproti tomu poskytují automaticky spravovanou identitu pro aplikace, které se mají použít při připojování k prostředkům, které podporují ověřování Microsoft Entra (dříve Azure AD). To znamená, že přihlašovací údaje nejsou uložené v kódu aplikace, což snižuje riziko úniků a neoprávněného přístupu.
Spravované identity navíc zjednodušují proces ověřování tím, že službám Azure umožňují bezpečně ověřovat v jiných službách Azure bez nutnosti explicitních přihlašovacích údajů. Toho dosáhnete pomocí tokenů vydaných společností Microsoft Entra, které se automaticky spravují a obměňují a zajišťují, aby přihlašovací údaje byly vždy aktuální a snížily riziko krádeže přihlašovacích údajů. Klíče rozhraní API jsou na druhé straně statické a vyžadují ruční obměnu, což může být náchylné k chybám a často zanedbává, což vede k potenciálním ohrožením zabezpečení. Pomocí spravovaných identit můžou vývojáři využívat integrované funkce zabezpečení Azure, jako je řízení přístupu na základě role (RBAC), k udělení přesných oprávnění k prostředkům a dalšímu vylepšení zabezpečení.
Microsoft doporučuje používat spravovanou identitu přes klíče rozhraní API při ověřování v Azure OpenAI nebo jakékoli jiné službě Azure, která podporuje spravovanou identitu.
Rozdíly mezi používáním klíčů rozhraní API a spravovanými identitami v rámci Azure OpenAI
Pojďme vyhodnotit dopad nevraceného ID klienta a nevraceného klíče rozhraní API.
Klíč rozhraní API funguje podobně jako běžné heslo. Pokud dojde k ohrožení zabezpečení, může k prostředku přistupovat kdokoli, kdo má klíč. V případě Azure OpenAI to znamená neomezené použití modelů AI, jako je GPT-4. Pokud je síť veřejně přístupná, může být dopad na zabezpečení ještě větší.
Naopak pokud dojde k úniku ID klienta, rizika jsou minimální. Důvodem je to, že samotné ID klienta nemůže navázat připojení k Azure OpenAI. Aby bylo možné využívat spravovanou identitu, musí služba fungovat v Azure a i když je Azure OpenAI veřejná, nemůžete se připojit z místního prostředí nebo přes síť pomocí aplikace.
Stručně řečeno, v porovnání s důsledky nevraceného klíče rozhraní API zahrnuje zneužití nevraceného ID klienta několik kroků, což znesnadňuje zneužití škodlivých herců.
Z těchto důvodů nabízejí spravované identity bezpečnější metodu správy operací v porovnání s klíči rozhraní API. Při ověřování ve službě Azure OpenAI nebo jakékoli jiné službě Azure, která podporuje spravovanou identitu, se doporučuje v nejsilnějších možných termínech používat spravovanou identitu přes klíče rozhraní API.
Systémové a uživatelem přiřazené identity
Při vytváření aplikace Azure OpenAI je pro optimální zabezpečení a správu prostředků zásadní rozdíl mezi identitami přiřazenými systémem a identitami přiřazenými uživatelem.
- Identity přiřazené systémem se vytvářejí a spravují v Azure pro konkrétní prostředek. Když dojde k odstranění prostředku, odstraní se také přidružená identita přiřazená systémem a zajistí, že životní cyklus identity je úzce spojený s prostředkem, ke kterému patří. Tento typ identity je ideální pro scénáře, kdy se identita musí používat jenom u jednoho prostředku, což poskytuje jednoduchost a snižuje režijní náklady na správu, protože Azure spravuje přihlašovací údaje identity.
- Identity přiřazené uživatelem se vytvářejí nezávisle na jakémkoli konkrétním prostředku a dají se sdílet napříč několika prostředky. Díky tomu jsou vysoce všestranné pro aplikace, které vyžadují konzistentní identitu napříč různými prostředky, což usnadňuje správu oprávnění a řízení přístupu. Identity přiřazené uživatelem se uchovávají i po odstranění prostředků, které je používají, což umožňuje větší flexibilitu při opětovném nasazení a opětovném použití identit.
Volba mezi identitami přiřazenými systémem a uživatelem závisí na konkrétních potřebách vaší aplikace. U aplikací s jedním prostředkem, kde jednoduchost a minimální správa představují priority, jsou obvykle nejlepší volbou identity přiřazené systémem. Naopak u aplikací, které vyžadují sdílenou identitu napříč více prostředky, nabízejí identity přiřazené uživatelem větší flexibilitu a možnost opakovaného použití.
