Udostępnij za pośrednictwem

Zabezpieczanie rozwiązania konstruktora interfejsu API danych

Konstruktor interfejsu API danych uwidacznia dane za pośrednictwem punktów końcowych REST i GraphQL. Zabezpieczanie interfejsu API wymaga uwagi na trzy podstawowe obszary: uwierzytelnianie (kto wywołuje?), autoryzację (co mogą zrobić?) i zabezpieczenia transportu (czy połączenie jest chronione?).

Ilustracja przedstawiająca przepływ kompleksowego żądania przedstawiający uwierzytelnianie, autoryzację i dostęp do bazy danych.

Trzy filary zabezpieczeń

Filar Pytanie, na które odpowiedziano Kluczowa koncepcja
Uwierzytelnianie Kto jest rozmówcą? Walidacja tokenów dostawcy tożsamości
Autoryzacja Co mogą zrobić? Uprawnienia oparte na rolach dla jednostek
Transport Czy połączenie jest bezpieczne? Szyfrowanie Tls (Transport Layer Security) dla całego ruchu

Wybierz dostawcę uwierzytelniania

Konstruktor interfejsu API danych obsługuje wielu dostawców uwierzytelniania. Wybierz ten, który jest zgodny ze scenariuszem wdrażania:

Dostawca Przypadek użycia Przewodnik
Nieuwierzytelnione DAB działa za zaufanym interfejsem obsługującym tożsamość (ustawienie domyślne). Skonfiguruj dostawcę bez uwierzytelniania
Microsoft Entra ID (EntraID/AzureAD) Aplikacje produkcyjne korzystające z tożsamości firmy Microsoft Konfigurowanie uwierzytelniania w usłudze Microsoft Entra
Niestandardowy token internetowy JSON (JWT) Dostawcy tożsamości innych firm (Okta, Auth0, Keycloak) Konfigurowanie niestandardowego uwierzytelniania JWT
App Service Aplikacje uruchomione za usługą Azure App Service EasyAuth (nagłówki platformy) Konfigurowanie uwierzytelniania usługi App Service
Symulator Lokalne programowanie i testowanie Konfigurowanie uwierzytelniania symulatora
OBO (delegowane przez użytkownika) Bazy danych SQL, które wymagają rzeczywistej tożsamości użytkownika (zabezpieczenia na poziomie wiersza, inspekcja) Konfigurowanie uwierzytelniania OBO

Uwaga / Notatka

Funkcja narzędzia Data API Builder 2.0 opisana w tej sekcji jest obecnie dostępna w wersji zapoznawczej i może ulec zmianie przed ogólną dostępnością. Aby uzyskać więcej informacji, zobacz Co nowego w wersji 2.0.

Uwierzytelnianie

Uwierzytelnianie weryfikuje tożsamość wywołującego. Konstruktor interfejsu API danych uwierzytelnia żądania, sprawdzając tokeny elementu nośnego JWT (EntraID/AzureAD, Custom) lub ufając nagłówkom tożsamości udostępnianym przez platformę (AppService, StaticWebApps). Simulator Pomija zewnętrzną walidację na potrzeby programowania.

Ilustracja przedstawiająca sposób uwierzytelniania klientów w konstruktorze interfejsu API danych przy użyciu tokenów JWT.

Jak to działa

  1. W przypadku dostawców JWT klient uzyskuje token od dostawcy tożsamości
  2. Klient wysyła token w nagłówku Authorization: Bearer <token> (dostawcy JWT) lub platforma dodaje nagłówki tożsamości (EasyAuth/SWA)
  3. Konstruktor interfejsu API danych weryfikuje token lub nagłówek platformy (wystawca, odbiorcy, podpis dla dostawców JWT)
  4. DaB wyodrębnia role użytkownika z nagłówka tokenu lub tożsamości

Krótki przewodnik

Setting Opis
runtime.host.authentication.provider Dostawca uwierzytelniania (Unauthenticated, EntraID/AzureAD, , CustomAppService, ) StaticWebAppsSimulator
runtime.host.authentication.jwt.audience Oczekiwane oświadczenie odbiorców dla dostawców JWT (nieużywane przez usługę AppService/StaticWebApps/Simulator/Unauthenticated)
runtime.host.authentication.jwt.issuer Oczekiwany wystawca/urząd dla dostawców JWT (nieużywane przez usługę AppService / StaticWebApps / Simulator / Unauthenticated)

Aby uzyskać informacje o konfiguracji specyficznej dla dostawcy, zobacz przewodniki uwierzytelniania w tej sekcji.

Autoryzacja

Autoryzacja określa, co może zrobić uwierzytelniony (lub anonimowy) użytkownik. Konstruktor interfejsu API danych używa kontroli dostępu opartej na rolach (RBAC), aby ograniczyć dostęp do jednostek i akcji.

Ilustracja przedstawiająca sposób, w jaki konstruktor interfejsu API danych wybiera rolę i ocenia uprawnienia do żądania.

