Conhecendo um pouco sobre o Dynamic Data Masking no SQL Server

DBA e Consultor de Banco de Dados

Conhecendo um pouco sobre o Dynamic Data Masking no SQL Server

Tempo de leitura: 6 minutos

Fala galerinha,

Espero que estejam todos bem 😊

Hoje falaremos um pouco sobre a feature Dinamyc Data Masking, já ouviu falar?

Tentarei ser o mais breve e claro possível.

O Dynamic Data Masking (Mascaramento de dados dinâmico) também chamado de DDM. É um recurso de segurança que foi adicionado no SQL Server 2016. O DDM ajuda a impedir que usuários não autorizados façam o acesso a dados considerados sensíveis. É importante frisarmos que estamos falando de uma tecnologia de mascaramento de dados e não de uma criptografia diretamente, OK? Como a máscara é incorporada ao esquema da tabela o DDM acaba sendo totalmente transparente para a aplicação e não requer nenhum tipo de alteração (Muito bom e prático né?? 😊. No entanto, nem tudo são flores. A segurança também é um fator importante e esse recurso não impede que os usuários mal-intencionados possam tentar usar técnicas de inferência ou força bruta para desmascarar os dados.

Falando em segurança, para que se tenha sucesso na implementação dessa funcionalidade o controle de acessos da sua instância é primordial. Caso contrário usuários com permissões elevadas poderão facilmente desmascarar os dados, tornando ineficiente o uso deste recurso, falaremos mais a frente sobre isso.

Tome muito cuidado ao utilizar essa funcionalidade como a sua principal camada de segurança.

Recomendo fortemente algumas ações antes de pensar em implementar o DDM, dentre elas estão :

  • Faça a revisão da permissão de todos os usuários da instância. Se estiver dentro de um domínio, de preferencia para a criação de grupos, separando por departamentos, funções, etc, isso te ajudará na manutenção e a manter a rastreabilidade dos usuários e também permitirá que esteja tudo interligado em um lugar só, caso um usuário saia da empresa, basta exclui-lo no AD (Active Directory) que ele já não terá mais acesso ao banco;
  • Se possível retire todos os usuários com acesso sysadmin da instância (de preferência centralizando essa elevação em poucas pessoas como um DBA ou alguma pessoa especializada dentro da organização);
  • Faça a criação de um usuário especifico com permissões limitadas para a aplicação;

O DDM suporta os seguintes tipos de máscaras:

  • Partial (Cadeia de caracteres personalizada) : Um método de mascaramento que mostra a primeira e a última letra e adiciona uma sequência de preenchimento personalizada no meio.
  • Default (Padrão) : Mascaramento completo dependendo do tipo de dados do campo:
    • Para tipos binários de dados, é utilizado um único byte de valor ASCII 0 (binary, varbinary,image).
    • Para os tipos de dados de data e hora, é utilizado 01.01.1900 00:00:00.0000000 (date,datetime2,datetime,datetimeoffset,smalldatetime,time).
    • Para tipos de dados numéricos, é utilizado o valor zero (bigint,bit,decimal,int,money,numeric,smalltint,smallint,smallmoney,tinyint,float,real).
    • Para tipos de dados de texto, é utilizado XXXX e se o tamanho do valor arquivado for inferior a 4 caracteres, o SQL também irá mostrar XXXX (char,nchar,varchar,nvarchar,text,ntext).
  • E-mail : Mascara endereços de e-mail mostrando apenas a primeira letra e o sufixo de .com constante no seguinte formato [email protected].
  • Random (Aleatório) : Um método de mascaramento que substituirá um valor aleatório dentro do intervalo especificado para um tipo numérico.

Faremos alguns exemplos práticos disso mais adiante.

Para maiores detalhes, consulte a documentação:

https://docs.microsoft.com/pt-br/sql/relational-databases/security/dynamic-data-masking?view=sql-server-ver15

As regras de mascaramento NÃO podem ser definidas para o seguinte contexto:

  1. Colunas criptografadas com Always Encrypted.
  2. Colunas do tipo Column_Set.
  3. Colunas do tipo Filestream.
  4. Colunas do tipo Computada.
    1. Se uma coluna computada depender de uma coluna mascarada, a coluna computada retornará os dados mascarados.
  5. Uma coluna com mascaramento de dados não pode ser uma chave para um índice FULLTEXT.

Bom, chega de teoria… Vamos praticar um pouco?

Laboratório :

Usarei nessa demonstração a base AdventureWorks2016 que você pode baixar no seu ambiente neste link :

Temos a seguinte consulta :

Suponhamos que os dados de e-mail, telefone, endereço e estado foram considerados sensíveis pela sua organização e queremos aplicar o DDM neles. Para aplicar as funções de mascaramento, é muito simples, você pode “criar” uma tabela já aplicando a função desejada nos campos desejados ou alterar uma existente. No mundo real geralmente as bases já estão criadas e você na maioria das vezes precisará alterar algo já previamente criado, então focarei os exemplos desta demonstração apenas nas alterações (Mas tenha ciência que é a mesma coisa na criação, basta adicionar a função na frente do campo) :

Exemplo : Aplicando a função de mascaramento E-mail().

Exemplo : Aplicando a função de mascaramento Default().

Exemplo : Aplicando a função de mascaramento Partial().

Exemplo : Função de mascaramento Random().

Para testar o que acabamos de fazer, iremos criar um usuário no SQL Server com a permissão de somente leitura (“db_datareader”)

Vamos fazer o login com esse usuário na nossa instância.

Agora vamos executar a nossa consulta novamente (com o usuário user_ddm) :

Show!! Os dados foram mascarados com sucesso!!

Com essa permissão que foi aplicada neste usuário de somente leitura ele não conseguirá fazer nada em relação a segurança do nosso mascaramento, mas e se fosse um “db_owner”?

Vamos logar nele e rodar a consulta novamente.

Eita, o que aconteceu? Com a permissão db_owner o usuário em questão já tem as permissões necessárias para visualizar o dado real.

Portanto, tome muito cuidado!!

Se o usuário fizer parte do grupo sysadmin ele poderá também conceder ou revogar a permissão de outros usuários da sua instância.

Lembra do nosso usuário “user_ddm” com permissão somente leitura membro da role “db_datareader”? Vamos conceder permissão pra ele visualizar os dados desmascarados a partir de um usuário sysadmin.

Agora executando a nossa consulta com o usuário “user_ddm”, ele também pode visualizar os dados “desmascarados”.


Conclusão :

A solução funciona bem e é de fácil implementação .No entanto, o controle de acessos passa a ser um fator chave para se ter sucesso no uso deste recurso.

É isso ai pessoal, espero que tenham gostado!

Qualquer dúvida deixe nos comentários.

Um grande abraço!

Gustavo Larocca

Consultor SQL Server

 

Um comentário

  1. Fabrizzio Caputo disse:

    Recurso muito legal! Com certeza há muita aplicabilidade.

Deixe uma resposta

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.