Megosztás a következőn keresztül:

Hitelesítés és api-k engedélyezése az Azure API Managementben

Minden API-kezelési szintre vonatkozik

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 Managementben magában foglalja az ügyfélalkalmazások végpontok közötti kommunikációjának védelmét az API Management-átjáróval és a háttérbeli API-k felé. 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-k biztonságossá tételének interakciós pontjait bemutató ábra.

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.

Important

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ó: Azure biztonsági alapkonfiguráció az API Managementhez.

Note

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:

Hitelesítés és engedélyezés

Íme a hitelesítés és az engedélyezés rövid magyarázata az API-khoz való hozzáférés kontextusában:

  • Hitelesítés: Az API-t elérő felhasználó vagy alkalmazás identitásának ellenőrzésének folyamata. A hitelesítés történhet hitelesítő adatokkal, például felhasználónévvel és jelszóval, tanúsítvánnyal vagy egyszeri bejelentkezéssel (SSO) vagy más módszerekkel.

  • Engedélyezés: Annak meghatározása, hogy egy felhasználó vagy alkalmazás rendelkezik-e engedéllyel egy adott API eléréséhez, gyakran jogkivonatalapú protokollon keresztül, például OAuth 2.0-val.

Note

A hitelesítés és az engedélyezés kiegészítése érdekében a hitelesítéshez vagy engedélyezéshez használt hitelesítő adatok és jogkivonatok védelme érdekében TLS használatával is biztonságossá kell tenni az API-khoz való hozzáférést.

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 Connect (OIDC) használatával, amely a felhasználói hitelesítés és az egyszeri bejelentkezés funkció biztosításával kibővíti az OAuth 2.0-t.

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 Microsoft Entra ID) a jogkivonat-kiállító, a jogkivonat pedig egy célközönség-jogcímet tartalmaz, 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 backend API erőforrásaihoz való hozzáférés engedélyezve lesz.

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 hitelesíti magát a backend rendszeren keresztül

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).

Az OAuth-kommunikációt bemutató ábra, ahol a célközönség a háttérrendszer.

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álja például a szabályzatokat a JWT érvényesítésére, elutasítva azokat a kérelmeket, amelyek token nélkül érkeznek, vagy amelyeknek a tokenje nem érvényes a szándékolt háttér API számára. Az API Managementet úgy is konfigurálhatja, hogy ellenőrizze a jogkivonatból kinyert egyéb érdekeltségi jogcímeket.

Note

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.

Example:

Tip

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.

Az OAuth-kommunikációt bemutató ábra, ahol a célközönség az API Management-átjáró.

Ennek különböző okai vannak. Például:

  • A háttérrendszer egy örökölt API, amely nem frissíthető az OAuth támogatásához

    Először konfigurálja az API-kezelést a jogkivonat érvényesítésére, ellenőrizve legalább a kibocsátó és a célpont állításait. 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. A cikk későbbi részében tekintse meg a szolgáltatásoldali beállításokat .

  • A háttérrendszer által megkövetelt környezet nem alakítható ki a hívótól

    Miután az API-kezelés sikeresen érvényesítette a hívótól kapott jogkivonatot, saját maga vagy a hívó alkalmazás által meghatározott környezet használatával kell beszereznie egy hozzáférési tokent a háttér API-hoz. 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 átadja a jogkivonatot az API Management-erőforrás rendszer által hozzárendelt vagy a felhasználó által hozzárendelt felügyelt identitásbó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érrendszereik hitelesítési és engedélyezési mechanizmusaitól függetlenül a szervezetek dönthetnek úgy, hogy az OAuth 2.0-n konvergálnak egy szabványosított engedélyezési megközelítéshez az előtérben. 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.

A hitelesítőadat-kezelőben felügyelt kapcsolat használatával történő saaS-szolgáltatás háttérbeli engedélyezését bemutató ábra.

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 kapcsolatok leegyszerűsítik a tokenek kezelését több helyzetben, 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 SSO-n keresztül azonosító szolgáltatójukból hitelesítenek az API Management szolgáltatásban, de egy közös szervezeti fiók használatával engedélyezik a hozzáférést 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).

Examples:

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ér (szolgáltatásoldal) közötti hozzáférés védelmére vagy korlátozására. A szervezet igényeitől függően ezeket használhatja 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

Mechanism Description Considerations
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 a hitelesítés erős formája, de az előfizetési kulcs használata bizonyos esetekben hasznos lehet; például nyomon követheti az egyes ügyfelek API-használatát, vagy hozzáférést biztosíthat adott API-termékekhez.

Tip

A mélységi védelem érdekében határozottan javasoljuk, hogy helyezzen üzembe egy webalkalmazási tűzfalat az API Management-példány előtt. Használja például az Azure Application Gatewayt vagy az Azure Front Doort.

Szolgáltatásoldali beállítások

Mechanism Description Considerations
Kezelt identitás hitelesítése Háttér API autentikálása rendszer által hozzárendelt vagy felhasználó által hozzárendelt felügyelt identitással. Ajánlott korlátozott hozzáférést kérni egy védett háttérerőforráshoz egy jogkivonat beszerzésével a Microsoft Entra ID-ből.
Tanúsítványhitelesítés A háttér API hitelesítése ügyféltanúsítvány használatával. A tanúsítvány a Key Vaultban tárolható.
Alapszintű hitelesítés Hitelesítse magát a háttér-API-hoz az Authorization fejlécben átadott felhasználónévvel és jelszóval. Nem ajánlott, ha biztonságosabb hitelesítési lehetőségek állnak rendelkezésre (például felügyelt identitás, tanúsítványok, hitelesítő adatok kezelője). Ha ezt választja, névvel ellátott értékekkel adja meg a hitelesítő adatokat, a titkokat pedig védje meg egy kulcstárban.

Kapcsolódó tartalom

  • Last updated on