Mascaramento de dados

O mascaramento de dados anonimiza colunas sensíveis no momento em que um branch é criado. Você anexa uma política de mascaramento à chamada de criação do branch, e as colunas correspondentes do novo branch são reescritas de forma irreversível — com hash, anuladas, truncadas ou substituídas — antes de o branch ficar acessível. O branch pai nunca é modificado.

Você recorre a isso para entregar dados com o formato de produção ao desenvolvimento, ao CI ou a um contratado sem entregar as PII contidas nele: formatos de tabela reais, contagens de linhas reais, e-mails falsos.

How it works

Uma política de mascaramento é um conjunto nomeado de regras com escopo de projeto. Cada regra corresponde a colunas por padrão e nomeia uma função de mascaramento embutida:

No momento da criação do branch, quando um masking_policy_id é fornecido:

1. O branch faz fork do seu pai normalmente (copy-on-write — instantâneo).
2. O branch entra no estado masking. Nenhum endpoint é provisionado e o proxy recusa conexões a ele: não há nenhuma janela em que os dados pré-mascaramento possam ser lidos.
3. Um worker de mascaramento se conecta ao compute do branch como um role de menor privilégio, descobre o esquema, faz corresponder suas regras contra ele e executa cada reescrita em uma única transação.
4. O branch aterrissa em ready e seus endpoints sobem — agora servindo apenas dados mascarados. Em qualquer falha, o branch aterrissa em failed e permanece selado; exclua-o e tente novamente.

As entradas das regras são tratadas como dados, nunca como SQL: os identificadores são citados e os valores dos argumentos são vinculados como parâmetros na execução, de modo que um nome de coluna ou constante hostil não consiga escapar da reescrita.

Built-in functions

O catálogo também é servido pela API:

curl -s https://api.test.kisenon.com/v1/masking-functions \
  -H "Authorization: Bearer $KISENON_API_KEY"

Managing policies

O mascaramento de dados está sendo lançado gradualmente. O editor de políticas e o menu suspenso de criação de branch descritos aqui estão sendo habilitados progressivamente; até o mascaramento estar ativo para a sua conta, a API responde 501 not_implemented e o console exibe um aviso de "ainda não disponível". Seus projetos não são afetados nesse meio-tempo.

No console, abra Project settings → Data masking para criar uma política: dê um nome a ela, adicione regras (colunas com padrão + um menu suspenso de função) e salve. A mesma superfície existe na API:

curl -s -X POST \
  https://api.test.kisenon.com/v1/projects/$PROJECT_ID/masking-policies \
  -H "Authorization: Bearer $KISENON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "dev-safe",
    "rules": [
      {"table_pattern": "users", "column_pattern": "email", "masking_fn": "mask_email"},
      {"table_pattern": "users", "column_pattern": "phone", "masking_fn": "mask_null"},
      {"table_pattern": "%", "column_pattern": "%ssn%", "masking_fn": "mask_ssn_partial"}
    ]
  }'

Depois crie um branch mascarado adicionando a política a uma chamada normal de criação de branch:

curl -s -X POST \
  https://api.test.kisenon.com/v1/projects/$PROJECT_ID/branches \
  -H "Authorization: Bearer $KISENON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "masked-dev", "masking_policy_id": "'$POLICY_ID'"}'

O branch reporta state: "masking" enquanto a reescrita roda; observe-o mudar para ready no console (ao vivo, via o stream de eventos do projeto) ou fazendo polling em GET /v1/branches/{id}.

Good to know

• O mascaramento é único, na criação. Editar uma política nunca afeta os branches que já foram criados com ela — eles mantêm o formato de dados com que nasceram. Recrie o branch para aplicar as novas regras.
• Uma política em uso não pode ser excluída. Excluir uma política com a qual um branch ativo foi criado retorna 409 policy_in_use; exclua esses branches primeiro.
• Regras sem correspondência são ignoradas, não fatais. Se o seu esquema mudou e um padrão não corresponde a nada, o branch ainda assim é concluído — verifique os padrões da regra se uma coluna que você esperava mascarada ainda tem o formato de dados real.
• Incompatibilidades de tipo fazem o branch falhar. Uma regra que corresponde a uma coluna que sua função não consegue reescrever (digamos mask_email em um integer) aborta todo o mascaramento — o branch aterrissa em failed e nunca é exposto pela metade mascarado.