Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Mesmo com proteções na camada de aplicação, uma vez que um usuário tenha acesso direto ao banco de dados, informações sigilosas podem ser acessadas. O acesso pode ser necessário por diversos motivos, sejam referentes à troubleshooting para encontrar a causa de alguma inconsistência ou outras razões que tornem isto necessário.

Nesta situação, o Data Masking (Mascaramento de dados) para o SQL Server mostra-se como uma ferramenta viável para proteger dados que não devem ser expostos, ao limitar a exposição destes para usuários sem os privilégios necessários. 

Aviso
titleVersões homologadas

Não são suportadas as versões limitadas e tipicamente classificadas como "Express" para o Protheus.

Disponibilidade da feature
SQL Server 2019 Standard, Enterprise
SQL Server 2017 Standard, Enterprise
SQL Server 2016 Standard, Enterprise

Configuração da feature

Não é necessário realizar instalações à parte, já que esta feature está disponível nativamente nas versões supracitadas.

Para fins de comparação, dois usuários serão criados, sendo um com permissão para visualização dos dados e outro sem permissão. A criação de um segundo usuário que visualizará apenas os dados necessários, e não possuirá permissão de visualização total, é essencial para o uso da feature

Expandir
titleCriação de usuário no banco de dados

Neste exemplo, serão criados dois usuários: TPPRD, que possui permissão total de acesso aos dados e deve ser criado conforme grants mínimos para o funcionamento do DBAccess; e TPPRDMASK, que visualizará apenas a máscara em dados sigilosos.

Usuário TPPRD - Usuário padrão 

Permissões selecionadas visualizadas pelo management studio:

As permissões padrão, que devem ser aplicadas, são: db_owner e public. Além destas, aplique também as permissões VIEW SERVER STATE, ALTER ANY CONNECTION e SELECT ON sys.dm_tran_locks:

Bloco de código
languagesql
USE master
GO
GRANT VIEW SERVER STATE to TPPRD;
GO
GRANT ALTER ANY CONNECTION to TPPRD;
GO
GRANT SELECT ON sys.dm_tran_locks to TPPRD;
GO

Usuário TPPRDMASK - Usuário sem visualização à dados sensíveis

Além das permissões acima, aplicar os seguintes grants:

Bloco de código
languagesql
USE master
GO
GRANT VIEW SERVER STATE to TPPRDMASK;
GO
GRANT ALTER ANY CONNECTION to TPPRDMASK;
GO
GRANT SELECT ON sys.dm_tran_locks to TPPRDMASK;
GO
Bloco de código
languagesql
USE TPPRD
GO
grant execute to TPPRDMASK;
GO
REVOKE UNMASK TO TPPRDMASK; 
GO
Expandir
titleCriação da conexão ODBC
Informações
titleObservação

A criação da conexão ODBC do usuário TPPRDMASK deve ser feita da mesma maneira que a criação da conexão ODBC do usuário TPPRD, e as únicas alterações serão no nome da fonte de dados e no usuário para conexão. 

 Abra o ODBC Data Source Administrator (administrador de fonte de dados ODBC), clique em Add... (Adicionar...) e selecione o driver ODBC para SQL Server. Em seguida, insira o nome da fonte de dados, uma descrição caso desejado, e o IP do servidor onde a base de dados está localizada. Em seguida, clique em Next.

Insira o usuário de conexão à base de dados. Clique em Next.

Selecione a opção para alterar a database padrão para a base do Protheus. Clique em Next.

Faça Não é necessário qualquer alteração na tela seguinte. Clique em Finish, e faça o teste do data source para validar se a conexão está ok.

Nota
titleAtenção

Realize também a criação do ODBC para o usuário sem permissão de visualização.

Expandir
titleCriação da conexão DBAccess

Configure a conexão DBAccess para ambos os usuários.

A configuração dos usuários precisa estar no mesmo DBAccess. NÃO coloque os dois usuários em DBAccess separados, exceto se estiver usando o DBAccess em modelo distribuído, pois isso pode gerar DeadLocks no banco de dados.

Exemplo de configuração para o usuário com permissão de visualização:


Image Added

Exemplo de configuração para o usuário sem permissão de visualização:

Image Added
ALTER TABLE dbo

.

SB1990  ALTER COLUMN B1_COD ADD MASKED WITH (FUNCTION = 'partial(2,"xxxx",0)'); 

Como essa tabela é sequencial, gerou o seguinte erro quando foi configurada  Para remover a máscara de dados.Para remover a Máscara de Dados, realizamos , utilize o seguinte comando:

Expandir
titleCuidados a serem tomados
Aviso
titleErros e validação da feature

Não aplique a máscara de dados à colunas sequenciais

.Não utilize colunas sequenciais com máscara. As colunas sequenciais podem

, pois isto pode travar a rotina que a

utilizam. É necessário testar e validar na aplicação todas colunas com máscara, para validar na camada da aplicação o resultado dessa

utiliza. 

Teste e valide a aplicação da máscara de dados pelo Protheus.Sempre valide uma nova feature em um ambiente de homologação antes de implementá-la no ambiente de produção.

Exemplo de erro ao configurar uma coluna sequencial com mascaramento: TC_Bof - NO CONNECTION

Image Added

Neste caso, foi utilizada mascarada a coluna B1_COD da tabela SB1990:

Bloco de código
languagesql
Bloco de código
languagesql
ALTER TABLE dbo.SB1990
ALTER COLUMN B1_COD DROP MASKED; 
Expandir
titleExemplo de uso

Criamos a A máscara de dados foi criada na coluna: ‘A1_NOME’ na tabela SA1990:


Bloco de código
languagesql
ALTER TABLE dbo.SA1990  

ALTER COLUMN A1_NOME ADD MASKED WITH (FUNCTION = 'partial(2,"xxxx",0)');


O usuário SEM acesso aos dados, visualiza da seguinte forma os dados:

O usuário COM acesso aos dados, visualiza da seguinte forma os dados:

Image Added

Para remover a Máscara de Dados, realizamos execute o seguinte comando:


Bloco de código
languagesql
ALTER TABLE dbo.SA1990

ALTER COLUMN A1_NOME DROP MASKED; 
Expandir
titleRelação de campos sugeridos para mascaramento
Aviso
titleAtenção

Os campos e tabelas aqui descritos são sugestões por, possivelmente, conterem dados sensíveis que possam comprometer a privacidade dos usuários, clientes ou outros atores envolvidos. Certifique-se que os campos devem ser ocultados e que o uso desta feature não comprometerá o funcionamento de sua operação. 

Realize a validação dos campos mascarados em um ambiente de homologação antes de efetuar esta alteração na base de produção para garantir que os dados necessários serão mascarados e não haverão outras consequências.