Segurança nos Bancos de Dados Oracle e SQL Server

Este artigo descreve conceitos básicos sobre banco de dados e algumas ferramentas de segurança contidas nos bancos Oracle 12C e SQL Server 2014. Além disso, mostraremos alguns testes de invasão que foram realizados nos mesmos.

No ambiente computacional, a segurança das informações deve ser minuciosamente elaborada e estruturada englobando toda a organização, pois uma falha em qualquer ponto pode envolver todo o ambiente. Em BD, as investidas podem ter como foco somente roubo de dados, mas também a adulteração de informações dessa base de dados. Esses métodos são bem variados e se diversificam de acordo com a pretensão final do ataque.

Por isso, o servidor de banco, mesmo não tendo conexão direta com a internet, deve ser preservado contra ataques que procuram os pontos vulneráveis de sua configuração, entre outros. A seguir entenderemos mais sobre os princípios a serem seguidos para preservar as informações contidas nos servidores

Os princípios da Segurança da Informação

Para se obter uma informação segura, a mesma deve ser confiável, íntegra e disponível. Informação é um ativo importante e essencial para os empreendimentos da empresa e deve ser protegida dos vários tipos de ameaças existentes, de modo a diminuir os riscos aos negócios e maximizar os lucros e as oportunidades. A ISO/IEC 17799:200 define segurança da informação como "a proteção da informação de vários tipos de ameaças para garantir a continuidade do negócio, minimizando os riscos, maximizando o retorno sobre os investimentos e as oportunidades de negócio.

As características básicas da segurança da informação são: confidencialidade, disponibilidade e integridade que podem ser consideradas como atributos.

A Confidencialidade garante que os dados sejam acessíveis apenas para pessoas autorizadas, independentemente de onde estes dados estejam armazenados.

Integridade garante que as informações não sofrerão nenhuma modificação durante o trajeto entre quem enviou e quem recebeu a informação, tendo assim sua real autenticidade após chegarem ao destino as informações armazenadas devem manter suas características originais mesmo depois de terem sido manipuladas.

Disponibilidade assegura que somente pessoas autorizadas tenham acesso à informação e aos ativos correspondentes sempre que necessário.

Tudo que acrescenta valor para a empresa são considerados ativos como: banco de dados, documentação de sistemas, planos de continuidade, informações arquivadas, entre outros. Segundo Mello (2012), a segurança deve estar presente em três estágios, físico, lógico e gerencial.

Principais Conceitos de BD

Um Sistema de Banco de Dados, em sua essência, é apenas um sistema computadorizado projetado para armazenamento de grandes blocos de informações, não possui gerenciamento, fica restrita ao modelo relacional, rede, hierárquico, entre outros, apenas as tabelas, e permite que os usuários busquem e atualizem as informações quando necessário, o mesmo é formado por software, hardware e usuários (DATE 2004, p.03).

Para acessar esses dados, utiliza-se o Sistema Gerenciador de Banco de Dados (SGBD), que são uma coleção de ferramentas, serviços e programas, um software com recursos específicos para simplificar o manuseio das informações de BD e o desenvolvimento de programas e aplicativos que têm por finalidade manter e manipular um BD. Esta ferramenta pode ser o Oracle, SQL Server, entre outros. O objetivo de um SGBD é criar um ambiente adaptado para a restauração e armazenamento das informações do banco.

O SGBD executa uma série de procedimentos, conhecidas pela sigla ACID, que representa atomicidade, consistência, isolamento e durabilidade, as quais definirão como serão executadas as transações de maneira a garantir a consistência da base de dados.

Na atomicidade, cada transação é dada como “atômica”, em outras palavras, entende - se que deverão ser gravados todos os dados ou nada. Quando se diz que uma transação é atômica entende-se que a mesma é irredutível, sendo assim se uma parte da transação falhar, toda transação deve ser desfeita, se todas as ações são efetuadas com sucesso, então a transação pode ser efetivada.

Na consistência os dados de um BD devem permanecer íntegros após qualquer transação concluída, ou seja, deve permanecer verdadeiro, coerente.

