Administrando o controle de acesso no SQL Server

Veja nesse artigo como criar e controlar o acesso de usuários SQL Server a nível de instância e a nível de banco de dados.

Vamos iniciar com a conceituação de uma instância SQL Server: é um serviço executado pelo sistema operacional, adicionado ao Windows no momento da instalação do SQL Server. Em uma instância pode conter um ou mais bancos de dados, mas um banco de dados sempre vai pertencer a somente uma instância.

Você pode ter mais de uma instância em seu servidor, limitando-se a uma instância padrão (MSSQLSERVER) e as demais nomeadas. Instâncias nomeadas tem o nome escolhido pelo usuário. É possível verificar o serviço da instância acessando o serviço do Windows e lá podemos parar, iniciar, configurar para iniciar automaticamente ou manualmente uma instância.

Conceituando Banco de dados

Banco de dados é uma coleção de dados que se relacionam entre si, daí vem sistema de banco de dados relacional. E para criar, alterar ou gerenciar um banco de dados, necessitamos de uma instância em nosso servidor.

Logo após a instalação da instância podemos identificar que já possuímos alguns bancos de dados instalados. No System Databases temos alguns:

Cada um desses tem sua funcionalidade e todos são fundamentais para o gerenciamento dos seus bancos de dados e também para a criação, remoção ou danificação de objetos contidos nestes bancos de dados e pode parar todo o serviço do servidor. Atualmente em cada instância é possível criar até 32.767 bancos de dados.

Conectando em uma Instância

Ao iniciar o SQL Server Management Studio nos deparamos com a tela representada na Figura 1.

Figura 1. Tela inicial de conexão a instância

A ferramenta SQL Server Management Studio auxilia na conexão com uma instância, administração de recursos, criação e manipulação de objetos. Outras ferramentas também podem ser utilizadas para tais funções.

Em qualquer sistema de banco de dados inicialmente tem que se conectar na instância antes de tentar manipular algum objeto, sendo no banco ou não. No caso da Figura 1 nos deparamos com o campo Server name, que pode assumir duas opções: Windows Authentication e SQL Server Authentication.

Na opção Windows Authentication, a instância do SQL Server aceita a autenticação do usuário do sistema operacional para estabelecer uma conexão. Pode ser utilizado o mesmo usuário utilizado para se logar no Windows.

Na opção SQL Server Authentication a conexão é realizada por um usuário criado na instância do SQL Server.

No momento da instalação do SQL Server é criado o usuário sa e configurada uma senha, que podem ser utilizados para a primeira conexão com a instância. O usuário sa, em primeiro momento é o owner do servidor, sendo assim, tem todos os acessos no servidor.

Os usuários da instância podem ser encontrados em Security – Logins. Lá podemos adicionar novos usuários, configurar política de senha, adicionar privilégios a instância, administrar acesso a bancos entre outras funções.

Cada usuário criado com a finalidade de conexão com a instância traz consigo um sid e um principal_id, que são informações importantíssimas para a criação de um controle das manipulações que estão sendo feitas no servidor.

Ao executarmos uma nova query, como a da Listagem 1, no banco de dados master podemos verificar os usuários cadastrados para ter conexão com a instância.

Listagem 1. Comando para verificar logins de instância

SELECT * FROM [sys].[sql_logins]

Na view sql_logins é possível identificar: login, principal_id, sid, data de criação, data de modificação, política de password, password, dentre outras informações. Toda as informações de logins podem ser encontradas no banco de dados master.

Ter um login com acesso a instância não garante que possa ter acesso às informações de banco, como Create, Delete, Update, Insert ou Select. Está ai a diferença entre acesso a nível de instância e a nível de banco de dados.

Na Figura 2 podemos identificar o local onde é concedido os acessos a logins a nível de instância.

Figura 2. Acessos a nível de instância.

Tenha cautela ao conceder o acesso de sysadmin a um usuário em caso de aplicações já em produção, pois ao conceder tal acesso estará informando que o usuário terá controle total.

O acesso public é um acesso que dá ao usuário os acessos mínimos. Para gerenciar, conceder ou revogar permissões é necessário que o login tenha esteja no grupo securityadmin. Lembrando que está sendo apresentado até o momento o controle de acesso a nível de instância.

