Segurança em Banco de Dados: Parte 2

Olá pessoal, tudo joinha?

Estou aqui de volta para mais um artigo, dando continuidade ao tópico Segurança em Banco de Dados. Recomendo a leitura do artigo anterior (Segurança em Banco de Dados: Parte 1)

No artigo anterior vimos alguns mecanismos de segurança de banco de dados, dentre eles, os Mecanismos de Segurança Discricionários, dando mais ênfase aos controles de acesso.

O método típico para impor o controle de acesso discricionário em um sistema de banco de dados é baseado na concessão e revogação de privilégios, em um contexto de SGBD relacionais. Se você já estudou o assunto sobre Linguagem SQL, deve ter visto os comandos GRANT (atribuir permissões) e REVOKE (revogar permissões), e é sobre eles que irei detalhar melhor, mas ante disso, vamos conhecer os dois tipos comuns de privilégios discricionários.

• Privilégio em Nível de Conta: Este nível de privilégio atua em um contexto mais alto, ou seja, na conta mantida para determinados usuários, sem entrar nos detalhes de qual serão os privilégios de atuação as tabelas (relações) do banco de dados. Podemos chamar de privilégios de primeiro nível.
• Privilégio em Nível de Tabela(relação): Neste nível, o controle de privilégios é exercido nos acessos às tabelas ou visões individuais no banco de dados.

No privilégio de nível de conta podem ser incluídos os seguintes privilégios:

• CREATE SCHEMA: Criação de esquemas na base de dados
• CREATE TABLE: Criação de tabelas
• CREATE VIEW: Criação de visões
• ALTER: Para aplicar mudanças de esquema, como por exemplo, a inclusão ou remoção de atributos nas relações (tabelas)
• DROP: Para exclusão de relações(tabelas) ou visões(views)
• MODIFY: Para inserir, excluir ou atualizar tuplas(linhas)
• SELECT: Para recuperar informações no banco de dados

Vale salientar que os privilégios listados acima são em nível de conta. Estes privilégios são implementados nos SGBDs.

Já os privilégios de segundo nível, se aplicam no nível de tabela(relações), sendo estas tabelas existentes na base de dados ou visões que utilizam estas tabelas. Neste tipo de controle, quando uma tabela é criada, ela recebe uma conta de proprietário(owner), e o proprietário desta tabela recebe todos os privilégios, por padrão, para atuar nesta tabela.

Neste contexto, o DBA, irá conceder  privilégios para conta do usuário proprietário, para cada tabela. Abaixo eu listo os três principais tipos de privilégios que podem ser concedidos para uma tabela “T”, por exemplo:

• Privilégio Leitura: Também chamado de privilégio SELECT, concede para uma tabela T o privilégio de usar uma instrução SELECT para recuperação de informações no banco de dados.
• Privilégios de Modificações: Concede a conta do usuário a possibilidade de modificar tuplas (linhas) de uma tabela (relação) T. Incluindo os privilégios para INSERT (inserir), UPDATE (atualizar) e DELETE (excluir). No caso do INSERT e UPDATE é possível especificar quais atributos da tabela T poderão ser modificados.
• Privilégios de Referência: Permitirá a conta ter capacidade de especificar restrições de integridade, ou seja, de criar relacionamentos entre a tabela T e outras tabelas, podendo restringir quais atributos serão usados.

Outra forma de gerenciar este trabalho operacional de conceder ou revogar privilégios, é criar papéis (roles) e atribuir estes papéis aos usuários. Nos papéis estarão definidas as regras que se deseja para conceder privilégios e quem receber estes papéis, automaticamente também recebem estes privilégios, isso facilita bastante a vida do DBA, vejamos alguns exemplos:

Imagine que  o usuário LUIS crie um papel chamado ROLE_FUNCIONARIO e depois atribua a este papel a possibilidade de SELECT e UPDATE na tabela FUNCIONARIO. Por fim este papel será atribuído para o usuário MARCIA.

Vejamos como ficaria o comando utilizando o comando GRANT (para atribuir permissões):

CREATE ROLE ROLE_FUNCIONARIO;