Já no isolamento as modificações feitas por transações simultâneas devem ser isoladas das modificações feitas por qualquer outra transação, ou seja, múltiplas transações podem ocorrer ao mesmo momento sem intervenções entre si. É importante atentar ao fato de que o isolamento não controla a ordem de execução das transações somente garante que uma transação não interfira na outra nem tenha acesso a outra.

Na durabilidade depois de uma transação ser concluída com sucesso, os dados permanecem no sistema, mesmo que ocorram falhas posteriores, ou seja, o dado deve permanecer gravado.

Esse artigo estudará dois bancos de dados, a serem estudados nos tópicos a seguir.

Oracle 12c

A Oracle está no mercado há mais de 20 anos e foi a primeira empresa a conseguir rodar um SGBD em um mainframe e microcomputadores. Atualmente, a empresa está em terceiro lugar na lista das maiores empresas de software do mundo. O Oracle 12c é a nona versão do SGBD, para facilitar os esforços dos clientes, padronizar, consolidar e automatizar os serviços de BD em nuvem.

É possível gerenciar usuários com permissões diferentes para controle de acesso a alvos, objetos e outros recursos do Enterprise Manager, segregando permissões para usuários e administradores conforme funções definidas a cada um dos usuários. Existem inúmeros privilégios para diferentes administradores, permitindo filtrar o acesso a cada área do Enterprise Manager.

O BD Oracle 12c possui ferramentas importantes para segurança dos dados armazenados, que são:

  1. Oracle Database Security: uma avançada tecnologia para proteção dos dados na fonte. É uma segurança em várias camadas, onde se consegue ter mascaramento dos dados, criptografia transparente e controle de usuários privilegiados. Ela oferece um portfólio vasto de soluções de segurança para garantir a privacidade dos dados e proteção contra ameaças internas.
  2. Oracle Advanced Security server: para criptografar os dados em repouso e mascarar os dados sempre que eles saírem do BD. Proteção dos dados de aplicativos com rapidez e facilidade com criptografia completa de table space ou colunas, incluindo backups e exportações, integração com módulos de segurança de hardware líderes do setor (HSMs) ou soluções de gerenciamento importantes em toda a empresa.
  3. Oracle Database Vault: aumenta a segurança das aplicações existentes e aborda exigências regulatórias que exigem separação de deveres, privilégios mínimos, e outros controles preventivos. Além disso, protege de forma proativa os dados do aplicativo sejam acessadas por usuários de BD privilegiados. Também pode ajudar a descobrir os privilégios de tempo de execução do Oracle Database sem interrupções.
  4. Auditoria: pode-se realizar a criação de log de auditoria, facilitando a interpretação da informação e tornando sua visualização mais clara e abrangente. Além disto, fornece subsídios para que os DBAs e auditores possam realizar diagnósticos mais precisos do que está acontecendo com os dados da base, assim como identificar possíveis problemas na aplicação que estejam refletindo no banco.
  5. O RMAN (Recovery Manager): é uma parte integrante do BD da Oracle, que permite a execução de backups do BD e, principalmente, a recuperação de dados em caso de falha do BD.
  6. Lista branca de objetos de BD para referenciar blocos PL/SQL: permite aumentar a segurança do BD criando uma White List de objetos, como visões, tabelas e triggers, que podem acessar um determinado bloco PL/SQL (function, procedure, packege ou type specification). Esta lista deve ser criada no mesmo schema do bloco PL/SQL sobre o qual o acesso será controlado.
  7. Privilégios default da role resouce: o privilégio UNLIMITED TABLE SPACE não faz mais parte daroleresource, permitindo aumentar a segurança do BD.
  8. Data/hora do último login do usuário: é possível consultar na tabela USER$ a data do último login do usuário no BD. Pode-se bloquear um usuário que não loga no BD após um determinado período. No Oracle 11g tem que verificar a última data de login através de registros de auditoria, o que não é muito seguro, pois eles podem ser excluídos a qualquer momento.

BD SQL Server 2014

A versão mais recente do SQL Server conta com novos recursos in-memory integrado ao BD central e também em nuvem, simplificando a adoção da mesma.

