Este conteúdo foi originalmente publicado no Blog da Oracle, patrocinadora institucional ouro da ACATE. Para acessá-lo, clique aqui.

Por Alan Williams e Sean Cahill *

A segurança de banco de dados pode parecer uma tarefa complexa, e chegar à arquitetura de segurança máxima desejada para proteger os dados confidenciais demanda tempo, pessoal e orçamento. Dito isso, há certas melhores práticas fundamentais que todas as organizações, de todos os tamanhos e setores, deveriam estar implementando. Na verdade, essas práticas básicas de segurança precisam estar em vigor antes de se gastar recursos em medidas de segurança adicionais. Adote o hábito de trancar a porta da frente da sua casa antes de pensar na compra de um sistema de segurança residencial caro, com câmeras e alarmes.

Considerar cuidadosamente a forma como privilégios administrativos são concedidos aos usuários de bancos de dados pode evitar grandes problemas para as organizações, incluindo a redução do risco de violações de dados onerosas. Apesar de você provavelmente confiar nos DBAs, os cibercriminosos geralmente usam ataques de spear phishing e outros meios para alvejar os usuários privilegiados de uma organização, tirando proveito de suas contas para uso malicioso, incluindo extração de dados confidenciais. Por exemplo, se um hacker consegue invadir a conta de um DBA com privilégio de execução do comando “SELECT ANY TABLE”, ele é capaz de acessar quase todos os dados do banco de dados, incluindo números de identificação social, números de cartões de crédito e propriedade intelectual.

Leia mais: Conheça alguns dos novos recursos favoritos do Oracle Database 19c

Comece executando a Oracle Database Security Assessment Tool para identificar possíveis pontos fracos na configuração do seu banco de dados. Em seguida, certifique-se de adotar as cinco melhores práticas a seguir, incluindo o modelo de privilégio mínimo e a separação de tarefas, para encontrar o equilíbrio certo entre a necessidade dos usuários de realizar seu trabalho e a necessidade de proteger o banco de dados. Você vai minimizar o risco oferecido por contas invadidas e melhorar a postura geral de segurança da sua organização.

1. Separação de tarefas

O conceito de separação de tarefas (SOD, Separation of Duties) determina que as tarefas de administração devem ser divididas entre vários usuários, em vez de ficarem a cargo de uma única pessoa com plenos poderes. Dividir tarefas como administração, segurança e operações diminui o risco de os usuários abusarem de seus privilégios e também reduz a área da superfície de ataque no caso de contas invadidas. Por exemplo, em vez de usar o onipotente privilégio “SYSDBA”, conceda privilégios direcionados, como “SYSBACKUP”, “SYSDG”, “SYSRAC” e “SYSKM”, para as tarefas específicas de backup do banco de dados, administração do Data Guard, gerenciamento do RAC e gerenciamento de chaves, respectivamente.

2. Usuários nomeados

Os administradores jamais devem compartilhar contas por praticidade (aliás, por nenhum outro motivo). Contas compartilhadas impedem a responsabilização, aumentam o risco e basicamente tornam impossível auditar as atividades do usuário. Cada usuário de uma organização deve ter uma conta individual nomeada, explicitamente associada ao seu nome; Bob Jones, por exemplo, teria uma conta com nome “Bob_Jones” ou “Robert_Jones”. Cada conta nomeada é então vinculada a privilégios personalizados, selecionados de acordo com a função dessa pessoa dentro da organização. Regras de gravação de logs de auditoria baseadas em políticas podem ser definidas e a atividade do usuário pode ser auditada individualmente.

3. Gestão de contas SYSDBA

A conta SYS do proprietário do banco de dados (SYSDBA) é um privilégio administrativo que fornece acesso irrestrito ao banco de dados, como uma conta ROOT no gerenciamento do sistema operacional. É simplesmente poder demais para que qualquer usuário o tenha de forma permanente. De fato, muitos dos próprios administradores de banco de dados pensam que ter os privilégios da conta SYSDBA os coloca em uma indesejável posição de potencial responsabilidade caso algo saia errado. Sendo assim, o uso dessa conta e de seus privilégios precisa ser administrado e monitorado de perto, e tais privilégios só devem ser concedidos quando for absolutamente necessário, tal como durante atualizações e correções do banco de dados. Tire proveito de um sistema de gerenciamento de contas privilegiadas combinado a um sistema de gerenciamento de mudanças e designe uma janela de tempo de uso específica a fim de gerenciar de perto o privilégio SYSDBA. Recomenda-se o uso de controles de segurança compensatórios quando contas SYS/SYSDBA são usadas. Um exemplo de tal controle seria exigir fluxos de trabalho de aprovação secundários (a regra das duas pessoas).

