No meu último artigo: Saúde, sistemas de informação e LGPD,cujo link de acesso está no final desse artigo, falei sobre os cuidados que devem ser observados nos sistemas de informação para adequação a LGPD na área de saúde.
No entanto, poucos são os gestores do setor que realmente se preocupam com os Bancos de Dados e entendem a sua relevância para o perfeito funcionamento da empresa. Acham que esse assunto é de exclusividade da TI e que eles não precisam ter a menor gerência ou conhecimento.
Então, para que servem os tais Bancos de Dados? Simplesmente são os sistemas responsáveis pelo armazenamento e gerenciamento de todas as informações geradas pelos demais sistemas de informação utilizados pela empresa! Se eles pararem os demais sistemas cairão tais como em uma cadeia de peças de dominó, causando uma tragédia operacional!
Devido a sua função e relevância (servir de alicerce para os demais sistemas de informação) são fortemente impactados pelas mudanças advindas das varáveis internas (mudanças operacionais da própria empresa) e externas (mudanças mercadológicas e/ou legislativas) como é o caso por exemplo da adequação as normas da LGPD.
São nesses momentos específicos que os gestores se deparam com a importância da necessidade de um conhecimento básico sobre esses sistemas. Pois encontram enormes dificuldades em responder a perguntas simples e corriqueiras tais como: quais são os bancos de dados e para que são utilizados, onde são armazenados, quem é o responsável pela realização das cópias de segurança e principalmente, quem são as pessoas que possuem acesso direto as suas instâncias e backups! Essas perguntas tornam-se para os gestores dignas das maiores incógnitas do universo! As respostas, as essas questões, são fundamentais para melhorar e monitorar a qualidade da segurança desses sistemas.
De nada adianta termos toda uma segurança da informação na utilização sistêmica, quando os bancos de dados estão vulneráveis. O vazamento de um banco de dados assemelha-se ao rompimento de uma barragem, pois não teremos apenas um usuário afetado mais sim uma avalanche de dados e recheadas de agravantes, pois todo o relacionamento e as informações que normalmente ficam anonimizadas (dados relativos ao titular que não possam ser identificados) em uma operação sistêmica ficam à mercê de serem vistos e utilizados.
Como podemos observar, os bancos de dados devem ser considerados pelas empresas como tesouros dignos de um cofre de banco! Toda a severidade no acesso, não só aos bancos como aos seus backups, deve ser considerada insuficiente. Novas políticas de segurança e testes de invasão devem ser medidas corriqueiras e não esporádicas! Pois em caso de vazamento a catástrofe deverá ser anunciada e jamais escondida, como reza a LGPD.
Nos modernos sistemas de gerenciamento de bancos de dados (SGDBs) existem várias ferramentas que podem, ou melhor, devem ser implementadas tanto pelos gestores responsáveis pelos bancos de dados quanto pelas empresas de desenvolvimento das aplicações. Desde a simples DDM (Dynamic Data Masking) ou Mascaramento Dinâmico de Dados até as robustas criptografias.
Na DDM, temos a possibilidade de limitarmos a exposição dos dados pessoais (campos específicos) ou confidenciais aos usuários que não são autorizados a vê-los. Seu funcionamento é simples, criam-se regras de mascaramento dos dados que serão aplicadas nos resultados obtidos em resposta as consultas solicitadas. Por exemplo, podemos mascarar o CPF de forma que apenas os 3 (três) primeiros dígitos apareçam ou ainda, apenas o dia e mês de uma data de nascimento, ou apenas o nome da rua de um endereço, etc.
Apesar dessas limitações na exposição serem úteis, são consideradas medidas fracas no que tange a segurança da informação. Elas não impedem que os usuários que se conectam diretamente ao banco de dados, executem consultas abrangentes que exponham dados confidenciais além de não coibir as técnicas de inferência.
As técnicas de inferência são constituídas por consultas permitidas que podem chegar a resultados não permitidos. Servindo como exemplo, poderíamos citar um usuário que não possui o acesso ao faturamento de uma determinada empresa, no entanto ele possui o direito as consultas dos faturamentos realizados a cada venda. Se essas consultas puderem ser exportadas para uma planilha, por exemplo, facilmente se evidenciará o faturamento da empresa.
Na critptografia, técnica de maior robustez e consequente eficácia, que pode ou não trabalhar em conjunto com a DDM, os dados sofrem uma alteração em seu conteúdo original ocultando-os totalmente de visitantes não autorizados. Trata-se de um contraponto à DDM onde os dados são armazenados de forma íntegra e apenas as suas consultas são mascaradas. Portanto, temos a possibilidade de criptografar apenas um campo de uma tabela (senha de acesso, por exemplo) assim como todo o banco de dados e seus respectivos backups. Nesse momento, uma observação técnica se faz necessária, podemos ter campos criptografados e campos com DDM trabalhando harmonicamente, no entanto os campos que estão criptografados não podem passar pelo processo da DDM.
A robustez do processo de criptografia/ descriptografia é fundamentada por camadas hierárquicas. Cada camada criptografa a camada abaixo dela, causando um entrelaçamento de dependência um ao outro, implicando na total impossibilidade da descriptografia na falta ou inconsistência de um único elemento. Geralmente são utilizados 3 níveis hierárquicos.
Para entendemos melhor a utilização dessa técnica, explicaremos um pouco sobre o funcionamento do principal recurso de critptografia que integra o SQL Server Enterprise Edition 2008 e superior, o TDE – "Transparent Data Encrypton' (encriptação transparente de dados).
Esse recurso também é conhecido como criptografia de dados em repouso, pois o embaralhamento das informações é executado antes da gravação em disco e os dados são desembaralhados quando lidos para a memória, todo o caminho entre o servidor de bancos de dados e o computador no qual a informação será mostrada é realizado sem qualquer criptografia. Normalmente utilizado para proteger todo o banco de dados e seus respectivos backups.
As principais vantagens do TDE são:
- De fácil implementação
- Nenhuma alteração da aplicação é requerida. Sim! Se a sua TI for a responsável pelo seu banco de dados, ela sozinha poderá implementar a critptografia baseada no TDE.
- É totalmente invisível ao usuário.
- Não aumenta o tamanho do banco de dados.
As principais desvantagens do TDE são:
- Somente encripta os dados em repouso, armazenados no disco. Os dados em movimento (que viajam entre o servidor de banco de dados e o equipamento onde o dado será mostrado) não sofre qualquer tipo de encriptação.
- Todos os dados contidos no banco de dados são encriptados, e não somente os dados sensíveis.
- Necessita de uma versão mais cara do banco de dados (enterprise edition ou superior).
- A taxa de compressão dos backups compactados é significamente reduzida. Temos arquivos de backups maiores devido a utilização do recurso.
- A uma pequena redução na performance do banco de dados. O banco de dados irá demorar um pouco mais para enviar a consulta e/ou gravação da informação.
- Para restaurar o backup da instância em outro servidor ganha uma complexidade maior.
Não resta a menor dúvida que principalmente com os adventos da GPDR (Lei europeia de privacidade de dados) e da LGPD (Lei brasileira similar a europeia), o TDE ganhou uma nababesca relevância. Porém, como tudo na vida, nem tudo em criptografia são flores! Como vimos, temos prós, mas também temos contras em sua utilização que devem sim, ser levados muito a sério.
O correto é realizar um assessment (uma avaliação) criteriosa se possível multidisciplinar da sua empresa, dos seus servidores de banco, das suas aplicações, da sua infraestrutura, dos sistemas, etc. para somente depois decidir se irá implementar ou não a criptografia, pois como bem sabemos na área de saúde, a diferença entre o remédio e o veneno em muitos casos está na dose utilizada.
Fernando de Carvalho Caliço. analista de Sistemas, colaborador do Escritório Miranda Lima Advogados.
