Júlio Battisti Livros e Cursosa sua sala de aula na internet

Para um Banco de Dados, podemos definir, dentre outras, as seguintes permissões:

® Create Table (Criar Tabela).

® Create View (Criar Consulta).

® Create SP (Criar Stored Procedure).

® Create Default.

® Create Rule.

® Create Function.

® Backup DB (Backup do Banco de Dados).

® Backup Log (Backup do Log de transações).

Podemos atribuir estas permissões para usuários e roles do Banco de Dados. Devemos sempre ter em mente, as seguintes regras:

® Uma permissão pode ser atribuída ou negada.

® Podemos atribuir ou negar permissões para usuários e roles.

® O usuário herda todas as permissões das roles as quais ele pertence.

® Negar tem precedência sobre permitir. Por exemplo, se um usuário pertencer a três roles – role1, role2 e role3. A role1 tem permissão para criar tabelas – Create Table. A role2 tem permissão para criar consultas – Create View. Com isso o usuário herda as permissões para criar tabelas e consultas. A role3 têm negadas as permissões para criar tabelas e consultas. Como negar tem precedência sobre permitir e, o usuário pertence às três roles, o usuário terá negadas as permissões para criar tabela e consultas. A permissão efetiva deste usuário será: Negada as permissões para criar tabelas e consultas.

® Procure agrupar os usuários que tem necessidades de acesso iguais em uma role. Atribua as permissões para a role em vez de atribuir para os usuários individualmente. Este procedimento irá facilitar bastante a administração de segurança e da administração das permissões de acesso no SQL Server 2005.

Agora vamos aprender a atribuir permissões 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 para o Banco de Dados Exemplo1, da instância SERVIDOR\SQL2005:

® Usuário: SERVIDOR\user1.

® Permitir: Create Table, Create View.

® Negar: Backup database, Backup Log.

® Role: role1

® Permitir: Create View, Backup database, Backup Log e Create rule.

Lembre que o usuário SERVIDOR\user1 é membro da role role1. Outro detalhe é que esta role ainda não foi adicionada como um User com permissão de acesso ao banco de dados Exemplo1. Faremos isso também, no decorrer do exemplo prático a seguir.

Para configurar as permissões sugeridas, siga os passos indicados a seguir:

1. Abra o SQL Server Management Studio.

2. Na janela Object Explorer, navegue até o Banco de Dados Exemplo1, da instância SERVIDOR\SQL2005.

3. Dê um clique com o botão direito no Banco de Dados Exemplo1, e no menu de opções que surge, dê um clique em Properties.

4. Na janela de propriedades do Banco de Dados Exemplo1, dê um clique na opção Permissions. Surge a janela indicada na Figura 6.29.

Figura 6.29 Definindo permissões para o Banco de Dados Exemplo1.

Nesta janela podemos configurar as permissões para o Banco de Dados. Na parte de cima temos uma lista com todos os usuários do Banco de Dados (observe que a Role role1 não faz parte desta lista). Na parte de baixo da janela podemos configurar as diversas permissões disponíveis, para o User selecionado na parte de cima.. Por padrão a permissão vem desmarcada, o que significa que o usuário não tem esta permissão. Antes de configurarmos as permissões, vamos adicionar a role role1, a lista de Users do banco de dados. Para isso, clique no botão Add... Será aberta a janela Select Users or Roles. No campo Enter the object names..., digite role1 e clique em OK.  Pronto, agora a role role1 faz parte da lista de users do banco de dados Exemplo1.

5. Vamos começar definindo as permissões para o User SERVIDOR\user1. Na parte de cima da janela, clique no User SERVIDOR\user1, para selecioná-lo e, na parte de baixo da janela, defina as permissões conforme indicado na Figura 6.30. Observe que a lista de permissões é bastante extensa. Você terá que usar a barra de rolagem, até localizar as permissões Create table e Create view, as quais serão permitidas (Allow), para o usuário SERVIDOR\user1. Observe que esta mesma janela pode ser utilizada para, explicitamente, negar uma ou mais permissões – coluna Deny. Localize as permissões Backup database e Backup log e marque a coluna Deny, para negar estas permissões para o usuário SERVIDOR\user1, conforme proposto no nosso exemplo.

Figura 6.30 Definindo as permissões para o usuário SERVIDOR\user1.

