Zabezpečte řešení vytvořené pomocí nástroje pro sestavení Data API

Tvůrce rozhraní Data API zveřejňuje vaše data prostřednictvím koncových bodů REST a GraphQL. Zabezpečení rozhraní API vyžaduje pozornost ve třech základních oblastech: ověřování (kdo volá?), autorizace (co můžou dělat?) a zabezpečení přenosu (je chráněné připojení?).

Tři pilíře zabezpečení

Pilíř	Otázka, na kterou odpovídá	Klíčový koncept
Autentizace	Kdo je volající?	Ověřit tokeny od poskytovatele identity
Authorization	Co můžou dělat?	Oprávnění založená na rolích u entit
Přeprava	Je připojení zabezpečené?	Šifrování TLS pro veškerý provoz

Volba zprostředkovatele ověřování

Tvůrce rozhraní DATA API podporuje více zprostředkovatelů ověřování. Zvolte ten, který odpovídá vašemu scénáři nasazení:

Provider	Případ použití	Guide
Microsoft Entra ID (EntraID/AzureAD)	Produkční aplikace využívající identitu Microsoftu	Konfigurace ověřování Entra
Vlastní JWT	Poskytovatelé identity třetích stran (Okta, Auth0, Keycloak)	Konfigurace vlastního ověřování JWT
App Service	Aplikace běžící za Azure App Service EasyAuth (platformní hlavičky)	Konfigurace ověřování ve službě App Service
Simulátor	Místní vývoj a testování	Konfigurace ověřování simulátoru
Static Web Apps	Aplikace se SWA auth headers na čele	Konfigurace ověřování ve službě App Service

Návod

Začněte s poskytovatelem simulátoru během vývoje a otestujte oprávnění bez konfigurace zprostředkovatele identity. Před nasazením přepněte na poskytovatele produkčního prostředí.

Autentizace

Ověřování ověřuje identitu volajícího. Tvůrce rozhraní DATA API ověřuje požadavky buď ověřováním nosných tokenů JWT (EntraID/AzureAD, Custom) nebo důvěryhodností hlaviček identity poskytovaných platformou (AppService, StaticWebApps). Simulator vynechává externí ověřování pro vývoj.

Jak to funguje

1. Pro zprostředkovatele JWT klient získá token od zprostředkovatele identity.
2. Klient odešle token v Authorization: Bearer <token> hlavičce (zprostředkovatelé JWT) nebo platforma vloží hlavičky identit (EasyAuth/SWA).
3. Tvůrce rozhraní Data API ověří hlavičku tokenu nebo platformy (vystavitel, cílová skupina, podpis pro poskytovatele JWT).
4. DAB extrahuje role uživatele z hlavičky tokenu nebo identity.

Stručná referenční dokumentace

Setting	Description
runtime.host.authentication.provider	Zprostředkovatel ověřování (EntraID/AzureAD, Custom, AppServiceStaticWebApps, ) Simulator
runtime.host.authentication.jwt.audience	Očekávaná deklarace cílové skupiny pro zprostředkovatele JWT (nepoužívá ji AppService/StaticWebApps/Simulator)
runtime.host.authentication.jwt.issuer	Očekávaný vydavatel nebo autorita zprostředkovatelů JWT (nepoužívá se u služeb AppService/StaticWebApps/Simulator)

Podrobné informace o konfiguraci naleznete v tématu Konfigurace ověřování MICROSOFT Entra ID.

Autorizace

Autorizace určuje, co může ověřený (nebo anonymní) uživatel dělat. Tvůrce rozhraní Data API používá řízení přístupu na základě role (RBAC) k omezení přístupu k entitě a akcím.

Jak to funguje

1. DAB přiřadí roli požadavku na základě tokenu a hlaviček.
2. DAB vyhledá oprávnění entity pro danou roli.
3. Pokud má role oprávnění k požadované akci, DAB provede dotaz.
4. Pokud ne, DAB vrátí odpověď 403 Forbidden.

Systémové role vs. role uživatelů

Typ role	Description
Anonymous	Přiřazeno, když není k dispozici žádná ověřená identita
Authenticated	Přiřazeno při ověření požadavku (hlavička JWT akceptovaná nebo důvěryhodná platforma) a není vybrána žádná konkrétní role uživatele.
Role uživatelů	Vlastní role z deklarace identity tokenu roles (nebo rolí platformy) vybrané pomocí hlavičky X-MS-API-ROLE

Ve výchozím nastavení zabezpečeno

Entity nemají ve výchozím nastavení žádná oprávnění. Musíte explicitně udělit přístup:

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

Podrobnou konfiguraci najdete v tématu Autorizace a role.

Zabezpečení na úrovni řádků a polí

Přejděte nad rámec oprávnění na úrovni entity s jemně odstupňovaným řízením přístupu:

Vlastnost	Description	Guide
Zásady databáze (zabezpečení na úrovni řádků)	Překládejte výrazy zásad do dotazových predikátů, které filtrují řádky na základě tvrzení nebo kontextu relace.	Implementace zabezpečení na úrovni řádků
Zabezpečení na úrovni polí	Zahrnout nebo vyloučit konkrétní sloupce dle role	Přístup k polím

Zabezpečení přenosu a konfigurace

Zabezpečení dopravy

• Použití protokolu TLS pro všechna připojení: Šifrování provozu mezi klienty a DAB
• Zakázání starších verzí protokolu TLS: Spoléháte pouze na protokol TLS 1.2 nebo novější.
• Použití koncových bodů HTTPS: Nikdy nezpřístupňujte DAB přes nešifrovaný protokol HTTP v produkčním prostředí.

Podrobnosti najdete v tématu Osvědčené postupy zabezpečení.

Zabezpečení konfigurace

• Ukládání tajných kódů do proměnných prostředí: Použití @env('SECRET_NAME') v konfiguraci
• Použití služby Azure Key Vault: Referenční tajné kódy s využitím @azure('key-vault-uri')
• Nikdy neukládejte tajné kódy: Udržujte dab-config.json bez hesel a připojovacích řetězců

{
  "data-source": {
    "connection-string": "@env('SQL_CONNECTION_STRING')"
  }
}

Monitorování a aktualizace

• Monitorování přístupu: Sledování požadavků a zjišťování anomálií pomocí Application Insights
• Kontrola protokolů: Kontrola neúspěšných pokusů o ověření a odepření oprávnění
• Zachovat aktualizaci DAB: Použití oprav zabezpečení upgradem na nejnovější verzi

Průvodci pro rychlé zahájení práce

Task	Guide
Nastavení ověřování Microsoft Entra ID	Konfigurace ověřování Entra
Použijte Okta nebo Auth0	Konfigurace vlastního ověřování JWT
Pusťte za službou Azure App Service	Konfigurace ověřování ve službě App Service
Místní testování oprávnění	Konfigurace ověřování simulátoru
Omezení řádků podle uživatele	Implementace zabezpečení na úrovni řádků
Porozumění přiřazení rolí	Autorizace a role

Související obsah

• Konfigurace ověřování Microsoft Entra ID
• Autorizace a role
• osvědčené postupy zabezpečení
• Referenční informace o konfiguraci modulu runtime