Ter permissão de login, quer seja um login do próprio SQL Server 2005 ou um login do domínio, é apenas a primeira etapa do processo. Muito bem, você consegui fazer o logon no SQL Server 2005, e agora? Uma vez conectado ao servidor SQL Server, o usuário precisa de permissões de acesso a um ou mais Bancos de Dados e para acessar os objetos (tabelas, views, stored procedures, etc.) de um ou mais bancos de dados.

Conforme vimos no Capítulo 2, em um único servidor SQL Server, podemos ter uma ou mais instâncias do SQL Server instaladas. Cada instância é como se fosse um servidor completamente separado. Em cada instância podemos ter vários Bancos de Dados, os quais podem ter os seguintes objetos, dentre outros:

® Tables

® Views

® Stored Procedures

® Extended Stored Procedures

® Users

® Roles

® Rules

® Defaults

® User Defined Data Types

® User Defined Functions

® Full-Text Catalogs.

Já aprendemos a criar alguns destes elementos e iremos aprender a criar outros no decorrer deste livro.

No item anterior vimos que o usuário precisa de um login para conectar-se com uma instância do servidor SQL. A conexão sempre é feita com uma instância do servidor SQL Server. Ao fazer a conexão, o usuário é automaticamente associado a um dos Bancos de Dados da instância a qual se conectou. Conforme veremos na parte prática, é possível definir com qual Banco de Dados o login será automaticamente associado. Mas isso não significa que o usuário somente poderá acessar dados do Banco de Dados com o qual ele é automaticamente associado, durante a conexão. Aí que entra o segundo estágio de segurança pelo qual o usuário terá que passar. Além de fazer a conexão, o usuário precisa estar autorizado para acessar o(s) Banco(s) de Dado(s), nos quais estão as informações que o usuário precisa acessar. Então, o próximo passo é autorizar o usuário a acessar um ou mais Bancos de Dados.

Podemos dar permissão para o usuário ou para uma Role ao qual ele pertence. O conceito de Role, no SQL Server 2005, é exatamente igual ao conceito de Grupos de Usuários no Windows 2000 Server ou no Windows Server 2003. Uma Role pode conter um ou mais usuários. Se dermos uma permissão para uma Role, todos os usuários que pertencem à Role irão herdar as permissões atribuídas à Role. É ou não é a mesma coisa que grupos de usuários no Windows, no UNIX, Linux, Novell, etc., Mas, enfim, quem sou eu para criticar a criatividade do pessoal que inventa os nomes para os objetos do SQL Server 2005.

Vejam que o usuário já precisa passar por dois níveis de segurança:

® Permissão para fazer a conexão com o SERVIDOR\INSTÂNCIA.

® Permissão para acessar um ou mais Bancos de Dados.

Nesta situação, o usuário jsilva tem permissão para fazer a conexão com uma instância do servidor SQL Server, porém não tem permissão para acessar o Banco de Dados Clientes, que está no servidor SQL. Neste caso se jsilva tentar acessar algun objeto do Banco de Dados Clientes, o acesso será negado, pois jsilva não tem permissão de acesso a este Banco de Dados.

Para que jsilva possa ter acesso ao Banco de Dados Clientes temos que adicioná-lo à lista de usuários autorizados a acessar o Banco de Dados Clientes e dar as permissões para que ele possa realizar as tarefas necessárias (você verá no próximo tópico que, na verdade, as permissões são dadas não diretamente aos ojbetos do banco de dados, tais como tabelas e views, mas sim ao Schema ao qual pertence o objeto. No próximo tópico farei uma explicação detalhada sobre Schemas, pois esta é uma das novidades de segurança, mais importantes do SQL Server 2005). Exemplos de permissões para Banco de Dados são as seguintes:

® Criar tabelas

® Excluir tabelas

® Alterar tabelas

® Criar Roles

® Criar Views

Conectei com o servidor SQL, tenho permissão de acesso ao Banco de Dados e ainda não consigo executar uma consulta. O que está acontecendo?

Além das permissões para acessar o Banco de Dados, podemos e devemos, definir permissões de acesso para cada objeto de um banco de dados. Por exemplo pode ser que alguns usuários devam ter permissão de leitura na tabela Cadastro do Banco de Dados Clientes, porém somente os gerentes devem ter permissão de leitura na tabela Pagamentos do Banco de Dados Clientes. Podemos definir o acesso, individualmente, para cada tabela, view, etc, para cada objeto de um banco de dados. Portanto, podemos definir permissões de acesso para cada objeto que faz parte de um Banco de Dados.

O fato de podemos definir permissões para cada objeto, nos dá uma grande flexibilidade. A partir desta flexibilidade é que podemos definir diferentes níveis de acesso para diferentes usuários, o que é bastante comum e necessário nas aplicações atuais. Alguns usuários devem ter permissão de leitura aos dados; outros de leitura e alteração; outros leitura, alteração e exclusão e assim por diante.

Aqui, temos os seguintes passos:

1. O usuário jsilva consegue fazer a conexão com a instância do servidor SQL Server 2005.

2. O usuário jsilva está autorizado a acessar o Banco de Dados Clientes.

3. O usuário jsilva NÃO ESTÁ AUTORIZADO a acessar os dados da tabela Pagamentos.