Você pode verificar no banco de dados master os logins e seus acessos, a partir do comando mostrado na Listagem 2. Podemos identificar o nome do usuário, nome de login, senha, sid que representa (como se fosse a digital do usuário, lembrando que o sid não pode ser repetido, dando mais facilidade e confiabilidade no caso de auditorias), disable (informa se o login está ativo ou desabilitado), createdate (traz a data de criação) e as demais colunas são informações de acesso a instância.

Listagem 2. Comando para verificar acessos concedidos a usuários.

SELECT S.name, S.loginname, S.password, l.sid, l.is_disabled, S.createdate, S.denylogin, S.hasaccess, S.isntname, S.isntgroup, S.isntuser, S.sysadmin, S.securityadmin, S.serveradmin, S.processadmin, S.diskadmin, S.dbcreator, S.bulkadmin FROM [sys].[syslogins] S LEFT JOIN [sys].[sql_logins] L ON S.sid = L.sid

Outra linha de comando que facilita a visualização de informações básicas de login é o da Listagem 3, que traz nome do login, banco de dados ao qual o usuário pertence, SID, dentre outras informações.

Listagem 3.Comando para verificar informações básicas de usuários.

Sp_helplogins

Já com as informações de login e senha dos usuários em mãos podemos iniciar a conexão com a instância, como mostrado na Figura 1 e estabelecer a primeira conexão com a instância do SQL Server.

Usuários do Windows também podem ter suas permissões controladas no acesso do SQL Server, notando que os acessos concedidos ao usuário no acesso ao sistema operacional não influenciam nos acessos a conexão a instância, ou seja, um usuário pode ter acesso de administrador do sistema e não ter permissão sysadmin na instância do servidor.

Outro detalhe que um administrador de banco de dados tem de se atentar é que em um ambiente de produção um usuário deve ter restrições no servidor, ou se possível nem ter acesso a arquivos e/ou softwares. Usuários do Windows com acessos de “Controle Total” ou “Modificar”, podem facilmente danificar seu ambiente ou até mesmo desinstalar uma instância SQL Server.

Para um usuário comum, um arquivo com extensão mdf ou ldf não representa muita coisa, mas facilmente o mesmo pode até mesmo deletar os arquivos, por isso, devemos ter atenção nas restrições dos usuários nas pastas onde os bancos são destinados. Os bancos de dados do sistema, por padrão seguem para mesma pasta destino, conforme listado na Listagem 4.

Listagem 4.Caminho padrão dos system databases.

C:\Program Files (x86)\Microsoft SQL Server\MSSQL.3\MSSQL\Data

Os bancos de dados do sistema são imprescindíveis para o funcionamento do servidor, portanto esses arquivos não podem, de forma alguma, estarem disponíveis para o usuário final da aplicação.

Usuários a nível de Banco de dados

Já conectado a instância nos deparamos com os acessos de usuários. Podemos ter acesso de conexão com instância e não ter ao menos acesso de leitura em um banco de dados que compõem o servidor.

Acessos a nível de bancos de dados facilitam o controle do usuário final, não sendo necessário que você crie um banco para cada departamento. Por exemplo, você pode destinar acesso a tabela de forma diferenciada, pois tem a opção de separar usuários por grupos.

Tomando uma situação como exemplo, em uma aplicação podemos atender aos setores do administrativo, do RH, do setor de compras e setor de vendas, todas utilizando um mesmo banco de dados, mas sem que um setor tenha acesso aos arquivos do outro setor.

Os usuários de nível de banco de dados podem ser identificados no caminho mostrado na Figura 3. Cada banco de dados deve, por padrão, seus usuários separados, ou seja, o usuário criado para o banco de dados D não tem os mesmos acessos no banco de dados Y, mesmo que os dois bancos pertençam a mesma instância.

Figura 4. Localização dos usuários a nível de banco.

Neste caso os usuários são divididos em grupos de acesso, no momento de um novo cadastro de usuário, bastar inclui-lo a um grupo e o mesmo terá todos os acessos que aquele grupo lhe dispõe.

