none
Permissoes em todas as tabelas RRS feed

  • Pergunta

  • Boa tarde senhores.

    Temos um sistema que será acessado pelos usuários usando Windows authentcation.

    O sistema devera ter acesso ao BD apenas por procedures. Não permitiremos querys soltas no sistema.

    Pergunta: Qual a melhor maneira de nega o select nas tabelas do schema do sistema?

    Tentei revogar o privilegio de select para o public mas não foi possível.

    Fiz as querys:

    select 'deny select on  pda.' + name + ' to [domain\user01] ;' from sys.tables where schema_id = 6

    select 'deny select on  pda.' + name + ' to [domain \ user01] ;' from sys.views where schema_id = 6

    para retirar o privilegio em tabelas e views, mas não achei isso muito otimizado.

    Reparem que terei que repetir o deny para todos os usuários.

    Alguem tem uma ideia mais ágil ??

    (SQL Server 2008)

    Obrigado

    segunda-feira, 14 de julho de 2014 18:45

Respostas

  • Bom dia Junior.

    Não vejo problemas na primeira questão. Você nega select nas tabelas e da grant exec nas procedures.

    Já fiz isso... E funciona perfeitamente.

    Passei a usar o AD. Isso resolveu o problema do primeiro post: " repetir o deny para todos os usuários."

    Obrigado pelo retorno.

    quarta-feira, 16 de julho de 2014 15:33

Todas as Respostas

  • Apareceu um problema.

    Como ninguém deve ter permissão de select nas tabelas ou views, executei o deny select para todos os usuários nas tabelas e views.

    E executei grant exec em todos as procedures para a role dos usuários.

    Porem as proceudres não executam. Da mensagem de permissão negada para select nas views.

    Quando eu dei o grant de exec na procedure isto não deveria ter sido contornado?

    Como resolver este problema ?

    Coloco um "executar como" em todas as procedures.

    Obrigado. 

    terça-feira, 15 de julho de 2014 13:33
  • Bom dia Ceilton,

    Acredito que o principal problema que você pode estar passando é relacionado com "database ownership chaining".

    Da uma olhada nesse post do Gustavo Maia, esta bem didático a explicação: 

    http://gustavomaiaaguiar.wordpress.com/2009/06/28/o-que-e-cross-database-ownership-chaining/

    Já relacionado a maneira de negar permissão, você pode utilizar o script da seguinte maneira para otimizar:

    Exemplo: DENY SELECT ON Schema::Customers FROM Role/User



    Att, Bruno Silva.

    terça-feira, 15 de julho de 2014 15:09
  • Bom dia Bruno.

    Li o post do Gustavo. Mas meu problema não é de acesso a bancos de dados diferentes. É tudo no mesmo banco.

    A view e a procedure estão no mesmo esquema. Os usuários tem permissão de exec na procedure e permissão de select negada na view (Deny select). Ao executar a procedure, aparece mensagem de permissão de selct negada na view.

    Coloquei um "execute as" na procedure para um usuário com permissão de select na view e funcionou.

    Mas por que o grant exec na procedure não permitiu que a view fosse vista de dentro da procedure ???

    terça-feira, 15 de julho de 2014 15:36
  • Ceilton,

    O mesmo acontece por causa do Ownership Chain, o usuário a executar a procedure precisa de permissões de acesso aos objetos que a procedure acessa, a não ser que você mude esse comportamento, que você fez ao adicionar o execute as.

    Veja:

    http://technet.microsoft.com/en-us/library/ms188676(v=sql.105).aspx

    http://sqlmag.com/sql-server/security-through-ownership-chains

    Abs;

    quarta-feira, 16 de julho de 2014 15:02
  • Ceilton DBA,

    Cara me diga uma coisa, se os usuários não podem fazer Select em Tabelas e Views!!!

    Como os mesmos vão conseguir utilizar uma Stored Procedure? Pois provavelmente a Procedure vai fazer acesso a dados em alguns casos?

    Outro ponto importante, a Database Role Public não pode ser alterada, o SQL Server não permiti isso, por padrão todo e qualquer usuário faz parte da Public e pelo menos o Select ele vai poder fazer.

    Neste caso, você pode alocar estes usuários em outra Roles ou Schemas e negar permissões para estes objetos!!!

    Entendo que você terá que analisar melhor a sua necessidade, pensando que os usuários podem ter acesso a aplicação via AD, mas internamente a aplicação vai fazer acesso a dados através de uma conta específica criada para manipular determinadas funcionalidades ou dados.

    Se os usuário vão poder somente executar Procedure, queira ou não queira as Procedures vão manipular internamente seus dados que estão alocados em tabelas.

    Se é para evitar acesso as tabelas, então trabalhe com Views.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    quarta-feira, 16 de julho de 2014 15:19
    Moderador
  • Bom dia Junior.

    Não vejo problemas na primeira questão. Você nega select nas tabelas e da grant exec nas procedures.

    Já fiz isso... E funciona perfeitamente.

    Passei a usar o AD. Isso resolveu o problema do primeiro post: " repetir o deny para todos os usuários."

    Obrigado pelo retorno.

    quarta-feira, 16 de julho de 2014 15:33
  • O DENY é mais restritivo e sobrepõe outras permissões.

    Faça um REVOKE dos DENY que você aplicou e execute a Stored Procedure (que já recebeu o GRANT EXEC)


    Alex Rosa - Premier Field Engineer - Data Platform

    Disclaimer: This content is provided "as-is" and without warranties of any kind, either express or implied. You should therefore verify any information contained in the content before acting on it.


    quarta-feira, 16 de julho de 2014 22:41