Imagine que temos uma tabela crítica e importante em um sistema e precisamos atribuir permissão de DELETE a um grupo de usuários. A prática normalmente utilizada por muitos DBAs e desenvolvedores é conceder a permissão diretamente na tabela como no exemplo abaixo:
GRANT DELETE ON NomeTabela TO NomeGrupo
O grande problema aqui é que esta prática torna os dados vulneráveis, pois nada impede que um usuário execute a ação de DELETE através de outras ferramentas que não seja sua aplicação. Por exemplo, utilizando o Query Analyzer ou qualquer outra ferramenta de execução de script.
Entretanto, o que poucos sabem é que utilizando o recurso Ownership Chains podemos atribuir permissões de SELECT, INSERT, UPDATE ou DELETE de forma indireta, através da utilização de store procedures ou views, permitindo assim uma melhor segurança aos dados e facilidade na administração de permissões.
Isto é possível porque quando um usuário acessa uma view, o SQL Server não realiza a checagem de permissão nos objetos que a view faz referência se estes objetos e a view tiverem o mesmo owner e se todos os objetos referenciados pela view estiverem no mesmo banco de dados. No caso de stored procedures, o SQL Server faz a checagem de permissão apenas na procedure. No entanto, se a cadeia for quebrada, ou seja, nem todos os objetos referenciados possuem o mesmo owner, o SQL Server realiza a checagem de permissão em cada objeto referenciado pela view ou stored procedure.
Aproveitando o exemplo mostrado acima, para que a nossa digamos cadeia de permissões funcione, basta criar uma stored procedure que execute a ação de DELETE e ao invés de atribuir a permissão diretamente na tabela, podemos simplesmente conceder a permissão de EXEC na stored srocedure. Com isso, o SQL Server entenderá que uma vez que o owner dos objetos envolvidos é o mesmo, o usuário que possuir a permissão de executar a stored procedure também terá permissão para executar as ações definidas na mesma, seja um SELECT, INSERT, UPDATE ou DELETE.
Veja o exemplo abaixo:
–Cria a tabela Tabela1
CREATE Table dbo.Tabela1 (Col1 as int, Col2 as varchar (10))
— Insere 3 registros na Tabela1
INSERT Tabela1 VALUES (1, ‘aaa’)
INSERT Tabela1 VALUES (2, ‘bbb’)
INSERT Tabela1 VALUES (3, ‘ccc’)
–Cria Stored Procedure DelTabela1
CREATE Proc dbo.DelTabela1 AS
DELETE From Tabela1 Where Col1 = 2
Go
— Atribui permissão para executar a procedure
GRANT EXEC ON DELTabela1 TO NomeGrupo
Neste exemplo, embora a permissão de DELETE não tenha sido atribuída diretamente na tabela, o usuário que executar a procedure conseguirá excluir os registros afetados.
Até o SQL Server 2000 SP3 o recurso de OwnerShip Chains também funcionava entre banco de dados (Cross Database). Neste caso, se o owner dos objetos e dos bancos de dados nos quais os objetos estavam alocados fossem o mesmo, o SQL Server não realizava a checagem de permissão nos objetos referenciados, mesmo estando estes objetos em outro banco de dados.
Com a aplicação do SP3, por default esta funcionalidade é desativada, mas você pode escolher se mantém ou não a funcionalidade selecionando a opção Allow cross-database ownership chaining durante a instalação do SP3. Mesmo após a instalação do SP3 também é possível ativá-la no nível banco de dados selecionando a opção Allow cross-database ownership chaining nas propriedades do banco de dados ou no nível servidor, configurando a opção Cross DB Ownership Chaining para 1 através da procedure de sistema sp_configure.
Como podemos observar, as duas grandes vantagens da utilização do Ownership Chains são:
1. Facilidade na administração de permissões: permite a administração de permissões em múltiplos objetos (por exemplo, várias tabelas), configurando permissão em um único objeto (por exemplo, uma view ou procedure). Dessa forma, se temos uma procedure que acessa cinco ou mais tabelas, precisamos atribuir permissão apenas na procedure e não nas cinco ou mais tabelas.
2. Segurança das informações: os usuários terão acesso às informações somente através da aplicação. Eles jamais terão acesso direto às tabelas, o que pode evitar grandes dores de cabeça.
Obs: Embora este recurso também esteja disponível no SQL Server 2005, até o recente release (April CTP), é possível configurar o Ownership Chains apenas no nível servidor.
Para saber mais sobre Ownership Chains, consulte o Books Online do SQL Server 2000 ou SQL Server 2005.