Compartilhar via

White paper de segurança do Azure Synapse Analytics: controle de acesso

  • Artigo

Observação

Este artigo faz parte da série de white papers sobre segurança do Azure Synapse Analytics. Para obter uma visão geral da série, confira White paper de segurança do Azure Synapse Analytics.

Dependendo de como os dados foram modelados e armazenados, a governança de dados e o controle de acesso podem exigir que os desenvolvedores e administradores de segurança usem abordagens diferentes ou combinação de técnicas para implementar uma base de segurança robusta.

O Azure Synapse dá suporte a uma ampla variedade de recursos para controlar quem pode acessar quais dados. Essas funcionalidades são criadas com base em um conjunto de recursos avançados de controle de acesso, incluindo:

Segurança em nível de objeto

Cada objeto em um pool de SQL dedicado tem permissões associadas que podem ser concedidas a uma entidade de serviço. No contexto de usuários e contas de serviço, é assim que tabelas individuais, exibições, procedimentos armazenados e funções são protegidos. Permissões de objeto, como SELECT, podem ser concedidas a contas de usuário (logons SQL, usuários ou grupos do Microsoft Entra) e funções de banco de dados, o que fornece flexibilidade para administradores de banco de dados. Além disso, as permissões concedidas em tabelas e exibições podem ser combinadas com outros mecanismos de controle de acesso (descritos abaixo), como segurança em nível de coluna, segurança em nível de linha e mascaramento de dados dinâmicos.

No Azure Synapse, todas as permissões são concedidas a usuários e funções no nível do banco de dados. Além disso, qualquer usuário que concedeu a função RBAC de Administrador do Synapse interna no nível do workspace recebe automaticamente acesso completo a todos os pools de SQL dedicados.

Além de proteger as tabelas SQL no Azure Synapse, o pool de SQL dedicado (anteriormente SQL DW), o pool de SQL sem servidor e as tabelas do Spark também podem ser protegidas. Por padrão, os usuários atribuídos à função de Colaborador de Dados de Blob do Armazenamento de data lakes conectados ao workspace têm permissões READ, WRITE e EXECUTE em todas as tabelas criadas pelo Spark quando os usuários executam código interativamente no notebook. Ele é chamado de passagem do Microsoft Entra e se aplica a todos os data lakes conectados ao workspace. No entanto, se o mesmo usuário executar o mesmo notebook por meio de um pipeline, a MSI (Identidade de Serviço Gerenciada) do workspace será usada para autenticação. Portanto, para que o pipeline execute com êxito a MSI do workspace, ele também deve pertencer à função Colaborador de dados de Armazenamento de blob do data lake que é acessado.

Segurança em nível de linha

A segurança em nível de linha permite que os administradores de segurança estabeleçam e controlem o acesso a linhas de tabela específicas com base no perfil de um usuário (ou um processo) que executa uma consulta. As características do perfil ou do usuário podem se referir à associação de grupo ou ao contexto de execução. A segurança em nível de linha ajuda a impedir o acesso não autorizado quando os usuários consultam dados das mesmas tabelas, mas devem ver subconjuntos diferentes de dados.

Observação

A segurança em nível de linha tem suporte no Azure Synapse e no pool de SQL dedicado (anteriormente SQL DW), mas não dá suporte para um pool de Apache Spark e um pool de SQL sem servidor.

Segurança ao nível da coluna

A segurança em nível de coluna permite aos administradores de segurança definir permissões que limitam quem pode acessar colunas confidenciais em tabelas. Ele é definido no nível do banco de dados e pode ser implementado sem a necessidade de alterar o design do modelo de dados ou da camada de aplicativo.

Observação

A segurança em nível de coluna tem suporte no Azure Synapse, exibições de pool de SQL sem servidor e no pool de SQL dedicado (anteriormente SQL DW), mas não dá suporte para as tabelas externas do pool de SQL sem servidor e o pool do Apache Spark. No caso das tabelas externas do pool de SQL sem servidor, uma solução alternativa pode ser aplicada criando uma exibição na parte superior de uma tabela externa.

Mascaramento de dados dinâmicos

O mascaramento de dados dinâmicos permite que os administradores de segurança restrinjam a exposição de dados confidenciais mascarando-os na leitura para usuários sem privilégios. Ele ajuda a impedir o acesso não autorizado a dados confidenciais, permitindo que os administradores determinem como os dados são exibidos no momento da consulta. Com base na identidade do usuário autenticado e sua atribuição de grupo no pool de SQL, uma consulta retorna dados mascarados ou não mascarados. O mascaramento é sempre aplicado independentemente se os dados são acessados diretamente de uma tabela ou usando uma exibição ou um procedimento armazenado.

Observação

O mascaramento de dados dinâmicos dá suporte no Azure Synapse e no pool de SQL dedicado (anteriormente SQL DW), mas não dá suporte para um pool de Apache Spark e um pool de SQL sem servidor.

Controle de Acesso baseado em função do Azure Synapse

Azure Synapse também inclui funções RBAC (controle de acesso baseado em função) do Synapse para gerenciar diferentes aspectos Synapse Studio. Aproveite essas funções internas para atribuir permissões a usuários, grupos ou outras entidades de segurança para gerenciar quem pode:

  • Publicar artefatos de código e listar ou acessar artefatos de código publicados.
  • Executar código em Pools do Apache Spark e runtimes de integração.
  • Acessar serviços (de dados) vinculados que são protegidos por credenciais.
  • Monitorar ou cancelar a execuções do trabalho e examinar a saída do trabalho e os logs de execução.

Próximas etapas

No próximo artigo desta série de white papers, saiba mais sobre autenticação.