6. Agora vamos definir as permissões para a role role1. Clique em role1, na parte de cima da janela, para selecioná-la. Na parte de baixo da janela, localize as permissões Create view, Backup database, Backup log e Create rule e marque a coluna Allow, para permitir estas permissões para a role role1, no banco de dados Exemplo1. Com estas configurações, na prática, todos os membros da role role1, heradrão as permissões que estão sendo atribuídas a role role1, ou seja: Create view, Backup database, Backup log e Create rule.

7. Dê um clique em OK e pronto, as permissões terão sido definidas.

8. A pergunta agora é: “Qual a permissão efetiva para o usuário SERVIDOR\user1”.

Vamos analisar com calma.

Primeiro: O usuário SERVIDOR\user1 pertence a role role1, portanto herdará as permissões desta role.

Segundo: Ao analisar as permissões efetivas, gosto de analisar para cada permissão, separadamente. Então vamos lá:

• Permissão Create table: O usuário tem esta permissão, na role role1 não é negada a permissão. Portanto, o usuário terá esta permissão e poderá criar novas tabelas no Banco de Dados Exemplo1.
• Permissão Create view: O usuário tem a permissão e também herda a permissão da role role1. Portanto, o usuário poderá criar novas views no Banco de Dados Exemplo1.
• Permissão Create rules: O usuário herda a mesma da role role1. Portanto o usuário poderá criar novas Rules no Banco de Dados Exemplo1.
• Permissão Backup database: Esta permissão é negada ao usuário. Não preciso nem continuar a minha análise, pois negar tem precedência sobre qualquer outra atribuição, ou seja, mesmo que o usuário herdasse de alguma outra role a permissão de fazer o backup do Banco de Dados, o negar teria precedência. Portanto o usuário não poderá fazer o backup do Banco de Dados. Se ele tentar fazer um backup, utilizando o comando BACKUP DATABASE, a seguinte mensagem será exibida:

Server: Msg 262, Level 14, State 1, Line 1
BACKUP DATABASE permission denied in database ‘Exemplo1’.
Server: Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

Observe que a mensagem indica, claramente, uma falta de permissões para efetuar a operação.

® Permissão Backup log: São válidos os mesmos comentários feitos para a permissão Backup database. Lembrar sempre que negar tem precedência sobre permitir. Se o usuário tentar fazer um backup do log, a seguinte mensagem será exibida:

Server: Msg 262, Level 14, State 1, Line 1
BACKUP LOG permission denied in database ‘Exemplo1’.
Server: Msg 3013, Level 16, State 1, Line 1
BACKUP LOG is terminating abnormally.

Também podemos definir as permissões, utilizando comandos T-SQL.

Para atribui-las utilize o comando GRANT.

Sintaxe para o comando GRANT:

GRANT { ALL | statement [ ,...n ] }

TO security_account [ ,...n ]

Vamos utilizar alguns exemplos para ilustrar a utilização do comando GRANT.

Exemplo 1: Garantir para o login SERVIDOR\user1 a permissão de criar novos Bancos de Dados:

USE Master

GRANT CREATE DATABASE TO [GROZA\user1]

Usei, primeiro, o comando USE Master, para tornar o banco de dados Master o banco atual. Isso é necessário, por que a permissão de criar novos bancos de dados só pode ser dada, sendo o banco de dados Master o banco atual. Na prática, ao criar um banco de dados, o usuário precisa gravar dados nas tabelas do banco de dados master, que é onde ficam as informações sobre tudo o que existe em uma instância do SQL Server 2005.

Quando o login for um usuário do Domínio 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.

Exemplo2: Atribuir as permissões CREATE TABLE, CREATE RULE e CREATE VIEW, para o usuário SERVIDOR\user1 no Banco de Dados Exemplo1.

USE Exemplo1

GRANT CREATE TABLE, CREATE RULE, CREATE VIEW

TO [SERVIDOR\user1]

Exemplo3: Atribuir as permissões CREATE TABLE, CREATE RULE e CREATE VIEW, para os usuários SERVIDOR\grupo1 e SERVIDOR\grupo2, no Banco de Dados Exemplo1.

USE Exemplo1

GRANT CREATE TABLE, CREATE RULE, CREATE VIEW

TO [SERVIDOR\grupo1], [SERVIDOR\grupo2]