GRANT SELECT, UPDATE ON FUNCIONARIO TO ROLE_FUNCIONARIO;

GRANT ROLE_FUNCIONARIO TO MARCIA;

Um mesmo usuário pode receber vários papéis se for necessário.

Ainda seguindo este exemplo acima, é possível também incrementar papéis(roles) com outros papéis existentes, ou seja, atribuir um papel a outro papel, acumulando regras vejamos abaixo um exemplo.

Imagine que LUIS  queira criar um papel que permita SELECT e INSERT na tabela DEPENDENTES e depois acumular este papel com o papel ROLE_FUNCIONARIO, vejamos abaixo como ficaria:

CREATE ROLE ROLE_DEPENDENTES;

GRANT SELECT, INSERT ON DEPENDENTES TO ROLE_DEPENDENTES;

GRANT ROLE_DEPENDENTES TO ROLE_FUNCIONARIO;

Neste exemplo, quem receber o papel ROLE_FUCIONARIO, terá privilégios acumulados.

Vamos aproveitar o momento e meter a mão na massa em uma questão de concurso.

(CEBRASPE/CESPE/TJCE/ANALISTA JUDICIÁRIO-CIÊNCIA DA COMPUTAÇÃO/2014)

A segurança é uma área importante a ser considerada pelos administradores de bancos de dados das organizações, haja vista que a segurança visa proteger os bancos de dados contra uma série de ameaças, sejam elas advindas de usuários internos ou externos. No que se refere a esse assunto, assinale a opção correta.

a) Uma VIEW é um mecanismo válido para que se restrinja o acesso a certos atributos de uma tabela, embora não seja possível criar restrições para um conjunto de tuplas

b) No controle de acesso, um usuário de banco de dados pode receber um privilégio específico sem que esteja relacionado às tabelas do banco de dados.

c) Um usuário, uma vez que possua o privilégio de INSERT acerca de determinada tabela, não pode receber novamente o referido privilégio para a mesma tabela.

d) Uma técnica eficiente para impedir um ataque de injeção de SQL é a utilização, ao máximo, das funções de banco de dados, em virtude desses objetos não serem alvos de ataques devido à dificuldade de se referenciá-los.

e) Manter um registro das operações realizadas no banco de dados é uma ação suficiente para que os dados sejam protegidos contra acesso não autorizado.

Comentários:

Questão maravilhosa para revisão, vamos por partes !

A letra a) está errada. Que a view é uma possibilidade de exibição de dados customizada, ou seja, inibindo alguns atributos de uma ou mais tabelas, tudo certo, mas, existe sim forma de restringir a visibilidade de linhas(tuplas), basta criar uma view com base em uma consulta que tenha cláusula WHERE com condições que tragam apenas um subconjunto de linhas de uma ou mais tabelas e em seguida atribuir um privilégio de SELECT para algum usuário em relação a esta view, ou seja, ele verá apenas dados que são filtrados ou seja, de algumas tuplas.

A letra b) está correta. Trata-se de privilégios obrigatórios, baseado em papéis. Vimos este tópico no artigo anterior  (Segurança em Banco de Dados: Parte 1)

A letra c) está errada. Ele pode receber, mas não vai fazer diferença alguma de forma direta. Ele pode também estar associado a mais de uma ROLE (regra), onde em ambas, possam haver por coincidência a mesma tabela envolvida.

A letra d) está errada. As funções são alvo preferidos dos ataques de Injeção de SQL, pois as funções podem ter parâmetros de interesse para invasão, portanto seu uso em banco deve ser mais restrito. (veremos este assunto no próximo artigo)

A letra e) está errada, pois isso não garante estes acessos não autorizados, pode no máximo servir para auditoria futura com a finalidade de saber qual operação foi feita no banco de dados por um determinado usuário.

Gabarito: b).

Bem, vou ficando por aqui pessoal, desejo  bons estudos e vamos que vamos.

Forte abraço! 😉 …e até o próximo artigo.

============================

Prof. Luis Octavio Lima

Referências: Sistemas de Banco de Dados – 6ª Ed. – Elmasri, Ramez; Navathe.