As práticas recomendadas para instalação são: aprimoramento da segurança física, que consiste no isolamento do físico de lógico para compor a base de segurança; usar firewalls, isolar serviços que reduz de maneira significativa o risco de comprometer ou afetar outros serviços. Além disso, configurar um sistema de arquivos seguro colabora bastante com a segurança, usando um Redundant Array of Independent Disks (RAID) para arquivos de dados críticos, desabilitar os protocolos NetBIOSe SMB, instalar o SQL Server em um controlador de domínio para armazenar os dados e gerenciar interações entre os usuários e o domínio, incluindo processos de logon do usuário, autenticação e pesquisas de diretório, contas de serviço executando os serviços do SQL Server utilizando as menores permissões possíveis, com poucos privilégios, executar contas de serviços utilizando as menores permissões possíveis, com poucos privilégios, solicitar autenticação do Windows para conexões com o SQL Server e utilizar senhas fortes para todos os logons do SQL Server.

As ferramentas essenciais para a segurança no SQL-Server 2014 são:

  1. Criptografia transparente (TDE): apanha os dados não criptografados de backup e criptografa os dados antes de inseri-los no disco. Com a finalidade de proteger um importante fator de compressão de backup SQL Server juntamente com a criptografia recentemente introduzida, a compressão é realizada com os dados de cópia de segurança primeiramente, antes da encriptação é aplicada aos dados comprimidos. Com esta ordem de ações, um importante fator de compressão pode ser preservado enquanto o backup repousa sobre o veículo de backup é criptografada.
  2. Gerenciamento de chaves de criptografia: serve para proteger os dados de backup no SQL Server 2014 e pode-se optar por criptografar quando você cria um backup. As opções de codificação integram um algoritmo de codificação e um certificado de chave assimétrica, que possa ser utilizada para a encriptação. Apenas chaves assimétricas que localizam-se na estendida Key Management é suportado.
  3. Certificação CC em alto nível de garantia, que oferece Common Criteria (CC): certificação na garantia de alto nível, com um maior isolamento de tarefas para maior segurança. Common Criteria é um conjunto internacionalmente aprovado de padrões de segurança que oferece uma avaliação clara e confiável dos recursos de segurança de produtos de tecnologia da informação.
  4. A auditoria de uma instância do mecanismo de BD do SQL Server ou de um BD individual envolve o controle e o registro em log dos eventos que ocorrem no Mecanismo de BD. A auditoria do SQL Server permite criar auditorias de servidor, que podem conter especificações de auditoria de servidor para eventos no nível de servidor, além de especificações de auditoria de BD para eventos no nível de BD. Os eventos auditados podem ser gravados nos logs de eventos ou nos arquivos de auditoria. Além disso, a auditoria do SQL Server fornece as ferramentas e os processos necessários para habilitar, armazenar e exibir auditorias em vários objetos de servidor e de BD.
  5. Backup com Management Studio: é possível gerar o script Transact-SQL backup correspondente, clicando no botão script e selecionando um destino para o script. Depois de se conectar à instância adequada do BD, no pesquisador de objetos, será realizado o backup dos dados no servidor.

Cenário

O cenário proposto será para testar as vulnerabilidades dos BDs Oracle e SQL Server. Será realizada uma comparação de qual foi o mais seguro diante dos ataques.

Para realização dos testes foi utilizado o Oracle Database 12c Enterprise Edition, Release 12.1.0.1.0 – 64bit, instalado no sistema operacional Oracle Linux Server 6.5, 64 bits; e o SQL Server 14, instalado no sistema operacional Windows 7 64bits. Ambos foram instalados em uma máquina VirtualBox-4.3.18-96516-Winx, que permite a instalação e utilização de um sistema operativo dentro de outro, dando suporte real a softwares de outros sistemas.

Foram criadas quatro tabelas e uma view com o usuário administrador default de cada BD. Em cada uma foi efetuado três insert’s diferentes para preenchimento de seus campos com três objetos distintos, e a view para seleção de campos específicos unindo três tabelas distintas.