Jak to działa

  1. DAB przypisuje rolę do żądania na podstawie tokenu i nagłówków
  2. DAB sprawdza uprawnienia podmiotu dla tej roli
  3. Jeśli rola ma uprawnienia do żądanej akcji, daB wykonuje zapytanie
  4. Jeśli tak nie jest, DAB zwraca odpowiedź 403 Forbidden

Role systemowe a role użytkowników

Typ roli Opis
Anonymous Przypisano, gdy nie ma tożsamości uwierzytelnionej
Authenticated Przypisano, gdy żądanie jest uwierzytelnione (zaakceptowano JWT lub zaufany nagłówek platformy) i nie wybrano żadnej określonej roli użytkownika
Role użytkownika Role niestandardowe z oświadczenia tokenu roles lub role platformy, wybrane za pośrednictwem nagłówka X-MS-API-ROLE.

Domyślnie zabezpieczone

Jednostki domyślnie nie mają uprawnień. Musisz jawnie udzielić dostępu:

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

Aby uzyskać szczegółową konfigurację, zobacz Omówienie autoryzacji.

Zabezpieczenia na poziomie wiersza i na poziomie pola

Wykraczanie poza uprawnienia na poziomie jednostki za pomocą szczegółowej kontroli dostępu:

Funkcja Opis Przewodnik
Zasady bazy danych (zabezpieczenia na poziomie wiersza) Tłumaczenie wyrażeń zasad na predykaty zapytań, które filtrują wiersze na podstawie oświadczeń lub kontekstu sesji Implementowanie zabezpieczeń na poziomie wiersza
Zabezpieczenia na poziomie pola Dołączanie lub wykluczanie określonych kolumn na rolę Dostęp do pola
On-Behalf-Of (OBO) Wymiana przychodzącego tokenu użytkownika dla podrzędnego tokenu SQL, aby baza danych uwierzytelniła się jako rzeczywisty użytkownik wywołujący (tylko mssql) Uwierzytelnianie delegowane przez użytkownika

Dziedziczenie roli

DAB 2.0 wprowadza dziedziczenie ról dla uprawnień encji. Łańcuch dziedziczenia to named-role → authenticated → anonymous. Jeśli rola nie jest jawnie skonfigurowana dla jednostki, dziedziczy ją z następnej szerszej roli. Zdefiniuj uprawnienia raz w anonymous, a każda szersza rola otrzymuje ten sam dostęp. Aby uzyskać szczegółowe informacje, zobacz Dziedziczenie ról.

Zabezpieczenia transportu i konfiguracji

Zabezpieczenia transportu

  • Użyj protokołu TLS dla wszystkich połączeń: szyfruj ruch między klientami i daB
  • Wyłącz starsze wersje protokołu TLS: polegaj tylko na protokole TLS 1.2 lub nowszym
  • Używanie punktów końcowych HTTPS: nigdy nie uwidaczniaj języka DAB za pośrednictwem niezaszyfrowanego protokołu HTTP w środowisku produkcyjnym

Aby uzyskać szczegółowe informacje, zobacz Najlepsze rozwiązania dotyczące zabezpieczeń.

Zabezpieczenia konfiguracji

  • Przechowywanie tajnych danych w zmiennych środowiskowych: użyj @env('SECRET_NAME') w konfiguracji
  • Korzystanie z usługi Azure Key Vault: odwołania do tajemnic za pomocą @azure('key-vault-uri')
  • Nigdy nie zatwierdzaj sekretów: zachowaj dab-config.json wolne od haseł i parametrów połączenia
{
  "data-source": {
    "connection-string": "@env('SQL_CONNECTION_STRING')"
  }
}

Monitorowanie i aktualizacje

  • Monitorowanie dostępu: śledzenie żądań i wykrywanie anomalii za pomocą usługi Application Insights
  • Przejrzyj dzienniki: Sprawdź, czy nie było nieudanych prób uwierzytelnienia i odmów dostępu
  • Utrzymuj DAB w aktualności: Stosuj poprawki zabezpieczeń poprzez uaktualnienie do najnowszej wersji

Przewodniki Szybki start

Zadanie Przewodnik
Używanie zaufanego interfejsu użytkownika bez walidacji JWT w DAB Skonfiguruj dostawcę bez uwierzytelniania
Konfigurowanie uwierzytelniania za pomocą Microsoft Entra ID Konfigurowanie uwierzytelniania w usłudze Microsoft Entra
Korzystanie z usługi Okta lub Auth0 Konfigurowanie niestandardowego uwierzytelniania JWT
Uruchamianie w środowisku Azure App Service Konfigurowanie uwierzytelniania usługi App Service
Lokalne testowanie uprawnień Konfigurowanie uwierzytelniania symulatora
Ograniczanie wierszy według użytkownika Implementowanie zabezpieczeń na poziomie wiersza
Zrozum przypisanie roli Omówienie autoryzacji

Treści powiązane

  • Last updated on