As principais permissões de Banco de Dados, possíveis de serem atribuídas com este comando, são descritas nas Tabelas 6.20 e 6.21.

Tabela 6.20 Principais permissões de Banco de Dados:

Tabela 6.21 Principais permissões de objetos do Banco de Dados:

As permissões SELECT, INSERT, DELETE, UPDATE e EXECUTE são definidas para objetos do Banco de Dados. Aprenderemos a utilizar o comando GRANT para definir estas permissões logo em seguida.

Exemplo 4: Atribuir todas as permissões para o usuário SERVIDOR\user2, no Banco de Dados Exemplo1.

USE Exemplo1

GRANT ALL

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 Banco de Dados, utilize o comando REVOKE.

Sintaxe para o comando REVOKE:

REVOKE { ALL | statement [ ,...n ] }

FROM security_account [ ,...n ]

Vamos a alguns exemplos para ilustrar a utilização do comando REVOKE.

Exemplo 1: Retirar a permissão de criar novos Bancos de Dados, atribuída para o login SERVIDOR\user1, anteriormente.

USE MASTER

REVOKE CREATE DATABASE TO [SERVIDOR\user1]

Podemos retirar mais do que uma permissão ao mesmo tempo, para um ou mais logins.

Exemplo 2: Retirar as permissões CREATE TABLE, CREATE RULE e CREATE VIEW, atribuídas para o usuário SERVIDOR\user1 no Banco de Dados Exemplo1.

USE Exemplo1

REVOKE CREATE TABLE, CREATE RULE, CREATE VIEW

TO [SERVIDOR\user1]

Exemplo3: Retirar as permissões CREATE TABLE, CREATE RULE e CREATE VIEW, atribuídas para os usuários SERVIDOR\grupo1 e SERVIDOR\grupo2, no Banco de Dados Exemplo1.

USE Exemplo1

REVOKE CREATE TABLE, CREATE RULE, CREATE VIEW

TO [SERVIDOR\grupo1], [SERVIDOR\grupo2]

Exemplo 4: Retirar todas as permissões atribuídas ao usuário SERVIDOR\user2, no Banco de Dados Exemplo1.

USE Exemplo1

REVOKE ALL

TO [SERVIDOR\user2]

Observe que utilizamos a palavra ALL, para significar todas as permissões.

Agora vamos à análise de mais um estudo de caso e, na seqüência, fica um exercício para o amigo leitor, onde temos a combinação de permissões em diversas roles e uma combinação entre permitir e negar permissões.

Estudo de Caso: Considere a situação descrita na Figura 6.31:

Figura 6.31 Permissões no Banco de Dados Exemplo1.

Para definir a permissão efetiva de um usuário devemos lembrar que o usuário herda as permissões das roles as quais ele pertence. Também devemos lembrar que estas permissões são cumulativas, isto é, se uma das roles as quais o usuário pertence tiver permissão CREATE TABLE e a outra role a qual o usuário pertence, tiver permissão CREATE VIEW, o usuário herdará as duas permissões.

No nosso exemplo, o user1 tem as permissões CREATE TABLE e CREATE VIEW. Além disso como ele pertence a role role1, ele herda as permissões da role role1. Com isso o usuário user1 está acumulando as permissões CREATE TABLE, CREATE VIEW, CREATE RULE e CREATE PROCEDURE, sendo as duas últimas herdadas da role role1.

Qual a permissão efetiva do usuário user1?

® CREATE TABLE.

® CREATE VIEW.

® CREATE RULE.

® CREATE PROCEDURE.

Vamos analisar a situação para o usuário user2. Este usuário tem as permissões CREATE TABLE e CREATE VIEW. Como ele também pertence à role role1, ele herda as permissões CREATE RULE e CREATE PROCEDURE. Como o usuário também pertence à role role2, ele herda as permissões da role2, que são “negar CREATE TABLE” e “negar CREATE VIEW”. Como negar tem precedência sobre permitir, o usuário user2 terá somente as permissões CREATE RULE e CREATE PROCEDURE.

Qual a permissão efetiva do usuário user2?

CREATE RULE.

CREATE PROCEDURE.

Exercício: Considerando a situação descrita na Figura 6.32, determine as permissões efetivas para os usuário user1, user2, user3, user4 e user5.

Figura 6.32 Determine as permissões efetivas para cada usuário.

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. 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.