Foram realizados cinco testes para verificar o grau de segurança e, ao mesmo tempo, uma comparação de cada um dos BD em questão. Para realização desses testes foi necessária a criação de cinco usuários em cada um dos BD: teste_conexão, teste_criptografia (com permissão de criar e selecionar tabelas), teste_dropObj (com permissão de visualização as tabelas criadas por outros usuários do BD, podendo também criar tabelas inserir campos nas mesmas), teste_rman (apenas no Oracle, com permissão de selecionar e criar tabelas) e teste_bkp (apenas no SQL Server, com permissão de selecionar e criar tabelas).

Primeiro Teste de conexão via web

Foi feito um código de conexão ao BD utilizando um laço de repetição “FOR”, com intuito de se descobrir a senha do BD, como mostra a Listagem 1. Sabe-se o login (teste_conexao), mas não se lembra a senha, e este código fará a repetição da senha cem vezes. A senha real deste usuário é “conexao” sem o til.

Listagem 1. Estrutura do código.
algoritmo “tentativas de senha” inicio algoritmo var senha: inteiro início para para senha de 1 até N faca escreva (senha) senha: senha ++ fim para fim algoritmo

Um BD seguro deverá bloquear o usuário automaticamente.

Segundo Teste de criptografia

Foi executado um script para ativar a criptografia nos BDs. Criou-se uma tabela com nome de criptografia com alguns campos criptografados e o usuário tentará visualizar esses dados.

Terceiro Teste: realizar o drop (EXCLUIR) uma tabela

O usuário System ou Sys (administrador no Oracle) e o sa (administrador no SQL Server) criou objetos no BD (tabelas e view). O usuário teste_dropObj realizou o comando para selecionar (select) e deletar (drop) os objetos criados pelo usuário system. Este usuário deverá apenas conseguir visualizar as tabelas e views criadas pelo system, pois ele possui permissão apenas de visualização.

Quarto teste: verificação de senhas dos usuários

Usando o usuário “system” no Oracle e usuário “sa” no SQL Server foi dado o comando select na tabela, onde os BDs armazenam todas as senhas criadas para cada usuário. O objetivo é ver se eles conseguirão visualizar as senhas de todos os usuários dos BDs.

Quinto Teste: invasão ao BD local

Veremos se uma pessoa não autorizada consegue invadir o servidor de BD e fazer várias tentativas para acessar o BD. Veremos quais resultados cada BD emitirá e se haverá sucesso a invasão.

Sexto Teste: utilizando a ferramenta RMAN x BACKUP do Oracle e Backup do SQL Server:

No Oracle foi deletado um datafile no BD e veremos se a ferramenta de backup do Oracle conseguirá recuperar o que foi deletado.

Já no SQL Server foi deletado um arquivo do BD e veremos se o backup do mesmo conseguirá recuperar o que foi deletado.

Sétimo Teste: senhas por força bruta

No Oracle foi usado o programa OPWG para tentar descobrir a senha do usuário “administrador do BD”, e no SQL Server foi utilizado a ferramenta SQL dict como a mesma finalidade.

Todos os testes foram executados dez vezes para verificar a veracidade de cada resultado.

Resultados dos testes práticos

A Tabela 1 exibirá o resultado do teste de tentativa de conexão via web em cada BD, referente ao primeiro teste.

Tabela 1. Tentativas de conexões ao BD via servidor web.
SGBD Usuário Tipo de conexão RESULTADOS
Oracle 12c C##teste_conexao Servidor web código em php BD foi bloqueado na 10° tentativa
SQL Server 2014 teste_conexao Servidor web código em php BD funcionando normalmente depois das 100 tentativas.

Na instalação do Oracle, o parâmetro FAILED_LOGIN_ATTEMPTS é definido como 10, por padrão, fazendo com que a cada conexão errada seja incrementada um ao contador e quando ele chega a 10 tentativas erradas o Oracle bloqueia o usuário, como mostra a Figura 1. Essa situação deve ser analisada pelos DBAs e, caso seja necessário, esse parâmetro pode ser definido como UNLIMITED.

Figura 1. Resultado do teste no Oracle.

