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

Conforme já descrevemos, podemos utilizar roles para simplificar a atribuição de permissões de acesso aos objetos do SQL Server 2005. Também nunca é demais salientar que role é semelhante, para não dizer idêntico, ao conceito de grupos de usuários do Windows.

Por exemplo, podemos criar uma role chamada FinançasConsulta e outra chamada FinançasAlteração. No Banco de Dados Finanças damos permissão somente de leitura para a role FinançasConsulta e de leitura, escrita, alteração e exclusão para a role FinançasAlteração. Depois incluímos os usuários que precisam de acesso somente de leitura na role FinançasConsulta, e os que precisam de acesso de leitura e alteração, incluímos na role FinançasAlteração. Se um usuário não deve mais ter acesso de alteração, é só retirá-lo da role FinançasAlteração. Com isso a administração da segurança no SQL Server 2005 fica bastante simplificada.

É também importante salientar as mudanças e novidades do SQL Server 2005, na área de segurança, já descritas anteriormente. A principal mudança é a separação entre Usuários e Schemas. No SQL Server 2005, todos os objetos de um banco de dados, tais como tabelas e views pertencem a um Schema. Agora, um usuário ou rule é o dono de um Schema e não existe mais o dono de um determinado objeto. Conforme descrito anteriormente, esta separação entre usuários e Schemas, facilita, bastante, a administração, principalmente em casos onde temos que alterar o dono de um determinado objeto ou excluir um usuário, o que era bem complicado de se fazer no SQL Server 2000. Para mais detalhes sobre Schemas e a questão do dono dos objetos, consulte o tópico teórico, no início do capítulo, sobre o Modelo de Segurança do SQL Server 2005.

Existem algumas roles que já são criadas no momento de instalação de uma determinada instância do SQL Server 2005. Temos as chamadas Server Roles e as Databases Roles. A seguir, temos as permissões associadas com cada uma destas roles.

As Server Roles têm permissão para realizar as tarefas administrativas mais comuns. Por exemplo, se um usuário é responsável por adicionar ou remover logins, você pode colocá-lo como membro da role securityadmin, que este usuário herdará as permissões da role securityadmin. Isto evita que você tenha que adicioná-lo a role Sysadmin, dando-lhe mais permissões do que realmente necessita para realizar o seu trabalho. Na Tabela 6.12, temos a descrição destas roles.

Tabela 6.12 Permissões associadas com as principais Server Roles.

Não é possível criar novas roles de servidor. Ou seja, você está limitado a utilizar as Server Roles que são criadas quando o SQL Server 2005 é instalado.

Também temos algumas roles pré-definidas para Banco de Dados. Na Tabela 6.13, temos a descrição destas roles.

Tabela 6.13 Permissões associadas com as principais Fixed Database Roles.

Existe ainda uma role chamada public. Todo usuário adicionado a um Banco de Dados, automaticamente, pertence a esta role. Não podemos adicionar novos usuários a esta role, pois qualquer usuário ou role que é adicionado ao Banco de Dados fará parte desta role. A role public não pode ser excluída. Devemos ter cuidado com as permissões atribuídas a esta role, uma vez que todos os usuários e roles do Banco de Dados fazem parte dela. Por outro lado, a role public, se corretamente utilizada, pode simplificar a administração, em determinadas situações. Por exemplo, se todos os usuários de um Banco de Dados devam ter acesso de leitura, basta dar a permissão de leitura para a role public. Como todos os usuários pertencem a role public, eles irão herdar a permissão de leitura, atribuída a role public.

Agora precisamos aprender a criar roles no SQL Server 2005 e a adicionar usuários a roles. Vamos seguir a nossa metodologia. Aprenderemos a criar roles utilizando o SQL Server Management Studio e também comandos T-SQL, na janela de execução de comandos. Lembrando que somente é possível criar novas roles em nível de Banco de Dados, isto é, não poderemos adicionar novas roles a nível de servidor.