Como mascarar dados sensíveis no Azure SQL (Data Masking)

Proteger dados pessoais como emails e numeros de cartao e uma exigencia basica de governanca de dados — e nem sempre obriga a reescrever a aplicacao. O Dynamic Data Masking do Azure SQL esconde colunas sensiveis nos resultados das consultas, mostrando os valores reais apenas a quem tem permissao. Assim, um analista ve apenas aXXX@XXXX.com enquanto os dados na tabela permanecem intactos.

Pre-requisitos

• Uma base de dados no Azure SQL Database (ou SQL Server 2022) onde tenhas permissoes de administrador.
• Uma ferramenta de consulta como o SQL Server Management Studio (SSMS) ou o Azure Data Studio.
• Conhecimentos basicos de T-SQL (CREATE TABLE, SELECT, ALTER TABLE).

Passo 1: Criar uma tabela de exemplo

Vamos comecar com uma tabela de clientes que guarda dados sensiveis. Executa o script seguinte para a criar e inserir alguns registos:

CREATE TABLE dbo.Clientes (
    ClienteID   INT IDENTITY PRIMARY KEY,
    Nome        NVARCHAR(100),
    Email       NVARCHAR(100),
    Telemovel   VARCHAR(20),
    Cartao      VARCHAR(19)
);

INSERT INTO dbo.Clientes (Nome, Email, Telemovel, Cartao)
VALUES
 (N'Ana Silva',   'ana.silva@email.pt',   '912345678', '4111111111111111'),
 (N'Bruno Costa', 'bruno.costa@email.pt', '936000111', '5500005555555559');

Passo 2: Aplicar mascaras as colunas sensiveis

Uma mascara define-se por coluna com a clausula ADD MASKED WITH (FUNCTION = '...'). Cada funcao esconde os dados de forma diferente. Vamos mascarar o email, o telemovel e o cartao:

-- email(): mostra a 1.a letra e o dominio -> aXXX@XXXX.com
ALTER TABLE dbo.Clientes
    ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');

-- partial(): mostra apenas os ultimos 3 digitos -> XXXXXX678
ALTER TABLE dbo.Clientes
    ALTER COLUMN Telemovel ADD MASKED WITH (FUNCTION = 'partial(0,"XXXXXX",3)');

-- default(): esconde o valor por completo -> XXXX
ALTER TABLE dbo.Clientes
    ALTER COLUMN Cartao ADD MASKED WITH (FUNCTION = 'default()');

A funcao partial(prefixo, preenchimento, sufixo) e a mais flexivel: o primeiro numero diz quantos caracteres iniciais manter, o texto entre aspas e o preenchimento visivel, e o ultimo numero quantos caracteres finais manter. Ja o default() aplica a mascara por omissao do tipo de dados — XXXX para texto, 0 para numeros e uma data fixa para datas.

Passo 3: Criar um utilizador para testar

As mascaras nao se aplicam a administradores (membros de db_owner), por isso nao veras qualquer efeito com a tua conta. Para o comprovar, cria um utilizador sem privilegios e da-lhe apenas permissao de leitura:

CREATE USER analista WITHOUT LOGIN;
GRANT SELECT ON dbo.Clientes TO analista;

Passo 4: Confirmar a mascara com EXECUTE AS

Podes assumir temporariamente a identidade desse utilizador para ver os dados exatamente como ele os veria, sem trocar de sessao:

EXECUTE AS USER = 'analista';
SELECT Nome, Email, Telemovel, Cartao FROM dbo.Clientes;
REVERT;

O resultado mostra os emails como aXXX@XXXX.com, o telemovel a terminar nos ultimos digitos e o cartao totalmente escondido. Os dados na base continuam intactos — so a apresentacao muda.

Passo 5: Conceder excecoes com UNMASK

Se um perfil especifico precisar de ver os valores reais (por exemplo, o apoio ao cliente), concede-lhe a permissao UNMASK. Desde o SQL Server 2022 e no Azure SQL podes faze-lo tambem ao nivel da coluna:

-- Acesso total aos valores reais
GRANT UNMASK TO analista;

-- Ou apenas a uma coluna (granular, SQL Server 2022 / Azure SQL)
GRANT UNMASK ON dbo.Clientes(Email) TO analista;

Para retirar a excecao mais tarde, usa REVOKE UNMASK .... Concede sempre o minimo necessario a cada perfil.

Verificar o resultado

Para listar todas as colunas mascaradas e a funcao aplicada, consulta a vista de sistema sys.masked_columns:

SELECT t.name AS Tabela, c.name AS Coluna, c.masking_function AS Mascara
FROM sys.masked_columns AS c
JOIN sys.tables AS t ON c.object_id = t.object_id
WHERE c.is_masked = 1;

Deves ver as tres colunas com a respetiva funcao de mascara. Se voltares a correr o SELECT com EXECUTE AS depois do GRANT UNMASK, os valores aparecem agora sem mascara.

Conclusao

Com poucas linhas de T-SQL protegeste dados sensiveis sem tocar na aplicacao nem duplicar tabelas. O proximo passo e definir a estrategia de excecoes: quem precisa mesmo de UNMASK e a que colunas. Lembra-te de que o masking e uma camada de apresentacao, nao de seguranca absoluta — combina-o sempre com controlo de acessos e, quando possivel, encriptacao. Que colunas da tua base merecem uma mascara ja hoje?