Para auditar usuários administrativos como o SYSDBA, crie políticas de auditoria unificadas e nomeadas e, em seguida, aplique as políticas ao usuário administrativo da mesma forma que você faria para usuários não administrativos. Além disso, você pode criar condições e exclusões granulares em suas políticas ou optar por auditar todas as declarações de nível superior feitas por usuários administrativos. No caso da auditoria tradicional, o “AUDIT_SYS_OPERATIONS” ativa ou desativa a auditoria de operações de nível superior, que são comandos SQL emitidos diretamente pelos usuários ao se conectarem usando os privilégios “SYSASM”, “SYSBACKUP”, “SYSDBA”, “SYSDG”, “SYSKM” ou “SYSOPER”.

4. Privilégio mínimo

A Separação de Tarefas (SOD) separa pessoas, processos e contas, mas você não consegue aplicá-la quando todos os usuários e contas têm todos os privilégios. Depois de ter a SOD implementada, aplicar o princípio do privilégio mínimo limita cada usuário e cada conta a ter apenas os privilégios necessários para as operações do dia a dia.  Em suma, esse modelo recomenda que os usuários recebam apenas o conjunto mínimo de privilégios necessários para que realizem suas tarefas relacionadas ao trabalho, e nada mais. Para alcançar o nível adequado de granularidade, conceda os privilégios de objeto específicos que são necessários, e não privilégios gerais do sistema, e lembre-se de remover esses privilégios quando eles não forem mais necessários. Crie funções específicas de tarefas, em vez de conceder funções plenas de poderes, como a SYSDBA integrada. O modelo de privilégio mínimo reduz a área da superfície de ataque do banco de dados limitando o que um invasor consegue fazer, até mesmo quando as credenciais estão de alguma forma comprometidas.

5. Proteção da auditoria

Os logs de auditoria são necessários para emissão de relatórios de conformidade e para perícia em caso de violações ou outros eventos adversos. Faça um registro irrefutável das ações realizadas por contas nomeadas, incluindo “CREATE USER”, “CREATE ANY TABLE”, “ALTER SYSTEM” e “ALTER SESSION”, e adicione informações contextuais, como endereço IP e hora do evento. Os registros de auditoria ajudam as organizações a identificar usuários perigosos, otimizar as auditorias e simplificar a conformidade.

A Oracle fornece políticas de auditoria unificadas predefinidas (opções de auditoria padrão para uma auditoria tradicional) que cobrem configurações comuns de auditoria relevantes para a segurança, como falhas de login, alterações em parâmetros de configuração do banco de dados e gerenciamento de contas e privilégios de usuários. Algumas dessas políticas de auditoria predefinidas são ativadas por padrão. Ative ou desative as que julgar relevantes com base nas suas próprias necessidades de auditoria e na postura de segurança desejada. Além disso, é possível criar políticas de auditoria unificadas nomeadas. Crie políticas de auditoria unificadas seletivas e eficazes adicionando condições variadas, incluindo “SYS_CONTEXT” e valores de Application Context. A Oracle também oferece a capacidade de fazer auditorias detalhadas, disparando processos de auditoria quando condições específicas são atendidas, como a seleção de uma coluna específica ou o acesso a uma tabela durante um horário específico.

Próximas etapas

Adote essas melhores práticas, incluindo a separação de tarefas e o princípio do privilégio mínimo, para encontrar o equilíbrio certo entre a necessidade dos usuários de realizar seu trabalho e a necessidade de proteger o banco de dados. Você vai minimizar o risco oferecido por contas invadidas e melhorar a postura geral de segurança da sua organização. Considere também executar a Oracle Database Security Assessment Tool hoje para identificar áreas potenciais para melhoria da configuração do seu banco de dados.

Essas práticas recomendadas não são nada revolucionárias, mas, infelizmente, são negligenciadas por um grande número de organizações. Nenhum dos métodos acima mencionados requer investimentos adicionais. Não seja uma “presa fácil” para os cibercriminosos. Reduza a área da superfície de ataque de sua organização hoje considerando cuidadosamente os privilégios dos usuários.

* Alan Williams é gerente sênior de produtos de segurança e Sean Cahill é gerente sênior de marketing de produtos de segurança na Oracle.