Início‎ > ‎

Evitar "super-usuários" para acessos a bases de dados

Uma boa prática normalmente utilizada pelos administradores de bancos de dados é a obrigatoriedade de autenticação nos acessos a qualquer base de dados. Embora benéfica do ponto de vista do banco de dados, esta prática gera um problema de gestão de identidades para as aplicações.

A solução mais usual é definir um usuário na base de dados para cada aplicação e fazer com que a própria aplicação faça o controle das permissões dos usuários. Esta arquitetura permite implementar facilmente o modelo de Clark-Wilson, levando ao problema conhecido como Confused Deputy, que consiste em enganar um sistema computacional de forma a usar seus privilégios indevidamente. Na maioria das vezes, o objetivo é conseguir uma elevação de privilégios pela manipulação das falhas de um sistema. No modelo de Clark-Wilson, os acessos aos dados são mediados por um sistema que implementa o conjunto de regras de acesso a estes mesmos dados. No caso mais comum, a aplicação tem acesso irrestrito à base de dados e a própria aplicação faz a gestão das permissões de cada usuário.

Ou seja, o modelo mais usado, que consiste em definir um único usuário de banco de dados para autenticar todos os acesso de uma determinada aplicação faz com que, caso exista uma vulnerabilidade na aplicação, seja possível realizar ataques de elevação de privilégios bem sucedidos. Em outras palavras, este modelo aumenta bastante o risco de acessos indevidos aos dados.

A melhor forma de mitigar este problema é garantir que cada usuário terá sempre o menor privilégio possível nos acessos às bases de dados. O ideal então é que as permissões adequadas a cada usuário sejam definidas tanto na aplicação quanto na base de dados e que o usuário seja autenticado nestas duas camadas, garantindo assim segurança em profundidade. Isto implica na necessidade de que os usuários e suas permissões sejam definidos tanto a aplicação quanto a base de dados, o que pode ocasionar problemas de inconsistência de permissões.

Para simplificar a gestão de usuários e permissões, é possível que a autenticação e autorização sejam feitas diretamente na base de dados. Neste caso, quando um usuário acessa a aplicação, esta faz a autenticação do usuário junto à base de dados e verifica também na base os acessos permitidos para o usuário. Com base nas informações recebidas da base de dados, a aplicação pode até ajustar os menus e opções mostrados ao usuário. No entanto, garante-se que, mesmo na presença de vulnerabilidades na aplicação, não será possível ao usuário acessar ou alterar dados para os quais não tem permissão. Este modelo traz também a vantagem de depender apenas dos mecanismos de controle de acesso das bases de dados, que são bastante maduros nos principais SGBDs, ao invés de depender de implementações de controle de acesso em aplicações que, normalmente, não tiveram o mesmo nível de testes.

Caso existam restrições quanto ao mapeamento de todos os usuários de uma aplicação para usuários da base de dados, pode-se também implementar o acesso às bases utilizando usuários com permissões diferentes conforme:
  1. Perfis de acesso: se for possível classificar os usuários em alguns poucos perfis de acesso, pode ser possível utilizar um usuário da base de dados para cada perfil, sempre definindo os mínimos privilégios necessários na base de dados.
  2. Funcionalidade ou módulo da aplicação: neste caso, a definição das permissões se dá com base na funcionalidade ou módulo da aplicação que requer acesso à base de dados. Com isto, é possível definir apenas os privilégios necessários para uma funcionalidade (ou conjunto de funcionalidades) específica da aplicação.
É importante notar que nos dois casos, a aplicação deverá ter a capacidade de se autenticar junto à base de dados utilizando todos os usuários cadastrados na base. Assim, sempre haverá o risco de ataques de Confused Deputy. Sempre haverá a possibilidade de que exista uma vulnerabilidade que, se explorada, permita escolher o perfil de acesso à base a ser utilizado.

Em último caso, sempre é possível definir um acesso de escrita e um acesso de leitura na base de dados. Assim, caso haja uma vulnerabilidade que permita alterar os comandos enviados para a base de dados (veja o item Evitar "command injection"), apenas funcionalidades que necessitem de acessos de escrita poderão ser subvertidas de forma a alterar dados na base. Esta solução traz uma pequena redução do risco sem contudo alterar drasticamente a forma de funcionamento da maioria das aplicações atuais.
Comments