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.
