Az Azure OpenAI által támogatott hitelesítési módszerek
Az Azure OpenAI számos hitelesítési módszert támogat az erőforrásokhoz való biztonságos és szabályozott hozzáférés biztosítása érdekében. Az elsődleges módszerek a következők:
- API-kulcsok: Az Azure OpenAI az API-kulcsalapú hitelesítést is támogatja. Az API-kulcsok az Azure Portalon jönnek létre, és az Azure OpenAI szolgáltatás felé irányuló kérések hitelesítésére használhatók. Ez a hitelesítési módszer biztonsági szempontból nem ajánlott, és csak végső megoldásként használható. Ha ezt a hitelesítési módszert kell használnia, fontos az API-kulcsok biztonságos kezelése és rendszeres elforgatása a jogosulatlan hozzáférés kockázatának csökkentése érdekében.
- Microsoft Entra-azonosító: Ez a módszer a Microsoft Entra robusztus identitás- és hozzáférés-kezelési képességeit használja. A felhasználók és alkalmazások Microsoft Entra-identitásokkal hitelesítik magukat, amelyek lehetnek hagyományos felhasználói fiókok vagy felügyelt identitások. Ez a módszer biztosítja, hogy csak hitelesített és jogosult felhasználók férhessenek hozzá az Azure OpenAI-erőforrásokhoz.
- Entrafelügyelt identitások: Az Azure-erőforrások felügyelt identitásai automatikusan felügyelt identitást biztosítanak a Microsoft Entra-ban az alkalmazások számára a Microsoft Entra-hitelesítést támogató erőforrásokhoz való csatlakozáshoz. Ezek az identitások rendszerhez rendelhetők, ami azt jelenti, hogy egy adott Azure-erőforráshoz vagy felhasználóhoz vannak rendelve, így egyetlen identitás több erőforrás között is megosztható. A felügyelt identitások leegyszerűsítik a hitelesítő adatok kezelését, és növelik a biztonságot azáltal, hogy szükségtelenné teszik a szigorúan kódolt hitelesítő adatok használatát az alkalmazáskódban.
Miért biztonságosabbak a felügyelt identitások, mint az API-kulcsok?
A Microsoft Azure felügyelt identitásai több okból is biztonságosabb alternatívát kínálnak az API-kulcsok helyett:
- A felügyelt identitások nem igénylik, hogy a fejlesztők közvetlenül kezeljék a hitelesítő adatokat, ezáltal csökkentve a véletlen kitettség vagy a visszaélés kockázatát.
- API-kulcsok használata esetén a fejlesztőknek ezeket a kulcsokat az alkalmazáskódjukba vagy konfigurációs fájljaikba kell beágyazniuk.
Az API-kulcsok véletlenül elérhetővé válnak forráskódtárakon, naplókon vagy más eszközökön keresztül. Ez az expozíció jogosulatlan hozzáféréshez és potenciális biztonsági incidensekhez vezethet. Ezzel szemben a felügyelt identitások automatikusan felügyelt identitást biztosítanak az alkalmazások számára a Microsoft Entra (korábban Azure AD) hitelesítést támogató erőforrásokhoz való csatlakozáskor. Ez azt jelenti, hogy a hitelesítő adatokat nem az alkalmazáskód tárolja, így csökken a szivárgások és a jogosulatlan hozzáférés kockázata.
A felügyelt identitások emellett leegyszerűsítik a hitelesítési folyamatot azáltal, hogy lehetővé teszik az Azure-szolgáltatások számára, hogy biztonságosan hitelesítsék magukat más Azure-szolgáltatásokban anélkül, hogy explicit hitelesítő adatokra van szükségük. Ez a Microsoft Entra által kibocsátott, automatikusan felügyelt és elforgatott jogkivonatok használatával érhető el, biztosítva, hogy a hitelesítő adatok mindig naprakészek legyenek, és csökkenjen a hitelesítő adatok ellopásának kockázata. Az API-kulcsok viszont statikusak, és manuális forgást igényelnek, ami hibalehetőséget jelenthet, és gyakran elhanyagolható, ami potenciális biztonsági réseket eredményezhet. A felügyelt identitások használatával a fejlesztők kihasználhatják az Azure beépített biztonsági funkcióit, például a szerepköralapú hozzáférés-vezérlést (RBAC) az erőforrások pontos engedélyeinek biztosításához, a biztonság további növeléséhez.
A Microsoft azt javasolja, hogy a felügyelt identitást API-kulcsokon keresztül használja az Azure OpenAI-ba vagy bármely más, a felügyelt identitást támogató Azure-szolgáltatásba való hitelesítéskor.
Különbségek az API-kulcsok és a felügyelt identitások használata között az Azure OpenAI-ban
Értékeljük ki a kiszivárgott ügyfélazonosító és a kiszivárgott API-kulcs hatását.
Az API-kulcsok a normál jelszóhoz hasonlóan működnek. Ha sérült, bárki hozzáférhet az erőforráshoz, aki rendelkezik a kulccsal. Az Azure OpenAI esetében ez az AI-modellek, például a GPT-4 korlátlan használatát jelenti. Ha a hálózat nyilvánosan elérhető, a biztonsági hatás még nagyobb lehet.
Ezzel szemben, ha az ügyfélazonosító kiszivárog, a kockázatok minimálisak. Ennek az az oka, hogy az ügyfélazonosító önmagában nem tud kapcsolatot létesíteni az Azure OpenAI-hoz. A felügyelt identitás használatához a szolgáltatásnak az Azure-ban kell üzemelnie, és még ha az Azure OpenAI nyilvános is, nem tud helyi környezetből vagy hálózaton keresztül csatlakozni egy alkalmazással.
Összefoglalva, a kiszivárgott API-kulcsok következményeihez képest a kiszivárgott ügyfél-azonosítók kihasználása több lépésből áll, ami megnehezíti a rosszindulatú szereplők kihasználását.
Ezen okok miatt a felügyelt identitások biztonságosabb módszert kínálnak a műveletek kezelésére az API-kulcsokhoz képest. Javasoljuk, hogy a lehető legerősebb feltételekkel használja a felügyelt identitást API-kulcsokkal az Azure OpenAI-ba vagy bármely más, a felügyelt identitást támogató Azure-szolgáltatásba való hitelesítéskor.
Rendszer és felhasználó által hozzárendelt identitások
Az Azure OpenAI-alkalmazások létrehozásakor a rendszer által hozzárendelt és a felhasználó által hozzárendelt identitások közötti különbség megértése kulcsfontosságú az optimális biztonság és erőforrás-kezelés szempontjából.
- A rendszer által hozzárendelt identitásokat az Azure hozza létre és felügyeli egy adott erőforráshoz. Egy erőforrás törlésekor a társított rendszer által hozzárendelt identitás is törlődik, biztosítva, hogy az identitás életciklusa szorosan össze legyen állítva azzal az erőforrással, amelyhez tartozik. Ez az identitástípus ideális olyan helyzetekben, amikor az identitást csak egyetlen erőforrásnak kell használnia, ami egyszerűséget biztosít, és csökkenti az adminisztrációs többletterhelést, mivel az Azure kezeli az identitás hitelesítő adatait.
- A felhasználó által hozzárendelt identitások minden adott erőforrástól függetlenül jönnek létre, és több erőforrás között oszthatók meg. Ez rendkívül sokoldalúvá teszi azokat az alkalmazásokat, amelyek konzisztens identitást igényelnek a különböző erőforrások között, így egyszerűbben kezelhetők az engedélyek és a hozzáférés-vezérlések. A felhasználó által hozzárendelt identitások az őket használó erőforrások törlése után is megmaradnak, így nagyobb rugalmasságot biztosítanak az identitások újbóli üzembe helyezése és újrafelhasználása terén.
A rendszer által hozzárendelt és a felhasználó által hozzárendelt identitások közötti választás az alkalmazás adott igényeitől függ. Az egy erőforrásból álló alkalmazások esetében, ahol az egyszerűség és a minimális felügyelet a prioritás, általában a rendszer által hozzárendelt identitások a legjobb választás. Ezzel szemben az olyan alkalmazások esetében, amelyek több erőforráson keresztül közös identitást igényelnek, a felhasználó által hozzárendelt identitások nagyobb rugalmasságot és újrafelhasználhatóságot biztosítanak.
