Permissionamento no SQL Server – O básico (Parte 1 de 3) › Renato Siqueira
Para começar, vamos à definição de permissão (Fonte: Dicionário Michaelis):
sf (lat permissione) 1 Ato de permitir; consentimento, licença. 2 Ret Figura em que se deixa aos ouvintes ou adversários a decisão de alguma coisa. 3Inform Autorização concedida a um usuário específico para acessar um certo recurso compartilhado ou área de disco. P. de acesso, Inform: descrição de todos os direitos de acesso para um usuário específico. Antôn (acepção 1):proibição.
Podemos então, deduzir que permissionamento significa:
"Atribuir permissão para alguém realizar determinada ação"
Em outras palavras , deduzimos que alguém (possuindo poder pra isso) pode autorizar uma outra pessoa a executar ou não determinada ação.
Essa ideia de permissionamento é mais velha que o nostradamus, bem atual e natural no nosso dia a dia e posso provar isto pra vocês com a série de frases abaixo:
Pessoas não autorizadas não devem entrar no CPD;
Para dirigir legalmente, é necessário ter habilitação (que é a autorização pra digirir determinado veículo);
No restaurante Shout Back é proibido fumar.
2. Mínimo privilégio
Existe um conceito antigo e fundido com o SQL Server que permeia todo o conceito de permissionamento, que é a concessão apenas das permissões necessárias, o chamado menor privilégio. No SQL Server, por exemplo, se eu adiciono um usuário no banco, nenhuma permissão é concedida automaticamente para o mesmo de forma direta, sendo necessárias outras concessões de permissão.
Criar um usuário no banco é criar e ponto. Nenhuma permissão é adicionada pelo simples fato da criação.
Para facilitar o entendimento, este é o fluxo dos status possíveis de permissão, sendo a ausência de permissão (em amarelo) o ponto inicial.
Significa que se eu inserir o usuário em determinada base de dados, ele NÃO terá permissão de leitura. Pra isso, preciso conceder a permissão à parte. Se eu não concedi para este usuário permissão para escrita, significa que ele simplesmente não tem permissão (entretanto, não tem permissão negada, o que é bem diferente) (ver bloco em amarelo) o que não impede que a concessão seja feita posteriormente.
Em outras palavras: privilégio mínimo: Concessão de permissões mas apenas o necessário e isso é muito bom: obriga que a permissão seja específica e que não faça nada mais do que supostamente deveria fazer.
Existem alguns comandos que são categorizados como DCL (Data Control Language), um termo formal e extremamente pop encontrado nos cursos de tecnologia em geral. Deixando a formalidade de lado, comandos DCL possuem o simples propósito de controlar o acesso aos dados e um dos principais comandos DCL são justamente os que envolvem permissionamento utilizando certos comandos (GRANT, DENY e REVOKE).
Sendo simplista: são comandos que gerenciam (concedem, revogam ou negam) permissões.
Maria pode entrar na casa
João não pode entrar na casa
Chaves pode usar o celular em sala de aula
Reescrevendo essas frases acima em algoritmo:
Frase A: CONCEDER ENTRADA NA CASA PARA MARIA
Frase B: NEGAR ENTRADA NA CASA PARA JOÃO
Frase C : NEGAR USO DO CELULAR NA SALA DE AULA PARA CHAVES
Traduzindo para a construção utilizada no DCL do SQL:
<AUTORIZAÇÃO> <PERMISSÃO> ON <SECURABLE> TO <PRINCIPAL>
No próximo item vamos analisar o que cada elemento significa.
4 – Concessão de permissões
A maioria das informações abaixo serão tecnicamente descritas na parte 2 da série, que trata sobre a arquitetura de permissionamento.
4.1. PRINCIPAL (Principal)
Basicamente, são os logins, usuários, roles e relacionados do SQL Server que recebem permissão em algo (que nos exemplos anteriores eram pessoas, ou determinado alguém, que recebe alguma permissão). Sendo mais abstrato, tem também a definição publicada pelo Mike Hotek (publicada em livro sobre SQL Server 2008², vide referências) que define bem o termo:
"São os meios pelos quais você se autentica e é identificado dentro de uma instância ou de um banco de dados"
Na frase: "Brenta pode andar de bicicleta", Brenta é "o principal".
4.2. SECURABLE (Securable)
A tradução para o termo "securable" mais aceita é "Alcançavel", termo presente na tradução do Training Kit 70-432 SQL Server 2008² . Pessoalmente, não gosto desta tradução (penso que algumas palavras não deviam ser traduzidas) mas ela auxilia um pouco o entendimento do conceito.
De acordo com o BOL¹ uma boa (e bem técnica) definição de securable é:
"Recursos no qual o sistema de autorização da Engine do SQL Server regulamenta o acesso."
O termo traduzido, "Alcançavel", passa a ideia de "algo que pode ser alcançado por uma permissão". Ou seja, tudo que é recurso pode ter uma permissão atribuída a alguém. Para citar alguns exemplos: Uma tabela, uma view, um banco de dados, uma procedure, etc. Tudo isso que pode ser alvo de uma permissão é chamado de securable.
Na frase: "Brenta pode andar de bicicleta", bicicleta é o "securable".
4.3. AUTORIZAÇÃO (Authorization)
São os comandos DCL propriamente ditos. Os três comandos para indicar qual autorização será concedida são:
GRANT: Significa conceder. Simples assim. O GRANT autoriza a execução de determinada ação.
DENY: Significa negar. O DENY proíbe a execução de determinada ação.
REVOKE: Significa revogar. É retirar uma autorização previamente concedida em algo.
Já tendo explicado o conceito de privilégio mínimo, reforço o conceito com a imagem abaixo:
O smiley representa a "não permissão", que é o simples fato de não possui autorização concedida e/ou negada.
O que o revoke faz não é NEGAR a permissão, ele simplesmente desfaz a permissão atual. Isso é um dos pontos que mais causam confusão quando o assunto é permissionamento.
Se eu tenho um GRANT de leitura em determinada tabela e a permissão é revogada, vou para a caixa amarela (sem permissão).
Se eu tenho um DENY de leitura em determinada tabela e a permissão é revogada, vou novamente para a caixa amarela (sem permissão).
Se eu não tenho permissão de leitura concedida e recebo DENY de leitura em determinada tabela, vou para a caixa vermelha.
Se eu tenho permissão de GRANT e recebo um DENY e depois um REVOKE, volto novamente para a caixa amarela (sem permissão).
A principal diferença entre não ter permissão e ter a permissão negada, é que um DENY restringe diretamente qualquer outra permissão em determinado objeto. Significa que, se você tiver GRANT de SELECT em determinada tabela mas receber um DENY no schema na qual aquela tabela faz parte, o DENY prevalece e o SELECT não poderá ser realizado.
Na frase: "Brenta pode andar de bicicleta", "pode" (GRANT) assume o valor da autorização (poder é uma forma de dizer "privilégio concedido").
4.4. PERMISSÃO (Permission)
É o centro de todo o assunto. É a ação que sofrerá permissionamento. Este elemento em específico é um assunto relativamente extenso e será abordada na parte 2 da série (Arquitetura). No post piloto eu indiquei o Permission Posters e será ele o material que utilizaremos para análise.
Na frase: "Brenta pode andar de bicicleta", a permissão é "andar".
4.5. Resumo
Tendo dito todos os conceitos acima, vamos mapear cada elemento com algoritmos de exemplo para facilitar o entendimento de toda a explicação:
Dividindo as frases em elementos:
Apenas para fundir todo o conceito com a prática, segue alguns exemplos de comando DCL, com sintaxe característica do SQL Server (embora o comando seja praticamente o mesmo em outros SGBD's de renome):
GRANT SELECT ON tb_produto TO [AW\renato.sq]
GRANT INSERT,DELETE,UPDATE ON tb_cheque to [UsrPerigo]
Traduzindo: Encadeamento de permissões. Imagine que você é dono de uma casa de cinco (5) cômodos e possui um hóspede que só tem acesso a um (1) cômodo. Pelo simples fato de você ser o dono da casa, automaticamente tem total liberdade em acessar quaisquer cômodos da casa. Já a do hóspede não, pois ele só tem acesso a um cômodo. Observe que a permissão é propagada naturalmente neste caso. Isto é a definição de cadeia de permissões da forma mais simples. Existem outros detalhes a serem abordados, e que serão vistos nos próximos posts.
Na minha opinião, o conteúdo apresentado é o mínimo que deve ser entendido sobre permissionamento. Espero que tenha sido útil pra alguém e no próximo post vamos discutir sobre a arquitetura das permissões.
¹ Security and Protection (BOL)
² MCTS Self-Paced Training Kit (Exam 70-432): Microsoft SQL Server 2008 Implementation and Maintenance (Mike Hotek)