Faça o curso: jQuery na Prática

Olá!

Recentemente estive sobre os olhares da auditoria Sarbanes-Oxley (SOX) para os bancos de dados Oracle da empresa que trabalho e gostaria de compartilhar alguns check-lists necessários para os DBAs passarem sem muitos problemas dessa auditoria.

Sobre a Lei Sarbanes-Oxley (SOX)

A auditoria SOX, foi criada em 2002 pelo senador Paul Sarbanes e deputado Michael Oxley, nos EUA, tendo como objetivo controlar e investigar todos os investimentos estrangeiros de empresas que possuem capital aberto no mercado, afim de evitar grandes fraudes e governança inapropriada.

Como muitas empresas que possuem operações financeiras no exterior, a SOX promove a criação de processos de auditoria e segurança em todos os departamentos da empresa, a fim de torná-la uma empresa confiável, transparente e principalmente segura.

Deste modo, a atenção ao departamento de Tecnologia da Informação é uma parte muito importante durante uma auditoria SOX, pois os sistemas da empresa devem ser seguros e seguir diversos processos internos elaborados pelas suas gestões para prevenir fraudes.

O banco de dados acaba sendo um alvo certo no processo de auditoria, porque simplesmente, armazena todos os dados vitais de uma empresa, e essa "caixa" de dados precisa ser segura e de acesso controlado, tornando uma dor de cabeça aos DBAs e projetos da empresa, porque muitas restrições são impostas.

Vocês poderão ver essas restrições impostas no check-list abaixo, onde são pontos que os auditores pedem evidências sobre o processo e/ou atividade realizada. Todo o check-list foi realizado para ambientes de bancos de dados Oracle.

Primeiramente, vamos iniciar o nosso check-list partindo da infra-estrutura, ou seja, o que é necessário para o ambiente de banco de dados estar de acordo com o SOX.

Infra-Estrutura

• Backup & Recover em dia;
• Documentação da Estratégia de Backup & Recover para cada banco de dados;
• Evidências de testes de recover vindas de Fita e/ou disco, o verdadeiro LOG da operação;
• Padrão de instalação seguindo o OFA (Optimal Flexible Architecture);

Para bancos de dados em ambientes Windows:

Lista de usuários Locais do servidor;

Permissões dos usuários e pastas Oracle;

DUMPSEC dos servidores;

Relacionamento de confiança entre os servidores;

Lista de serviços do windows, para saber qual é necessário ou não;

Lista de protocolos utilizados pelo servidor;

Permissão dos arquivos listener.ora, sqlnet.ora e Executáveis;

Permissão do Oratab;

Arquivo de Parâmetro, quais e qual o motivo dos parâmetros;

Informação sobre os processos do Windows Scheduler;

Informações sobre os processos Batch, não é permitido fixar a senha de usuários em hardcode;

Informações sobre as últimas atualizações do Windows, principalmente de Vulnerabilidade.

Para bancos de dados em ambientes Linux/Unix:

Utilizar o umask 022 no profile Oracle;

Fornecer os detalhes do profile default dos usuários e csh.login do sistema operacional;

Lista de serviços que estão executando, e desativar os desnecessários.

Lista dos usuários do DBA Group;

Permissão dos arquivos, diretórios e FileSystem do Oracle User;

Permissão do OraTab;

Permissão de shell scripts, não é permitido fixar a senha de usuários em hardcode;

Permissão nos arquivos Listener.ora, sqlnet.ora e Executáveis/Libs;

Arquivo de Parâmetro, quais e qual o motivo dos parâmetros;

Informações sobre os processos da Crontab e suas permissões.

Informações de permissão sobre os arquivos de dados, traces e log;

Agora, vamos para um check-list mais refinado, internamente no banco de dados, o que o DBA deverá prestar atenção na auditoria, veja abaixo:

Banco de dados