Caso opine por esta forma de controle de acesso saiba que após destinar um usuário em um grupo de acesso, por exemplo o Gerente Administrativo, poder ter acesso a objetos do RH, não necessariamente ele terá acesso a todos os arquivos ou todas as permissões.

A forma utilizada para o controle de acesso a usuários deve ser definida já no início do projeto da criação de um banco de dados, influenciando até na criação das colunas das tabelas, verificando a necessidade de ter uma coluna especifica para identificação dos usuários que estão alterando a tabela.

Um grande aliado para o controle de acesso de usuários é o Schema de objetos. O schema é um agrupamento de objetos com acessos pré-concebidos, e pode ser de um usuário, mas não necessariamente deve ter o usuário que a criou como seu dono.

Na Figura 4podemos identificar onde estão localizados os schemas do banco de dados.

Por padrão o schema inicial é o dbo e pertence ao owner do banco.

Figura 4. Localização dos Schema.

É importante compreender que todo objeto possui um schema e os objetos podem pertencer a um schema e ser transferido para outro, assim como os usuários. Então, se um funcionário for promovido para outro setor e são utilizados os schemas para controle de acesso, basta que seja alterado o schema do usuário promovido.

No momento de criação de um usuário já é necessário informar a qual schema este novo usuário irá pertencer, e sem a associação de um schema não será possível finalizar a criação do usuário. Em objetos, como tabelas, caso não seja associado um schema, é assumido o schema padrão (dbo).

A Figura 5mostra como é a criação de um usuário no banco de dados, com a escolha de um login a nível de banco e a associação a um schema.

Figura 5. Criação de usuário a nível de banco de dados.

Para isso, basta localizar os users, conforme mostrado na Figura 3 . Logo após, basta clicar com o botão direito do mouse em Users - New Users... e logo estará disponível em modo designer a Figura 5.

Outra forma prática de controle de acesso a usuários é trabalhar com acessos de roles, que é a forma de agrupar ainda usuários no SQL Server. As roles restringem os usuários a comandos como CREATE, BACKUP, EXEC, Administração de logins, dentre outros.

Conforme visto na Figura 2 temos também a role public, a qual vem, por padrão, somente com o mínimo de acesso possível ao banco de dados.

Existem também outras roles fixas:

Estas roles não podem ser alteradas ou excluída por usuários. É possível identificá-las no caminho mostrado na Figura 6.

Figura 6. Caminhos das Databases Roles.

Para adicionar uma role a um banco de dados, basta utilizar sp_addrole, conforme mostrado na Listagem 5.

Listagem 5. Sintaxe de criação de database roles.

EXEC sp_addrole “Nome”, “Dono da role”

Caso não seja especificado o “dono da role”, por padrão, o SQL Server entenderá que o dbo será adicionado como dono da role. Também não é possível criar roles a nível de instância, pois roles estão disponíveis somente para criação a nível de banco de dados.

Para excluir uma role você pode utilizar a procedure sp_droprole conforme sintaxe da Listagem 6. Note que será necessária a utilização do EXEC na composição da sintaxe por se tratar de procedures.

Listagem 6.Removendo Role

EXEC sp_droprole “Nome da role”

Caso seja necessário identificar as roles disponíveis através de sintaxe, você poderá utilizar o sp_helprole, conforme executado na Listagem 7 o qual não necessita de identificação de nome da role.

Listagem 7.Verificando informações de roles existente

EXEC sp_helprole

Para adicionar um usuário a uma role você poderá utilizar o sp_addsvrrolemember que poderá observar a sintaxe na Listagem 8. Caso deseje remover um usuário da role basta utilizar os mesmos parâmetros, só que ao invés de utilizar sp_addsvrrolemember, execute sp_dropsvrrolemember com os mesmos parâmetros, login e role.

Listagem 8. Adicionando um usuário a role.

EXEC sp_addsvrrolemember “login”, “Role”

Adicionando e removendo permissões

Agora veremos os modos de conceder, remover ou negar acesso a usuários. Para isso, temos as seguintes opções:

GRANT concede acesso a usuários a um determinado objeto do banco de dados, seja de select, alteração, remover ou ALL. Além disso, também pode ser utilizado a nível de instância.

Na Listagem 9 podemos ver a sintaxe para utilizarmos um GRANT.

