A realidade atual em muitas organizações é que os DBAs estão focados em alta disponibilidade e desempenho de banco de dados, e não na segurança dos dados.
A reação do profissional muitas vezes é adotar uma postura relutante na implementação de configurações de segurança devido à falta de compreensão completa do risco de acesso indevido dos dados ou devido ao receio de que utilizando as melhores práticas de segurança possa involuntariamente prejudicar o desempenho de algumas funcionalidades da camada de persistência do banco de dados.
Para agravar essa percepção, o DBA pode ter um pouco de preocupação, incerteza e dúvida sobre como implementar as configurações de banco de dados que resultem na melhoria da segurança sem impactar em suas operações, pois exigem testes de reversão em muitos casos.
No entanto, a principal razão para se preocupar com a segurança está no impacto negativo a sua imagem perante seus clientes. O impacto negativo, além de afetar diretamente a reputação do DBA, acarreta em sanções financeiras, por exemplo pela de perda de dados, sendo uma conduta passível de penalidades previstas na legislação.
O objetivo deste artigo é entender os riscos mais comuns na segurança do banco de dados Oracle, a partir da versão 9 até 12, e saber como resolvê-los aplicando as melhores práticas com base nos boletins de segurança da Oracle.
Desde o lançamento da versão 9i, a Oracle tem feito um esforço público para mudar suas rotinas de instalação para que sejam “seguras por padrão”. No entanto, os erros comuns em segurança discutidos neste artigo, por diversos motivos são definidos por padrão, por exemplo quando um banco de dados é criado manualmente.
Visando compreender os principais erros de segurança no banco de dados, definimos sete recomendações, ordenadas levando-se em consideração o grau de risco e sua relevância no contexto de segurança da informação.
Descuido com as conexões e tráfego de rede
Em muitos casos, a primeira tentativa de um hacker é recuperar informações do identificador do sistema Oracle (SID – Oracle System Identifier) para realização de diferentes ataques. O SID é um nome exclusivo para uma instância de banco de dados de um determinando servidor. Além disso, é usado por padrão para localizar o arquivo de parâmetro, onde sua função é identificar arquivos relevantes, como os controlfiles do banco de dados.
Se uma conexão utiliza o SID errado ao conectar no SGBD, será exibida a mensagem ORA-12505: TNS:listener does not currently know of SID given in connect descriptor. Para evitar ataques de força bruta é essencial escolher um SID forte. No momento de escolher o SID procure não utilizar palavras do dicionário, palavras com menos de 10 caracteres, incluir pelo menos um caractere especial.
Desta forma, o SID será forte do ponto de vista de um ataque de força bruta. Vale ressaltar que o SID forte não permite, por si só impedir um hacker de realizar a conexão com o banco de dados, mas é uma boa prática como uma camada adicional, e como parte de uma abordagem de defesa para a segurança.
Em aplicações web, a String de conexão fornece um conjunto de valores que especifica informações para conexão nos repositórios de dados do back-end (banco de dados). A String de conexão é passada para um provedor ou driver para iniciar uma conexão.
O ataque chamado CSPP (Connection String Parameter Pollution) explora especificamente o ponto e vírgula delimitada na String de conexão do banco de dados pelo qual são construídos dinamicamente, com base nas entradas do usuário. O CSPP, se realizado com sucesso, pode ser usado para furtar identidades de usuários e credenciais.
CSPP é um ataque de alto risco, devido à relativa facilidade de ser realizado, e os resultados potenciais que podem ter alto impacto.
Cabe aos DBAs orientar os desenvolvedores de software sobre o perigo destes ataques e aprender sobre o mecanismo de defesa para orientá-los em seu código. Da mesma forma, os fornecedores de software devem disponibilizar modelos ou classes para facilitar a codificação, eliminando a adivinhação dos desenvolvedores na proteção contra essas vulnerabilidades. Por exemplo, a Oracle disponibiliza a classe OracleConnectionStringBuilder para conexões que utilizem o Data Provider em softwares desenvolvidos em .NET. Com a utilização dessa classe, os desenvolvedores podem usar um arquivo de configuração para fornecer a String os valores por meio de pares de chave/valor. Isso torna a criação de Strings de conexão menos propenso a erros, e, finalmente, proporciona melhor segurança.
Além das Strings de conexão, é necessário proteger a rede e seu tráfego do acesso indevido. Tomar medidas para diminuição ou eliminação das ameaças, e as consequências de uma violação de segurança são fatores primordiais para detectar qualquer aumento dos níveis de ameaça. Para gerenciar conexões de rede, é comumente utilizado o Oracle Net Manager através do comando netmgr.
Algumas práticas podem ser aplicadas para melhorar a segurança da rede, tais como habilitar logs, conforme linha 1 da Listagem 1. E também não configurar senhas no listener.
Listagem 1. Habilitando o log no Listener.
1 LSNRCTL> SET LOG_STATUS on
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
LISTENER parameter "log_status" set to ON
The command completed successfullyOutra medida de segurança é prevenir administração on-line, exigindo que o administrador tenha privilégios de gravação no arquivo listener.ora por meio do parâmetro ADMIN_ ...
