Você sabia que quanto mais recursos de privacidades ofertados, maior será a confiança entre a empresa e o cliente? E que o mesmo acontece no mundo de TI?
Todo usuário deseja que seus dados confidenciais sejam acessíveis apenas para si mesmo – nem mesmo para aqueles com privilégios mais altos dentro da empresa. Portanto, à medida que você move dados para a nuvem, proteger os ativos dos dados é fundamental para criar confiança com seus clientes e parceiros.
Para habilitar esse tipo de prevenção, o Azure Synapse dá suporte a uma ampla variedade de recursos avançados de controle de acesso para controlar quem pode (ou não) acessar os dados selecionados pelo usuário. Esses recursos são:
- Segurança em nível de objeto.
- Segurança em nível de linha.
- Segurança em nível de coluna.
- Mascaramento de dados dinâmicos.
- Controle de acesso baseado em função do Synapse.
Segurança em nível de objeto
No Azure Synapse, sempre que criamos tabelas, exibições, procedimentos armazenados e funções, eles são criados como objetos. Em um pool de SQL dedicado, esses objetos podem ser protegidos concedendo permissões específicas a usuários ou grupos no nível do banco de dados.
Por exemplo, você pode conceder permissões SELECT a contas de usuário ou funções de banco de dados para dar acesso a objetos específicos.
Para atribuir permissão:
Para revogar a permissão:
Além disso, quando você atribui um usuário à função RBAC de Administrador do Synapse, ele obtém automaticamente acesso total a todos os pools de SQL dedicados nesse workspace. Ele permite que eles executem qualquer ação (incluindo o gerenciamento de permissões) em todos os bancos de dados.
Além disso, quando um usuário atribuído à função Colaborador de Dados do Blob de Armazenamento (tem permissões READ, WRITE e EXECUTE) de data lakes e os data lakes estão conectados ao workspace como Synapse ou Databricks, essas permissões são aplicadas automaticamente às tabelas criadas pelo Spark. Isso é conhecido como passagem do Microsoft Entra.
Veja, quando a função Colaborador de Dados do Blob de Armazenamento é atribuída à alguém:
Em seguida, é possível consultar a tabela criada pelo Spark.
Mas quando o papel é removido do usuário que fez a tabela, ela dá erro.
Segurança em nível de linha
A RLS é um mecanismo para restringir o acesso em nível de linha (leitura, gravação, …), com base nos dados de contexto do usuário. Um caso de uso típico é como, Tabelas de banco de dados comuns usadas por vários locatários para armazenar os dados e, nesse caso, queremos que cada locatário restrinja o acesso apenas aos seus próprios dados.
Ele permite esse controle de acesso refinado sem precisar redesenhar o Data Warehouse. Ele também elimina a necessidade de usar exibições para filtrar linhas para gerenciamento de controle de acesso.
NOTA: A lógica de restrição de acesso está localizada na camada de banco de dados e o sistema de banco de dados aplica as restrições de acesso sempre que os dados são acessados de qualquer camada. Isso torna o sistema de segurança mais confiável e robusto, reduzindo a área de superfície do seu sistema de segurança.
Como implementar a SPI?
A RLS pode ser implementada usando SECURITY POLICY. A RLS é uma forma de controle de acesso baseado em predicado que funciona aplicando automaticamente um Predicado de Segurança a todas as consultas em uma tabela. Security Predicate associa a função de predicado à tabela. A função de predicado é basicamente uma função definida pelo usuário que determina que um usuário que executa a consulta terá acesso à linha ou não.
Há dois tipos de predicados de segurança:
- Predicados de filtro: Ele filtra silenciosamente as linhas que os usuários não devem ver durante as operações SELECT, UPDATE e DELETE. Isso é usado quando você deseja ocultar dados sem interromper a experiência do usuário. Por exemplo, em um banco de dados de funcionários, o predicado de filtro é usado para garantir que os vendedores possam ver apenas seus próprios registros de clientes. Eles nem saberiam sobre discos pertencentes a outros vendedores.
- Predicados de bloco: Ele bloqueia explicitamente as operações de gravação (INSERT, UPDATE, DELETE) que violam regras predefinidas. Se um usuário tentar executar uma ação que viole as regras, a operação falhará com uma mensagem de erro. Isso é usado onde você deseja evitar modificações não autorizadas.
Implementando predicados de filtro
Etapa 1:
Criar usuários e tabelas fictícios e, em seguida, conceder acesso de leitura a esses objetos.
Etapa 2:
Crie a função de predicado de filtro de segurança.
A função retorna uma tabela com um único valor que é 1, quando satisfaz a condição WHERE. E SCHEMABINDING garante que os objetos subjacentes (tabelas, exibições etc.) referenciados pela função não possam ser modificados (descartados ou alterados) enquanto a função existir.
Etapa 3:
Crie uma política de segurança que filtre a segurança do predicado e vincule a função de predicado à tabela.
Passo 4:
Teste sua RLS.
Quando um usuário (por exemplo, ‘Mann’) executa uma consulta na tabela, o SQL Server invoca automaticamente a função de predicado de segurança para cada linha na tabela. Internamente, a função é chamada pelo SQL Server como parte do plano de execução da consulta. Portanto, as permissões necessárias para executar as funções são inerentemente tratadas pelo mecanismo do SQL Server. Portanto, não há necessidade de dar permissão explicitamente às funções.
Etapa 5:
Você pode desativar o RLS alterando a política de segurança.
Segurança em nível de coluna
É semelhante ao RLS, mas, como o próprio nome sugere, aplica-se ao nível da coluna. Por exemplo, em serviços financeiros, apenas os gerentes de contas têm acesso aos números de previdência social (SSN) do cliente, números de telefone e outras informações de identificação pessoal (PII).
Além disso, o método de implementação do CLS é diferente. Ele é implementado concedendo segurança no nível do objeto.
Implementando o CLS
Passo 1:
Criando usuário e tabela fictícios.
Passo 2:
Conceda ao usuário o acesso às colunas, exceto as colunas confidenciais.
Passo 3:
Agora, se o usuário tentar acessar colunas inteiras, ele dará erro.
Mascaramento de dados dinâmicos
É o processo de limitar a exposição de dados sensíveis, ao usuário que não deve ter acesso para visualizá-los. Por exemplo, agentes de atendimento ao cliente que precisam acessar registros de clientes, mas não devem ver números completos de cartão de crédito, que podem ser mascarados.
Você pode perguntar, por que não podemos usar CLS ou por que não restringimos completamente o acesso?
Por estas razões: –
- Um CLS restringirá completamente o acesso de colunas de leitura e alteração. Mas quando um mascaramento é aplicado em uma coluna, ele não impede atualizações nessa coluna. Portanto, se os usuários receberem dados mascarados ao consultar a coluna mascarada, os mesmos usuários poderão atualizar os dados se tiverem permissões de gravação.
- No mascaramento, você pode usar SELECT INTO ou INSERT INTO para copiar dados de uma coluna mascarada para outra tabela que será armazenada como dados mascarados (supondo que sejam exportados por um usuário sem privilégios UNMASK). Mas no CLS você não pode fazer nada, se não tiver acesso à coluna restrita.
OBSERVAÇÃO:
- Usuários e funções administrativas (como sysadmin ou db_owner) sempre podem visualizar dados não mascarados por meio da permissão CONTROL, que inclui as permissões ALTER ANY MASK e UNMASK.
- Você pode conceder ou revogar a permissão UNMASK no nível do banco de dados, no nível do esquema, no nível da tabela ou no nível da coluna para um usuário, função de banco de dados, identidade do Microsoft Entra ou grupo do Microsoft Entra.
Implementando o DDM
Passo 1:
Criando usuário fictício.
Etapa 2:
Crie uma tabela e aplique o mascaramento nas colunas necessárias.
Etapa 3:
Conceder a permissão SELECT no esquema em que a tabela reside. Os usuários exibem dados mascarados.
Passo 4:
Conceder a permissão UNMASK permite que os usuários vejam dados desmascarados.
Etapa 5:
Use a instrução ALTER TABLE para adicionar uma máscara a uma coluna existente na tabela ou para editar a máscara nessa coluna.
Controle de acesso baseado em função do Synapse
Basicamente, ele aproveita as funções internas para atribuir permissões a usuários, grupos ou outras entidades de segurança para gerenciar quem pode:
- Publique artefatos de código e liste ou acesse artefatos de código publicados.
- Execute código em pools do Apache Spark e runtimes de integração.
- Acesse serviços vinculados (dados) protegidos por credenciais.
- Monitore ou cancele execuções de trabalho, revise a saída do trabalho e os logs de execução.
Fonte: Blog Tech Community.
Transforme a gestão de dados da sua empresa com a expertise da DataEX
Proteger e gerenciar dados com precisão é essencial para garantir a confiança dos clientes e parceiros. Com soluções avançadas de análise de dados e inteligência artificial, sua empresa pode implementar estratégias eficazes de controle de acesso e segurança de dados, como as oferecidas pelo Azure Synapse DW. Isso não apenas melhora a proteção das informações, mas também otimiza a eficiência operacional.
Se sua empresa busca uma abordagem inovadora para transformar seus processos de gestão de dados, a DataEX pode ser sua parceira estratégica. Nossa expertise em soluções de análise de dados e IA permite elevar a segurança e o desempenho do seu negócio. Agende uma reunião com nossos especialistas e descubra como podemos impulsionar seus resultados com inteligência de dados.
Preencha o formulário abaixo e nosso time de especialistas entrará em contato.
Nos siga em nossas redes sociais e leia o Blog Data Universe diariamente.
