Configurando um SGBD Oracle de forma # segura # Gerson S V Júnior (

Transcrição

1 Configurando um SGBD Oracle de forma # segura # Gerson S V Júnior (

2 O que deve ser observado? Protecting the database environment (Proteja seu ambiente) Install only what is required (Instale somente o que for realmente necessário) Enforce password management (Quantidade de falhas de logon, expira usuários, etc) Lock and expire default user accounts (Bloqueie usuários default (scott, hr...)) Manage access to SYSDBA and SYSOPER roles (Nem todo mundo é DBA) Changing default user passwords (Defina boas políticas de senha) Change passwords for administrative accounts (Senhas de Sys e System: changeoninstall) Public privileges (Privilégios para UTL_FILE (arquivos), UTL_SMTP ( s)...) Authenticate clients (Autenticação pelo S.O não é bom) Change default passwords for all users (Altere as senhas dos usuários default (scott/tiger@orcl)) Restrict operating system access (Só usuário que instalou o banco deve acessar aquivos) Prevent runtime changes to listener (Não permitindo alterações indevidas no listner) Enable Oracle data dictionary protection (Projeta o Dicionário de Dados) Checking network IP addresses (Limitando IP s que podem acessar o banco) Encrypt network traffic (Criptografe o tráfego da rede) Apply all security patches (Mantenha seu banco atualizado OTN, Metalink) Report security issues to Oracle (E claro... Informe a Oracle, se encontrar algum furo!) Fonte:

3 Quais iremos abordar? Protecting the database environment (Proteja seu ambiente) Install only what is required (Instale somente o que for realmente necessário) Enforce password management (Quantidade de falhas de logon, expira usuários, etc) Lock and expire default user accounts (Bloqueie usuários default (scott, hr...)) Manage access to SYSDBA and SYSOPER roles (Nem todo mundo é DBA) Changing default user passwords (Defina boas políticas de senha) Change passwords for administrative accounts (Senhas de Sys e System: changeoninstall) Public privileges (Privilégios para UTL_FILE (arquivos), UTL_SMTP ( s)...) Authenticate clients (Autenticação pelo S.O não é bom) Change default passwords for all users (Altere as senhas dos usuários default (scott/tiger@orcl)) Restrict operating system access (Só usuário que instalou o banco deve acessar aquivos) Prevent runtime changes to listener (Não permitindo alterações indevidas no listner) Enable Oracle data dictionary protection (Projeta o Dicionário de Dados) Checking network IP addresses (Limitando IP s que podem acessar o banco) Encrypt network traffic (Criptografe o tráfego da rede) Apply all security patches (Mantenha seu banco atualizado OTN, Metalink) Report security issues to Oracle (E claro... Informe a Oracle, se encontrar algum furo!) Fonte:

4 Enforce password management Criação de Profiles (perfis) no qual o usuário criado será associado, e desta forma obedecerá a alguns possíveis limites quanto a uso de recursos do banco de dados e/ou quanto a políticas de senha. Kernel limits Maximum concurrent sessions for a user (sessions_per_user) CPU time limit per session (cpu_per_session) CPU time limit per call (cpu_per_call) Call being parse, execute and fetch Maximum connect time (connect_time) The session will be dropped by oracle after specified time. Maximum idle time (idle_time) The session will be dropped by oracle after specified time of doing nothing. Long running processes are not idle! Maximum blocks read per session (logical_reads_per_session) Maximum blocks read per call (logical_reads_per_call) Maximum amount of SGA (private_sga) Password limits Maximum failed login attempts (failed_login_attempts) Maximum time a password is valid (password_life_time) Minimum of different passwords before password can be reused (password_reuse_max) Minimum of days before a password can be reused (password_reuse_time) Number of days an account is locked after failing to login (password_lock_time)??? (password_grace_time) Verify function for passwords (password_verify_function)

5 Enforce password management Criando o Profile create profile profile_fsm limit sessions_per_user 2 -- connect_time unlimited -- minutes idle_time minutes failed_login_attempts 3 -- password_life_time days password_reuse_time password_reuse_max unlimited -- password_verify_function null; Associando o usuário ao Profile alter user teste_fsm profile profile_fsm;

6 Manage access to SYSDBA and SYSOPER roles Cenário Perfeito: O programador está bem afim de colocar em prática tudo que ele aprendeu sobre P.O.G (Programação Orientada a Gambiarra) e entra em contato com o DBA. - Chuck Norris, tem jeito de você dar um privilégio pra mim aí? - Diz cara, o que tá rolando, que privilégio tu precisa? - Coisa besta, só pra criar e dropar umas tabelas, dar truncate s, alterar umas chaves, bobagem! - Rapaz faz assim, bota isso num script e manda pra mim que eu faço pra tu. - Não cara, mas eu vou precisar fazer isso mais de uma vez - Zero bronca, eu vou ficar aqui o dia todo faz o script aí e manda pra mim, é: chucknorris@dba.com - Não pow, desenrola aí pra mim Resposta completamente errada: Beleza, teu usuário agora é DBA, vê aí se tu consegue! Resposta correta, de um DBA decente, estilo Chuck Norris: Rapaz, não vou dar não. Marca uma reunião aí pra gente ver o que tu realmente precisa e por enquanto

