Continuando o post sobre usuários, neste, vamos distribuir permissões para execuções de comando, criar grupos de permissões de acordo com o nível de responsabilidade e alterar permissões a nível de servidor utilizando as server roles.
NOTA: Os comandos aqui foram testados no SQL Server e no Azure SQL, com a mesma sintaxe
CRIANDO ROLES DE BANCOS (USER-DEFINED ROLES)
As roles personalizadas de banco de dados podem ser muito úteis quando temos uma equipe de usuários muito grande e que ficaria confuso dar permissão para cada um de forma individual.
Ainda dentro das roles podemos negar ou permitir autorizações específicas para um determinado SCHEMA caso as tabelas sejam organizadas dessa forma.
Procedures e Views também podem ser negadas ou autorizadas de acordo com a role e o perfil do usuário;
As permissões são gerenciadas por três comandos: GRANT, DENY E REVOKE;
Não há uma hierarquia definida, porém, um comando sobrepõe o outro e vale o último comando aplicado;
NOTA: Mesmo que um usuário esteja em uma role de banco com o perfil autorizado a executar SELECT e o DBA aplicou DENY SELECTa este usuário, o Deny sobrepõe a permissão da role.
SINTAXE PARA CRIAÇÃO E ALTERAÇÃO DE ROLES NO BANCO
A criação de role é feita por um comando bem simples mas, que precisa ser executado no banco em questão, onde as permissões serão gerenciadas.
Então, quando for executar, não esqueça de alterar para o seu banco
ATRIBUINDO PERMISSÃO PARA USUÁRIOS E ROLES
Para atribuir permissão utilizamos o comando GRANT, e junto com o GRANT, podemos atribuir a este usuário a autorização para que ele também possa dar permissão a outros.
Abaixo temos alguns exemplos de como manusear o comando e suas permissões aplicando também para operações como insert e delete.
TRATANDO PERMISSÕES DE SCHEMA DO BANCO
Ainda com o GRANT, é possível liberar o acesso a determinados SCHEMAS do banco. Veja abaixo.
Nota: o comando REVOKE revoga a última ação que foi realizada para um determinado usuário. Se no comando anterior foi aplicado um GRANT SELECT, o REVOKE irá desfazer essa permissão, revogando o GRANT.
EXTRA: PROCEDURE ENTRE DOIS BANCOS
Se por um acaso houver uma procedure que faça uma consulta em outro banco, mas o usuário que está executando possui acesso a somente um banco, esse comando irá retornar uma falha de acesso e permissão.
Na primeira imagem, temos o resultado da procedure que foi executada por um usuário com permissão nos dois bancos.
Na segunda imagem temos o resultado da procedure executada por um usuário com acesso apenas em um dos bancos:
Como podem ver, a proc executou um consulta retornando a quantidade de linhas que o primeiro select encontrou no prim21eeiro banco e select. Porém, como este usuário não possui acesso ao segundo banco, a query não retornou e encerrou a operação com erro.
No Azure SQL essa situação é um pouco diferente. Mesmo com autorização nos dois bancos, o usuário não consegue referenciar outro banco, pois o engine do Azure SQL não permite.
Assim, finalizo a primeira parte deste post, para ele não ficar mais extenso do que já está e no próximo, abordarei mais algumas situações e finalizo essa parte do conteúdo.
E os scripts que foram usados aqui, estarão no github!!
Saúde!
ManageBI 