A Data API Builder-megoldás biztonságossá tétele

A Data API Builder REST- és GraphQL-végpontokon keresztül teszi elérhetővé az adatokat. Az API biztonságossá tételéhez három alapvető területre van szükség: a hitelesítésre (ki hív?), az engedélyezésre (mit tehetnek?) és az átviteli biztonságra (a kapcsolat védett?).

A hitelesítést, engedélyezést és adatbázis-hozzáférést megjelenítő, végpontok közötti kérelemfolyamat ábrája.

A biztonság három pillére

Alappillér Megválaszolt kérdés Kulcsfogalom
Authentication Ki a hívó? Tokenek érvényesítése identitásszolgáltatótól
Authorization Mit tehetnek? Szerepköralapú jogosultságok entitásokhoz
Szállítás Biztonságos a kapcsolat? Transport Layer Security (TLS) titkosítás az összes forgalomhoz

A hitelesítésszolgáltató kiválasztása

A Data API Builder több hitelesítésszolgáltatót is támogat. Válassza ki az üzembe helyezési forgatókönyvnek megfelelőt:

Szolgáltató Felhasználási eset Guide
Hitelesítés nélküli A DAB egy megbízható felület mögött található, amely kezeli az identitást (alapértelmezett) A hitelesítés nélküli szolgáltató konfigurálása
Microsoft Entra-azonosító (EntraID/AzureAD) Éles környezetben futó alkalmazások Microsoft azonosítóval A Microsoft Entra-hitelesítés konfigurálása
Egyéni JSON Web Token (JWT) Külső identitásszolgáltatók (Okta, Auth0, Keycloak) Egyéni JWT-hitelesítés konfigurálása
App Service Az Azure App Service EasyAuth mögött futó alkalmazások (platformfejlécek) App Service hitelesítés konfigurálása
Szimulátor Helyi fejlesztés és tesztelés Szimulátor-hitelesítés konfigurálása
OBO (felhasználó által delegált) Valós felhasználói identitást igénylő SQL-adatbázisok (sorszintű biztonság, naplózás) OBO-hitelesítés konfigurálása

Megjegyzés:

Az ebben a szakaszban ismertetett Data API Builder 2.0 funkció jelenleg előzetes verzióban érhető el, és az általános rendelkezésre állás előtt változhat. További információ: A 2.0-s verzió újdonságai.

Authentication

A hitelesítés ellenőrzi a hívó identitását. A Data API Builder JWT-tulajdonosi jogkivonatok (EntraID/AzureAD, Custom) vagy a platform által biztosított identitásfejlécek (AppService, StaticWebApps) hitelesítésével hitelesíti a kéréseket. Simulator kihagyja a fejlesztés külső érvényesítését.

Ábra arról, hogyan hitelesítik az ügyfelek a Data API Buildert JWT-jogkivonatokkal.

Hogyan működik?

  1. JWT-szolgáltatók esetén az ügyfél jogkivonatot szerez be az identitásszolgáltatótól
  2. Az ügyfél elküldi a jogkivonatot a Authorization: Bearer <token> fejlécben (JWT-szolgáltatók) vagy a platform identitásfejléceket injektál (EasyAuth/SWA)
  3. A Data API Builder ellenőrzi a jogkivonat vagy a platform fejlécét (kiállító, célközönség, JWT-szolgáltatók aláírása)
  4. A DAB kinyeri a felhasználó szerepköreit a jogkivonatból vagy az identitásfejlécből

Rövid összefoglalás

Setting Leírás
runtime.host.authentication.provider A hitelesítésszolgáltató (Unauthenticated, , EntraID/AzureADCustom, AppService, ) StaticWebAppsSimulator
runtime.host.authentication.jwt.audience JWT-szolgáltatók várható célközönség-jogcíme (nem használatos az AppService/StaticWebApps/Simulator/Unauthenticated esetében)
runtime.host.authentication.jwt.issuer Az elvárt kiállító/hatóság JWT-szolgáltatók számára (nem használja: AppService/StaticWebApps/Simulator/Unauthenticated)

A szolgáltatóspecifikus konfigurációról az ebben a szakaszban található hitelesítési útmutatókban olvashat.

Engedélyezés

Az engedélyezés határozza meg, hogy egy hitelesített (vagy névtelen) felhasználó mire képes. A Data API Builder szerepköralapú hozzáférés-vezérléssel (RBAC) korlátozza az entitásokhoz és műveletekhez való hozzáférést.

Ábra arról, hogy a Data API Builder hogyan választ ki egy szerepkört, és hogyan értékeli ki a kérések engedélyeit.