7 Manage access to SYSDBA and SYSOPER roles O que podemos concluir com isso é que: NEM TODO MUNDO PODE SER DBA!! O simples comando grant dba to usuario_chumbeta; pode causar um prejuízo imenso! Portanto, sempre que um acesso mais sofisticado precise ser concedido, deve ser muito bem avaliado pelo DBA e antes de ser feito, TODAS AS POSSIBILIDADES devem ser consideradas. Lembrando que, um usuário de banco com privilégios de DBA, pode fazer absolutamente tudo, como: Criar novos usuários; Conceder privilégio de DBA pra outros usuários; Criar, Alterar e Dropar tabelas, funções, procedures, packages, etc Derrubar e subir o banco; Alterar parâmetros de banco; Dar Select em todas as views do dicionário de dados; Etc Etc Etc

8 Public privileges (Ex.: UTL_FILE) Quando um usuário é criado, automaticamente ele recebe alguns privilégios que são públicos. Todo e qualquer usuário pode utilizar. Uma das packages do banco que por default os usuários podem acessar é a UTL_FILE. A UTL_FILE é a package que tem procedures e funções para manupulações de arquivos, diretamente no S.O em que o banco encontra-se instalado. Então isso quer dizer um indivíduo conectado ao banco pode manipular arquivos do S.O?? Bem, se o DBA não tomar cuidado isso é verdadeiro. Para tal existe um parâmetro do banco que deve ser verificado, é o UTL_FILE_DIR. Este parâmetro diz para o banco, em que locais do S.O o banco poderá gravar arquivos. Se este parâmetro estiver NULO, ninguém acessa lugar nenhum. Se este parâmetro tiver um *... meus sentimentos! Qualquer usuário pode manupular arquivos onde quiser. VAMOS AOS EXEMPLOS!!!

9 Public privileges (Ex.: UTL_FILE) Visto o perigo deste descuido, temos que ter atenção no momento de alterar este parâmetro. Arquivos de sistema podem ser manipulados facilmente, e tudo que um Hacker gostaria de encontrar neste parâmetro é um simples e tranquilo *. O ideal é que, seja verificado junto com os desenvolvedores e/ou proprietário da aplicação para verificar o que REALMENTE é necessário ser liberado para manipulação de arquivos. E além disso tudo, sempre buscar utilizar estruturas de DIRECTORY que aí podem ser concedidas permissões apenas de leitura e/ou apenas de escrita em um determinado local, isto torna mais Simples o gerenciamento.

10 Enable Oracle Data Dictionary Protection Este recurso consiste em não permitir que os usuários acessem as views do dicionário de dados do Oracle. Com este tipo de acesso, um hacker que consiga chegar ao banco de dados, pode facilmente descobrir algumas informações valiosas, como podemos ver no exemplo abaixo: Com um simples select na view v$instance, o suposto invasor consegue saber: nome da instancia, nome do servidor, data que o banco subiu pela ultima vez, status do banco etc Isso pode se tornar perigoso, estas informações podem ser valiosas para um possível ataque. Vamos ver como acabar com isso.

11 Enable Oracle Data Dictionary Protection Para não permitir que pessoas não autorizadas acesse estas informações, existe um parâmetro no Oracle que faz com que possamos dizer ao banco que ninguém acessa o dicionário de dados, e a partir daí apenas os usuários EXPLICITAMENTE AUTORIZADOS poderão acessar estas views do dicionário de dados. O parametro chama-se O7_DICTIONARY_ACCESSIBILITY e por default ele vem setado como FALSE, para que o dicionário passe a ser acessado apenas por usuário autorizados, torna-se necessário que seja dada permissão de forma explicita, por exemplo: grant select on v$instance to gjunior, este comando, concede acesso de select na view v$instance do dicionário de dados. Vamos aos exemplos!!

12 Checking Network IP Adresses Este é um recurso do banco de dados que permite restringir que IP s da rede podem (ou não) acessar o banco de dados. Esta é uma solução extremamente simples que envolve apenas alteração de um arquivo de configuração do Oracle para informar que IP s podem acessar o banco e que IP s não podem acessar o banco. O arquivo é o SQLNET.ORA, ele encontra-se no caminho: {ORACLE_HOME}\network\admin. Para que este recurso seja utilizado, o arquivo deve ficar da seguinte forma:

13 Referências b_database.pdf protocol.ora+ip+access+10g+security&source=bl&ots=czmoxpjjsy&sig=psccy W9EoySHK4t8yBAfpp3AeCU&hl=pt- BR&ei=1mwRSsuqL4yclQff0riwCA&sa=X&oi=book_result&ct=result&resnum=1

14 Dúvidas