Nyilvános ügyfél- és bizalmas ügyfélalkalmazások
A Microsoft Authentication Library (MSAL) kétféle ügyfelet határoz meg; nyilvános ügyfelek és bizalmas ügyfelek számára. Az ügyfél olyan szoftverentitással rendelkezik, amely egy identitásszolgáltató által hozzárendelt egyedi azonosítóval rendelkezik. Az ügyféltípusok megkülönböztethetők attól, hogy biztonságosan hitelesíthetők az engedélyezési kiszolgálóval, és bizalmas, identitást igazoló információkat tárolnak, hogy azok a hozzáférés hatókörén belül ne legyenek elérhetők vagy ismertek egy felhasználó számára.
| Nyilvános ügyfélalkalmazások | Bizalmas ügyfélalkalmazások |
|---|---|
 Asztali alkalmazás |
 Webalkalmazás |
 Böngésző nélküli API |
 Webes API |
 Mobilalkalmazás |
Szolgáltatás/démon |
Nyilvános ügyfél- és bizalmas ügyfél-engedélyezés
Egy adott ügyfél nyilvános vagy bizalmas jellegének vizsgálatakor kiértékeljük, hogy az ügyfél képes-e igazolni az identitását az engedélyezési kiszolgálón. Ez azért fontos, mert az engedélyezési kiszolgálónak képesnek kell lennie megbízni az ügyfél identitásában a hozzáférési jogkivonatok kiállításához.
A nyilvános ügyfélalkalmazások olyan eszközökön futnak, mint az asztali, böngésző nélküli API-k, mobil- vagy ügyféloldali böngészőalkalmazások. Nem megbízhatók az alkalmazás titkos kulcsainak biztonságos megőrzéséhez, mivel csak a felhasználó nevében férhetnek hozzá a webes API-khoz. Amikor egy adott alkalmazás forrás- vagy lefordított bájtkódja bárhol továbbítódik, amelyet nem megbízható felek olvashatnak, szétszerelhetnek vagy más módon megvizsgálhatnak, az nyilvános ügyfél. Mivel ők is csak a nyilvános ügyfélfolyamatokat támogatják, és nem képesek a konfigurációs idejű titkos kulcsok tárolására, nem rendelkezhetnek ügyféltitkokkal.
A bizalmas ügyfélalkalmazások kiszolgálókon futnak, például webalkalmazásokon, webes API-alkalmazásokon vagy szolgáltatás-/démonalkalmazásokon. A felhasználók és a támadók nehezen férnek hozzá, ezért megfelelően tárolhatják a konfigurációs idő titkos kulcsait, hogy igazolják személyazonosságukat. Az ügyfélazonosító a webböngészőn keresztül érhető el, de a titkos kód csak a háttércsatornában lesz átadva, és soha nem lesz közvetlenül közzétéve.
Titkos kódok és fontosságuk az identitás igazolásában
Az alábbiakban néhány példát mutatunk be arra, hogy az ügyfél hogyan tudja igazolni identitását az engedélyezési kiszolgálón:
- Felügyelt identitások az Azure-erőforrásokhoz – Csak alkalmazásalapú hitelesítési forgatókönyvek esetén az Azure-ra épülő alkalmazás- és szolgáltatásfejlesztőknek lehetőségük van arra, hogy a titkos kódok kezelését, rotálását és védelmét magukra a platformra használják. A felügyelt identitások esetében az identitásokat az Azure-erőforrások biztosítják és törlik, és senki, köztük a globális Rendszergazda istrator sem férhet hozzá az alapul szolgáló hitelesítő adatokhoz. Felügyelt identitások használatával megakadályozhatja a titkos kódok kiszivárgásának kockázatát, és lehetővé teheti, hogy a szolgáltató kezelje a biztonságot.
- Ügyfélazonosító és titkos kód – Ebben a mintában az engedélyezési kiszolgáló létrehoz egy értékpárt az ügyfél regisztrálásakor. Az ügyfélazonosító egy olyan nyilvános érték, amely azonosítja az alkalmazást, míg az ügyfél titkos kódja az alkalmazás személyazonosságának igazolására használt bizalmas érték.
- A tanúsítvány birtoklásának igazolása – A nyilvános kulcsú infrastruktúra (PKI), amely olyan szabványokat tartalmaz, mint az X.509, az alapvető technológia, amely lehetővé teszi az interneten keresztüli biztonságos kommunikációt, és az internetes adatvédelem gerincét képezi. A PKI-t olyan digitális tanúsítványok kiállítására használják, amelyek ellenőrzik az online kommunikációban részt vevő felek személyazonosságát, és az alapul szolgáló technológia, amely olyan protokollokat működtet, mint a HTTPS, amelyet széles körben használnak a webes forgalom védelmére. A tanúsítványok hasonlóképpen használhatók a szolgáltatásközi (S2S) kommunikáció védelmére az Azure-ban a szolgáltatások közötti kölcsönös hitelesítés engedélyezésével. Ez magában foglalja, hogy minden szolgáltatás egy tanúsítványt nyújt be a másiknak, mint a személyazonosság igazolására alkalmas eszközt.
- Aláírt állítás bemutatása – A számítási feladatok identitás-összevonásában használt aláírt állítások lehetővé teszik egy megbízható külső identitásszolgáltatói jogkivonat cseréjét a Microsoft Identitásplatform a Microsoft Entra által védett erőforrások meghívásához szükséges hozzáférési jogkivonatok beszerzéséhez. A számítási feladatok identitásának összevonásával különböző összevonási forgatókönyveket engedélyezhet, például az Azure Kubernetes Service-t, az Amazon Web Services EKS-t, a GitHub Actionst stb.
Mikor számít az ügyfélidentitás igazolása?
Az ügyfélidentitás igazolása akkor számít, ha az ügyfélalkalmazás hitelességét és hitelesítését is ellenőrizni kell, mielőtt hozzáférést biztosítana bizalmas adatokhoz vagy erőforrásokhoz. Néhány példa:
- API-hozzáférés szabályozása – Ha rendelkezik forgalmi díjas API-val (például számlázáshoz), vagy bizalmas adatokat vagy erőforrásokat tesz elérhetővé, a hozzáférés megadása előtt ellenőriznie kell az ügyfél identitását. Ez például akkor fontos, ha biztosítja, hogy csak az engedélyezett alkalmazások férhessenek hozzá az API-hoz, és hogy a megfelelő ügyfélnek kell fizetnie a forgalmi díjas API-használatért.
- A felhasználók védelme az alkalmazások megszemélyesítésével szemben – Ha rendelkezik egy szolgáltatással üzembe helyezett, felhasználó által használt alkalmazással (például egy háttéralapú webalkalmazással), amely bizalmas adatokhoz vagy szolgáltatásokhoz fér hozzá, az alkalmazás által használt erőforrások védelme érdekében az ügyfél titkos kulcsainak használatával megakadályozhatja, hogy a rossz szereplők megszemélyesítsenek egy megbízható ügyfelet az adathalász felhasználók számára, és kiszűrjék az adatokat vagy a visszaélésekhez való hozzáférést.
- S2S-kommunikáció – Ha több háttérszolgáltatással (például alsóbb rétegbeli API-kkal) kell kommunikálnia egymással, ellenőrizheti az egyes szolgáltatások identitását, hogy csak a funkciójuk elvégzéséhez szükséges erőforrásokhoz férhessenek hozzá.
Általánosságban elmondható, hogy az ügyfélidentitás igazolása akkor számít, ha hitelesítésre és engedélyezésre van szükség egy felhasználótól független vagy azon felüli ügyfél számára.
Bizalmas ügyfelek: ajánlott eljárások titkos kódok kezeléséhez
Felügyelt identitások használata az üzembe helyezés és a biztonság egyszerűsítése érdekében – A felügyelt identitások automatikusan felügyelt identitást biztosítanak a Microsoft Entra-azonosítóban az alkalmazások számára, amelyeket a Microsoft Entra-hitelesítést támogató erőforrásokhoz való csatlakozáskor használhatnak. Az alkalmazások felügyelt identitásokkal szerezhetnek be csak Microsoft Entra-azonosítójú jogkivonatokat hitelesítő adatok kezelése nélkül. Ez eltávolíthatja a titkos kódok kezelésével kapcsolatos számos összetettséget, miközben növeli a biztonságot és a rugalmasságot. Felügyelt identitások használata esetén a legtöbb esetben, ha nem minden ajánlott eljárásról van már gondoskodni.
Biztonságos tárolás használata – Az ügyfél titkos kulcsokat biztonságos helyen, például Key Vaultban vagy titkosított konfigurációs fájlban tárolhatja. Kerülje az ügyfél titkos kulcsainak egyszerű szövegben vagy beadott fájlokként való tárolását a verziókövetési rendszerekben.
Hozzáférés korlátozása – Az ügyfél titkos kulcsaihoz való hozzáférés korlátozása csak az arra jogosult személyek számára. Szerepköralapú hozzáférés-vezérléssel az ügyfél titkos kulcsokhoz való hozzáférését csak azok számára korlátozhatja, akiknek szükségük van rá a működési feladataik elvégzéséhez.
Ügyféltitkok elforgatása – Az ügyfél titkos kulcsainak szükség szerinti vagy ütemezett elforgatása minimalizálhatja annak kockázatát, hogy a titkos kulcsok illetéktelen hozzáféréshez jussanak. Alkalmazás esetén a kulcs használatának időtartamát a használt titkosítási algoritmus erőssége és/vagy a szabványok vagy a jogszabályi megfelelőségi eljárások betartása befolyásolja.
Használjon hosszú titkos kulcsokat és erős titkosítást – Az előző ponthoz szorosan kapcsolódó, erős titkosítási algoritmusok használata az átvitel közbeni (a vezetéken) és a inaktív (lemezen) adatokhoz, segít biztosítani, hogy a nagy entrópia titkos kulcsok ne legyenek találgatásosak. Az olyan algoritmusok, mint az AES-128 (vagy újabb) segíthetnek az inaktív adatok védelmében, míg az RSA-2048 (vagy újabb) hatékonyan védheti az átvitt adatokat. A kiberbiztonság folyamatosan változó jellege miatt mindig ajánlott a biztonsági szakértőkkel konzultálni, és rendszeresen áttekinteni az algoritmusok kiválasztását.
Kerülje a titkos kódok korlátozását – Ne kódolja az ügyfél titkos kódját a forráskódban. Ha elkerüli a titkos kulcsokat a forráskódban, minimalizálhatja a forráskódhoz hozzáférő rossz szereplők értékét. Azt is megakadályozhatja, hogy az ilyen titkos kulcsokat véletlenül leküldje a nem biztonságos adattárakba, vagy elérhetővé teheti a projekt közreműködői számára, akik forráseléréssel rendelkezhetnek, de titkos hozzáféréssel nem.
A kiszivárgott titkos kódok tárházainak monitorozása – Sajnálatos tény, hogy a forráskód kezelésekor hibás bejelentkezések történnek. A Git előzetes véglegesítési horgai a véletlen bejelentkezések megelőzésének javasolt módjai, de nem helyettesítik a monitorozást is. Az adattárak automatikus monitorozása azonosíthatja a kiszivárgott titkos kulcsokat, és a feltört hitelesítő adatok elforgatására szolgáló tervvel csökkentheti a biztonsági incidenseket.
Gyanús tevékenységek figyelése – Naplók és naplók figyelése az ügyfél titkos kulcsokkal kapcsolatos gyanús tevékenységek esetén. Ahol lehetséges, automatizált riasztások és válaszfolyamatok használatával értesítheti a személyzetet, és meghatározhatja az ügyfél titkos kulcsaival kapcsolatos szokatlan tevékenységekkel kapcsolatos vészhelyzeteket.
Az alkalmazásokat ügyféltitkosságot szem előtt tartva építheti ki – A biztonsági modell csak olyan erős, mint a lánc leggyengébb láncszeme. Ne továbbítsa a biztonsági hitelesítő adatokat vagy jogkivonatokat bizalmas ügyfelekről nyilvános ügyfelekre, mivel ez az ügyfél titkos adatait áthelyezheti egy nyilvános ügyfélbe, lehetővé téve a bizalmas ügyfél megszemélyesítését.
Megbízható forrásokból származó naprakész kódtárak és SDK-k használata – A Microsoft Identitásplatform különböző ügyfél- és kiszolgálóoldali SDK-kat és köztes szoftvereket biztosít, amelyek célja, hogy növelje a hatékonyságot, miközben az alkalmazásokat biztonságban tartja. Az olyan kódtárak, mint a Microsoft.Identity.Web, leegyszerűsítik a hitelesítés és engedélyezés hozzáadását a webalkalmazásokhoz és API-khoz a Microsoft Identitásplatform. A függőségek naprakészen tartása biztosítja, hogy az alkalmazások és szolgáltatások kihasználhassák a legújabb biztonsági újításokat és frissítéseket.
Az ügyféltípusok és képességeik összehasonlítása
Az alábbiakban néhány hasonlóság és különbség van a nyilvános és a bizalmas ügyfélalkalmazások között:
- Mindkét alkalmazástípus fenntart egy felhasználói jogkivonat-gyorsítótárat, és csendesen beszerezhet egy jogkivonatot (ha a jogkivonat megtalálható a gyorsítótárban). A bizalmas ügyfélalkalmazások emellett alkalmazásjogkivonat-gyorsítótárral is rendelkeznek az alkalmazás által beszerzett jogkivonatokhoz.
- Mindkét alkalmazástípus kezelheti a felhasználói fiókokat, és lekérhet egy fiókot a felhasználói jogkivonat gyorsítótárából, lekérhet egy fiókot az azonosítójából, vagy eltávolíthat egy fiókot.
- Az MSAL-ben a nyilvános ügyfélalkalmazások négyféleképpen szerezhetnek be jogkivonatot külön hitelesítési folyamatokon keresztül. A bizalmas ügyfélalkalmazások csak háromféleképpen szerezhetnek be jogkivonatot, és az egyik módszer az identitásszolgáltató által engedélyezett végpont URL-címének kiszámítására. Az ügyfélazonosító az alkalmazás létrehozásakor egyszer lesz átadva, és nem kell újból átadni, amikor az alkalmazás jogkivonatot szerez be. További információ: jogkivonatok beszerzése.
A nyilvános ügyfelek hasznosak a felhasználók által delegált hozzáférés engedélyezéséhez a védett erőforrásokhoz, de nem tudják bizonyítani saját alkalmazásaik identitását. A bizalmas ügyfelek viszont a felhasználó- és alkalmazáshitelesítést és az engedélyezést is elvégezhetik, és a biztonságot szem előtt tartva kell kialakítani, hogy titkos adataik ne legyenek megosztva nyilvános ügyfelekkel vagy más harmadik felekkel.
Bizonyos esetekben, például az S2S-kommunikáció, az infrastruktúra, például a felügyelt identitások nagyban megkönnyítik a szolgáltatások fejlesztését és üzembe helyezését, és eltávolítják a titkos kódok kezelésével általában járó összetettség nagy részét. Ha a felügyelt identitások nem használhatók, fontos, hogy szabályzatok, megelőző intézkedések és vészhelyzetek legyenek érvényben a titkos kódok védelmére és a hozzájuk kapcsolódó biztonsági incidensekre való reagálásra.
Lásd még
További információ az alkalmazáskonfigurációról és a példányosításról: