4 referências bibliográficas - Projeto Pesquisa

UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO
CURSO DE SISTEMAS DE INFORMAÇÃO — BACHARELADO
TRABALHO DE CONCLUSÃO DE CURSO I (TCC-I)
PROPOSTA PARA O TRABALHO DE CONCLUSÃO DE CURSO - Aplicado
Versão: 2
Título: SISTEMA PARA AUDITORIA DE SEGURANÇA DE BANCO DE DADOS
ORACLE
Palavras-chave:
Segurança. Auditoria. Oracle.
1 IDENTIFICAÇÃO
Nome: Alan Filipe Mattiollo
Código/matrícula: 46746
Endereço residencial:
Rua: Mariana Bronnemann
Bairro: Velha
CEP: 89036-080
Telefone fixo: (47) 3035-5189
Complemento: Ap. 02
n: 384
Cidade: Blumenau
UF: SC
Celular: (47) 9176-1261
Endereço comercial:
Empresa: Teclógica
Rua: XV de Novembro
CEP: 89010-902
n·: 759
Cidade: Blumenau
E-Mail FURB: [email protected]
Bairro: Centro
UF: SC
Telefone: 3036-7700
E-Mail alternativo: [email protected]
1.1 ORIENTADOR
Nome: Cláudio Ratke
E-Mail FURB: [email protected]
E-Mail alternativo:
1.2 SUPERVISOR/ESPECIALISTA DA APLICAÇÃO
Nome: Eduardo Ehlert
Função/Cargo: Gerente de Projetos
Telefone contato: (47) 9176-1280
2
2 DECLARAÇÕES
2.1 DECLARAÇÃO DO ALUNO
Declaro que estou ciente do Regulamento do Trabalho de Conclusão de Curso de
Sistemas de Informação e que a proposta, a qual concordo, foi revisada e está dentro dos
padrões metodológicos da disciplina. Ainda me comprometo pela obtenção de quaisquer
recursos necessários para o desenvolvimento do trabalho, caso esses recursos não sejam
disponibilizados pela Universidade Regional de Blumenau (FURB).
Assinatura:
Local/Data:
2.2 DECLARAÇÃO DO ORIENTADOR
Declaro que estou ciente do Regulamento do Trabalho de Conclusão do Curso de
Sistemas de Informação e que a proposta, a qual concordo, foi por mim revisada em
todas as páginas. Ainda me comprometo a orientar o aluno da melhor forma possível de
acordo com o plano de trabalho explícito nessa proposta.
Assinatura:
Local/Data:
2.3 DECLARAÇÃO DO SUPERVISOR/ESPECIALISTA DA APLICAÇÃO
Declaro que estou ciente do Regulamento do Trabalho de Conclusão do Curso de
Sistemas de Informação e que minha participação no referido trabalho não implica em
nenhuma relação de ordem trabalhista e de remuneração bem como, manifesto ciência
de que, por tratar-se de trabalho acadêmico, não tenho qualquer direito relacionada à sua
autoria. Outrossim, autorizo a publicação do referido trabalho como também de
informações técnicas de outros sistemas a ele relacionados.
Assinatura:
Local/Data:
3
TCC-I- APLICADO - AVALIAÇÃO DO ESPECIALISTA-1
Acadêmico(a):
ASPECTOS AVALIADOS
1.
INTRODUÇÃO
1.1. O tema de pesquisa está devidamente contextualizado / delimitado?
1.2. O problema está claramente formulado?
1.3. A justificativa/relevância apresentada está coerente com o problema apresentado?
2.
OBJETIVOS
2.1. O objetivo geral está claramente definido e é passível de ser alcançado?
2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral?
(Caso não sejam apresentados objetivos específicos, deixe esse item em branco.)
3. FUNDAMENTAÇÃO TEÓRICA
3.1. A revisão bibliográfica está de acordo com o tema abordado e é suficiente sobre o assunto?
3.2. São apresentados trabalhos correlatos, bem como é realizada a correlação dos mesmos com a proposta?
4.
DESENVOLVIMENTO / ESPECIFICAÇÃO / MODELAGEM
4.1. A descrição do sistema proposto está clara, adequadamente fundamentada e abrange solução para todos
os problemas apresentados?
4.2. Os requisitos funcionais e não funcionais do software a ser desenvolvido foram claramente descritos e
estão coerentes com os objetivos da proposta?
4.3. Os requisitos a serem implementados são suficientes para o software?
4.4. O diagrama de casos de uso apresentado está correto e coerente com os requisitos?
(Verificar a descrição dos principais casos e uso no apêndice)
5. AVALIAÇÃO GERAL (Organização e apresentação gráfica / linguagem usada)
5.1. A exposição do assunto é ordenada, isto é, as idéias estão bem encadeadas e a linguagem utilizada é
clara?
5.2. As informações retiradas de outros autores estão devidamente referenciadas e constam nas referências
bibliográficas?
5.3. As referências bibliográficas citadas contemplam adequadamente os assuntos abordados na proposta (São
utilizadas obras atualizadas e/ou as mais importantes da área)?
A Proposta de TCC deverá ser revisada, isto é, necessita de complementação, se:
 qualquer um dos itens tiver avaliação “NÃO ATENDE”;
 se 4 (quatro) ou mais itens tiverem avaliações “ATENDE PARCIALMENTE”.
PARECER: (
) APROVADA
Assinatura do(a) Avaliador(a):
( ) NECESSITA DE COMPLEMENTAÇÃO
Local/Data:
Atende
Parcialmente
Não
Atende
Atende
Avaliador(a):
TCC-I- APLICADO - AVALIAÇÃO DO ESPECIALISTA-2
Acadêmico(a):
ASPECTOS AVALIADOS
1. INTRODUÇÃO
1.1. O tema de pesquisa está devidamente contextualizado / delimitado?
1.2. O problema está claramente formulado?
1.3. A justificativa/relevância apresentada está coerente com o problema apresentado?
2. OBJETIVOS
2.1. O objetivo geral está claramente definido e é passível de ser alcançado?
2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral?
2.2.1. (Caso não sejam apresentados objetivos específicos, deixe esse item em branco.)
3. FUNDAMENTAÇÃO TEÓRICA
3.1. A revisão bibliográfica está de acordo com o tema abordado e é suficiente sobre o assunto?
3.2. São apresentados trabalhos correlatos, bem como é realizada a correlação dos mesmos com a proposta?
4. DESENVOLVIMENTO / ESPECIFICAÇÃO / MODELAGEM
4.1. A descrição do sistema proposto está clara, adequadamente fundamentada e abrange solução para todos os
problemas apresentados?
4.2. Os requisitos funcionais e não funcionais do software a ser desenvolvido foram claramente descritos e estão
coerentes com os objetivos da proposta?
4.3. Os requisitos a serem implementados são suficientes para o software?
4.4. O diagrama de casos de uso apresentado está correto e coerente com os requisitos?
4.4.1. (Verificar a descrição dos principais casos e uso no apêndice)
5. AVALIAÇÃO GERAL (Organização e apresentação gráfica / linguagem usada)
5.1. A exposição do assunto é ordenada, isto é, as idéias estão bem encadeadas e a linguagem utilizada é clara?
5.2. As informações retiradas de outros autores estão devidamente referenciadas e constam nas referências
bibliográficas?
5.3. As referências bibliográficas citadas contemplam adequadamente os assuntos abordados na proposta (São
utilizadas obras atualizadas e/ou as mais importantes da área)?
A Proposta de TCC deverá ser revisada, isto é, necessita de complementação, se:
 qualquer um dos itens tiver avaliação “NÃO ATENDE”;
 se 4 (quatro) ou mais itens tiverem avaliações “ATENDE PARCIALMENTE”.
PARECER: (
) APROVADA
Assinatura do(a) Avaliador(a):
( ) NECESSITA DE COMPLEMENTAÇÃO
Local/Data:
Atende
Parcialmente
Não
Atende
Atende
Avaliador(a):
TCC-I- APLICADO - AVALIAÇÃO METODOLÓGICA (PROFESSOR DE TCC-I)
Acadêmico(a):
1. Os elementos pré-textuais (capa e folha de rosto) estão adequadamente formatados?
2. Os elementos textuais (capítulos, seções, formatação) estão corretamente definidos e
formatados?
3. Os parágrafos (fonte, alinhamento, margem, espaçamento) estão corretos?
4. As siglas estão todas devidamente apresentadas?
5. As citações obedecem às normas da ABNT?
6. Os textos de citação (direta – citar página, quantidade de linhas, espaçamento, aspas - e
indireta) estão adequadamente apresentados?
7. As listas estão adequadamente formatadas (numeração, alinhamento, uso do “;”e início
com letra minúscula)?
8. As ilustrações e tabelas estão adequadamente formatadas (legenda, fonte, borda)?
9. As referências bibliográficas obedecem às normas da ABNT?
10. Os elementos pós-textuais (descrição casos de uso e outros) estão adequadamente
apresentados?
A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se:
 qualquer um dos itens tiver resposta “NÃO ATENDE”;
 se 4 (quatro) ou mais itens tiverem avaliação “ATENDE PARCIALMENTE”.
PARECER: (
) APROVADA
Assinatura do(a) avaliador(a):
( ) NECESSITA DE COMPLEMENTAÇÃO
Local/Data:
Não Atende
ASPECTOS AVALIADOS
Atende
Parcialmente
Prof. Sérgio Stringari
Atende
Avaliador(a):
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
ALAN FILIPE MATTIOLLO
SISTEMA PARA AUDITORIA DE SEGURANÇA DE BANCO
DE DADOS ORACLE
Proposta de Trabalho de Conclusão de Curso
submetida à Universidade Regional de
Blumenau para a obtenção dos créditos na
disciplina Trabalho de Conclusão de Curso I
do curso de Sistemas de Informação —
Bacharelado.
Prof. Cláudio Ratke - Orientador
BLUMENAU
2012 / I
2
1 INTRODUÇÃO
Organizações têm objetivos de negócio. Para realizar esses objetivos de negócio,
muitas decisões precisam ser tomadas diariamente. Tipicamente, uma grande quantidade de
informações é necessária para que sejam tomadas as decisões corretas.
Entretanto, estas informações não estão sempre disponíveis em um formato adequado.
As organizações precisam de sistemas formais que permitam que sejam produzidas as
informações necessárias, no formato certo, no tempo certo. Estes sistemas são chamados de
sistemas de informação. Um sistema de informação é um modelo simplificado do mundo real
de uma organização (Hann, 2005).
Segundo Elmasri e Navathe (2003), um banco de dados é uma coleção de dados
relacionados, e é justo dizer que bancos de dados desempenham um papel importante em
quase todas as áreas aonde computadores são utilizados, incluindo negócios, comércio
eletrônico, engenharia, medicina, direito, educação, entre outros.
Segundo Date (2004), um banco de dados é basicamente um sistema computadorizado
que mantém registros. O banco de dados pode ser considerado uma espécie de armário
eletrônico de arquivamento, isto é, ele é um repositório ou contêiner para uma coleção
computadorizada de arquivos de dados. Usuários do sistema podem realizar uma variedade de
operações envolvendo estes arquivos de dados.
Existe uma grande quantidade de sistemas de banco de dados, as soluções mais
conhecidas e que requerem licença são Oracle Database, SQL Server e DB2. Há também
soluções gratuitas, como o MySQL e o PostgreSQL.
O banco de dados Oracle é líder no mercado mundial, em um estudo do Gartner
DataGuest de 2011, baseado no revenda total dos softwares, o banco de dados Oracle possui
48,8% do mercado, detendo maior receita do que seus sete concorrentes mais próximos
combinados (Oracle University, 2009).
O Oracle é o banco de dados número um em uso hoje. O fato de ser escolhido por
organizações militares e agências ao redor do mundo é um legado do projeto que deu origem
ao banco de dados. O Oracle tem uma vasta quantidade de funções, produtos e ferramentas
relacionadas à segurança. Infelizmente, o fato de estes recursos existirem não significa que
são utilizados corretamente ou mesmo que são utilizados. Em fato, a maioria dos usuários está
familiarizada com menos de 20% dos mecanismos de segurança do Oracle (Natan, 2009).
Proteger a privacidade dos dados está cada vez mais difícil. Em um relatório do
Identity Theft Resource Center, 414 violações de segurança foram descobertas nos Estados
3
Unidos em 2011. Isto representa mais de 22 milhões de registros com informações sensíveis
de identidade ou de cartão de crédito comprometidas. O IT Policy Compliance Group
concluiu que 90% das companhias não atendem as regras regulatórias dos Estados Unidos.
Uma violação de dados financeiros pode custar 35 milhões de dólares para ser remediado, um
custo de 239 dólares por registro (Oracle University, 2009).
Com o intuito de tentar melhorar a segurança, companhias criam inúmeras regras e
controles. Essas regras devem ser distribuídas por toda a área de infraestrutura de TI, e
normalmente o local aonde os dados residem não recebe a devida atenção. O principal
responsável pela segurança de um banco de dados é o administrador de banco de dados
(DBA), porém, todos os usuários que possuem acesso ao banco de dados precisam estar
conscientes de seus privilégios e seguir cartilhas de segurança, como não compartilhar suas
senhas.
Proteger os dados é algo complexo porque o banco de dados Oracle em si é complexo
e extremamente configurável, também porque as aplicações, a necessidade de dados e seu uso
são diferentes em cada organização (Natan, 2009).
O presente trabalho propõe a verificação do nível de segurança do banco de dados
Oracle e deve informar as alterações necessárias para se adequar ao modelo padrão ou
customizado de segurança.
1.1
PROBLEMA
A instalação do banco de dados acompanha uma configuração padrão que funciona,
mas que não atende a todas as necessidades de segurança. A grande quantidade de
ferramentas e recursos que o Oracle disponibiliza não é simples de serem configurados, assim,
muitas vezes os próprios administradores de bancos de dados acabam mantendo a
configuração padrão, fazendo com que o ambiente se torne inseguro.
Essa grande quantidade de ferramentas e recursos leva a possibilidade de serem
escolhidas as ferramentas erradas para desenvolver soluções de segurança em um determinado
ambiente, o que pode significar tempo de trabalho desperdiçado e esforço contínuo para
manter a solução ao longo do tempo.
1.2
JUSTIFICATIVA
4
Informações financeiras, de clientes, de empregados, de cartão de crédito, usualmente
todas elas estão armazenadas no banco de dados. Como quase todos os ativos de informação
considerados valiosos residem em um banco de dados, é preciso assegurar que estejam bem
protegidos.
No final de 2011, um cliente internacional da Teclógica submeteu a empresa local a
um processo de auditoria. Os auditores desta empresa possuíam uma extensa lista de
configurações que deveriam ser seguidas nos ambientes da empresa nacional. Como
fornecedor, coube a Teclógica verificar se as configurações presentes nas bases de dados
afetadas pela auditoria estavam em concordância.
A necessidade de verificar cada configuração nos diversos recursos de segurança que o
banco de dados Oracle oferece é bastante trabalhoso. As configurações que não estivessem de
acordo deveriam ser ajustadas. Cada recurso que necessitava de ajuste demandava certa
quantidade de pesquisa e verificações para viabilizar ou não sua alteração no ambiente,
levando sempre em consideração todos os recursos que os sistemas do cliente utilizavam e os
possíveis impactos se houvessem alterações.
1.3
OBJETIVOS
O objetivo geral do trabalho proposto é o desenvolvimento de um sistema que
verifique o nível de segurança de um banco de dados Oracle.
Os objetivos específicos do trabalho proposto são:
a) aprofundar-se no estudo de segurança da informação em banco de dados Oracle;
b) pesquisar como funciona o processo de auditoria de segurança e porque ele é
necessário;
c) desenvolver módulos que permitam o cadastro de valores para os diversos
parâmetros e recursos de segurança para posterior verificação;
d) desenvolver um relatório que informe o nível de segurança da base de dados e as
alterações necessárias para se adequar ao modelo de segurança escolhido.
5
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo aborda assuntos a serem apresentados nas seções a seguir, tais como
arquitetura do Oracle, segurança de banco de dados Oracle, autenticação de banco de dados,
autorização, auditoria, criptografia, common criteria, sistema atual além de trabalhos
correlatos.
2.1
CENÁRIO ATUAL
O sistema proposto neste trabalho será implantando na área de infraestrutura da
empresa Teclógica. A Teclógica é uma empresa que desenvolve softwares e oferece serviços
de consultoria e suporte a sistemas e a infraestrutura.
A área de infraestrutura está subdividida em outras duas áreas, a de projetos e a de
suporte. Na área de projetos são desenvolvidas e implantadas novas soluções. A área de
suporte é responsável por manter os diversos itens de configuração da Teclógica e de seus
clientes, buscando atingir as metas descritas nos contratos, como nível de serviço estabelecido
em um contrato de acordo de nível de serviço (SLA) e o tempo de disponibilidade dos itens de
configuração.
Na área de suporte de infraestrutura há uma equipe que trabalha com banco de dados e
é responsável por monitora-los, mantê-los atualizados e disponíveis. Essa equipe deve atender
a todas as demandas que estejam relacionadas a banco de dados, tais como: corrigir erros,
aplicar melhorias, analisar o desempenho e gerar relatórios de tudo que ocorre nos ambientes.
A necessidade de verificar as configurações relacionadas à segurança é uma demanda
anual de um cliente da Teclógica, que passa por uma auditoria por parte de sua detentora, uma
empresa internacional. Todas as verificações que precisam ser feitas para certificar-se que a
configuração de um banco de dados atende a todos os requisitos do modelo de segurança são
realizadas manualmente. É preciso avaliar a configuração de determinado parâmetro no
ambiente e compará-lo com a configuração presente no documento modelo da empresa. A
grande quantidade de configurações e produtos que precisam ser checados torna essa tarefa
bastante demorada. O processo também é repetitivo, visto que há sempre mais de um banco
de dados a ser verificado e quando o ambiente está configurado em Real Application Clusters
(RAC), é preciso verificar cada nó, também tornando o trabalho suscetível a erros.
6
2.2
ARQUITETURA DO ORACLE
Segundo Bryla e Loney (2009), enquanto o banco de dados Oracle é armazenado em
um disco do servidor, uma instância Oracle existe na memória do servidor. Uma instância
Oracle é composta de um grande bloco de memória alocado em uma área denominada System
Global Area (SGA), junto com vários processos em segundo plano que interagem com a SGA
e os arquivos de banco de dados no disco.
Segundo Watson (2010), os processos em segundo plano da instância são os processos
iniciados quando a instância é iniciada e executados até que ela termine. Uma sessão de
usuário é um processo de usuário que é conectado a um processo de servidor. O processo de
servidor é iniciado quando a sessão é criada e destruída quando a sessão termina.
De acordo com Watson (2010), existem três tipos de arquivo que compõem um banco
de dados Oracle, mais alguns que existem externamente ao banco de dados e são, estritamente
falando, opcionais. Os arquivos obrigatórios são o arquivo de controle (controlfile), os
arquivos de redo log online e os arquivos de dados. Os arquivos externos que normalmente
estarão presentes são o arquivo de parâmetros de inicialização, o arquivo de senha e os
arquivos de redo log arquivados, além dos arquivos de log e rastreamento.
Em um ambiente Oracle RAC, um mesmo banco de dados será utilizado por mais de
uma instância, cada instância fica em um servidor diferente e há uma interconexão de alta
velocidade entre eles. O banco de dados residirá em um subsistema de disco especializado.
Os arquivos de dados em um banco de dados Oracle são agrupados em uma ou mais
tablespaces. Os objetos em uma tablespace são armazenados em segmentos, um segmento é
um grupo de extensões que abrange um objeto de banco de dados tratado pelo Oracle como
uma unidade, por exemplo, uma tabela ou índice. Uma extensão consiste de um ou mais
blocos no banco de dados. Quando um objeto é expandido, o espaço adicionado ao objeto é
alocado como uma extensão.
Todas as estruturas lógicas em um banco de dados Oracle precisam ser armazenadas
em algum lugar no banco de dados. O Oracle mantém um dicionário de dados que grava
metadados sobre cada objeto – o dono do objeto, sua definição, privilégios relacionados, entre
outros. Para objetos que requerem espaço para armazenamento físico, o Oracle irá alocar
espaço dentro de um tablespace (Loney, 2009).
Segundo Watson (2010), o dicionário de dados é um conjunto de metadados: dados
sobre dados. Ele descreve o banco de dados, tanto física quanto logicamente, e seu conteúdo.
7
As definições de usuários, informações de segurança, restrições de integridade e informações
de monitoramento de desempenho fazem parte do dicionário de dados.
O banco de dados Oracle fornece várias ferramentas e mecanismos para proteger os
dados corporativos, essas ferramentas dividem-se em três categorias abrangentes:
autenticação, autorização e auditoria.
2.3
SEGURANÇA DE BANCO DADOS ORACLE
Na área financeira, médica, de telecomunicação, infraestrutural, governamental, e até
militar, os bancos de dados e os dados dentro dele são o negócio. Nos últimos anos, bancos de
dados tem se tornado frequentes alvos de ataques cibernéticos. No inicio, os ataques tinham
por objetivo causar perdas no negócio e notoriedade na comunidade hacker. Isto mudou
drasticamente com foco em extrair informações sensíveis e valiosas na tentativa de ganho
monetário por parte do agressor (Shaul; Ingram, 2007).
Segurança de dados tem se tornado a área de maior foco para regulamentações, tanto
governamental quando industrial. Regulamentações com sérias consequências por não
cumprimento. A maior parte dos dados sensíveis passa mais de 95% do seu tempo em um
banco de dados, mais geralmente em um banco de dados Oracle (Shaul; Ingram, 2007).
A segurança é uma questão de preocupação vital para todas as instalações. As
empresas devem ter um manual de segurança documentando todas as regras e procedimentos.
Em segurança, não há certo ou errado; há somente conformidade e não conformidade com os
procedimentos acordados. O conjunto de produtos Oracle fornece muitos recursos para impor
a segurança até e além dos padrões mais altos especificados por qualquer legislação (Watson,
2010).
Segundo Watson (2010), o princípio mais seguro a seguir quando determinar o acesso
aos sistemas de computador é aquele do menor privilégio: ninguém deve ter acesso a qualquer
coisa que esteja além do mínimo absolutamente necessário para executar seu trabalho, e
qualquer coisa não especificamente permitida é proibida. O banco de dados Oracle está de
acordo com essas regras, com isso, por padrão, ninguém pode fazer nada, com exceção dos
usuários SYS e SYSTEM. Nenhum outro usuário pode se conectar, nem mesmo aqueles
criados pelas rotinas de criação de banco de dados padrão.
O fortalecimento do sistema é o processo pelo qual se configura de forma segura um
sistema para protegê-lo de acessos não autorizados. O fortalecimento do sistema é necessário
em qualquer sistema que tenha uma grande quantidade de opções de configuração e é viável
8
em qualquer sistema que tenha medidas de segurança para fazer com que este seja utilizado
em ambientes orientados por segurança. O banco de dados Oracle se encaixa nas duas
categorias (Natan, 2009).
O propósito de fortalecer a segurança de um banco de dados é eliminar a maior
quantidade de riscos de segurança possíveis. Isto pode ser feito removendo todos os
elementos não essenciais do banco de dados e selecionando opções que limitem os acessos e
diminuam os riscos. Quanto maior é o sistema e as capacidades que ele utiliza, mais riscos de
segurança estarão presentes. Entretanto, quanto maior a base de dados e a quantidade de
funcionalidades que esta utiliza, mais importante se torna seu fortalecimento (Natan, 2009).
Com a evolução do banco de dados Oracle mais e mais opções podem ser utilizadas
para garantir a segurança dos dados. O aumento do nível de segurança em um banco Oracle
passa por uma grande quantidade de atividades e envolvem muitas opções de configuração, a
mais importante é: se tem algo que não seja utilizado, remova (Natan, 2009).
Segundo Natan (2009), quanto menor for a quantidade de opções e recursos utilizados
por um sistema, mais seguro ele será, de fato se algo não é utilizado pelo sistema não significa
que não possa ser utilizado por algum invasor. Exemplos de configurações que podem ser
alteradas ou removidas se não utilizadas:
a) remover ou bloquear contas pré-definidas e alterar suas senhas.
b) remover grupos de privilégios.
c) remover componentes de software.
d) remover opções não utilizadas, como EXPROC se o sistema não utilizar
procedimentos externos.
e) remover privilégios públicos.
O banco de dados Oracle possui uma grande quantidade de parâmetros. A maior parte
das configurações de um banco de dados Oracle é realizada através de parâmetros de
instância, esses parâmetros são armazenados em um arquivo de texto ou em um arquivo
binário, sendo este último modo o recomendado pela Oracle. Alguns parâmetros controlam
configurações relacionadas a opções de segurança. Um componente muito importante na
arquitetura do banco de dados Oracle é o listener, responsável por ouvir em uma porta e
receber as solicitações de autenticação dos usuários. Por se tratar de um processo que se
comunica diretamente com a rede, o arquivo de configurações do listener precisa ser
configurado corretamente.
9
Em termos Oracle, segurança de rede significa proteção de confidencialidade e
integridade. A parte de confidencialidade assegura que ninguém pode ler os dados enquanto
estes passem pela rede, e a parte de integridade assegura que ninguém pode alterar os dados
enquanto estes se movem (Shaul; Ingram, 2007).
As ferramentas e mecanismos de segurança fornecidos pelo banco de dados Oracle
dividem-se em três categorias abrangentes: autenticação, autorização e auditoria.
2.4
AUTENTICAÇÃO DE BANCO DE DADOS
Autenticação é o processo no qual o Oracle tenta identificar sua identidade quando
você faz logon no banco de dados e decide se o permitirá. Autenticação é o primeiro passo em
qualquer acesso para o banco de dados – é o portão da frente do seu castelo. Se não existir
uma forma de identificar uma parte da conexão ou houver uma forma de atacar o esquema de
autenticação e fingir uma identidade, nada mais importa (Natan, 2009).
O Oracle disponibiliza vários métodos para autenticar usuários. Todas as opções
disponíveis permitem que se escolha a método mais apropriado para um determinado
ambiente.
Em um ambiente onde a rede é protegida do ambiente externo com firewalls e o
tráfego da rede entre usuário e o servidor de banco de dados usa algum método de
criptografia, a autenticação pelo banco de dados é o método mais fácil de autenticar o seu
usuário. Muitas operações especiais do banco de dados requerem uma forma diferente e mais
segura de autenticação, seja a feita pelo sistema operacional ou usando arquivo de senhas
(Bryla; Loney, 2009).
A autenticação da rede conta com serviços de terceiros, como Distributed Computing
Environment (DCE), Kerberos, Public Key Infrastructure (PKI) e Remote Authentication
Dial-in User Service (RADIUS). A autenticação de três camadas autentica o usuário enquanto
mantém a identidade do cliente no servidor. Além disso, a camada intermediária fornece
serviços de pool de conexão e implementa a lógica de negócio para o cliente.
2.5
AUTORIZAÇÃO
De acordo com Bryla e Loney (2009), a autorização fornece acesso a vários objetos
nos banco de dados, uma vez que tenha sido autenticado nele. Alguns usuários podem ser
autorizados para executar um relatório em relação à tabela de vendas diárias, alguns podem
10
ser desenvolvedores e, portanto, precisam criar tabelas e relatórios. Alguns usuários podem
nunca se conectar, mas seus esquemas podem possuir uma quantidade de tabelas para uma
aplicação especifica, como folha de pagamento ou contas a receber.
A autorização vai além do simples acesso a objetos de bancos de dados, acesso a uma
tabela ou relatório. A autorização também inclui os direitos de uso de recursos do sistema,
como privilégios para executar determinadas ações, tempo de uso de processamento, tempo
máximo que a sessão poderá ficar ociosa, entre outros.
Após o usuário estar autenticado no banco de dados, a próxima etapa é determinar que
tipos de objetos, privilégios e recursos o usuário tem permissão para acessar ou usar. Os perfis
podem controlar como as senhas são gerenciadas e colocar limites em vários tipos de recursos
do sistema.
No Oracle, existem dois tipos de privilégios, os de sistema e os de objeto. Esses
privilégios podem ser atribuídos diretamente a uma conta de usuário, ou por meio de
atribuições (roles).
Um privilégio de sistema é um direito para executar uma ação em qualquer objeto no
banco e dados, assim como outros privilégios que não envolvem nenhum objeto, mas sim
procedimentos como executar jobs em lote, alterar os parâmetros do sistema, criar atribuições
e até mesmo conectar-se ao banco de dados (Bryla; Loney, 2009).
Ao contrário de um privilégio de sistema, um privilégio de objeto é um direito para
executar um tipo de ação em um objeto especifico, como uma tabela ou uma sequência que
não está no esquema do usuário (Bryla; Loney, 2009).
Uma atribuição (role) é um grupo nomeado de privilégios, seja de sistema ou de
objeto, ou uma combinação dos dois, que ajuda a facilitar a sua administração. Os privilégios
são concedidos a uma atribuição, que por sua vez é concedida a uma conta de usuário,
diminuindo drasticamente o overhead administrativo envolvido na manutenção de privilégios
para usuários. A utilização de atribuições aumenta a segurança, visto que é possível
especificar uma senha para que o usuário que possua determinada atribuição possa ativa-la.
2.6
AUDITORIA
Auditoria é um exame metódico ou revisão de um ambiente com o objetivo de garantir
complacência com regulamentos e para detectar anormalidades e acessos não autorizados.
Segurar ambientes de tecnologia da informação (TI) depende fortemente do processo de
auditoria (Stewart; Tittel; Chapple, 2005).
11
Independentemente da qualidade das suas diretivas de segurança, existem ocasiões em
que uma diretiva não é suficiente. Será preciso aceitar que os usuários possuem privilégios
que podem ser perigosos. Tudo que pode ser feito é monitorar o uso destes privilégios e
controlar oque os usuários estão fazendo com ele.
A auditoria precisa ser utilizada de forma criteriosa. Habilitar auditoria em muitos
componentes do banco de dados, de forma contínua pode causar um número excessivo de
registros e um gargalo no sistema. A auditoria tem por objetivo ajudar a proteger os bens da
empresa monitorando como, por quem e quando os recursos estão sendo utilizados. O DBA
deve utilizar a auditoria com frequência para monitorar a saúde do banco de dados.
Segundo Bryla (2009), a auditoria em um banco de dados Oracle abrange vários níveis
diferentes de monitoramento. Em um nível alto, ela pode registrar tanto as tentativas bemsucedidas quanto as malsucedidas de login, acesso a objetos, ou execução de determinadas
ações.
Existem três técnicas de auditoria em banco de dados Oracle:

A auditoria de banco de dados pode rastrear o uso de certos privilégios, a
execução de certos comandos, o acesso a certas tabelas ou tentativas de logon.

A auditoria baseada em valor utiliza triggers de banco de dados. Quando uma
linha é inserida, atualizada ou excluída, um bloco de código será executado
para que possa registrar os detalhes completos do evento.

O Oracle Fine Grained Auditing (FGA) permite controlar o acesso a tabelas de
acordo com quais linhas ou colunas foram acessadas. É muito mais precisa que
a auditoria de banco de dados e a auditoria baseada e valor.
2.7
CRIPTOGRAFIA
A criptografia pode melhorar a segurança tanto dentro quanto fora do banco de dados.
A Oracle fornece um recurso chamado Transparent Data Encryption (TDE) que provê o
beneficio de criptografia sem overhead adicional no armazenamento de dados em disco.
Segundo Bryla (2009), um usuário pode ter uma necessidade legítima de acessar a
maioria das colunas de uma tabela, mas se uma das colunas estiver criptografada e ele não
conhecer a chave de criptografia, as informações não serão utilizáveis. A mesma preocupação
é verdadeira para informações que precisam ser transmitidas através de uma rede. As técnicas
de autenticação, autorização e auditoria garantem acesso legítimo aos dados a partir de um
12
usuário de banco de dados, mas não impedem o acesso de um usuário do sistema operacional
que tenha acesso aos arquivos desse sistema que compõem o próprio banco de dados.
Pode-se utilizar o TDE para garantir ainda mais a integridade dos dados. O TDE
criptografa os dados nos arquivos de dados, undo logs, redo logs, e no buffer cache da system
global area (SGA) na memória. Usar o TDE provê um nível avançado de segurança para
dados sensíveis sem que seja preciso alterar as aplicações que usam esses dados. Usuários e
desenvolvedores continuaram acessando e armazenando as linhas do mesmo modo que
sempre o fizeram; a única alteração será na forma com que as linhas serão armazenadas
fisicamente no nível do sistema operacional (Loney, 2009).
Quando finalizada a instalação padrão de um banco de dados Oracle e Oracle client,
suas comunicações serão transmitidas em texto claro na infraestrutura de rede. Se dados
sensíveis forem transmitidos em texto claro há um potencial ponto de vulnerabilidade bem
como de confidencialidade de dados. Para criptografar o tráfego de rede entre o cliente Oracle
e o servidor Oracle pode-se utilizar o recurso de criptografia de dados que vem no pacote
Oracle Advanced Security Options (Natan, 2009).
2.8
COMMON CRITERIA
O modelo de avaliação de segurança a partir de boas práticas do mercado (auditoria
externa) assume que existem “melhores práticas” disponíveis sobre como proteger um
determinado tipo de ambiente ou produto. Este modelo mede a segurança ao comparar o nível
de controle gerencial sobre o ambiente do sistema. O resultado final é uma lista de
fragilidades de segurança, ou defeitos, que devem ser corrigidos para que os sistemas operem
em um nível aceitável de riscos de segurança (Batista, 2007).
O marco inicial da avaliação de segurança ocorreu quando o governo norte-americano
publicou a norma intitulada Trusted Computing System Evaluation Criteria (TCSEC),
também conhecido como Orange Book, para avaliação de segurança (criptografia, firewalls,
etc.). Em 1991 uma comissão europeia publicou uma norma de certificação de segurança
intitulada Information Technology Security Evaluation Criteria (ITSEC) baseada no TCSEC,
posteriormente tornando-se o padrão europeu para avaliação de produtos e sistemas (Batista,
2007).
Segundo Albuquerque e Ribeiro (2002), outros padrões surgiram na década de 1990,
como o Canadian Trusted Computer Product Evaluation (CTCPEC) que é a junção das
normas TCSEC e ITSEC, o Minimum Security Functionality Requirements for Muiti-user
13
Operating Systems (MSFR), desenvolvido pelo National Institute of Standards and
Technology (NIST), e o Federal Criteria (FC) desenvolvida pelos EUA.
Com tantas normas de certificação, as empresas multinacionais acabaram tendo
problemas ao ter que certificar seus produtos perante cada órgão de governo, gerando
enormes custos de certificação. Para resolver este problema os países envolvidos
encaminharam para a International Organization for Standardization (ISO) uma proposta de
consolidação de todos os critérios para avaliação de segurança em um único critério. A ISO
acatou a ideia e posteriormente apresentou a normal ISO 15.408:1999, nomeando-a Common
Criteria (Batista, 2007).
2.9
TRABALHOS CORRELATOS
O sistema proposto permitirá a customização de um modelo de segurança,
funcionalidade não presente no software correlato Oracle Configuration Management, que
possui um pacote que pode ser adquirido separadamente, chamado Enterprise Monitoring for
Security & Compliance. Estão embutidas neste software as práticas de segurança padrões da
Oracle. Também possui funções avançadas, como:
a) ações corretivas automatizadas e criação de chamados para rápida solução.
b) comparação de configurações baseado em padrões reconhecidos.
c) mantém histórico das alterações.
Foram consultados os trabalhos de Bruno Castellani Gucowski e Dayana Fernanda
Trapp para conclusão do curso de Ciências da Computação na Universidade Regional de
Blumenau.
O trabalho de Gucowski (2011) foi desenvolver um middleware para garantir a
segurança da informação e abstração dos aspectos e conceitos dos requisitos da ISSO/IEC
15.408 para os desenvolvedores de software.
O trabalho de Trapp (2010) foi desenvolver um software para analisar um sistema e
verificar se o mesmo implementa requisitos de segurança estabelecidos pela norma ISO/IEC
15.408.
14
3
DESENVOLVIMENTO
Neste capítulo estão descritos as particularidades técnicas do sistema proposto tais
como a descrição do mesmo e a apresentação dos requisitos funcionais e não funcionais,
diagrama de casos de uso e suas descrições e principais softwares a serem utilizados.
3.1
SISTEMA PROPOSTO
Propõem-se o desenvolvimento de uma aplicação web para auditoria de segurança em
banco de dados Oracle. O sistema possuirá telas para configuração de um modelo, que será
utilizado na verificação do banco de dados alvo. O sistema deverá trazer um modelo padrão
baseado nas configurações e nas melhores praticas recomendadas pela Oracle.
Após a customização do modelo de segurança, a principal função do sistema será a
verificação do nível de segurança, que irá comparar o valor dos parâmetros no banco de dados
alvo, bem como o valor dos parâmetros nos arquivos de configuração no sistema operacional
com os valores presentes no modelo de segurança escolhido. Alguns parâmetros são mais
críticos e pesarão mais na avaliação. A quantidade de parâmetros verificados e o resultado de
cada um de acordo com sua criticidade resultarão no nível de segurança do banco de dados
como um todo.
Um relatório deverá apontar todas as configurações que estão em concordância em
relação ao modelo e todas aquelas que requerem atenção. Para as configurações que não
estiverem de acordo, será informada a configuração correta e as possíveis causas se forem
alteradas. Se aplicável, o relatório deverá alertar possíveis necessidades de configuração e a
relação entre elas.
Após a análise, um administrador de banco de dados usará o relatório para informar ao
cliente todos os pontos que precisam ser alterados. Para implantar o sistema, será preciso
instalar o Oracle Applications Express (APEX) no banco de dados alvo. Esta instalação fará
parte da instalação do próprio sistema. O Oracle APEX é um ambiente de rápido
desenvolvimento de aplicações web baseado no banco de dados Oracle.
A implantação do novo sistema irá acelerar a verificação das configurações de
segurança de um banco de dados. O usuário do sistema não precisará verificar as
configurações, bastará informar qual modelo de segurança deve ser utilizado.
Para construção deste sistema, serão utilizadas as seguintes ferramentas:
15
3.2

Oracle Database 11g;

Oracle Aplication Express (APEX).
ESPECIFICAÇÃO DE REQUISITOS
O Quadro 1 apresenta os requisitos funcionais previstos para o sistema e sua
rastreabilidade, ou seja, vinculação com os casos de uso associados.
Requisitos Funcionais
RF01: O sistema deverá permitir o cadastro de configurações para um
Caso de Uso
UC01
modelo de segurança customizado.
RF02: O sistema deverá possibilitar o uso de um modelo de segurança
UC02
baseado nas recomendações da Oracle
RF03: O sistema deverá permitir o cadastro de exceções de configurações.
UC03
RF04: O sistema deverá permitir o usuário efetuar login no sistema.
UC04
RF05: O sistema deverá permitir o usuário alterar a senha de login.
UC05
RF06: O sistema deverá possibilitar a verificação das configurações de
UC06
segurança.
RF07: O sistema deverá emitir um relatório com o resultado da análise de
UC07
segurança.
Quadro 1: Requisitos funcionais
O Quadro 2 lista os requisitos não funcionais previstos para o sistema.
Requisitos Não Funcionais
RNF01: O sistema deverá utilizar banco de dados Oracle 11g.
RNF02: O sistema será desenvolvido em PL/SQL.
RNF03: As telas e relatórios serão desenvolvidos com o Oracle APEX.
RNF04: O sistema poderá ser acessado através de qualquer navegador.
RNF05: Os status das configurações são:
 ATENDE: Configuração está de acordo com o modelo de segurança.
 ALERTA: Configuração não está de acordo e não é tão critica ou está parcialmente
