Depois de uma longa pausa nas colunas volto com tudo continuando com o assunto de segurança que começamos a ver na coluna anterior, agora vamos falar um pouco sobre os Roles no SQL Server e as permissões.

Fazendo uma pequena revisão do que foi visto na última coluna: vimos que a porta de entrada para o SQL Server é um login, seja ele interno do SQL Server ou o login que é mapeado através de um usuário ou grupo do Windows. Vimos também que após o login é feito um mapeamento para um usuário do banco de dados e que para cada banco de dados que o login possui permissão um usuário deve ser mapeado para este login.

Tudo certo até aqui. Porém ainda não vimos onde as permissões se encaixam neste esquema. No SQL Server as permissões são divididas em dois grandes grupos: permissões que dizem respeito ao gerenciamento do servidor de banco de dados e permissões que dizem respeito ao banco de dados e seus objetos.

As permissões que tratam sobre o gerenciamento do servidor são relativas ao servidor como um todo e geralmente são sobre o que o login pode fazer , como reiniciar o servidor , fazer backup , criar novos bancos de dados no servidor , logins , etc. Estas permissões são atribuídas diretamente ao login.

Já as permissões que tratam sobre o gerenciamento do banco de dados e seus objetos permitem um controle mais específico sobre o banco de dados e sobre os objetos que estão contidos nele. Exemplos de permissão para bancos de dados: acesso à criação de objetos como tabela , views , Stored Procedures , permissão para fazer backup , limitar os acesso de modo que somente leituras são feitas , etc. Estas permissões são atribuídas a um role ( visto abaixo ) ou a um usuário de banco de dados , conforme vimos na coluna anterior.

Como vimos na coluna anterior , após um login ser criado dentro do SQL Server este login é mapeado para um usuário de banco de dados que pode possuir o mesmo nome do login ou não.

Para agrupar estes usuários de banco de dados podemos utilizar um role , que nada mais é do que um grupo. Porém para não confundir com os grupos de contas de usuários do Windows aqui no SQL Server foi dado o nome de role. Existem basicamente dois tipos de roles:

Fixed Server Roles: Aqui não agrupamos usuários de bancos de dados e sim logins. Estes fixed server roles trabalham com o primeiro tipo de permissão vista no começo da coluna: as permissões que dizem respeito ao gerenciamento do servidor. Não podemos criar Server Roles e só podemos incluir logins nos fixed Server Roles pré-determinados.

Exemplos de Fixed Server Roles: sysadmin , dbcreator e serveradmin. Para atribuir um login a um fixed server role podemos utilizar a aba Server Role da janela de criação de login como mostrado na figura abaixo onde estamos colocando o login teste como membro do fixed server role sysadmin:

Fixed Database Roles: Neste tipo de role colocamos os usuários de bancos de dados agrupados para conceder-lhes os privilégios referentes aos objetos do banco de dados.

Com este tipo de role podemos colocar nossos usuários de bancos de dados dentro de um fixed database role criado, como o db_dlladmin, db_datareader ou db_datawriter. Diferentemente dos fixed server roles, aqui podemos criar os nossos próprios roles e a eles atribuir permissões ao invés de trabalhar concedendo ou negando permissões para usuários de banco de dados individualmente.

Todo usuário de banco de dados é colocado dentro de um fixed database role chamado public que não possui nenhuma permissão (a não ser nos bancos de dados de exemplo Northwind e Pubs).

Para colocar um usuário de banco de dados em um fixed database role podemos utilizar a aba Database Access da janela de criação de login , como mostra a figura abaixo onde o login teste foi mapeado como o usuário de banco de dados t e que foi colocado nos fixed database roles db_datareader e db_datawriter:

Até aqui vimos que um login precisa ser mapeado para dentro de um banco de dados e que podemos colocar este login como membro de um fixed server role. O usuário de banco de dados para qual este login foi mapeado também pode ser agrupado dentro de fixed database roles pré-definidos ou nos roles que definimos por nós mesmos.

Agora vamos falar um pouco sobre as permissões. Mas antes é necessário dizer sobre o que devemos conceder ou não a permissão e quais permissões são relativas a quais objetos. Basicamente falando podemos trabalhar com permissões sobre:

1) Comandos.

Devemos atribuir permissões a comandos com o CREATE TABLE , CREATE VIEW , etc para um usuário. Abaixo são listadas a maioria dos comandos em que se pode atribuir permissões a um usuário:

· CREATE DATABASE
· CREATE DEFAULT
· CREATE FUNCTION
· CREATE PROCEDURE
· CREATE RULE
· CREATE TABLE
· CREATE VIEW
· BACKUP DATABASE
· BACKUP LOG

2) Objetos de Bando de dados.

Aqui concedemos a permissão do que o usuário pode fazer sobre um determinado objeto como por exemplo fazer um SELECT em determinada tabela. A tabela abaixo mostra qual objeto permite qual ação que sofrerá o controle de permissões:

Estas permissões , tanto para comandos como para ações sobre objetos , podem ser atribuídas para usuários de banco de dados ou roles através dos comandos GRANT , DENY e REVOKE . Três regrinhas simples para nunca se esquecer de como as permissões funcionam:

a) Um usuário de banco de dados tem como fazer um comando ou uma ação sobre um objeto se na soma de suas permissões (o que foi atribuído individualmente para o usuário ou através da sua participação em um role) tem ao menos um GRANT e nenhum DENY.

b) Se um usuário de banco de dados não tem nenhum DENY e nem nenhum GRANT na soma de suas permissões para uma determinada ação ou um comando então este usuário está com REVOKE e não poderá executar o comando ou a ação para o objeto.

c) Se na soma das permissões o usuário tem ao menos um DENY no comando ou na ação sobre um objeto ele não pode executar o comando ou ação para o objeto. Esta regra é muitas vezes referenciada como ‘vale o mais restritivo’.

Chega de teoria! Vamos ver alguns exemplos práticos galera: vou representar um GRANT como , um DENY como e o REVOKE simplesmente quanto não houver um GRANT ou um DENY (quadrado vazio).

Exemplo 1:

Suponha que Mauro e Aline são dois usuários do banco de dados dbTeste que não estão em nenhum fixed database role (public não possui nenhuma permissão) e em nenhum fixed server role. Para a tabela CLIENTES as permissões foram dadas da seguinte maneira:

A usuária Aline, no que diz respeito à tabela CLIENTES:

· Não poderá fazer SELECT , pois possui um DENY na sua ação de SELECT.
· Poderá fazer INSERT, pois possui um GRANT na sua ação de INSERT.
· Não poderá fazer UPDATE , pois está com REVOKE na sua ação de UPDATE.
· Poderá fazer DELETE , pois está com GRANT na sua ação de DELETE.

O usuário Mauro, no que diz respeito à tabela CLIENTES:

· Poderá fazer SELECT, pois possui um GRANT na sua ação de SELECT.
· Não poderá fazer INSERT, pois está com REVOKE na sua ação de INSERT.
· Não poderá fazer UPDATE, pois possui um DENY na sua ação de UPDATE.
· Poderá fazer DELETE, pois está com GRANT na sua permissão de DELETE.

Exemplo 2:

Vamos manter as mesmas permissões do exemplo 1 porém aqui criamos um role chamado rl_operadores e colocamos tanto a usuária Aline como o Mauro dentro deste role. A figura abaixo mostra as permissões para a Aline , o Mauro e o role rl_operadores:

A usuária Aline, no que diz respeito à tabela CLIENTES agora fica assim:

· Não poderá fazer SELECT, além do DENY na usuária o role também está com DENY.

· Poderá fazer INSERT, pois possui um GRANT na sua ação de INSERT e no role está com REVOKE.

· Poderá fazer UPDATE, pois está com REVOKE na sua ação de UPDATE para a usuária mas o role está com GRANT.

· Não poderá fazer DELETE, pois apesar de estar com GRANT na sua ação de DELETE para a usuária existe um DENY no role.

O usuário Mauro, no que diz respeito à tabela CLIENTES agora fica assim:

· Não poderá fazer SELECT, pois apesar de possuir um GRANT na sua ação de SELECT para o usuário mas no role há um DENY.

· Não poderá fazer INSERT, pois está com REVOKE na sua ação de INSERT para o usuário e também um REVOKE no role para esta ação.

· Não poderá fazer UPDATE, pois possui um DENY na sua ação de UPDATE para o usuário e um GRANT no role.

· Não poderá fazer DELETE, pois apesar de estar com GRANT na sua permissão de DELETE para o usuário existe um DENY no role.

Ufa, finalmente terminamos! Galera este foi o básico sobre permissões e espero falar mais sobre isso em colunas futuras, mas acho que já deu para pelo menos ter uma idéia de como o SQL Server gerencia as permissões, não é ?

Grande abraço pessoal e até a próxima coluna, onde publicarei as respostas para os desafios da coluna 50, finalmente!