Por Edwin Marinho
Soluções automatizadas ou semiautomatizadas de migração de dados têm sido constantemente adotadas para otimizar processos de engenharia de software. Este tipo de processo visa gerenciar de forma incremental as mudanças ocorridas em bancos de dados relacionais. No entanto, essa prática pode se tornar potencialmente nociva quando usuários de bancos de dados possuem permissões além do necessário, o que pode facilitar o trabalho de um cibercriminoso que tenta ganhar privilégios em um sistema.
As rotinas de migração de dados são comumente realizadas através de linguagens de programação, frameworks ou ferramentas independentes (como Flyway ou Liquidbase). Alguns frameworks, como Rails e Django, possuem suas próprias ferramentas para execução desse tipo de tarefa. Entretanto, bibliotecas de mapeamento objeto-relacional, como o GORM para Golang, oferecem tanta flexibilidade no recurso de migração que se torna tentadora a inclusão desses processos diretamente no código da aplicação.
Nestes cenários mais flexíveis, vulnerabilidades referentes ao acesso a dados pela aplicação, como SQL Injection, darão muito mais poder para um atacante, possibilitando explorar tanto os dados quanto a estrutura do banco. Além disso, as credenciais para acesso ao banco de dados nas aplicações, geralmente, ficam em arquivos de configuração, que dão margem para outros tipos de ataques, incluindo a tentativa de acesso direto à base de dados. Um atacante poderia, por exemplo, criar triggers que silenciosamente alterariam valores em tabelas específicas.
Restringindo os privilégios
Como boa prática, é prudente fornecer o mínimo de privilégios possível para que os usuários ou aplicações de terceiros interajam com determinados sistemas. Isso não é diferente no caso de bancos de dados. A preocupação adicional nessas situações está relacionada aos privilégios que a aplicação terá em relação à definição e manipulação dos registros. Rotinas de migração em bancos de dados relacionais normalmente exigem permissões tanto de DDL (Data Definition Language) como de DML (Data Manipulation Language).
Desta forma, a recomendação é que rotinas de migração de dados sejam realizadas com um usuário diferente do que será utilizado pela aplicação. Além disso, o usuário da aplicação deve possuir privilégios restritos, podendo apenas executar operações estritamente definidas em tabelas específicas, diminuindo os riscos inerentes de uma potencial vulnerabilidade. É importante notar que esta recomendação também é aplicável no uso de frameworks que segregam as funcionalidades de aplicação e de migração.
Bancos de dados relacionais como o PostgreSQL permitem, por exemplo, limitar algumas operações (SELECT, INSERT, UPDATE, DELETE, CREATE, etc.) para usuários em tabelas específicas. Este tipo de funcionalidade auxilia na restrição do que o usuário do banco de dados da aplicação pode fazer. Também se torna possível garantir que o próprio desenvolvedor possua recursos distintos ao programar para migração de dados ou para aplicação, evitando a inclusão de falhas advindas de privilégios que não deveriam ser concedidos à aplicação.
É importante destacar: mesmo em caso de ataques explorando vulnerabilidades do tipo SQL Injection ou de roubo de credenciais, não seria possível para um atacante hipotético explorar privilégios adicionais concedidos a um usuário de aplicação em um ambiente onde estes privilégios não foram concedidos. Ou seja, garantir a segurança em vários níveis reduz os potenciais danos de uma vulnerabilidade, mesmo que ela ainda não tenha sido detectada.