• Lista de usuários Genéricos, ou seja, Lista dos owners da aplicação;
• Lista de usuários Convencionais, os usuários finais;
• Lista de Profiles e seus parâmetros;
• A função VERIFY_PASS_FUNCTION deve ser programada para de acordo com a política de senha da empresa;
• Permissões de visualização no dicionário de dados Oracle, principalmente as views dba_source e dba_objects;
• Lista de permissão dos Usuários por objeto, role e grants de sistema;
• Lista de permissão dos usuáriso com WITH OPTION para concessão de permissão;
• Documentação do processo de Backup sobre os componentes lógicos, como tabelas, procedures, packages, functions e triggers;
• Documentação do processo de agendamento de Jobs ou a utiização do DBMS_SCHEDULER, Quem usa, Como usa e quem utiliza;
• O DBA não pode utilizar as contas SYS e SYSTEM, deve possuir uma conta própria e nomeada para cada profissional;
• Senha no Listener;
• Não utilizar autenticação via SO para logar-se como SYS AS SYSDBA;
• Utilizar arquivo de senha no banco de dados;
• Utilizar o parâmetro DBLINK_ENCRYPT_LOGIN = TRUE no banco de dados quando se trabalha com versões anteriores ao 9.2.0.1;
• Recomendação de habilitar o AUDIT_TRAIL = DB ou SO, mas é apenas recomendação, depende de analise de ambiente;
• Habilitar o parâmetro AUDIT_SYS_OPERATIONS = TRUE para auditoria no usuário SYS;
• Ocultar as autenticações no banco de dados pelo sistema operacional, usando o parâmetro OS_AUTHENT_PREFIX = ";
• Ter habilitado o parâmetro REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE para administração remota.

Dependendo da empresa que irá auditar, alguns itens podem ser incluídos e outros nem solicitados, porém, nunca se sabe o que eles vão pedir, por isso, fica a recomendação e as devidas atenções de segurança.

Outro detalhe importante sobre uma auditoria SOX, que os auditores pedem todos os documentos de processo e/ou atividade do banco de dados, portanto, mais e mais documentos são necessário para os nossos ambientes, como:

• Documentação de Instalação do banco de dados;
• Documentação do controle de incidentes de banco de dados;
• Documentação do controle de alteração do banco de dados feitas atráves de aplicação, ou seja, quando é necessário incluir, deletar ou modificar algum objeto da base;
• Documentação dos serviços que estão sendo monitorados no banco de dados;
• Documentação de procedimentos de manutenção no banco de dados e etc;

Para a equipe de DBAs pode ser um imenso problema isso, porque documentar todo esses processos leva muito tempo e dificilmente um específico profissional sabe tudo sobre um determinado ambiente. Por um lado, a documentação é extremamente importante para equipes com muitos DBAs, ou empresa que possuem alta rotatividade desses profissionais, pois o ambiente fica muito mais controlado, seguro e fácil de se administrar. Eu sou totalmente favorável a qualquer tipo de documentação, tanto banco e aplicação.

Uma recomendação importante quando for passar por auditoria SOX, são elas:

• O DBA deve ter um backup, ou seja, outro profissional que faça as mesmas tarefas quando ele ficar doente ou sair da empresa;
• Tenha ambientes separados para a aplicação, exemplo: Ambiente de DESENVOLVIMENTO, HOMOLOGAÇÂO e PRODUÇÂO;
• Tenha uma gestão de incidentes ou projeto que controle todas as transações sobre os ambientes mencionados acima;
• Todo o código PL/SQL que passe a terceiros ou outras filiais deve usar o aplicativo WRAP para criptografia dos dados e posteriormente comparar os checksum;
• Tenha ótimas estratégias de Backup & Recover;
• E um acesso restrito para querys em ambiente de produção.

BOM! Acho que é isso pessoal, esses são alguns ("grandes") check-lists para supotar uma auditoria da SOX, ou até melhor, para conhecer também um pouco mais sobre como proteger o seu banco de dados, não precisa passar por uma auditoria para poder implementar alguns sugestões que estão acima ou até mesmo, documentar os seus processos. São check-lists que é válido como um todo!

Para mais informações, o meu Blog está a disposição.

Abraços,