Auditoria SOX – Sarbanes-Oxley

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.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s