Skydda din Data API Builder-lösning

Data-API-byggare exponerar dina data via REST- och GraphQL-slutpunkter. För att skydda API:et krävs tre kärnområden: autentisering (vem anropar?), auktorisering (vad kan de göra?) och transportsäkerhet (är anslutningen skyddad?).

Tre grundpelare för säkerhet

Välj din autentiseringsprovider

Data API Builder stöder flera autentiseringsproviders. Välj den som matchar distributionsscenariot:

Authentication

Autentisering verifierar anroparens identitet. Data API Builder autentiserar begäranden genom att antingen validera JWT-ägartoken (EntraID/AzureAD, Custom) eller lita på identitetshuvuden som tillhandahålls av plattformen (AppService, ). StaticWebApps Simulator hoppar över extern validering för utveckling.

Så här fungerar det

1. För JWT-leverantörer hämtar klienten en token från identitetsprovidern
2. Klienten skickar token i Authorization: Bearer <token> huvudena (JWT-leverantörer) eller plattformen infogar identitetsrubriker (EasyAuth/SWA)
3. Data-API-byggare verifierar token- eller plattformshuvudet (utfärdare, målgrupp, signatur för JWT-leverantörer)
4. DAB extraherar användarens roller från token- eller identitetsrubriken

Snabbreferens

För providerspecifik konfiguration, se autentiseringsguiderna i det här avsnittet.

Authorization

Auktorisering avgör vad en autentiserad (eller anonym) användare kan göra. Data API Builder använder rollbaserad åtkomstkontroll (RBAC) för att begränsa åtkomsten till entiteter och åtgärder.

Så här fungerar det

1. DAB tilldelar en roll till begäran baserat på token och rubriker
2. DAB söker efter entitetens behörigheter för den rollen
3. Om rollen har behörighet för den begärda åtgärden kör DAB frågan
4. Annars returnerar DAB ett 403 Forbidden svar

Systemroller jämfört med användarroller

Säker som standard

Entiteter har inga behörigheter som standard. Du måste uttryckligen bevilja åtkomst:

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

Detaljerad konfiguration finns i Översikt över auktorisering.

Säkerhet på radnivå och fältnivå

Gå längre än behörigheter på entitetsnivå med detaljerad åtkomstkontroll:

Arv av roll

DAB 2.0 introducerar rollbaserad arvshantering för entitetsbehörigheter. Arvskedjan är named-role → authenticated → anonymous. Om en roll inte uttryckligen har konfigurerats för en entitet ärver den från nästa bredare roll. Definiera behörigheter en gång på anonymous, så får varje bredare roll samma åtkomst. Mer information finns i Rollärvning.

Transport- och konfigurationssäkerhet

Transportsäkerhet

• Använd TLS för alla anslutningar: Kryptera trafik mellan klienter och DAB
• Inaktivera äldre TLS-versioner: Förlita dig endast på TLS 1.2+
• Använd HTTPS-slutpunkter: Exponera aldrig DAB över okrypterad HTTP i produktion

Mer information finns i Metodtips för säkerhet.

Konfigurationssäkerhet

• Lagra hemligheter i miljövariabler: Använd @env('SECRET_NAME') i konfigurationen
• Använd Azure Key Vault: Referera till hemligheter med @azure('key-vault-uri')
• Checka aldrig in hemligheter: Håll dig dab-config.json fri från lösenord och anslutningssträngar

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

Övervakning och uppdateringar

• Övervaka åtkomst: Använd Application Insights för att spåra begäranden och identifiera avvikelser
• Granska loggar: Sök efter misslyckade autentiseringsförsök och behörighetsnekanden
• Håll DAB uppdaterat: Tillämpa säkerhetskorrigeringar genom att uppgradera till den senaste versionen

Snabbstartsguider

Relaterat innehåll

• Konfigurera den oautentiserade leverantören
• Konfigurera Microsoft Entra ID-autentisering
• Översikt över auktorisering
• Säkerhetens bästa praxis
• Referens för programkörningskonfiguration