BLOG RODRIGO ALMEIDA

Olá,

Uma das táticas mais “sujas”, diga-se de passagem, é a alteração de senha do usuário sem a sua permissão, pois pode ocorrer em diversos momentos do dia-a-dia, por exemplo:

• O cara saiu de férias, é deixou algum objeto no owner dele.
• Preciso pegar algumas informações da tabela do FULANO.
• É necessário fornecer algumas permissões do usuário X para Y.
• Ou a MELHOR! Existe um owner na aplicação que foi criado em 1900 e bolinhas, e agora, precisa de manutenção e ninguém tem acesso a esse usuário, porque ninguem sabe a senha.

Bom, para resolver esses “probleminhas”, existe uma técnica no Oracle que podemos utilizar para ter acesso completo a um específico usuário, um pequeno “hack” no dicionário Oracle, mas para conseguir a façanha, é necessário que tenha acesso a view DBA_USERS, que foi utilizado nesse exemplo.

LEMBRANDO

Lógicamente, que todos os exemplos que citei acima, poderiam ser feitos pelo DBA da empresa ou alguém que tenha acesso a usuários gerenciais do banco de dados, como SYSTEM, usuários com role de DBA e etc. Isso é apenas um exemplo de como se aplicar a técnica.

Agora, vou passar o exemplo prático de como funciona.

1) Vamos criar um usuário.

@id


HORA EXECUTADA
-------------------
09-09-2008 11:45:57

INSTANCE_NAME   HOST_NAME            STATUS
--------------- -------------------- ----------
xe              DBARODRIGO          OPEN

USER IS "SYS"

create user RODRIGO
identified by rodrigo;

Usuário criado.

grant create session to RODRIGO;

Concessão bem-sucedida.

disco

Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

2) Teste a conexão do novo usuário no banco de dados.

conn rodrigo/rodrigo

Conectado.

disco

Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

3) Conectado com um usuário administrativo, faça um select básico na view DBA_USERS.

conn system

Informe a senha:

Conectado.

select username, account_status, password
    from dba_users
    where username = 'RODRIGO';

USERNAME ACCOUNT_STATUS PASSWORD

—————————— ——————————– ——————————

RODRIGO OPEN F697FBF0BB2DA2EC

4) Altere a senha do usuário desejado, no exemplo, vou alterar a senha para FERNANDA.

alter user RODRIGO identified by FERNANDA;

Usuário alterado.

5) Pegue o valor gerado para a nova senha.

select username, account_status, password
  from dba_users
  where username = 'RODRIGO';

USERNAME ACCOUNT_STATUS PASSWORD

—————————— ——————————– ——————————

RODRIGO OPEN FB34D454E9FFDE18

Observação
Pode parecer confuso, mais vamos recapitular os valores que são equivalentes as senhas:
F697FBF0BB2DA2EC = RODRIGO
FB34D454E9FFDE18 = FERNANDA

6) Para voltar a senha anterior, apenas utilize a opção VALUES junto com IDENTIFIED BYcom o valor da coluna password.

conn system

Informe a senha:

Conectado.

alter user RODRIGO identified by values 'F697FBF0BB2DA2EC';

O valor F697FBF0BB2DA2EC (gerado por um algoritmo HASH), é equivalente ao valor RODRIGO.
Agora, veja os testes.

conn rodrigo/fernanda

Conectado.

disco

Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

conn system

Informe a senha:

Conectado.

alter user RODRIGO identified by values 'F697FBF0BB2DA2EC';

Usuário alterado.

disco

Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

conn rodrigo/rodrigo

Conectado.

disco

Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

Como eu não alterei o valor para a senha FERNANDA, se eu tentar logar com essa senha, terei erros, veja.

conn rodrigo/fernanda

ERROR:

ORA-01017: invalid username/password; logon denied

FINISH!

Uma técnica de hack bem conhecida entre os DBAS, que até a versão 10gR2 (no Patchset 10.2.0.4) ainda continua, eu não sei ainda se nas versões 11g já possui algum tipo de segurança nesse ponto, então aprecie com moderação.

ATUALIZAÇÃO

Para as versões 11g essa técnica não é mais aplicada devido as alterações estruturais no banco de dados por parte de segurança, que ficou muito mais confiável. Então, essa técnica se aplica até a versão Oracle Database 10g Release 2.

Abraços,

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 2.002 por um senador Paul Sarbanes e um deputado Michael Oxley no 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, afim de tornar-la uma empresa confiável, transparente e principalmente segura.

Deste modo, a atenção ao departamento de Tecnologia da Informação (TI) é 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.

Essas restrições impostas poderão ver 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!

Abraços,