de acordo.
 CRITICO: Configuração não está de acordo e é importante.
Quadro 2: Requisitos não funcionais
16
3.3
MODELAGEM
Esta seção apresenta o diagrama que será necessário para o entendimento do sistema
proposto.
3.3.1 DIAGRAMA DE CASOS DE USO
Esta seção apresenta o diagrama de casos de uso preliminar do sistema proposto, sendo
que os detalhamentos dos casos de uso estão disponíveis no Apêndice A.
uc Use Case Model
UC04 - Efetuar login
UC02 - Selecionar
modelo de segurança
UC05 - Alterar senha
«precedes»
UC03 - Cadastrar
exceções
UC06 - Executar
v erificação
DBA
«precedes»
UC01 - Cadastrar
configurações
UC07 - Emitir relatório
com resultado da
análise
Figura 1: Diagrama de casos de uso
17
4
REFERÊNCIAS BIBLIOGRÁFICAS
ALBUQUERQUE, Ricardo; RIBEIRO, Bruno. Segurança no desenvolvimento de software.
Rio de Janeiro: Campus, 2002.
BATISTA, Carlos F. A. Métricas de segurança de software. 2007. 103 f. Dissertação
(Mestrado em Informática) - Programa de Pós-Graduação em Informática, Pontifícia
Universidade Católica do Rio de Janeiro, Rio de Janeiro. Disponível em: <
http://www.dominiopublico.gov.br/download/texto/cp040026.pdf >. Acesso em: 26 mai.
2012.
BRYLA, Bob. OCP oracle database 11g administração II. Tradução Teresa Cristina Felix
de Souza. Porto Alegre: Bookman, 2010.
BRYLA, Bob; LONEY, Kevin. Oracle database 11g manual do dba. Tradução Altair
Caldas Dias de Moraes. Porto Alegre: Bookman, 2009.
DATE, C. J. An introduction to database systems, 8th edition. Boston: Pearson Education,
2004.
ELMASRI, Ramez; NAVATHE, Shamkant B. Fundamentals of database systems fourth
edition. Boston: Pearson Education, 2003.
HAN, Lex De. Mastering oracle sql and sql*plus. Berkeley, CA: Apress, 2005.
LONEY, Kevin. Oracle database 11g the complete reference. New York: McGraw-Hill,
2009.
NATAN, Ron Ben. HOWTO secure and audit oracle 10g and 11g. Boca Raton: CRC
Press, 2009.
SHAUL, Josh; INGRAM, Aaron. Practical oracle security. Rockland: Syngress, 2007.
STEWART, James Michael; TITTEL Ed; CHAPPLE Mike. CISSP: certified information
systems security professional study guide 3rd edition. Alameda, CA: Sybex, 2005.
ORACLE UNIVERSITY. Addresing data privacy, regulatory compliance, and insider
threats. Oracle University, 2009.
WATSON, John. OCA oracle database 11g administração I. Tradução Altair Caldas Dias
de Moraes. Porto Alegre: Bookman, 2010.
18
APÊNDICE A – Detalhamento dos casos de uso
Esta seção da proposta apresenta a descrição dos casos de uso conforme previstos no
diagrama apresentado na seção 3.3.1.
UC01 Cadastrar configurações
Permite ao DBA cadastrar e alterar o valor de parâmetros.
UC02 Selecionar modelo de Segurança
Permite ao DBA selecionar o modelo de segurança que será utilizado para posterior
verificação do banco de dados alvo.
UC03 Cadastrar exceções
Permite ao DBA cadastrar algumas configurações que devem ser desconsideradas no
momento da verificação do banco de dados alvo.
UC04 Efetuar login
Permite ao DBA realizar login no aplicativo.
UC05 Alterar senha
Permite ao DBA alterar a senha de login do aplicativo.
UC06 Executar verificação
Permite ao DBA executar a verificação de segurança no banco de dados alvo. A execução irá
disparar um job que irá comparar as configurações do modelo de segurança com aquelas
presentes no banco de dados alvo.
Constraints
Pré-condição . O DBA deve selecionar um modelo de segurança. Caso não tenha sido
selecionado será utilizado o modelo padrão recomendado pela Oracle.
Pós-condição . O relatório com o resultado da verificação poderá ser visualizado.
UC07 Emitir relatório com resultado da análise
Permite ao DBA visualizar o relatório com o resultado da verificação de segurança.
Constraints
Pré-condição . O DBA deve ter executado a verificação, gerando os resultados para o
relatório.
Pós-condição . O resultado de segurança no banco de dados alvo poderá ser visualizado.
19
Verificação não realizada {Exceção}
Se a verificação de segurança não foi executada será apresentada a mensagem “Verificação de
segurança não foi executada”.