Hogyan működik?

  1. A DAB a jogkivonat és a fejlécek alapján szerepkört rendel a kéréshez
  2. A DAB megkeresi az entitás engedélyeit a szerepkörhöz
  3. Ha a szerepkör rendelkezik engedéllyel a kért művelethez, a DAB végrehajtja a lekérdezést
  4. Ha nem, a DAB visszajelez 403 Forbidden

Rendszerszerepkörök és felhasználói szerepkörök

Szerepkör típusa Leírás
Anonymous Hozzárendelve, ha nincs hitelesített identitás
Authenticated A kérelem hitelesítésekor (JWT elfogadott vagy megbízható platformfejléc) van hozzárendelve, és nincs kiválasztva konkrét felhasználói szerepkör
Felhasználói szerepkörök Egyéni szerepkörök a roles jogkivonat jogcíméből (vagy platformszerepkörökből), kiválasztva a X-MS-API-ROLE fejlécen keresztül

Alapértelmezés szerint biztonságos

Az entitások alapértelmezés szerint nem rendelkeznek engedélyekkel. A hozzáférést explicit módon kell megadnia:

{
  "entities": {
    "Book": {
      "permissions": [
        { "role": "authenticated", "actions": ["read"] }
      ]
    }
  }
}

A részletes konfigurációért tekintse meg az engedélyezés áttekintését.

Sorszintű és mezőszintű biztonság

Lépje túl az entitásszintű engedélyeket a részletes hozzáférés-vezérléssel:

Funkció Leírás Guide
Adatbázis-szabályzatok (sorszintű biztonság) Szabályzatkifejezések fordítása olyan lekérdezési predikátumokra, amelyek jogcímek vagy munkamenet-környezet alapján szűrik a sorokat Sorszintű biztonság megvalósítása
Mezőszintű biztonság Adott oszlopok belefoglalása vagy kizárása szerepkörenként Mezőhozzáférés
Valaki nevében (OBO) Cserélje le a bejövő felhasználói jogkivonatot egy alsóbb rétegbeli SQL-jogkivonatra, hogy az adatbázis tényleges hívó felhasználóként hitelesítse magát (csak mssql esetén) Felhasználó által delegált hitelesítés

Szerepköröröklés

A DAB 2.0 szerepköröröklést vezet be az entitásengedélyekhez. Az öröklési lánc az named-role → authenticated → anonymous. Ha egy szerepkör nincs explicit módon konfigurálva egy entitáshoz, akkor a következő szélesebb szerepkörtől örököl. Egyszer állítsa be az engedélyeket a anonymous-n, és minden szélesebb szerepkör ugyanazt a hozzáférést kapja. További részletekért lásd a szerepköröröklést.

Átviteli és konfigurációs biztonság

Átviteli biztonság

  • TLS használata minden kapcsolathoz: Az ügyfelek és a DAB közötti forgalom titkosítása
  • Régebbi TLS-verziók letiltása: Csak a TLS 1.2+-ra támaszkodhat
  • HTTPS-végpontok használata: Soha ne tegye közzé a DAB-t titkosítatlan HTTP-en keresztül éles környezetben

További részletekért tekintse meg a biztonsági ajánlott eljárásokat.

Konfigurációs biztonság

  • Titkos kódok tárolása környezeti változókban: Használat @env('SECRET_NAME') a konfigurációban
  • Az Azure Key Vault használata: Titkos kulcsok hivatkozása a következővel: @azure('key-vault-uri')
  • Soha ne köteleződjön el titkos adatokkal: Tartsa -t jelszavak és kapcsolati karakterláncok nélkül
{
  "data-source": {
    "connection-string": "@env('SQL_CONNECTION_STRING')"
  }
}

Figyelés és frissítések

  • Hozzáférés monitorozása: Az Application Insights használatával nyomon követheti a kéréseket és észlelheti a rendellenességeket
  • Naplók áttekintése: Sikertelen hitelesítési kísérletek és engedélymegtagadások ellenőrzése
  • A DAB frissítése: Biztonsági javítások alkalmazása a legújabb verzióra való frissítéssel

Rövid útmutatók

tevékenység Guide
Megbízható előtér használata JWT-ellenőrzés nélkül a DAB-ban A hitelesítés nélküli szolgáltató konfigurálása
Microsoft Entra ID hitelesítés beállítása A Microsoft Entra-hitelesítés konfigurálása
Az Okta vagy az Auth0 használata Egyéni JWT-hitelesítés konfigurálása
Azure App Service mögött futtatni App Service hitelesítés konfigurálása
Engedélyek helyi tesztelése Szimulátor-hitelesítés konfigurálása
Sorok korlátozása felhasználó szerint Sorszintű biztonság megvalósítása
A szerepkör-hozzárendelés ismertetése Engedélyezés áttekintése

Kapcsolódó tartalom

  • Last updated on