Evitando que os usuários excluam dados SQL

Question

Acabamos de adquirir um programa que exige que os usuários tenham uma conta no servidor MS SQL, com acesso de leitura / gravação ao banco de dados do programa.

Minha preocupação é que, como esses usuários agora terão acesso de gravação ao banco de dados, eles poderiam se conectar diretamente ao servidor SQL fora do cliente do programa e depois mexer com os dados diretamente nas tabelas.

Existe alguma maneira que eu possa impedir o acesso ao banco de dados enquanto ainda permitir acesso através do programa cliente?

Editar: SQL 2008 Express, pode atualizar para o SQL 2008 R2 Standard, se necessário.

Toda estação de trabalho precisará de acesso para que as pessoas registrem seu horário / horário. As estações de trabalho estão bloqueadas, então ninguém tem osql, gerente de estúdio ou qualquer coisa assim. No entanto, eles poderiam configurar uma fonte de dados ODBC e, em seguida, conectar-se via Excel / Access.

Pensando nisso agora, mexer com os dados não é mais uma preocupação maior, há questões de privacidade, já que as taxas de pagamento de todos, etc., estarão neste sistema.

Concordo que é um design muito ruim.

    

Answer 1

Não. Se os usuários tiverem acesso de leitura / gravação ao banco de dados e puderem se conectar a ele sem usar o programa, poderão fazer algo como UPDATE sometable SET attribute = NULL; e destruir seu conjunto de dados ou fazer qualquer alteração arbitrária que quiserem.

Infelizmente, as permissões de SQL não têm a capacidade de expressar o conceito de alterações normais versus maliciosas feitas por pessoas que de outra forma teriam acesso, e eu suspeito que negar permissão para atualizar os registros seria um tanto autodestrutivo.

Assim como o comentário de Joel, eu estaria pedindo um reembolso se isso for uma preocupação em seu ambiente. Mantenha backups e logs frequentes;)

Se você tiver uma maneira de impedir que os logins não usem o aplicativo (por exemplo, restringindo conexões a uma única fonte, se seu aplicativo for executado através de serviços de terminal ou citrix), você pode definitivamente usá-lo para melhorar a segurança.

    

Answer 2

Estou um pouco atrasado nisso, e concordo que você deve apontar o culpabilizador para os desenvolvedores do aplicativo e eu colocaria minhas preocupações por escrito e conseguiria alguém com poder político para entender os riscos, mas espero dar você mais algumas opções.

Se eu estivesse realmente preso, procuraria criar um acionador para o evento LOGON. No gatilho, eu encontraria uma maneira de discriminar entre o que chamarei de logon "legítimo" e um logon "ilegítimo" e impedir que os ilegítimos sejam concluídos. Os logons legítimos seriam os usuários se conectando ao banco de dados adequado com o aplicativo adequado, além de logins administrativos, logins de tarefas, etc. que você possa precisar. Eu tomaria muito cuidado ao escrever isso, já que parece ser uma boa maneira de se trancar para fora do servidor. BOL diz que os LOGON TRIGGERS estão disponíveis no SQL 2008, tenho certeza que eles estão disponíveis no Express.

O problema com essa tática é que você pode se ver jogando "whack-a-mole", onde você exclui o Excel e o Access, e então alguém descobre como escrever um aplicativo vb.net rápido que permite que eles entrem, então Se você bloquear isso, alguém modifica a string de conexão para alterar o nome do aplicativo, etc. Quanto mais experientes forem os usuários, mais difícil será pará-los. Se você tem desenvolvedores, eles podem ver isso como um desafio. Eu diria que qualquer um que esteja tentando agressivamente encontrar uma maneira de contornar os controles de segurança, mesmo que esses controles não sejam perfeitos, é um problema. (Se eu trancar a porta de tela em minha casa, é bastante óbvio que não quero que ninguém entre. Se alguém usar um canivete para cortar a tela e entrar, eles certamente fizeram algo errado.)

Outra coisa a fazer é simplesmente executar uma consulta nas DMVs para encontrar usuários que não estejam jogando pelas regras. Você pode obter informações de nome de usuário, host e aplicativo dos DMVs do sistema. Se você executar a consulta periodicamente (uma vez por minuto ou mais) e salvar os resultados em uma tabela, poderá dar uma olhada todos os dias (ou semana) e, em seguida, executar rap nos atores mal-intencionados. Ou faça o RH fazer isso.

Outra coisa a tentar é, se você tiver algo que procure e relate consultas demoradas, pode procurar por consultas "estranhas". Na verdade, peguei alguém fazendo algo uma vez, enquanto revia logs para consultas de problemas. Freqüentemente, usuários inexperientes que estão pesquisando executam consultas ineficientes que lêem muitos dados ou causam bloqueios de longa duração. Às vezes, se o aplicativo tiver um "estilo" certo e definido para a maneira como ele escreve as consultas, você pode escolher as consultas que são escritas por alguém (ou algo assim). IOW, para usar um exemplo muito artificial, há uma grande diferença entre:

selecione * do salário onde empregado="eu"

e

selecione * na ordem salarial por salary_amount

Para resumir: Consertar o aplicativo seria melhor. Evitar logins pode ser OK. Tentar encontrar violadores depois do fato pode ser tudo o que você pode fazer.