Listagem 9. Concedendo acesso a nível de banco de dados.

GRANT “permissão” ON “objeto” TO “usuário”

Em um exemplo concedendo acesso de atualização na tabela de vendas, no local definido com privilégio, você informaria UPDATE para o objeto que seria informado a TblVendas, e no local de login informaria o login do usuário ao qual será concedido o acesso de alteração.

A sintaxe da Listagem 9 está simplificada para facilitar a compreensão. Caso seja necessário dar acessos do tipo DDL (Linguagem de definição de dados), basta informar como privilégio CREATE, CREATE VIEW, DROP, TRUNCATE, entre outros.

Também é possível disponibilizar acessos com o GRANT a nível de servidor. A sintaxe para isso é mostrada na Listagem 10, tendo como pequena alteração somente a remoção do objeto, contendo apenas privilégio e usuário.

Listagem 10.Atribuindo acesso a nível de instância.

GRANT “permissão” TO “usuário”

REVOKE ao contrário do GRANT a função REVOKE retira a permissão concedida a um usuário, não confunda REVOKE com DENY, a função REVOKE somente remove um acesso já concedido.

Conforme podemos verificar na Listagem 11 , a função REVOKE tem a sintaxe bem parecida com a GRANT.

Listagem 11.Removendo permissão a nível de banco de dados.

REVOKE “permissão” ON “objeto” TO “usuário”

A utilização do CASCADE no REVOKE retira todos os acessos concedidos em uma entidade. A opção de utilização do REVOKE ALL já está sendo retirada de uso. Antes de utilizá-la, leia a documentação do SQL Server para verificar se ainda está disponível em sua versão. Portanto, dê preferência a especificação da permissão que deseja retirar.

Assim como a função GRANT a função REVOKE também pode ser utilizada a nível de instância.

DENY é uma função muito confundida com a função REVOKE, pois ela não permite um GRANT a um usuário em um objeto ou entidade.

Simplificando isso, caso deseje adicionar um usuário a um schema, mas não deseja que o mesmo não faça alteração em determinada tabela que faz parte deste schema, basta você fazer um DENY de UPDATE no objeto.

Na Listagem 12 verificamos a sintaxe básica para realizar DENY em um objeto.

Listagem 12. Utilizando DENY a nível de banco de dados.

DENY “permissão” ON “objeto” TO “usuário”

As funções GRANT, REVOKE e DENY não se diferenciam muito na sintaxe básica. O grande lance é como e quando utilizar. Também é possível utilizar a função DENY a nível de instância, conforme mostrado na Listagem 13 .

Listagem 13. Utilizando DENY a nível de instância.

DENY “permissão” TO “usuário”

Já a função SETUSER é de versões anteriores do SQL Server, mas tem a finalidade de testar as permissões de um usuário. Então, antes de utilizá-la, verifique a versão do seu SQL Server.

A restrição da função SETUSER é o suporte Microsoft, que só está disponível para usuários SQL Server. Caso você esteja trabalhando com a função e utilizando um usuário do sistema operacional (Windows authentication), o mesmo não terá suporte.

SETUSER tem uma sintaxe simples, assim como podemos ver na Listagem 14.

Listagem 14.Utilizando a função SETUSER.

SETUSER “Usurário com acesso”; GO GRANT “permissão” ON “objeto” TO “usuário”; GO SETUSER

O exemplo acima utiliza o SETUSER um usuário que se passa por outro para testar suas permissões. Para utilizar esta função é necessário que o usuário que se está testando seja sysadmin ou db_owner.

Ao usar a função SETUSER, caso o usuário tenha permissões DDL e, ao assumir você crie um objeto, o mesmo não pertencerá a você, mas sim ao usuário que você assumiu.

Neste artigo foi verificado informações de importância para qualquer profissional que trabalha com banco de dados. É imprescindível que se mantenha um nível de segurança dos dados da aplicação, agrupamento de acesso e como conceder, retirar e negar acesso. Algumas cláusulas podem ter restrições dependendo da sua versão do SQL Server.

Bibliografia

http://msdn.microsoft.com/pt-br/library/ms123401.aspx

http://technet.microsoft.com/pt-br/library/aa991542.aspx

Artigos relacionados