none
Policie - Restringir Updates, Inserts e Deletes de usuários RRS feed

  • Pergunta

  • Amigos, boa noite !

    Gostaria de pedir a ajuda e opinião de vocês. O banco de produção ao qual trabalho, é administrado pelo DBA e por alguns desenvolvedores, os chamados "pai dos produtos". Sabemos que as alterações devem ser realizadas via procedures, mas em muitos casos, o usuário conecta no banco com o login / senha da aplicação (SQL Authentication) e consegue acesso as tabelas. Estamos mudando a maneira de autenticar para Windows Authentication e resolver de vez esse problema.

    Porém, estou querendo restringir o acesso dos usuários á essa tabela para operações DML, mas para isso pensei em criar uma policie "on change" para que ela faça o "rollback" da transação do usuário como se fosse uma trigger. Tem como fazer isso com policie? Se não, com trigger, róla de usar algum evento pra identificar que a transação veio do SSMS ou Query Analyzer e fazer o rollback de um update, insert ou delete do usuário?

    quarta-feira, 26 de setembro de 2012 00:16

Respostas

  • Bom Dia,

    O uso de Policies é indicado quando estamos olhando a estrutura dos objetos e não os dados da bases de dados. Não há como utilizar políticas para isso, visto que as facetas olham apenas características de estrutura. Se você está de olho nas operações DML, eu acredito que o uso da trigger é a solução mais trivial. Para saber se a alteração partiu de um SSMS, você pode utilizar a função APP_NAME().

    A sugestão do Roberto é mais interessante se for possível de implementar (isso é, se os pais do produto realmente não precisarem manipular os dados). Caso não seja possível, é interessante avaliar o uso de Application Roles. Esse recurso viabiliza que um usuário quando usado pela aplicação tenha os acessos e quando utilizado por outras aplicações (SSMS e QA por exemplo) não consiga fazer as operações desejadas.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    quarta-feira, 26 de setembro de 2012 11:52
  • Leonardo,

    a database role você "configura" da forma que achar melhor. Você pode até usar roles já existentes. Exemplo: se as alterações de dados realmente são feitas via procedures, você pode atribuir a role db_denydatawriter a todos os seus usuários e dar direito (grant) de execução nas procedures.

    Consequentemente, mesmo que eles se conectem no Management Studio, não conseguiram modificar qualquer dado de forma direta. Somente através das procedures.

    Faça o teste com alguns usuários. O uso de triggers pode baixar a performance das rotinas e o bloqueio através das roles tende a ter um overhead menor. Em alguns momentos as triggers realmente são necessárias, mas acredito que as roles podem cair bem para seu caso.

    Observação: tenho visto alguns softwares que estão fazendo o seguinte: quando um usuário é criado, ele é criado por um sistema (e não diretamente no Management Studio). Com isso, o sistema criptografa a senha do usuário e cria este usuário com a senha criptografada. Consequentemente, se este usuário acessar o Management Studio, não conseguirá se logar, pois na verdade a senha dele é outra.

    E nos sistemas, sempre que este usuário tenta fazer alguma coisa que precise da senha dele, o sistema criptografa a senha que está sendo digitada por ele e compara com a senha do SQL. Se forem iguais, continua.

    É um recurso interessante, apesar de nem sempre ser possível utilizá-lo, por diversos fatores. Principalmente pelo fato de isso envolver diretamente a equipe de programadores.

    Mas esses comentários foram só a título de informação.

    No seu caso, eu testaria as roles (database roles / application roles) primeiro. E se elas realmente não pudessem ser usadas, aí sim pensaria nas triggers.


    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br
    Email: contato@robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    quinta-feira, 27 de setembro de 2012 11:19

Todas as Respostas

  • Não seria mais interessante você criar uma DatabaseRole, atribuir a ela apenas direitos de leitura e escrita nas tabelas que quiser e, em seguida, atribuir esta Role aos seus usuários?

    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br
    Email: contato@robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    quarta-feira, 26 de setembro de 2012 10:50
  • Bom Dia,

    O uso de Policies é indicado quando estamos olhando a estrutura dos objetos e não os dados da bases de dados. Não há como utilizar políticas para isso, visto que as facetas olham apenas características de estrutura. Se você está de olho nas operações DML, eu acredito que o uso da trigger é a solução mais trivial. Para saber se a alteração partiu de um SSMS, você pode utilizar a função APP_NAME().

    A sugestão do Roberto é mais interessante se for possível de implementar (isso é, se os pais do produto realmente não precisarem manipular os dados). Caso não seja possível, é interessante avaliar o uso de Application Roles. Esse recurso viabiliza que um usuário quando usado pela aplicação tenha os acessos e quando utilizado por outras aplicações (SSMS e QA por exemplo) não consiga fazer as operações desejadas.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    quarta-feira, 26 de setembro de 2012 11:52
  • Então Roberson,

    mesmo com a database role, os usuários terão permissão pra alterar os dados, correto? E isso eu quero evitar.

    Pensei que havia alguma maneira de restringir via policie, não queria trabalhar com triggers, mas se não tem o overhead melhor, estou bem familiarizado com triggers DML e ás vezes fica aquela incógnita em usa-las. Gustavo, pelo que vi o uso das DML triggers mesclado com o APP_NAME() resolve meu problema. Já que essas tabelas não tem muitas operações de manipulação de dados.

    Obrigado pela ajuda pessoal !

    quarta-feira, 26 de setembro de 2012 23:43
  • Leonardo,

    a database role você "configura" da forma que achar melhor. Você pode até usar roles já existentes. Exemplo: se as alterações de dados realmente são feitas via procedures, você pode atribuir a role db_denydatawriter a todos os seus usuários e dar direito (grant) de execução nas procedures.

    Consequentemente, mesmo que eles se conectem no Management Studio, não conseguiram modificar qualquer dado de forma direta. Somente através das procedures.

    Faça o teste com alguns usuários. O uso de triggers pode baixar a performance das rotinas e o bloqueio através das roles tende a ter um overhead menor. Em alguns momentos as triggers realmente são necessárias, mas acredito que as roles podem cair bem para seu caso.

    Observação: tenho visto alguns softwares que estão fazendo o seguinte: quando um usuário é criado, ele é criado por um sistema (e não diretamente no Management Studio). Com isso, o sistema criptografa a senha do usuário e cria este usuário com a senha criptografada. Consequentemente, se este usuário acessar o Management Studio, não conseguirá se logar, pois na verdade a senha dele é outra.

    E nos sistemas, sempre que este usuário tenta fazer alguma coisa que precise da senha dele, o sistema criptografa a senha que está sendo digitada por ele e compara com a senha do SQL. Se forem iguais, continua.

    É um recurso interessante, apesar de nem sempre ser possível utilizá-lo, por diversos fatores. Principalmente pelo fato de isso envolver diretamente a equipe de programadores.

    Mas esses comentários foram só a título de informação.

    No seu caso, eu testaria as roles (database roles / application roles) primeiro. E se elas realmente não pudessem ser usadas, aí sim pensaria nas triggers.


    Roberson Ferreira - Database Developer
    Acesse: www.robersonferreira.com.br
    Email: contato@robersonferreira.com.br

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    quinta-feira, 27 de setembro de 2012 11:19