Em um mundo onde cada vez mais informação importante está adentrando e sendo disponibilizada na internet, é de extrema importância garantir a segurança dos mesmo contra acesso de usuários não autorizados. E geralmente esta responsabilidade fica a cargo dos Bancos de Dados.
Os Bancos de Dados devem ter pelo menos três objetivos principais para um funcionamento adequado e esperado: a confidencialidade, a integridade e a disponibilidade. Para alcançar estes objetivos, primeiramente deve se criar uma política de segurança prática e coesa, onde determina quais condutas são sinônimos desses escopos (1).
Algumas das políticas mais usadas atualmente pelos SGDBs geralmente são os mecanismos de segurança discricionários (Discretionary Access Control – DAC), ou os mecanismos de segurança obrigatórios (Mandatory Access Control – MAC)(2). Onde o DAC tem uma política de controle de acesso determinada pelo proprietário (owner) do objeto, e o MAC que tem uma política de acesso que passa pelo sistema e não pelo proprietário do objeto, onde o MAC impõe restrições de acordo com os níveis a qual os usuários e objetos estão categorizados(3). Além dos SGDBs essas políticas de segurança também são utilizadas pelos sistemas operacionais, tal como o mecanismo de acesso SELinux (Security-Enhanced Linux) que faz a implementação da arquitetura MAC em seu controle no sistema operacional linux(4)(6).
Por sua vez o SepgSQL é um módulo do banco de dados PostgreSQL que dá suporte ao Controle de Acesso Obrigatório (MAC), baseando-se nas políticas de segurança do SELinux(5). Fazendo também um controle de granularidade de dados, ou seja, permitindo o acesso ou não de determinadas tabelas, linhas ou colunas do banco de dados, usando como base o contexto e segurança(6).
Todos os arquivos e processos são rotulados ou obtém um contexto de segurança que identifica de quem pertencem, qual a sua regra ou papel, seu tipo e o nível de segurança impregnado. Um exemplo desse contexto você pode ver a seguir.
unconfined_u:object_r:user_home_t:s0
O campo unconfined_u seria o usuario SELINUX, o object_r seria sua regra ou papel, user_home_t seria o tipo, e por último s0 seria o nível de segurança(7).
REFERÊNCIAS
(1) Dos Santos, Daniel L. – Controle de Acesso em Sistemas Gerenciadores de Banco de Dados, Disponível em: < http://repositorio.roca.utfpr.edu.br/jspui/bitstream/1/3588/1/CT_GESER_V_2014_1.pdf >. Acesso em: 7 out. 2018.
(2) De Souza, Ana P. – Segurança de BDs por concessão de privilégios de acesso a usuários no Oracle, Disponível em: < https://www.devmedia.com.br/seguranca-de-bds-por-concessao-de-privilegios-de-acesso-a-usuarios-no-oracle/33266 >. Acesso em: 7 out. 2018.
(3) Schwerz, André L – Roberto, Rafael L. – Segurança em Banco de Dados, Disponível em: < https://www.dropbox.com/s/tfr4jb8xh1brl84/04%20-%20Seguranca.pdf >. Acesso em: 7 out. 2018.
(4) National Security Agency. – SELinux Frequently Asked Questions (FAQ), Disponível em: < https://www.nsa.gov/what-we-do/research/selinux/faqs.shtml >. Acesso em: 7 out. 2018.
(5) The PostgreSQL Global Development Group. – Appendix F. Additional Supplied Modules, Disponível em: < https://www.postgresql.org/docs/10/static/sepgsql.html >. Acesso em: 7 out. 2018.
(6) The PostgreSQL Global Development Group. – SEPostgreSQL Introduction, Disponível em: < https://wiki.postgresql.org/wiki/SEPostgreSQL_Introduction >. Acesso em: 7 out. 2018.
(7) Red Hat, Inc. – SELINUX CONTEXTS – LABELING FILES, Disponível em: < https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-working_with_selinux-selinux_contexts_labeling_files >. Acesso em: 17 out. 2018.