Partilhar via

Proteja sua solução de construtor de API de dados

O Data API Builder expõe os seus dados através de endpoints REST e GraphQL. Proteger a sua API requer atenção a três áreas principais: autenticação (quem está a ligar?), autorização (o que podem fazer?) e segurança de transporte (a ligação está protegida?).

Ilustração do fluxo de pedidos de ponta a ponta mostrando autenticação, autorização e acesso à base de dados.

Três pilares de segurança

Pilar Pergunta que responde Conceito-chave
Authentication Quem é o chamador? Validar tokens de um fornecedor de identidade
Authorization O que podem fazer? Permissões baseadas em funções nas entidades
Transportes A ligação é segura? Encriptação da Segurança da Camada de Transporte (TLS) para todo o tráfego

Escolha o seu fornecedor de autenticação

O Data API Builder suporta múltiplos fornecedores de autenticação. Escolhe aquele que corresponde ao teu cenário de implantação:

Provider Caso de utilização Guide
Não autenticado O DAB está atrás de uma interface confiável que gere a identidade (por defeito) Configurar o fornecedor não autenticado
Microsoft Entra ID (EntraID/AzureAD) Aplicações de produção que usam a identidade Microsoft Configurar autenticação Microsoft Entra
Token Web JSON Personalizado (JWT) IDPs de terceiros (Okta, Auth0, Keycloak) Configurar autenticação JWT personalizada
Serviço de Aplicações Aplicações a executar atrás do Azure App Service EasyAuth (cabeçalhos da plataforma) Configurar a autenticação do App Service
Simulador Desenvolvimento local e testes Configurar autenticação do simulador
OBO (delegado pelo utilizador) Bases de dados SQL que requerem a identidade real do utilizador (segurança ao nível da linha, auditoria) Configurar autenticação OBO

Observação

A funcionalidade Data API builder 2.0 descrita nesta secção está atualmente em pré-visualização e pode mudar antes da disponibilidade geral. Para mais informações, consulte O que há de novo na versão 2.0.

Authentication

A autenticação verifica a identidade do chamador. O Data API builder autentica os pedidos validando tokens portadores JWT (EntraID/AzureAD, Custom) ou confiando nos cabeçalhos de identidade fornecidos pela plataforma (AppService, ). StaticWebApps Simulator Ignora a validação externa para desenvolvimento.

Ilustração de como os clientes se autenticam no Data API Builder usando tokens JWT.

Como funciona

  1. Para os fornecedores JWT, o cliente adquire um token do fornecedor de identidade
  2. O cliente envia o token no cabeçalho Authorization: Bearer <token> (fornecedores de JWT) ou a plataforma injeta cabeçalhos de identidade (EasyAuth/SWA)
  3. O Data API builder valida o token ou cabeçalho da plataforma (emissor, audiência, assinatura para fornecedores JWT)
  4. O DAB extrai as funções do utilizador do token ou do cabeçalho de identidade

Referência rápida

Configuração Descrição
runtime.host.authentication.provider O fornecedor de autenticação (Unauthenticated, EntraID/AzureAD, Custom, AppService, StaticWebApps, ) Simulator
runtime.host.authentication.jwt.audience Reivindicação esperada do público para fornecedores JWT (não usada por AppService/StaticWebApps/Simulator/Não autenticado)
runtime.host.authentication.jwt.issuer Emissor/autoridade esperada para fornecedores JWT (não usado por AppService/StaticWebApps/Simulator/Não autenticado)

Para configuração específica do fornecedor, consulte os guias de autenticação nesta secção.

Authorization

A autorização determina o que um utilizador autenticado (ou anónimo) pode fazer. O Data API Builder utiliza controlo de acesso baseado em funções (RBAC) para restringir o acesso a entidades e ações.

Ilustração de como o Data API Builder seleciona um papel e avalia permissões para um pedido.

Como funciona

  1. O DAB atribui um papel ao pedido com base no token e nos cabeçalhos
  2. O DAB verifica as permissões da entidade para esse papel
  3. Se o papel tiver permissão para a ação solicitada, o DAB executa a consulta
  4. Caso contrário, o DAB retornará uma resposta 403 Forbidden.

Funções do sistema vs. funções de utilizadores

Tipo de função Descrição
Anonymous Atribuída quando não existe identidade autenticada
Authenticated Atribuído quando um pedido é autenticado (aceite JWT ou cabeçalho de plataforma de confiança) e não é selecionada nenhuma função de utilizador específica.
Papéis de utilizador Funções personalizadas a partir da reivindicação do token roles (ou funções da plataforma), selecionadas através do cabeçalho X-MS-API-ROLE

Proteger por predefinição

As entidades não têm permissões por padrão. Deve conceder explicitamente o acesso:

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

Para configuração detalhada, consulte Visão geral da Autorização.

Segurança ao nível da linha e ao nível do campo

Vá além das permissões ao nível da entidade com controlo de acesso detalhado:

Feature Descrição Guide
Políticas de base de dados (segurança ao nível das linhas) Traduzir expressões de política em predicados de consulta que filtram linhas com base em reivindicações ou contexto de sessão Implementar segurança ao nível das linhas
Segurança a nível do campo Incluir ou excluir colunas específicas por função Acesso ao campo
Em-Nome-De (OBO) Trocar o token de utilizador recebido por um token SQL descendente para que a base de dados se autentique como o utilizador efetivo que está a chamar (somente para MSSQL) Autenticação delegada pelo utilizador

Herança de funções

O DAB 2.0 introduz a herança de funções para permissões de entidade. A cadeia de herança é named-role → authenticated → anonymous. Se uma função não estiver explicitamente configurada para uma entidade, herda da próxima função mais ampla. Defina as permissões uma vez em anonymous e todos os papéis de maior abrangência têm o mesmo acesso. Para mais informações, veja Herança de Funções.

Segurança do transporte e da configuração

Segurança dos transportes

  • Use TLS para todas as ligações: Encripte o tráfego entre clientes e DAB
  • Desativar versões legadas do TLS: Confiar apenas no TLS 1.2+
  • Utilize pontos de extremidade HTTPS: Nunca exponha DAB em HTTP não encriptado em produção

Para mais detalhes, consulte as melhores práticas de segurança.

Segurança de configuração

  • Armazene segredos em variáveis de ambiente: Use @env('SECRET_NAME') na sua configuração
  • Use Azure Key Vault: Referenciar segredos com @azure('key-vault-uri')
  • Nunca comprometa segredos: Mantenha-se dab-config.json livre de palavras-passe e strings de ligação
{
  "data-source": {
    "connection-string": "@env('SQL_CONNECTION_STRING')"
  }
}

Monitorização e atualizações

  • Monitorizar o acesso: Utilizar o Application Insights para rastrear pedidos e detetar anomalias
  • Rever registos: Verifique tentativas de autenticação falhadas e recusas de permissões
  • Mantenha o DAB atualizado: Aplique patches de segurança atualizando para a versão mais recente

Guias de início rápido

Tarefa Guide
Use uma interface confiável sem validação JWT no DAB Configurar o fornecedor não autenticado
Configurar a autenticação do Microsoft Entra ID Configurar autenticação Microsoft Entra
Utilize o Okta ou o Auth0 Configurar autenticação JWT personalizada
Executar por trás do Azure App Service Configurar a autenticação do App Service
Testar permissões localmente Configurar autenticação do simulador
Restringir linhas por utilizador Implementar segurança ao nível das linhas
Compreender a atribuição de funções Visão geral da autorização

Conteúdo relacionado

  • Last updated on