Já o SQL Server não vem com esta configuração por padrão. Para que sejam bloqueados os logins por uma quantidade determinada de erros, o mesmo necessita ser configurado manualmente.

A Tabela 2 mostra o resultado do select na tabela criptografada, mostrando os resultados do segundo teste.

Tabela 2. Criptografia de dados.
SGBD Usuário CÓDIGO RESULTADOS
Oracle 12c c##teste_criptografia select*from criptografia Nem enxerga a tabela criptografada
SQL Server 2014 teste_criptografia select*from criptografia Campo criptografado

Foi utilizada a System Function pwd Encrypt para criptografar o campo senha do usuário no SQL Server. Nesse caso, apenas quem possuir a chave para desencriptar poderá visualizar o valor real deste campo, como mostra a Figura 2.

No Oracle colocou-se uma senha no WALLET e criou-se a tabela: apenas quem possui a senha para abrir o WALLET consegue dar o select na tabela e visualizar a mesma, como mostra a Figura 3.

Figura 2. Resultado do segundo teste no Oracle 12c.
Figura 3. Resultado do segundo teste no SQL Server.

No teste de exclusão, o usuário teste_dropbj, não conseguiu excluir a tabela cargo em nenhum dos BDs, pois o mesmo não possui permissão para exclusão. A Tabela 3 e as Figuras 4 e 5 mostra o resultado do terceiro teste.

Tabela 3. Demonstrativo do teste de exclusão de tabelas.
Usuário Permissão Tentativas / exclusão / tabelas RESULTADOS
C##teste_dropobj Select / insert / create 10 Negativo
teste_dropobj Select / insert / create 10 Negativo
Figura 4. Oracle 12c - drop table system.cargo;
Figura 5. SQL Server 2014 - drop table formacaoescolar;

Para o quarto teste, o select mostrou todos os campos da tabela selecionada, porém, o campo password vem criptografado por default nos BDs. A Tabela 4 mostra o nível do usuário que realizou o select nos BDs e os resultados obtidos podem ser vistos nas Figuras 6 e 7.

Tabela 4. Tentativa de visualização das senhas dos usuários do BD.
SGBD Usuário Permissão Select na tabela que armazena senhas RESULTADOS
Oracle 12c Sytem adm BD syslogins senha criptografada
SQL Server 2014 Sa adm BD syslogins senha criptografada
Figura 6. Oracle 12c – select username, password, password_versions from dba_users;
Figura 7. SQL Server 2014 – select name, password, loginpropertye(name, ‘password’) hash from syslogin where password is not null order by name;

A Tabela 5 mostra como cada banco ficou depois da tentativa de invasão, referente ao quinto teste.

Tabela 5. Invasão ao servidor.
SGBD Usuário Tipo de conexão RESULTADOS
Oracle 12c C##teste_conexao Local / servidor invadido BD foi bloqueado na 10° tentativa
SQL Server 2014 teste_conexao Local / servidor invadido BD funcionando normalmente depois das 100 tentativas com senhas erradas.

No Oracle o usuário foi bloqueado na décima tentativa de login errado (Figura 8), enquanto no SQL Server nada aconteceu em todas as tentativas.

Figura 8. Resultado do quinto teste no Oracle 12c.

Referente ao sexto teste, no Oracle foi criada uma tabela com nome de tb_rman e foi realizado o backup completo. Em seguida, a mesma foi populada com 600.000 linhas. Esta tabela foi excluída e foi realizada a restauração do backup. O mesmo processo foi realizado com SQL Server.

Conforme a Tabela 6, no Oracle, o backup foi restaurado com sucesso, tanto a tabela quanto as suas 600.000 linhas. Já no SQL Server, só foi retornado com êxito o backup completo, as linhas inseridas depois do backup completo não retornaram, pois para se ter um backup dos logs de transação é necessário fazê-lo manualmente, enquanto no Oracle esses logs são armazenados nos chamados arquives, de forma automática.

