Permissionamento no SQL Server – O básico (Parte 1 de 3)

keep-calm-and-ask-permission-5

Olá,

Conforme prometido no post de abertura , a ideia da primeira parte da série aqui é explicar de forma descomplicada alguns conceitos básicos sobre permissionamento, sobretudo no SQL Server (embora grande parte dos conceitos possa ser aplicada em outras tecnologias).

Os tópicos quentes são:

1. Conceito de permissão
2. Permissionamento mínimo
3. DCL
4. Concessão de permissões
5. Permission Chain


 

1. Conceito de permissão

Para começar, vamos à definição de permissão (Fonte: Dicionário Michaelis):

permissão
per.mis.são
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.

Alt

 

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.

3-  DCL 

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.

Observe as frases abaixo:

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:

deny1

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.

Para exemplicar:

  • 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:

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

Dividindo as frases em elementos:

Tabelaar

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):

5. Permission Chain

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.

Conclusão

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.

[]’s


Referências:

1 Comment

  1. Pingback: Permissionamento no SQL Server – Piloto | DBCC BLOG('SQL Server')

Leave a Comment

Your email address will not be published. Required fields are marked *