API-k hitelesítése és engedélyezése az Azure API Managementben
A KÖVETKEZŐRE VONATKOZIK: Minden API Management-szint
Ez a cikk bemutatja az API Management gazdag, rugalmas funkcióit, amelyek segítségével biztonságossá teheti a felhasználók hozzáférését a felügyelt API-khoz.
Az API-hitelesítés és -engedélyezés az API Management szolgáltatásban magában foglalja az ügyfélalkalmazások APIO Management átjáróra irányuló és a háttérbeli API-kon keresztül zajló végpontok közötti kommunikációjának védelmét. Számos ügyfélkörnyezetben az OAuth 2.0 az előnyben részesített API engedélyezési protokoll. Az API Management támogatja az OAuth 2.0-s hitelesítést az ügyfél és az API Management-átjáró között, az átjáró és a háttér API között, vagy mindkettő függetlenül.
Az API Management más ügyféloldali és szolgáltatásoldali hitelesítési és engedélyezési mechanizmusokat támogat, amelyek kiegészítik az OAuth 2.0-t, vagy amelyek akkor hasznosak, ha az OAuth 2.0 api-k engedélyezése nem lehetséges. Ezek közül a lehetőségek közül a szervezet API-környezetének fejlettségétől, a biztonsági és megfelelőségi követelményektől, valamint a szervezet általános API-fenyegetések enyhítésére vonatkozó megközelítésétől függ.
Fontos
A felhasználók API-khoz való hozzáférésének védelme az API Management-környezet védelmének számos szempontja közé tartozik. További információ: Az Azure API Management biztonsági alapkonfigurációja.
Feljegyzés
Más API Management-összetevők külön mechanizmusokkal rendelkeznek a felhasználói hozzáférés védelmére és korlátozására:
- Az API Management-példány Azure-vezérlősíkon keresztüli kezeléséhez az API Management a Microsoft Entra ID-ra és az Azure szerepköralapú hozzáférés-vezérlésére (RBAC) támaszkodik.
- Az API Management fejlesztői portálja számos lehetőséget támogat a biztonságos felhasználói regisztráció és bejelentkezés megkönnyítése érdekében.
Hitelesítés kontra engedélyezés
Íme egy rövid magyarázat a hitelesítésről és az engedélyezésről az API-khoz való hozzáférés kontextusában:
Hitelesítés – Az API-hoz hozzáférő felhasználó vagy alkalmazás identitását ellenőrző folyamat. A hitelesítés történhet hitelesítő adatokkal, például felhasználónévvel és jelszóval, tanúsítvánnyal, egyszeri bejelentkezéssel (SSO) vagy más módszerekkel.
Engedélyezés – Annak megállapítására irányuló folyamat, hogy egy felhasználó vagy alkalmazás rendelkezik-e engedéllyel egy adott API eléréséhez, gyakran tokenalapú protokollon keresztül, mint például OAuth 2.0.
Feljegyzés
A hitelesítés és az engedélyezés kiegészítéseként az API-khoz való hozzáférést TLS használatával is védeni kell a hitelesítéshez vagy engedélyezéshez használt hitelesítő adatok vagy tokenek védelme érdekében.
Az OAuth 2.0 fogalmai
Az OAuth 2.0 egy szabványos engedélyezési keretrendszer, amelyet széles körben használnak az erőforrásokhoz, például a webes API-khoz való hozzáférés biztonságossá tételéhez. Az OAuth 2.0 korlátozza, hogy az ügyfélalkalmazás milyen műveleteket hajthat végre az erőforrásokon a felhasználó nevében anélkül, hogy megosztaná a felhasználó hitelesítő adatait. Bár az OAuth 2.0 nem hitelesítési protokoll, gyakran használják az OpenID Csatlakozás (OIDC) használatával, amely kiterjeszti az OAuth 2.0-t a felhasználói hitelesítés és az egyszeri bejelentkezés funkcióval.
OAuth-folyamat
Mi történik, ha egy ügyfélalkalmazás olyan API-t hív meg, amely TLS és OAuth 2.0 használatával védett kéréssel rendelkezik? A következő egy rövidített példafolyamat:
Az ügyfél (a hívó alkalmazás vagy a tulajdonos) hitelesítő adatokkal hitelesíti az identitásszolgáltatót.
Az ügyfél időkorlátos hozzáférési jogkivonatot (JSON webes jogkivonatot vagy JWT-t) szerez be az identitásszolgáltató engedélyezési kiszolgálójáról.
Az identitásszolgáltató (például a Microsoft Entra ID) a jogkivonat kiállítója , és a jogkivonat tartalmaz egy célközönségi jogcímet , amely engedélyezi az erőforrás-kiszolgálóhoz (például egy háttér API-hoz vagy magához az API Management-átjáróhoz) való hozzáférést.
Az ügyfél meghívja az API-t, és bemutatja a hozzáférési jogkivonatot – például egy engedélyezési fejlécben.
Az erőforrás-kiszolgáló ellenőrzi a hozzáférési jogkivonatot. Az érvényesítés egy összetett folyamat, amely ellenőrzi, hogy a kiállító és a célközönség jogcíme tartalmaz-e várt értékeket.
A jogkivonat-érvényesítési feltételek alapján a háttér API erőforrásaihoz való hozzáférés meg lesz adva.
Az ügyfélalkalmazás típusától és forgatókönyveitől függően különböző engedélyezési folyamatokra van szükség a jogkivonatok lekéréséhez és kezeléséhez. Az engedélyezési kódfolyamatot és az engedélyezési típust például gyakran használják webes API-kat hívó alkalmazásokban. További információ az OAuth-folyamatokról és az alkalmazásforgatókönyvekről a Microsoft Entra ID-ban.
OAuth 2.0 engedélyezési forgatókönyvek az API Managementben
1. forgatókönyv – Az ügyfélalkalmazás közvetlenül engedélyezi a háttérrendszert
Gyakori engedélyezési forgatókönyv, amikor a hívó alkalmazás közvetlenül hozzáférést kér a háttér API-hoz, és egy OAuth 2.0-jogkivonatot jelenít meg egy engedélyezési fejlécben az átjárónak. Az Azure API Management ezután "transzparens" proxyként működik a hívó és a háttér API között, és változatlanul továbbítja a jogkivonatot a háttérrendszernek. A hozzáférési jogkivonat hatóköre a hívó alkalmazás és a háttér API között van.
Az alábbi képen egy példa látható, ahol a Microsoft Entra ID az engedélyezési szolgáltató. Az ügyfélalkalmazás lehet egy egyoldalas alkalmazás (SPA).
Bár a HTTP-kéréssel együtt küldött hozzáférési jogkivonat a háttér API-hoz készült, az API Management továbbra is lehetővé teszi a mélységi védelem használatát. Konfiguráljon például szabályzatokat a JWT érvényesítésére, a jogkivonat nélkül érkező kérések elutasítására vagy egy olyan jogkivonatra, amely nem érvényes a tervezett háttér API-ra. Az API Managementet úgy is konfigurálhatja, hogy ellenőrizze a jogkivonatból kinyert egyéb érdekeltségi jogcímeket.
Feljegyzés
Ha az Azure API Managementen keresztül közzétett API-t az OAuth 2.0-val védi, az API Managementet úgy konfigurálhatja, hogy egy érvényes jogkivonatot hozzon létre tesztelési célokra az Azure Portal vagy a fejlesztői portál tesztkonzoljának felhasználója nevében. Hozzá kell adnia egy OAuth 2.0-kiszolgálót az API Management-példányhoz, és engedélyeznie kell az OAuth 2.0 engedélyezési beállításait az API-ban. További információ: Hogyan engedélyezheti a fejlesztői portál tesztkonzolját az OAuth 2.0 felhasználói engedélyezésének konfigurálásával.
Példa:
Tipp.
Abban a különleges esetben, amikor az API-hozzáférés a Microsoft Entra ID-val van védve, konfigurálhatja a validate-azure-ad-token szabályzatot a jogkivonatok érvényesítéséhez.
2. forgatókönyv – Az ügyfélalkalmazás engedélyezi az API Management használatát
Ebben a forgatókönyvben az API Management szolgáltatás az API nevében jár el, és a hívó alkalmazás hozzáférést kér az API Management-példányhoz. A hozzáférési jogkivonat hatóköre a hívó alkalmazás és az API Management-átjáró között van. Az API Managementben konfiguráljon egy szabályzatot (validate-jwt vagy validate-azure-ad-token) a jogkivonat érvényesítéséhez, mielőtt az átjáró átadja a kérést a háttérrendszernek. Egy külön mechanizmus általában biztosítja az átjáró és a háttér API közötti kapcsolatot.
Az alábbi példában a Microsoft Entra ID ismét az engedélyezési szolgáltató, és a kölcsönös TLS (mTLS) hitelesítés biztosítja az átjáró és a háttérrendszer közötti kapcsolatot.
Ennek különböző okai vannak. Példa:
A háttérrendszer egy örökölt API, amely nem frissíthető az OAuth támogatásához
Az API Managementet először úgy kell konfigurálni, hogy érvényesítse a jogkivonatot (legalább a kiállító és a célközönség jogcímeinek ellenőrzése). Az ellenőrzés után használja a rendelkezésre álló lehetőségek egyikét az API Managementből érkező kapcsolatok, például a kölcsönös TLS -hitelesítés (mTLS) biztonságossá tételéhez. Tekintse meg a szolgáltatásoldali beállításokat a cikk későbbi részében.
A háttérrendszer által megkövetelt környezet nem alakítható ki a hívótól
Miután az API Management sikeresen érvényesítette a hívótól kapott jogkivonatot, be kell szereznie egy hozzáférési jogkivonatot a háttér API-hoz a saját környezete vagy a hívó alkalmazásból származtatott környezet használatával. Ez a forgatókönyv a következő módon valósítható meg:
Egyéni szabályzat, például küldési kérés a háttér API-hoz érvényes hozzáférési jogkivonat lekérésére egy konfigurált identitásszolgáltatótól.
Az API Management-példány saját identitása – a jogkivonat átadása az API Management-erőforrás rendszer által hozzárendelt vagy felhasználó által hozzárendelt felügyelt identitásából a háttér API-nak.
A szervezet szabványosított engedélyezési megközelítést szeretne alkalmazni
Az API-háttérrendszereiken található hitelesítési és engedélyezési mechanizmusoktól függetlenül a szervezetek dönthetnek úgy, hogy az előtérben szabványosított engedélyezési megközelítést használnak az OAuth 2.0-n. Az API Management átjárója konzisztens engedélyezési konfigurációt és az API-felhasználók számára a szervezet háttérrendszereinek fejlődésével közös élményt nyújt.
3. forgatókönyv: Az API Management engedélyezi a háttérrendszer használatát
Felügyelt kapcsolatok (korábbi nevén engedélyezések) esetén az API Management hitelesítőadat-kezelőjével engedélyezheti egy vagy több háttér- vagy SaaS-szolgáltatáshoz, például a LinkedInhez, a GitHubhoz vagy más OAuth 2.0-kompatibilis háttérrendszerekhez való hozzáférést. Ebben az esetben egy felhasználó vagy ügyfélalkalmazás kérést intéz az API Management-átjáróhoz, amelynek átjáróhozzáférése identitásszolgáltató vagy más ügyféloldali beállítások használatával van vezérelve. Ezután a szabályzatkonfiguráción keresztül a felhasználó vagy az ügyfélalkalmazás delegálja a háttérbeli hitelesítést és az API Managementhez való engedélyezést.
Az alábbi példában az ügyfél és az átjáró között egy előfizetési kulcsot használunk, a GitHub pedig a háttér API hitelesítőadat-szolgáltatója.
Egy hitelesítőadat-szolgáltatóval való kapcsolattal az API Management az OAuth 2.0-folyamat API-hozzáférési jogkivonatait szerzi be és frissíti. A Csatlakozás sok több forgatókönyvben egyszerűsítik a jogkivonatok kezelését, például:
- Előfordulhat, hogy egy ügyfélalkalmazásnak engedélyeznie kell több SaaS-háttérrendszert, hogy több mezőt oldjon fel a GraphQL-feloldók használatával.
- A felhasználók az identitásszolgáltatójuktól hitelesítik magukat az API Management szolgáltatással, de egy közös szervezeti fiók használatával engedélyezik egy háttérbeli SaaS-szolgáltatónak (például a LinkedInnek).
- Egy ügyfélalkalmazásnak (vagy robotnak) egy hitelesített felhasználó nevében kell hozzáférnie a háttérbeli biztonságos online erőforrásokhoz (például e-mailek ellenőrzése vagy megrendelés elküldése).
Példák:
- Hitelesítőadat-kezelő konfigurálása – Microsoft Graph API
- Hitelesítőadat-kezelő konfigurálása – GitHub API
- Hitelesítőadat-kezelő konfigurálása – felhasználó által delegált hozzáférés a háttérbeli API-khoz
Az API-k védelmének egyéb lehetőségei
Bár az engedélyezés előnyben részesített, és az OAuth 2.0 lett az API-k erős engedélyezésének domináns módszere, az API Management számos más mechanizmust biztosít az ügyfél és az átjáró (ügyféloldal) vagy az átjáró és a háttérrendszer (szolgáltatásoldal) közötti hozzáférés védelmére vagy korlátozására. A szervezet követelményeitől függően ezek használhatók az OAuth 2.0 kiegészítésére. Másik lehetőségként konfigurálja őket egymástól függetlenül, ha a hívó alkalmazások vagy háttér API-k örököltek, vagy még nem támogatják az OAuth 2.0-t.
Ügyféloldali beállítások
| Mechanizmus | Leírás | Megfontolandó szempontok |
|---|---|---|
| mTLS | A csatlakozó ügyfél által bemutatott tanúsítvány ellenőrzése és a tanúsítványtulajdonságok ellenőrzése az API Managementben felügyelt tanúsítványon | A tanúsítvány egy kulcstartóban tárolható. |
| A hívó IP-címének korlátozása | A hívások szűrése (engedélyezése/megtagadása) adott IP-címekről vagy címtartományokból. | Használatával korlátozhatja bizonyos felhasználók vagy szervezetek hozzáférését, illetve a felsőbb rétegbeli szolgáltatásokból érkező forgalmat. |
| Előfizetési kulcs | Egy vagy több API-hoz való hozzáférés korlátozása API Management-előfizetés alapján | Javasoljuk, hogy egy előfizetési (API-) kulcsot használjon egy másik hitelesítési vagy engedélyezési módszer mellett. Az előfizetési kulcs önmagában nem egy erős hitelesítési forma, de bizonyos esetekben hasznos lehet az előfizetési kulcs használata, például az egyes ügyfelek API-használatának nyomon követése vagy adott API-termékekhez való hozzáférés biztosítása. |
Tipp.
A mélységi védelem érdekében erősen ajánlott egy webalkalmazási tűzfal üzembe helyezése az API Management-példányon keresztül. Használjon például Azure-alkalmazás Átjárót vagy Az Azure Front Doort.
Szolgáltatásoldali beállítások
| Mechanizmus | Leírás | Megfontolandó szempontok |
|---|---|---|
| Felügyelt identitás hitelesítése | Hitelesítés háttér API-ra rendszer által hozzárendelt vagy felhasználó által hozzárendelt felügyelt identitással. | A védett háttérerőforráshoz való hatókörön belüli hozzáféréshez ajánlott a Microsoft Entra ID azonosítójából beszerezni egy jogkivonatot. |
| Tanúsítványhitelesítés | Hitelesítés a háttér API-val ügyféltanúsítvány használatával. | A tanúsítvány a Key Vaultban tárolható. |
| Alapszintű hitelesítés | Hitelesítés a háttér API-ra egy engedélyezési fejlécen keresztül átadott felhasználónévvel és jelszóval. | Nem ajánlott, ha jobb lehetőségek állnak rendelkezésre. |
Következő lépések
- További információ a hitelesítésről és az engedélyezésről a Microsoft Identitásplatform.
- Ismerje meg, hogyan háríthatja el az OWASP API biztonsági fenyegetéseit az API Management használatával.