Como desabilitar comandos de banco de dados destrutivos?

Question

A maioria dos sysadmins entenderia o risco de que comandos destrutivos, como DROP ou DELETE, sejam executados por hackers para os bancos de dados SQL que eles gerenciam. Existe uma maneira de desativar completamente esses comandos de serem executados, talvez configurando MySQL / MS SQL / PostgreSQL, ou modificando o código-fonte se eles forem de código aberto, excluindo esses recursos perigosos.

 Once you have your webapp online,
 would someone with honorable intentions
 ever need to DROP a table?!

Esta poderia ser a solução do santo graal para a segurança do banco de dados "principal", em vez de tentar evitar esses comandos totalmente desnecessários. É claro que, durante os períodos de desenvolvimento ou manutenção, eles poderiam ser reativados e, em seguida, desativados quando não forem necessários.

    

Answer 1

Os disparadores DDL no SQL Server 2005 podem impedir que as tabelas sejam descartadas ou modificadas.

Se você limitar sua interação com o banco de dados a procedimentos armazenados, não precisará se preocupar com isso. A conta do aplicativo só pode executar procs armazenados - portanto, não haverá permissões para injeção de sql.

Se você não puder fazer isso, poderá remover os direitos para excluir e fazer qualquer tipo de DDL. Isso é melhor que nada. Mas se alguém quiser atualizar todos os seus dados com Nulos, eles podem.

Você terá um backup que será mantido atualizado se você tiver dados valiosos ou se descobrir fora de um trabalho / empresa.

    

Answer 2

Você não precisa modificar o código db porque isso já existe. É só que as pessoas não usam. A maioria dos aplicativos da Web precisa, no máximo, da capacidade de inserir, selecionar, atualizar, excluir e criar. Muitos processos de instalação acompanham o processo de usar um usuário privilegiado para criar as contas e os bancos de dados necessários com privilégios mínimos. O mediawiki do IIRC faz isso muito bem.

No entanto, não consigo contar o número de aplicativos da web que encontrei onde o usuário do db do aplicativo da web tem privilégios totais para o seu db ou o pior ainda para toda a instalação do db. Além disso, alguns aplicativos são criados de maneiras que exigem muitos privilégios. Ou não faça uso de contas privilegiadas e não privilegiadas internas para funções administrativas.

    

Answer 3

Parece que você pode querer verificar um firewall de banco de dados. O GreenSQL é um código aberto: link

Felicidades

    

Answer 4

Sim, quando meu banco de dados é de produção, talvez precise descartar tabelas temporárias que criei.

Se você é realmente paranóico, provavelmente deve ter seus desenvolvedores usando visualizações e procedimentos armazenados para que a conta que normalmente tem acesso às tabelas não possa manipular diretamente e, ao invés disso, tenha que acessá-los via view / procedure.

Pelo menos com o mysql você não precisa dar às contas a capacidade de criar e soltar tabelas. Reserve um tempo e veja o sistema permissões e limite as contas corretamente.

Outra opção que você poderia usar ao custo do desempenho seria executar todo o acesso através do Proxy do Mysql com um paranóico filtro que bloqueia tudo que você não gosta.

    

Answer 5

Isso não é diferente do acesso a arquivos. A conta do usuário deve ter os direitos mínimos absolutos necessários para realizar o trabalho. Permissões como descarte devem ser concedidas somente a uma conta de nível de administrador, a menos que seja absolutamente inevitável, caso em que o design do aplicativo talvez deva ser revisado. Excluir é frequentemente necessário, mas deve ser restrito apenas às tabelas em que é necessário.

O código não precisa ser modificado se o cuidado e o bom senso forem usados ao conceder permissões. A remoção completa de comandos potencialmente perigosos pode resultar em um sistema de banco de dados inatingível.

    

Answer 6

O que fizemos foi adicionar todos à função db_denydatawriter (somente SQLServer), o que remove quaisquer permissões de inserção, atualização e exclusão.

Em seguida, controlamos todo o nosso acesso ao banco de dados para nossos usuários da Web por meio de procedimentos armazenados. Desde que você não conceda a eles permissão para criar seus próprios procedimentos armazenados e desde que você não permita que eles executem SQL arbitrário dentro dos procedimentos armazenados, você estará bem bloqueado.

Isso vai além de não ser possível eliminar tabelas, mas se você não estiver usando procedimentos armazenados em todos os lugares, poderá enfrentar uma grande batalha ao converter seu código.