Tabela 6. Backup de dados.
SGBD Usuário Comando para voltar o backup RESULTADOS
Oracle 12c Sys Recover database/restore database Backup completo realizado com sucesso / arquivos de log backup realizado com sucesso
SQL Server 2014 Sa Backup / restaurar backup Backup completo realizado com sucesso / logs de transação não foram recuperados

Já para o sétimo teste, utilizando o programa OPWG no Oracle (Figura 9), conseguiu-se visualizar a senha do usuário “sys”, enquanto no SQL Server, utilizando a ferramenta SQL dict (Figura 10), obteve a senha do usuário “sa”, como mostra a Tabela 7.

Tabela 7. Teste de senhas por força bruta.
SGBD Usuário ao qual sofrerá o ataque Ferramentas RESULTADOS
Oracle 12c Sys OPWG Descoberta da senha
SQL Server 2014 Sa SQL dict Descoberta da senha
Figura 9. Resultado do sétimo teste no Oracle.
Figura 10. Resultado do sétimo teste no SQL Server 2014.
Tabela 8. Índice com percentual de fracasso e sucesso.
BANCO DE DADOS SUCESSO FRACASSO TOTAL DE TESTES
ORACLE 12C 85,7% 14,3% 100,0%
SQL SERVER 2014 42,9% 57,1% 100,0%
Figura 11. Índice com percentual de fracasso e sucesso.

A Tabela 8 e a Figura 11 mostram o percentual de sucessos e fracassos dos resultados obtidos nos sete testes.

O SQL Server é um SGBD bem conceituado na atualidade, possui muita credibilidade e tem como histórico a facilidade de uso e de gerenciamento. O Oracle, por sua vez, é um dos maiores do mundo, e prioriza a segurança e amplitude de recursos.

Ambos são excelentes, mas o SQL Server traz como vantagem mais clara o menor custo, aproximadamente metade do valor do Oracle.

No SGBD SQL Server, todas as funcionalidades estão inclusas no seu valor de licenciamento inicial, ao passo que, no SGBD Oracle é necessário adquirir licenças adicionais (Options). Apresenta um elevado custo, maior complexidade em seu gerenciamento, porém possui muitos recursos voltados à segurança e desempenho que podem ser essenciais para a organização.

Nenhum sistema de banco de dados é totalmente seguro, porém é necessário que se configure o maior número possível de ferramentas e técnicas, a fim de evitar impactos causados por vulnerabilidades de segurança. Além disso, é de suma importância que haja auditoria constante do BD.

Frente aos testes realizados, o Oracle apresentou 85,7% de segurança, enquanto o SQL Server 42,9%. Este percentual foi embasado nos sete testes realizados neste artigo. Os resultados mostram que algumas técnicas de invasão precisam ser estudadas para que o DBA garanta a confidencialidade das informações armazenadas em seu BD.

Assim, pode-se afirmar que o Oracle demonstrou maior segurança diante de ataques, uso incorreto ou malicioso do sistema, pois o mesmo dispõe de mais recursos de segurança, por padrão.

Referências Bibliográficas

DATE, C. J. Introdução a Sistemas de Bancos de Dados. Rio de Janeiro: Ed Campus, 8ª ed., 2004.

KOLLING, Gabriella S. Segurança da Informação. set. 2012
http:// seguranca-da-informacao.info/index.html

MELLO, A.; VICTÓRIA, Jr., C.; NOWACZYK, D.; MIGUEL, W. Computers in your future, thirdedition: banco de dados. São Paulo: Artmed, 1999. p. 192–200.

MICROSOFT. Server andCloud Platform. abr. 2014.
http://ww.microsoft.com/pt-br/server-cloud/products/sql-server/

ORACLE. Oracle Advanced Security. 2013
http://www.oracle.com/br/ products/database/options/advancedsecurity/overview/index.html

ORACLE. Enterprise Manager Cloud Control Introduction 12c Release 1(12.1.0.1). 2013.
http://download.oracle.com/docs/cd/E24628_01/doc.121/e25353/whats_ new.htm.

SÊMOLA, Marcos. A importância da gestão de segurança da informação. 2003.
http://www.linorg.cirp.usp.br/SSI/SSI2003/Palest/P03-Apresentacao. pdf

Artigos relacionados