Fala, pessoal! Tudo certo?
Espero que sim!
Esses dias em uma conversa, foi-me apresentado um certo problema:
“Como realizar o processamento de dados que nem o criador do pipe pode visualizar?”.
Isso ficou em minha mente por algum tempo, pensei em uma solução que pode encaixar-se bem neste problema.
Então vamos lá! 🙂
Detalhando o problema
Imaginem que temos certos dados que são muito sensíveis em nossa empresa, como por exemplo:
- Religião
- Opção sexual
- Classe social
- Salário
- Etnia
Mesmo sendo administradores desses dados não deveríamos ter acesso à eles. Mas como engenheiro de dados, devemos lidar com esse problema de não poder ver os dados, mas precisar manipula-los.
No primeiro momento, podemos pensar que uma simples criptografia do campo já basta para tal situação. Porem, mesmo para criptografar, precisaríamos ver o dado antes, violando a premissa principal.
O caminho é por aí, mas temos alguns passos antes para garantirmos a premissa.
Como resolver esse problema?
Vamos usar um exemplo para ilustrar como poderíamos resolver esse problema.
Digamos que temos um sistema de RH que tem como saída a base de todos os funcionários contendo informações sensíveis, como salário por exemplo.
Precisamos criar um pipe que leia essa base, criptografe a informação e então carregue-a em um banco de dados.
No destino desses dados, uma aplicação contem a lógica para descriptografar segundo regras de negocio (usuários autorizados).
Abaixo o pipe as-is:
A estratégia aqui é termos 2 pipes.
No primeiro iremos montar o processo de ingestão e realizar todos os testes, nesse caso, teremos todos os acessos necessários e devemos mockar os dados.
O segundo será o pipe real, nesse caso, teremos siglas de sistema realizando o trabalho, sem a possibilidade de intervenção humana (acesso aos dados) no meio do processo.
Podemos chamar de pipe de desenvolvimento e um pipe de produção.
Esse tipo de coisa já pode estar implementada em sua esteira DevOps, a separação de ambientes é algo bem comum, inclusive para o mundo dos dados.
Abaixo como ficariam os ambientes separados:
Dessa maneira, poderíamos criar todo o processo de ingestão de dados criptografados no ambiente de desenvolvimento e então enviar essas alterações para o ambiente de produção, protegendo assim os dados sensíveis.
Poderíamos também, para proteger as chaves usar a tecnologia do vault, para guardar essas chaves de forma segura, sendo possível descriptografar quando o acesso for realmente necessário.
Precauções
Algumas precauções quando realizar esse tipo de processo.
- Schema
- É imprescindível que você conheça o schema dos dados, caso contrario você não poderá criar o processo no ambiente de desenvolvimento.
- Chaves
- É importante que essas chaves não estejam as mesmas para os dois ambientes.
- Código
- Provavelmente você irá utilizar um repositório de versionamento de códigos (git, github, bitbucket, etc..), então tome cuidado com senhas inclusas diretamente no código (hard coded).
- Checagem
- Verifique após o deploy para a produção se algum usuário autorizado pode checar os dados, no caso ilustrado, poderíamos perguntar ao gestor se os salários estão corretos.
Conclusão
Espero que tenham gostado dessa maneira que encontrei para lidar com esse problema, creio que deve haver outros padrões para lidar com esse tipo de situação, mas gostaria aqui de ilustrar ao menos uma! 😀
Se você achou outras formas de lidar com esse problema, por favor, compartilhe comigo! Ficarei feliz em saber como você lidaria com esse problema!
Um abraço e até a próxima!
🙂
