NUNCA MAIS PASSE RAIVA POR NÃO CONSEGUIR RESOLVER UM PROBLEMA COM O EXCEL - GARANTIDO!
UNIVERSIDADE DO VBA - Domine o VBA no Excel Criando Sistemas Completos - Passo a Passo - CLIQUE AQUI
« Lição anterior | ![]() |
Δ Página principal | ![]() |
¤ Capítulos | ![]() |
Próxima lição » |
SQL Server 2005 - CURSO COMPLETO Autor: Júlio Battisti |
||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Lição 108 - Capítulo 06 - Dando permissões a objetos de um banco de dados | ||||||||||||||
As permissões a objetos aplicam-se aos diversos elementos de um Banco de Dados. Por exemplo, em uma tabela podemos ter permissão de leitura dos dados (SELECT), adição de novos registros (INSERT), exclusão de registros (DELETE) e assim por diante. As permissões objetos são as que mais diretamente se relacionam com as atividades diárias dos usuários do Banco de Dados. Por exemplo, se um determinado usuário utiliza uma aplicação que acessa o Banco de Dados no servidor SQL Server e este usuário deve ter permissão somente de leitura para os dados de uma determinada tabela, o incluímos em uma role com permissão SELECT na tabela e pronto, o usuário somente poderá consultar os dados. Na Tabela 6.22, temos a descrição das principais permissões a objetos. Tabela 6.22 Principais permissões de objetos do Banco de Dados:
Podemos atribuir estas permissões para usuários e roles do Banco de Dados. As considerações que podemos fazer em relação a atribuição de permissões para objetos do Banco de Dados ‑são as mesmas que fizemos para o caso de permissões para o Banco de Dados. Agora vamos aprender a atribuir permissões nos objetos do Banco de Dados Exemplo1, para usuários e roles. Depois vamos testar as permissões. Exemplo prático: Utilizando o SQL Server Management Studio, atribua as seguintes permissões indicadas na lista a seguir, para a tabela Clientes, do Banco de Dados Exemplo1, da instância SERVIDOR\SQL2005: SERVIDOR\user1: SELECT E INSERT SERVIDOR\user2: INSERT E DELETE role1: UPDATE e DELETE Para configurar as permissões sugeridas, siga os passos indicados a seguir: 1. Abra o SQL Server Management Studio, e navegue até o Banco de Dados Exemplo1, da instância SERVIDOR\SQL2005. 2. Dê um clique no sinal de mais ao lado de Exemplo1, para exibir as classes de objetos deste Banco de Dados. 3. Dê um clique no sinal de + ao lado da opção Tables, para exibir as tabelas do Banco de Dados. 4. Dê um clique como botão direito do mouse na tabela Clientes e, no menu que surge, dê um clique em Properties. Será exibida a janela de propriedades da tabela Clientes. 5. Nesta janela dê um clique na opção Permissions, no painel da esquerda. Surge a janela para definição de permissões da tabela Clientes. 6. A lista de users, com permissões está em branco. Então, o primeiro passo, é adicionar os Users SERVIDOR\user1, SERVIDOR\user2 e a role role1. Para fazer isso, clique no botão Add... Será aberta a janela Select User or Roles. Clique no botão Browse..., para exibir a lista de User e Roles disponíveis. Será aberta a janela Browse for Objects. Marque os users SERVIDOR\user1, SERVIDOR\user2 e a role role1, conforme exemplo da Figura 6.33. Clique em OK para fechar a janela Browse for Objects. Você estará de volta a janela Select Users and Roles. Clique em OK para fechar esta janela. Você estará de volta a guia Permissions, da janela de propriedades da tabela Clientes, do banco de dados Exemplo1.
7. Para definir as permissões para cada usuário/role, é só selecionar o respectivo usuário na lista User or roles e, na parte de baixo da janela, definir as permissões para o usuário/role selecionado. A exemplo do que ocorre com as permissões de banco de dados, as permissões para objetos de um banco de dados, também podem ser permitidas (Allow) ou negadas (Denny). 8. Clique no user SERVIDOR\user1, para selecioná-lo. Marque as permissões SELECT e INSERT, na coluna Allow, para dar estas permissões para o usuário SERVIDOR\user1. 9. Clique no user SERVIDOR\user2, para selecioná-lo. Marque as permissões INSERT e DELETE, na coluna Allow, para dar estas permissões para o usuário SERVIDOR\user2. 10. Clique na role role1, para selecioná-la. Marque as permissões UPDATE e DELETE, na coluna Allow, para dar estas permissões para a role role1, conforme indicado na Figura 6.34:
11. Definidas as permissões propostas no nosso exemplo, dê um clique em OK para fechar a janela de propriedades da tabela Clientes. 12. A pergunta é: “Qual a permissão efetiva para os usuários SERVIDOR\user1 e SERVIDOR\user2, na tabela Clientes, do banco de dados Exemplo1, com base nas permissões atribuídas no nosso último exemplo? Vamos analisar com calma. Primeiro: O usuário SERVIDOR\user1 pertence a role role1, portanto o usuário user1 herdará as permissões desta role. Portanto o usuário SERVIDOR\user1 acumulará as permissões explicitamente atribuídas para ele – SELECT e INSERT – e as herdadas da role role1 – UPDATE e DELETE. Com isso a permissão efetiva do usuário SERVIDOR\user1 será: SELECT INSERT UPDATE DELETE Ou seja, o usuário poderá selecionar, inserir, alterar e excluir registros. Exercício: Determine as permissões efetivas do usuário SERVIDOR\user2 na tabela Clientes. Também podemos definir as permissões de Banco de Dados, utilizando comandos T-SQL. Para atribuir permissões de objetos do Banco de Dados utilize o comando GRANT. Sintaxe para o comando GRANT: GRANT { ALL [ PRIVILEGES ] | permission [ ,...n ] } { [ ( column [ ,...n ] ) ] ON { table | view } | ON { table | view } [ ( column [ ,...n ] ) ] | ON { stored_procedure | extended_procedure } | ON { user_defined_function } } TO security_account [ ,...n ] [ WITH GRANT OPTION ] [ AS { group | role } ] Como a sintaxe completa não é muito amistosa, vamos utilizar alguns exemplos para ilustrar a utilização do comando GRANT. Exemplo 1: Garantir para o usuário SERVIDOR\user1, a permissão de selecionar novos registros e atualizar os registros existentes, na tabela Clientes do Banco de Dados Exemplo1: Use Exemplo1 GRANT SELECT, UPDATE ON Clientes TO [SERVIDOR\user1] Quando o login for um usuário do Windows, o nome deve vir entre colchetes, como no exemplo: [SERVIDOR\user1] Podemos atribuir mais do que uma permissão ao mesmo tempo, para um ou mais logins ou usuários. Exemplo 2: Garantir para os usuários SERVIDOR\user1 e SERVIDOR\user2, a permissão de selecionar novos registros, atualizá-los e exclui-los, na tabela Clientes do Banco de Dados Exemplo1: Use Exemplo1 GRANT SELECT, UPDATE, DELETE ON Clientes TO [SERVIDOR\user1], [SERVIDOR\user2] Exemplo 3: Atribuir todas as permissões para o usuário SERVIDOR\user2, na tabela Clientes do Banco de Dados Exemplo1. USE Exemplo1 GRANT ALL ON Clientes TO [SERVIDOR\user2] Observe que utilizamos a palavra ALL, para significar todas as permissões. Para uma descrição completa, de todas as opções do comando GRANT, consulte o tópico Transact SQL Reference, no Books OnLine. Para retirar (revoke) as permissões de objetos do Banco de Dados utilize o comando REVOKE. Sintaxe para o comando REVOKE: REVOKE [ GRANT OPTION FOR ] { ALL [ PRIVILEGES ] | permission [ ,...n ] } { [ ( column [ ,...n ] ) ] ON { table | view } | ON { table | view } [ ( column [ ,...n ] ) ] | ON { stored_procedure | extended_procedure } | ON { user_defined_function } } { TO | FROM } security_account [ ,...n ] [ CASCADE ] [ AS { group | role } ] Como a sintaxe completa não é muito amistosa, vamos utilizar alguns exemplos para ilustrar a utilização do comando REVOKE. Exemplo 1: Retirar a permissão UPDATE, atribuída para o usuário SERVIDOR\user1, anteriormente. USE Exemplo1 REVOKE UPDATE ON Clientes TO [SERVIDOR\user1] Podemos retirar mais do que uma permissão ao mesmo tempo, para um ou mais usuários. Exemplo 2: Retirar as permissões SELECT, UPDATE E DELETE, atribuídas para o usuário SERVIDOR\user1 na tabela Clientes do Banco de Dados Exemplo1. USE Exemplo1 REVOKE SELECT, UPDATE, DELETE ON Clientes TO [SERVIDOR\user1] Exemplo 3: Retirar todas as permissões atribuídas ao usuário SERVIDOR\user2, na tabela Clientes do Banco de Dados Exemplo1. USE Exemplo1 REVOKE ALL ON Clientes TO [SERVIDOR\user2] Observe que utilizamos a palavra ALL, para significar todas as permissões. Para negar (negar) as permissões de objetos do Banco de Dados utilize o comando DENY. Sintaxe para o comando DENY: DENY { ALL [ PRIVILEGES ] | permission [ ,...n ] } { [ ( column [ ,...n ] ) ] ON { table | view } | ON { table | view } [ ( column [ ,...n ] ) ] | ON { stored_procedure | extended_procedure } | ON { user_defined_function } } TO security_account [ ,...n ] [ CASCADE ] Como a sintaxe completa não é muito amistosa, vamos utilizar alguns exemplos para ilustrar a utilização do comando DENY. Exemplo 1: Negar permissão UPDATE, para o usuário SERVIDOR\user1, na tabela Clientes, do Banco de Dados Exemplo1. USE Exemplo1 DENY UPDATE ON Clientes TO [SERVIDOR\user1] Podemos negar mais do que uma permissão ao mesmo tempo, para um ou mais usuários. Exemplo 2: Negar as permissões SELECT, UPDATE E DELETE, para o usuário SERVIDOR\user1, na tabela Clientes do Banco de Dados Exemplo1. USE Exemplo1 DENY SELECT, UPDATE, DELETE ON Clientes TO [SERVIDOR\user1] Exemplo 3: Negar todas as permissões atribuídas ao usuário SERVIDOR\user2, na tabela Clientes do Banco de Dados Exemplo1. USE Exemplo1 DENY ALL ON Clientes TO [SERVIDOR\user2] Observe que utilizamos a palavra ALL, para significar todas as permissões. Na Figura 6.35, temos a janela com as permissões da tabela Clientes, após a execução do comando do Exemplo 3:
Observe que todas as permissões foram negadas para o usuário SERVIDOR\user2, com exceção de permissões tais como Alter, Control, Take Ownership e outras, as quais não se aplicam a tabelas, e sim a outros objetos de um banco de dados, tais como Views e Stored Procedures. E para finalizar, mais um pequeno exercício. Exercício: Considerando a situação descrita na Figura 6.36, determine as permissões efetivas para os usuário user1, user2, user3, user4 e user5, na tabela Produtos do Banco de Dados Exemplo1.
Observe que à medida que novas permissões vão sendo atribuídas pode ser difícil de terminar o real nível de acesso de cada usuário, a cada objeto, de cada um dos bancos de dados. Para que você possa manter um controle sobre a atribuição de permissões, faço as seguintes sugestões: ® Mantenha uma documentação sobre as atribuições de permissão. É chato? É. Ninguém gosta? Ninguém gosta. Porém a documentação é de fundamental importância, pois se não tivermos um controle sobre as atribuições de permissão, podemos chegar a situações onde usuários que não devem ter acesso estão tendo e usuários que devem ter acesso não estão tendo, enfim, uma grande bagunça. ® Procure sempre atribuir permissões à roles e não aos usuários individualmente. Isto facilita bastante a administração das permissões. |
||||||||||||||
« Lição anterior | ![]() |
Δ Página principal | ![]() |
¤ Capítulos | ![]() |
Próxima lição » |
Universidade do Access - Curso Completo de Access
com tudo para você dominar o Access - do Básico ao
Avançado - até a Criação de Sistemas Profissionais
Completos - Passo a Passo - Tela a Tela
Aplica-se ao Access 2019, 2016, 2013 e 2010!
Para todos os detalhes, acesse:
Contato: Telefone: (51) 3717-3796 | E-mail: webmaster@juliobattisti.com.br | Whatsapp: (51) 99627-3434
Júlio Battisti Livros e Cursos Ltda | CNPJ: 08.916.484/0001-25 | Rua Vereador Ivo Cláudio Weigel, 537 - Universitário, Santa Cruz do Sul/RS, CEP: 96816-208
Todos os direitos reservados, Júlio Battisti 2001-2025 ®
LIVRO: MACROS E PROGRAMAÇÃO VBA NO EXCEL 2016 - CURSO COMPLETO E PRÁTICO
DOMINE A PROGRAMAÇÃO VBA NO EXCEL - 878 PÁGINAS - CLIQUE AQUI