UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA
FACULDADE DE CIÊNCIAS APLICADAS DE MINAS
Autorizada pela Portaria no 577/2000 – MEC, de 03/05/2000
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
S
UM ESTUDO DAS VULNERABILIDADES EM
IN
A
BANCO DE DADOS
U
N
IM
PAULO CESAR CAMARGOS FERREIRA
Uberlândia
2009
S
PAULO CESAR CAMARGOS FERREIRA
A
UM ESTUDO DAS VULNERABILIDADES EM
U
N
IM
IN
BANCOS DE DADOS
Trabalho de Final de curso submetido à
UNIMINAS como parte dos requisitos para
a obtenção do grau de Bacharel em
Sistemas de Informação.
.
Orientador: Prof. Francisco Jose Muller
Uberlândia
2009
PAULO CESAR CAMARGOS FERREIRA
UM ESTUDO DAS VULNERABILIDADES EM
S
BANCOS DE DADOS
IN
A
Trabalho de Final de curso submetido à
UNIMINAS como parte dos requisitos para
a obtenção do grau de Bacharel em
Sistemas de Informação.
IM
Orientador: Prof. Francisco José Muller
Banca Examinadora:
U
N
Uberlândia, dia 08 de Julho de 2009.
Prof. Francisco José Muller (Orientador)
Profa. Dra. Kátia Lopes Silva
Prof. Esp. Walteno Martins Parreira Júnior
Uberlândia
2009
S
A
IN
IM
U
N
À minha mãe, Venina, por todo amor e imenso
apoio na realização desse sonho, sofrendo
junto comigo a cada etapa concluída.
AGRADECIMENTOS
À Deus, por me ajudar durante toda essa jornada acadêmica e por conceder tantas
maravilhas em minha vida, das quais uma delas se concretiza neste momento.
À meus pais, Alcides e Venina, pelo apoio e incentivo durante toda minha vida e,
principalmente, por estar ao meu lado nos momentos mais difíceis, orientando-me e
torcendo para que mais uma etapa de minha vida acadêmica fosse concretizada.
Também a minha irmã, Lucilene, por acreditar e apoiar-me nas inúmeras situações
difíceis que enfrentei.
S
À meus familiares, que souberam compreender minhas ausências em tantos
momentos, mas sempre festejaram comigo as conquistas dessa fase.
realização desse trabalho.
A
À minha namorada, Alessandra, pela compreensão e apoio nos momentos finais de
IN
Aos professores da Uniminas pelo conhecimento que me foi transmitido e que
possibilitou atingir minhas metas e conquistas profissionais. Em especial, ao
professor Francisco Muller, que me orientou e apontou os caminhos no
U
N
IM
desenvolvimento desse trabalho.
RESUMO
Com o avanço cada vez maior da tecnologia moderna, o volume de informação
gerado por sistemas informatizados aumenta consideravelmente todos os dias.
Muitas dessas informações são armazenadas dentro de bancos de dados de
empresas e podem conter dados vitais para a perenidade da organização. Em
alguns casos, o valor dos dados contidos nessas bases é desconhecido pelas
próprias empresas, sendo que os custos por esse desconhecimento acabam sendo
S
contabilizados após um desastre ou roubo dessas informações. Garantir a
segurança dessa informação, de modo que esta não seja danificada, roubada ou
perdida é uma das atribuições do administrador de banco de dados. Este trabalho
A
tem como objetivo analisar as vulnerabilidades as quais um banco de dados de uma
empresa estaria sujeito e descrever recomendações e medidas de segurança para
IN
garantir a integridade, confiabilidade e confidencialidade dos dados ali registrados.
O trabalho aborda questões de segurança aplicáveis nas camadas física e lógica
dos sistemas de gerenciamento de bases de dados Oracle e SQL Server, sendo
que muitas das recomendações são universais para ambas as ferramentas, não se
IM
atendo a uma plataforma específica de sistema operacional.
U
N
Palavras Chave: Segurança, Banco de Dados, Vulnerabilidades, Medidas de
Segurança.
ABSTRACT
With the increasing advances in modern technology, the volume of information
generated by systems increases considerably every day. Many of these information
are stored in databases of companies and may contain information vital to the
survival of the organization. In some cases, the data value contained in these
databases is unknown by the companies themselves, and the costs for that
ignorance they are counted after a disaster or theft of such information. Ensuring
S
security of information, so that is not damaged, lost or stolen is one of the tasks of
the database administrator. This work aims to analyze the vulnerabilities to which a
A
database of a company is subject and describe recommendations and security
measures to ensure the integrity, reliability and confidentiality of the data recorded
there. The work addresses issues of security for the physical and logical layers of
IN
database management systems Oracle and SQL Server, and many of the
recommendations are universal for both tools are not given a platform specific
IM
operating system.
U
N
Keywords: Security, Database, Vulnerabilities, Security Measures.
LISTA DE FIGURAS
Figura 1 – Freqüência de perda de informações nas empresas entrevistadas..................... 17
Figura 2 – Principais ameaças e vulnerabilidades ao servidor de banco de dados. ............. 29
Figura 3 – Tabelas no banco de dados. ............................................................................... 31
Figura 4 – Exemplo de código ASP.NET vulnerável à injeção de SQL. ............................... 33
Figura 5 – Representação de uma estrutura física de segurança. ....................................... 41
Figura 6 – Acesso através de senha padrão do usuário System do Oracle. ........................ 47
Figura 7 – Escolha do método de autenticação durante instalação do SQL Server 2008. ... 48
S
Figura 8 – Usuário administrador do banco com opção para forçar política de senha do
Windows ativada.................................................................................................................. 49
Figura 9 – Usuário único de todos os departamentos para acesso à base de dados. .......... 52
Figura 10 – Usuários distintos para cada departamento acessar o banco de dados. ........... 53
A
Figura 11 – Exemplo de configuração de usuário Oracle para instalação e utilização do
SGBD Oracle9i em sistemas operacionais Unix. ................................................................. 55
Figura 12 – Privilégio padrão do grupo BUILTIN\Administradores no SQL Server. .............. 55
IN
Figura 13 – Grupo “Administradores” do sistema operacional e os respectivos membros
desse grupo......................................................................................................................... 56
Figura 14 – Demonstração de remoção do grupo BUILTIN\Administradores. ...................... 57
Figura 15 – Exemplo de código escrito em PHP. ................................................................. 59
IM
Figura 16 – Função PHP para validação de tipos de variáveis. ........................................... 60
Figura 17 – Função PHP para validação de variáveis numéricas......................................... 60
Figura 18 – Exemplo de código ASP utilizando RegularExpressionValidator. (Fonte: MSDN.
2005) ................................................................................................................................... 61
Figura 19 – Exemplo de procedimento com codificação vulnerável. .................................... 61
U
N
Figura 20 – Validação de SQL dinâmico através de SQLParameterCollection. (Fonte: MSDN.
2005) ................................................................................................................................... 62
Figura 21 – Representação de uma política de backup full diário. ....................................... 65
Figura 22 – Representação de uma política de backup diária, com 01 backup full (completo)
e backups transacionais no decorrer do dia......................................................................... 66
Figura 23 – Representação de uma política de backup com 02 backups full na semana,
intercalados com backups diferenciais nos demais dias e backups transacionais no decorrer
de cada dia. ......................................................................................................................... 67
Figura 24 – Tela de propriedades do SQL Server apresentando a opção de “Failure”
marcada no AUDIT LEVEL. ................................................................................................. 71
LISTA DE ABREVIATURAS E SÍMBOLOS
ABNT - Associação Brasileira de Normas Técnicas
ASP – Active Server Pages
DBA – Database Administrator
DDL – Data Definition Language
FTP – File Transfer Protocol
ISO - International Standards Organization
S
IEC – International Electrotechnical Commission
A
PHP – Personal Home Page: Hypertext Preprocessor
SGBD – Sistema Gerenciador de Banco de Dados
IN
SMTP – Simple Mail Transfer Protocol
VLAN – Virtual Local Area Network
SQL – Structured Query Language
IM
HP – Hewlett Packard
U
N
SCOM – System Center Operation Manager
SUMÁRIO
1 INTRODUÇÃO ....................................................................................................................................10
1.1 CENÁRIO ATUAL..............................................................................................................................10
1.2 IDENTIFICAÇÃO DO PROBLEMA .........................................................................................................11
1.3 OBJETIVOS DO TRABALHO ...............................................................................................................12
1.3.1 Objetivo Específico ...............................................................................................................12
1.3.2 Objetivo Geral.......................................................................................................................12
1.4 JUSTIFICATIVA PARA A PESQUISA .....................................................................................................13
1.5 ORGANIZAÇÃO DO TRABALHO .........................................................................................................14
2 FUNDAMENTOS DA SEGURANÇA DA INFORMAÇÃO..................................................................16
A
S
2.1 – SEGURANÇA DA INFORMAÇÃO.......................................................................................................16
2.2 – NORMA BRASILEIRA PARA GESTÃO DE SEGURANÇA DA INFORMAÇÃO...............................................18
2.2.1 – Segurança física e do ambiente ........................................................................................18
2.2.2 – Segurança de equipamentos.............................................................................................19
2.2.3 – Controle de acessos ..........................................................................................................21
2.3 – MONITORAMENTO ........................................................................................................................26
3 AMEAÇAS À SEGURANÇA DO BANCO DE DADOS .....................................................................28
IM
IN
3.1 – FUNDAMENTOS DE BANCO DE DADOS ............................................................................................29
3.2 – ESPIONAGEM NA REDE .................................................................................................................31
3.3 – QUEBRA DE SENHA ......................................................................................................................32
3.4 – INCLUSÃO DE CÓDIGO SQL ..........................................................................................................32
3.5 – FALHAS DE SEGURANÇA NATIVAS ..................................................................................................34
3.6 – ACESSO NÃO AUTORIZADO AO SERVIDOR ......................................................................................34
3.7 – VULNERABILIDADES DE CONFIGURAÇÃO ........................................................................................35
3.8 – DESASTRES NATURAIS .................................................................................................................36
4 MÉTODOS E PROCEDIMENTOS DE SEGURANÇA À BANCO DE DADOS .................................37
U
N
4.1 – SEGURANÇA FÍSICA ......................................................................................................................37
4.1.1 – Acesso físico não autorizado ao servidor..........................................................................37
4.1.2 Segurança do equipamento .................................................................................................40
4.1.3 Desastres naturais................................................................................................................42
4.2 FALHAS DE SEGURANÇA NATIVAS.....................................................................................................42
4.3 MÉTODOS DE AUTENTICAÇÃO DEFICIENTES ......................................................................................44
4.3.1 Ataque de dicionário .............................................................................................................44
4.3.2 Ataque de força bruta ...........................................................................................................45
4.3.3 Autenticações deficientes em bancos de dados ..................................................................46
4.4 VULNERABILIDADES DE CONFIGURAÇÃO ...........................................................................................50
4.4.1 Remoção de usuários e bancos de exemplo .......................................................................50
4.5 VULNERABILIDADES DE APLICATIVOS................................................................................................58
4.5.1 Tratativas de segurança em PHP.........................................................................................59
4.6 IMPORTÂNCIA DO BACKUP ...............................................................................................................62
4.7 MONITORAMENTO DO BANCO...........................................................................................................68
4.8 AUDITORIA NO BANCO DE DADOS .....................................................................................................70
5 CONCLUSÃO .....................................................................................................................................72
5.1 PROPOSTAS DE TRABALHOS FUTUROS .............................................................................................73
10
1 INTRODUÇÃO
1.1 Cenário atual
A tecnologia moderna é a grande responsável pela enorme
quantidade de informação que é gerada todos os dias em várias partes do mundo.
Muitas
dessas
informações
são
geradas
por
sistemas
informatizados
e
armazenadas em bases de dados de empresas, em sua maioria, as responsáveis
S
por essas informações.
Nestas bases de dados estão armazenadas, dependendo da empresa
e do negócio envolvido, as mais diversas informações como dados de clientes e
A
fornecedores; catálogo de produtos; dados de transações e movimentações
financeiras; a vida financeira da empresa; históricos de toda a organização; dentre
IN
outras inúmeras informações.
O valor que estas bases de dados representam para essas
organizações, às vezes, é desconhecido até por elas próprias. Outras, só
IM
conseguem mensurar esse valor com mais precisão no momento em que suas
informações, registradas nas bases de dados, são perdidas ou danificadas.
Como estas informações tornam-se cada vez mais valiosas a cada
minuto em que estão sendo processadas, certas medidas de segurança devem ser
U
N
adotadas nas bases de dados para garantir seu sigilo, integridade e confiabilidade.
Dessa forma, a organização garante a sua perenidade e a continuidade do negócio;
caso contrário, o valor dessas bases de dados para a organização será então
conhecido perante o cálculo dos prejuízos gerados com a perda das informações.
Em um ambiente de banco de dados pouco protegido é possível a
invasão e o roubo de informações com certa facilidade, pois estes não possuem
sequer uma segurança bem implementada no nível da camada de banco de dados
que impeça tal ato. São também ambientes vulneráveis a situações de desastre
físico e lógico; que não possuem dispositivos para restauração do ambiente, bem
como não possuem estratégias para controlar intervenções diretas na base de
dados.
11
Com base nessa realidade, o ideal seria que essas empresas
buscassem proteger seus dados adotando mecanismos e políticas de segurança
computacional, pois tais medidas visam impedir o roubo de dados, destruição da
informação, ataques de crackers, acessos não autorizados, dentre outros.
Definir regras de acesso ao ambiente de banco de dados, com a
utilização de senhas bem elaboradas; manter o SGBD – Sistema de Gerenciamento
de Base de Dados sempre atualizado, corrigindo assim falhas de segurança;
monitoramento do ambiente de banco de dados; a adoção de uma política de
backup e restauração eficiente como principal medida de segurança, que possibilite
S
reverter situações de perda ou corrupção de informações; todas essas são medidas
importantes a serem consideradas no dia-a-dia de trabalho do administrador de
banco de dados (do inglês, DBA – Database Administrator) na tentativa de “blindar”
A
a base de dados e garantir a segurança da informação.
No entanto, algumas empresas não se atêm a esses detalhes tão
IN
importantes para a segurança e continuidade de seu negócio, tornando-se alvo de
ataques e correndo o risco de ter seus dados roubados ou destruídos por um
invasor. Inclusive, nem todas as empresas podem dispor de profissionais de
IM
segurança da informação que possam vir a implementar proteção ao ambiente
computacional.
Nesse contexto, o presente trabalho destina-se a apresentar falhas e
vulnerabilidades genéricas em ambientes de bancos de dados que podem vir a
U
N
comprometer a segurança e continuidade do negócio da empresa, bem como
propor estratégias e métodos que visam fortalecer a segurança das informações
presentes nas bases de dados da organização.
1.2 Identificação do problema
Com o crescimento das bases de dados dentro das empresas, devido
a grande quantidade de informação produzida constantemente, há uma
necessidade de se adotar políticas de segurança adequadas para proteger essas
informações, que se tornam valiosas às organizações a cada minuto.
12
Há uma série de requisitos que devem ser observados no momento de
se disponibilizar uma base de dados para utilização. São medidas simples que
acabam passando despercebidas no dia-a-dia das empresas, mas que não
deveriam ser ignoradas, pois em situações adversas é que se percebe o quanto
poderia ter sido feito para evitar tais problemas.
No entanto, alguns profissionais de informática desconhecem as
soluções que podem ser implementadas nesses ambientes que, de certa forma, são
críticos para o negócio da empresa. Desconhecem que determinadas rotinas diárias
devem ser observadas, no intuito de possibilitar uma análise criteriosa em casos de
S
falhas ou fraudes no sistema; ou mesmo que determinados mecanismos de acesso
são frágeis e passíveis de serem explorados por algum invasor, possibilitando o
A
roubo ou destruição de informações da base de dados.
Uma análise dessas vulnerabilidades mais comuns e genéricas se faz
necessário para que o DBA possa adquirir conhecimento sobre estes métodos e
IN
fragilidades que as bases de dados estão sujeitas, bem como medidas para
proteger o ambiente de banco de dados da empresa da ação de pessoas não
IM
autorizadas.
1.3 Objetivos do trabalho
U
N
1.3.1 Objetivo Específico
O objetivo deste trabalho é descrever sobre as vulnerabilidades
existentes no ambiente de banco de dados e apresentar diferentes configurações e
medidas de segurança a serem aplicadas nesses ambientes, no intuito de se
proteger as informações armazenadas dentro do banco de dados da organização.
1.3.2 Objetivo Geral
O trabalho está focado em auxiliar profissionais de informática na
descoberta de vulnerabilidades e na implantação de estratégias de segurança para
bancos de dados. Também, os profissionais de banco de dados terão uma base de
13
informações formatada sobre segurança em ambientes computacionais de banco
de dados, de modo que possa facilitar na implantação de uma política de segurança
eficiente em bases de dados Oracle e SQL Server.
É certo que cada SGBD é diferente um do outro e que possuem
particularidades únicas, cada ambiente de uma determinada empresa é diferente de
outra; porém, há diversos detalhes de segurança que estão presentes em qualquer
ambiente e são passíveis de implementação.
Será descrito algumas ameaças a bancos de dados como, por
exemplo, a injeção de SQL e acesso externo não autorizado ao servidor. Pretende-
S
se também, apresentar uma abordagem sobre fragilidade de senhas; métodos de
autenticação deficientes; falhas de segurança nativas (mais conhecidos como
A
bugs); a importância das atualizações de banco de dados (também conhecidos
como patches); a importância do backup, bem como algumas ferramentas para
monitoramento do ambiente computacional.
IN
Este trabalho não destina-se a fazer um comparativo entre os SGBD’s
Oracle e SQL Server no que tange a medir qual dentre estes possuem melhor
solução de segurança, bem como entre diferentes plataformas de hardware ou
IM
software.
Enfim, este trabalho busca orientar o profissional de informática na
implantação de um ambiente de banco de dados seguro e bem monitorado, e
também no conhecimento das ameaças a que suas bases de dados estão expostas
U
N
no dia-a-dia, de modo a garantir a segurança das informações ali armazenadas.
1.4 Justificativa para a pesquisa
A principal justificativa para a realização deste trabalho é apresentar
propostas de configuração de um ambiente de banco de dados seguro para a
organização,
baseado
no
agrupamento
de
artigos
de
especialistas
e
documentações oficiais de fabricantes de sistemas de gerenciamento de banco de
dados; uma vez que esses documentos geralmente abordam tecnologias e serviços
específicos, dispersos um dos outros e não referenciam, de forma prática, um
14
ambiente de banco de dados de forma mais ampla.
Implantar mecanismos de segurança eficazes no ambiente de banco
de dados é um procedimento de extrema importância para as organizações que
desejam se precaver de perdas ou desastres em suas bases de dados, pois estas
sabem o quanto é importante todas as informações que estão contidas em seus
repositórios. Não é somente um dado financeiro da empresa, nem tampouco o
nome de seus clientes; é toda a estrutura do seu negócio que ali está armazenada.
Dependendo do modelo de negócio, a perda de informações significa perda
imediata de receita para a empresa ou prospecção de novos negócios futuramente.
S
Neste sentido, o presente trabalho oferecerá aos profissionais de
informática, suporte no desenvolvimento e implantação de procedimentos de
A
segurança adequados ao seu ambiente de banco de dados; obter um
monitoramento de todos os processos em execução, de modo a possibilitar
auditorias futuras; rotinas de backup bem programadas, para possibilitar a
IN
restauração do ambiente rapidamente e assim, causar o menor impacto e tempo de
indisponibilidade possível no negócio da empresa; bem como restringir acessos
indesejados aos servidores de banco de dados.
IM
Por fim, destaca-se também a importância deste trabalho para o meio
acadêmico, pois existem poucos trabalhos acadêmicos abordando vulnerabilidades
de sistemas computacionais de banco de dados e contramedidas para proteção
U
N
desses ambientes como um todo.
1.5 Organização do Trabalho
No Capítulo 2 são apresentados conceitos importantes de banco de
dados e também sobre segurança em um ambiente computacional, com destaque
ao ambiente de banco de dados. O conhecimento desses assuntos se faz
necessário para facilitar o entendimento e configuração desse tipo de ambiente.
O Capítulo 3 irá apresentar os problemas de segurança que devem
ser observados no momento da configuração do ambiente computacional de banco
de dados; e mostrar as falhas de segurança que poderão danificar o banco ou
15
possibilitar a obtenção de informações sigilosas.
O Capítulo 4 irá abranger as propostas e métodos de segurança que
podem ser implementados para corrigir as vulnerabilidades no ambiente
computacional de banco de dados, bem como o monitoramento do banco, no intuito
de controlar intervenções e prevenir problemas.
O Capítulo 5 encerra este trabalho sintetizando todas as propostas
levantadas, bem como perspectivas de trabalhos futuros que podem vir a
U
N
IM
IN
A
S
complementar este.
16
2 FUNDAMENTOS DA SEGURANÇA DA INFORMAÇÃO
2.1 – Segurança da informação
Conforme a Norma ABNT NBR ISO/IEC 17799:2005 (2005, p.ix), a
informação é um ativo importante e essencial para os negócios da empresa e
precisa ser protegido dos vários tipos de ameaças existentes, de modo a diminuir os
riscos aos negócios e maximizar o retorno sobre os investimentos e as
S
oportunidades de negócio.
Para tal é necessário sua implementação a partir de um conjunto de
controles
adequados
que
envolvem
políticas,
estruturas
organizacionais,
A
procedimentos e funções. Mesmo após sua implantação, esse conjunto de controles
precisa ser auditado e melhorado para garantir a segurança da organização e o
gestão de negócio.
IN
cumprimento dos objetivos do negócio, em conjunto com outros processos da
Estudos realizados pela McAfee e Datamonitor (COMPUTERWORLD,
IM
2007) com empresas de grande porte de todo o mundo, apontaram que apenas 6%
das empresas entrevistadas puderam afirmar com certeza que não tiveram
problemas com perda de informações. Outro dado importante é a constatação que
cerca de 60% das entrevistadas tiveram casos de perda de dados em 2006 e 33%
U
N
desses casos poderiam ter levado a empresa a fechar seu negócio. Levantou-se
também que em países como Estados Unidos, que possuem legislações para evitar
perdas de dados e o nível de conscientização das empresas seja elevado, e
também na Alemanha, os índices de perda de dados foram os maiores de toda a
pesquisa. Os dados consolidados da pesquisa são apresentados na figura 2, em
seqüência.
A
S
17
Figura 1 – Freqüência de perda de informações nas empresas entrevistadas.
IN
(Fonte: COMPUTERWORLD. 2007)
Os mecanismos para a perda de dados partem desde ataques
externos na tentativa de roubo de informação até situações de perdas acidentais.
IM
Com a tecnologia atual e a falta de restrição de acesso ou privilégios
excessivos à sistemas e servidores, pode-se carregar registros do banco de dados
em dispositivos móveis ou mídias portáteis. Um funcionário mal-intencionado,
aproveitando-se de políticas de segurança mal configuradas ou inexistentes, pode
U
N
corromper os dados do catálogo de preços da empresa, gerando transtornos e até
perda de receita.
Seja intencional ou acidental, interno ou externo, a segurança das
informações deve ser sempre uma constante dentro das organizações. Diante
disso, a implantação de processos e métodos de proteção deve ser adotada tanto
para ataques externos como para ataques internos.
Políticas de controle de acesso à ambientes restritos; implementação
de segurança de equipamentos e do ambiente onde estes se encontram; bem como
o monitoramento de servidores e processos, de modo a alertar em caso de
intervenções não autorizadas; são métodos de segurança física que podem ser
adotados para a proteção da informação.
18
2.2 – Norma brasileira para gestão de segurança da informação
Para auxiliar os profissionais de TI na implantação de processos de
segurança no ambiente computacional das empresas surgiram um conjunto de
normas padronizadas e procedimentos de segurança da informação. A ABNT NBR
ISO/IEC 17799:2005 é um conjunto de normas para gestão de segurança da
informação e foi elaborada pela ABNT (Associação Brasileira de Normas Técnicas),
uma equivalente à norma internacional ISO/IEC 17799:2005.
Essa norma abrange diversos setores da política de segurança da
S
informação desde a segurança física de instalações e equipamentos, como parte
externa dos prédios e acesso físico de funcionários, fornecedores, parceiros e
A
clientes; segurança lógica, que envolve monitoramento de processos, controle de
acesso lógico e desenvolvimento de sistemas de informação; até a gestão de
processos, que envolve continuidade de negócios, vulnerabilidades, incidentes e
IN
auditoria de sistemas de informação.
Por possuir um conteúdo bastante abrangente e extenso, do qual cada
um possui uma importância singular, serão listados alguns pontos da norma. São
o
IM
eles:
o
Monitoramento.
o
Segurança de equipamentos;
Controle de acessos;
U
N
o
Segurança física e do ambiente;
2.2.1 – Segurança física e do ambiente
Descreve que toda e qualquer instalação física utilizada para o
armazenamento de informações importantes à empresa seja monitorada, de acesso
restrito e controlado, bem como possua uma estrutura física adequada para
prevenção de todas as possíveis invasões ou efeitos naturais (inundações,
terremotos, incêndios).
Os tópicos abaixo descrevem alguns exemplos sobre o que um prédio
19
destinado a processamento de informações deva possuir em nível de segurança:
o
Construção robusta e fortificada com alarme, sistema de incêndio que
obedeça a normas nacionais e internacionais, portas corta-fogo;
o
Controle eletrônico de acesso ao prédio ou a existência de uma
portaria com porteiro;
o
Construção de barreiras físicas para impedir o acesso não autorizado
e a contaminação do meio ambiente;
o
Registro de entrada e saída de visitantes ao prédio com controle de
S
data e hora, inclusive com acesso de terceiros supervisionados e restritos
somente aos locais de atividades de suporte ou afins;
Direitos de acesso a áreas seguras sejam revistos e atualizados em
A
o
determinados períodos, e revogados quando necessário;
o
A fachada dos edifícios deve ser discreta, de modo que não se
o
IN
perceba a real finalidade do prédio;
Materiais perigosos, inflamáveis e de papelaria sejam armazenados
distantes das áreas de segurança;
Equipamentos
destinados
IM
o
à
contingência
e
backup
sejam
armazenados em outro local afastado do prédio, se possível, de modo a não
U
N
serem afetados no caso de um desastre no prédio principal.
2.2.2 – Segurança de equipamentos
Objetiva a proteção do equipamento contra furtos, danos, ameaças
físicas e do meio ambiente ou qualquer outra atividade que venha a interromper as
atividades da empresa. Tal proteção visa reduzir o risco de acesso não autorizado
as informações, evitando assim perdas e danos nas mesmas.
Esse tópico contém subcategorias que abrangem a instalação,
manutenção, reutilização e alienação, remoção do equipamento, utilidades de
suprimento, segurança do cabeamento, e também da segurança do equipamento
fora da organização. Abaixo segue um resumo sobre cada uma dessas
subcategorias:
20
o
Instalação e proteção do equipamento: os equipamentos sejam
colocados nos locais destinados, protegidos de ameaças externas do meio
ambiente (sol, chuva) e acesso não autorizado (vide segurança física e do
ambiente), e que seja estabelecido restrições quanto a comer, beber ou
fumar nesses locais. Os prédios também devem ser dotados de mecanismos
de proteção contra raios, inclusive as linhas de entrada de energia e
comunicação.
o
Utilidades de suprimento: os equipamentos devem ser protegidos
contra falta de energia elétrica ou outras interrupções causadas por falhas
S
das utilidades, como ar-condicionado, ventilação, suprimento de água e
esgoto; devendo as mesmas serem inspecionadas em intervalos regulares e
o
A
testadas para assegurar seu funcionamento correto.
Segurança do cabeamento: o cabeamento de energia e de transporte
de dados seja protegido contra danos ou interceptações, evitando trajetos
IN
que passem por áreas públicas; cabos de energia e de dados sejam
separados, de forma a não causar interferências um no outro; utilizar
marcações facilmente identificáveis para reduzir erros de manuseio, dentre
o
IM
outros pontos de acordo com cada situação.
Manutenção de equipamentos: convém que os equipamentos tenham
uma manutenção correta para assegurar sua disponibilidade e integridade.
Para isso, recomenda-se a realização de manutenções em horários
U
N
recomendados pelo fornecedor, por pessoal autorizado e de confiança, bem
como o registro de todas as atividades realizadas, inclusive das falhas reais
ou suspeitas.
o
Segurança do equipamento fora da organização: sejam tomadas
medidas de segurança para os equipamentos que operem fora dos prédios
da empresa, porém tais acessos devem ser antecipadamente autorizados
pela gerência. Outros direcionamentos sobre proteção de equipamentos
móveis estão disponíveis no tópico “Computação e comunicação móvel”,
item 11.7.1 da ABN NBR ISO/IEC 17799:2005.
o
Reutilização e alienação segura: todos os equipamentos que
contenham informações sensíveis sejam examinados antes do descarte e
21
sejam
destruídos,
apagados
ou
sobregravados
por
técnicas
que
impossibilitem a sua recuperação.
o
Remoção de propriedade: qualquer equipamento, informação ou
software não seja retirado do local destinado sem autorização prévia dos
responsáveis e a correta identificação destes.
2.2.3 – Controle de acessos
Esse tema abrange desde a definição de uma política de controle de
S
acesso; o gerenciamento de usuário, acesso à rede, ao sistema operacional e até a
aplicação; bem como acesso remoto a informações. Cada um desses itens possui
A
um conjunto de instruções específico as suas características e funcionalidades.
Assim como nos tópicos sobre segurança física e do ambiente e
segurança de equipamentos, esse tópico também possui subcategorias que
IN
detalham todos os níveis de controle de acesso a serem observados dentro da
empresa para segurança da informação. Estes são apresentados resumidamente
IM
na seqüência devido ao seu amplo conteúdo.
2.2.3.1. Requisitos de negócio para controle de acesso
Tem como objetivo controlar o acesso à informação. Para tal, políticas
U
N
de controle de acesso devem ser criadas, documentadas e analisadas baseadas
nos requisitos de acesso dos negócios e a segurança da empresa. Nessa política
de controle de acesso devem constar claramente quais são as regras de controle de
acesso lógico e físico para todos os usuários e grupos de usuários.
Segundo o tópico 11.1.1 da norma ABN NBR ISO/IEC 17799:2005,
alguns dos itens apresentados abaixo são importantes e devem constar na política
de controle de acesso a ser montada:
o
Identificação de todas as informações relacionadas às aplicações de
negócios e os riscos a que as informações estão expostas;
o
Administração de direitos de acesso em um ambiente distribuído e
conectado à rede que reconheça todos os tipos de conexões disponíveis;
22
o
Separação das regras de controle de acesso em categorias como
pedido de acesso, autorização e administração de acesso, etc;
o
Definir requisitos para as autorizações formais de pedidos de acesso;
o
Definir requisitos para análise crítica periódica de controles de acesso;
o
Remoção de direitos de acesso.
2.2.3.2. Gerenciamento de acesso do usuário
S
Tem como objetivo garantir o acesso dos usuários autorizados à
informação, bem como restringir os acessos não autorizados. Aborda a
implementação de procedimentos formais para registro e cancelamento de
A
usuários, abrangendo todo o ciclo de vida do usuário e controlando a concessão e
revogação de privilégios de acessos nos sistemas de informação e serviços
IN
disponíveis na corporação.
Segundo a norma da ABNT, é interessante conter nesse procedimento
formal os seguintes itens:
Utilizar identificador único de usuário (ID de usuário) para assegurar a
IM
o
responsabilidade deste por suas ações;
o
Verificar se o nível de acesso do usuário é adequado ao propósito do
negócio e, também, seja condizente com a política de segurança da
U
N
organização;
o
Remover imediatamente ou bloquear os direitos de acesso dos
usuários que mudaram de cargo ou funções, ou deixaram a empresa;
o
Estabelecer perfis de acesso do usuário baseados nos requisitos de
negócio, de modo a possibilitar melhor gerenciamento de privilégios de
usuários, uma vez que estarão inseridos em perfis específicos a determinada
ação dentro dos sistemas de informação;
o
Adoção de um processo de autorização para concessão de privilégios
e que estes não sejam concedidos até a finalização da autorização, bem
como o registro de todos os privilégios concedidos seja mantidos;
23
Senhas de usuários nunca sejam guardadas em sistemas de
o
computador desprotegidas;
Direitos de acesso dos usuários sejam revisados e analisados em
o
intervalos regulares.
2.2.3.3. Responsabilidades dos usuários
Seu objetivo é prevenir acessos de usuários não autorizados à
informações ou o comprometimento delas. Para isso será necessário a
S
conscientização do usuário quanto as suas responsabilidades nesse processo,
especificamente em relação a suas senhas e a segurança dos equipamentos que
A
utiliza; adotar a política de mesa e tela limpa, evitando deixar expostos à vista de
qualquer pessoa papéis ou documentos abertos no computador, de modo a reduzir
a possibilidade de acessos não autorizados, roubo de documentos sigilosos ou de
IN
recursos de processamento da informação.
Em relação à utilização de senhas, convêm que:
Não sejam utilizadas senhas fáceis com caracteres numéricos ou
o
o
o
IM
alfabéticos seqüenciais;
Manter a confidencialidade das senhas;
Evitar anotar as senhas em papéis ou que fiquem anotadas em locais
U
N
desprotegidos;
o
Utilizar senhas fáceis de lembrar e com maior complexidade;
o
Trocar as senhas regularmente e não compartilhar senhas de usuários
finais.
Outro assunto abordado dentro do tópico sobre responsabilidades dos
usuários refere-se aos equipamentos de usuários que não são monitorados como
os desktops (estações de trabalho). Os usuários devem estar cientes dos requisitos
de segurança da informação e procedimentos para proteger esses equipamentos
como bloquear a máquina ao afastar-se desta e não deixar sessões ativas nos
equipamentos.
24
Por fim, cuidados quanto ao armazenamento de informações
importantes e essenciais a empresa; proteção dos equipamentos de impressão e o
uso não autorizado desses são requisitos da política de mesa limpa que, também,
são de responsabilidade dos usuários.
2.2.3.4. Controle de acesso à rede
Tem como objetivo prevenir o acesso não autorizado aos serviços de
rede, controlando os acessos internos e externos, de modo que os usuários tenham
S
acesso somente ao que lhes foi permitido. É importante a criação de uma política de
acesso à redes e serviços de rede que esteja alinhada à política de controle de
A
acesso do negócio da empresa.
Esse tópico abrange critérios de segurança para conexão externa à
rede da empresa, utilizando técnicas de criptografia; controles de conexão à redes
IN
compartilhadas, cujo acesso os usuários deve ser restrito; a segregação de grandes
redes em outros domínios de redes lógicas, comumente conhecidas como VLAN;
dentre outros.
IM
É importante que para esses métodos o nível de controle de acesso
deva ser definido primeiramente através de uma análise ou avaliação de riscos;
estar baseado na política de controle de acesso da empresa e levar em conta os
U
N
custos relativos à implementação e seu nível de impacto nessas redes.
2.2.3.5. Controle de acesso ao sistema operacional
Objetiva prevenir o acesso não autorizado a sistemas operacionais
restringindo o acesso dos usuários autorizados conforme a política de controle de
acesso, registrando o número de tentativas efetuadas e, em casos extraordinários,
o tempo de acesso aos sistemas operacionais.
Para isso há alguns sub-tópicos que apresentam propostas de
segurança em diversos pontos; por exemplo, medidas a serem tomadas nas etapas
de entrada no sistema (comumente conhecido como log-on) na qual um usuário não
autorizado não tenha condições de obter informações sobre o sistema; também na
25
adoção de identificadores únicos para cada usuário, de modo que facilite o
rastreamento das atividades do usuário dentro dos sistemas operacionais.
No processo de gerenciamento de senhas devem-se configurar
métodos para a escolha de senhas de qualidade, que sejam trocadas regularmente
e que essas não possam ser reutilizadas. Esse ponto é bastante importante, pois a
senha é um dos principais meios de validação de usuários para acesso a um
serviço de computador.
Esse tópico também aborda a adoção de métodos para desconexão
automática do usuário por inatividade, de modo a prevenir o acesso de pessoas não
S
autorizadas. Um ponto interessante, porém excepcional, é referente a restrição de
conexão em determinados horários, no entanto, tal medida é mais importante em
A
sistemas que acessam informações sensíveis à empresa.
IN
2.2.3.6. Controle de acesso à aplicação
Objetiva controlar o acesso não autorizado à informação contida nos
sistemas de aplicação da empresa. Esses sistemas devem controlar o acesso dos
IM
usuários as informações tratadas pelo sistema, bem como o nível de privilégios
desses usuários.
Para tal as aplicações devem apresentar menus de opções
específicos ao perfil de cada usuário e controlar os processos que estes podem
U
N
efetuar com as informações que lhes são apresentadas, como leitura, escrita,
alteração ou remoção.
No caso de sistemas que trabalham com dados sensíveis, convém
que seja colocados em ambientes computacionais dedicados, sendo executados a
partir de computadores dedicados ou compartilhem recursos somente com sistemas
de aplicações confiáveis.
2.2.3.7. Computação móvel e trabalho remoto
Visa garantir segurança da informação quando da utilização de
computação móvel e do advento do trabalho remoto. Importante a criação de uma
26
política formal e a adoção de medidas de segurança adequadas para a
normalização dessa prática de trabalho, de modo a não comprometer as
informações do negócio da empresa, levando-se em consideração os riscos de se
trabalhar com equipamentos de computação móvel em lugares desprotegidos.
Essa política normativa deve incluir os requisitos de acesso externo,
técnicas criptográficas, cópias de segurança (backups), proteção contra vírus,
regras para conexão de equipamentos móveis (notebooks, palmtops, laptops,
celulares, etc) e diretrizes sobre a utilização desses recursos em locais públicos.
Considerações importantes sobre acesso à redes sem fios devem ser
S
observados, pois possuem diferenças em relação à questões de segurança e
quanto a realização de backups. Por isso, a conscientização dos usuários quanto
A
aos riscos de utilização dessa forma de trabalho deve ser bem enfatizada.
O trabalho remoto somente deve ser autorizado pela empresa quando
esta estiver certa de que as devidas providências relacionadas à segurança das
IN
informações tenham sido implementadas como, por exemplo, a segurança do local
IM
de trabalho remoto seja ideal e o mau uso dos recursos móveis.
2.3 – Monitoramento
U
N
O monitoramento visa detectar atividades não autorizadas no
ambiente computacional da empresa, com o intuito de se registrar atividades
operacionais e falhas no processamento da informação. O monitoramento de
sistema deve ser utilizado para averiguar a eficácia dos processos de controle de
acesso, de modo que estejam adequados ao modelo de política de acesso definido
pela organização.
Assim como nos tópicos sobre Segurança de Equipamentos e
Segurança Física e do Ambiente, esse tópico possui subcategorias que detalham os
vários tipos de monitoramento e procedimentos a serem adotados. São eles:
o
Registros de auditoria: registros (logs) que contenham atividades dos
usuários, exceções e outros eventos de segurança da informação sejam
gerados e guardados por um período determinado para averiguações futuras
27
em caso de investigações e monitoramento de controle de acesso.
o
Uso do sistema: estabelecer e analisar regularmente procedimentos
para monitoramento de uso dos recursos de processamento da informação
como acessos autorizados e não autorizados, operações privilegiadas, falhas
do sistema, etc. O nível de monitoramento requerido para os recursos
individuais deve ser determinado através de uma análise/avaliação de riscos.
o
Proteção das informações dos registros: abrange a proteção das
informações coletadas de acesso não autorizado e falsificação.
o
Registros de administrador e operador: atividades executadas por
registradas e analisadas regularmente.
Registros de falhas: todas as falhas ocorridas devem ser registradas e
A
o
S
usuários administradores e operadores do sistema também devem ser
analisadas para a tomada de ações corretivas do evento.
Sincronização dos relógios: diz respeito a sincronização dos relógios
IN
o
de qualquer computador visando assegurar a exatidão dos registros
gravados para auditoria, de modo a garantir a credibilidade das informações
U
N
IM
coletadas.
28
3 AMEAÇAS À SEGURANÇA DO BANCO DE DADOS
Em um ambiente computacional a segurança das informações deve
ser planejada e estruturada para atingir toda a empresa, pois uma falha em
qualquer um desses pontos pode comprometer todo o ambiente. No caso do
ambiente de banco de dados, os ataques podem visar tão somente roubo de dados
como também a corrupção de informações desse banco. Nesses casos, os métodos
são bem diversificados e variam de acordo com a proposta de ataque a que se
S
destina.
O servidor de banco de dados, mesmo que não esteja diretamente
A
conectado à Internet, precisa ser protegido contra ataques que exploram os pontos
fracos de sua configuração, estouros de buffer existentes ou práticas de
IN
desenvolvimento ineficazes, entre outros.
Dentre as várias ameaças a um servidor de banco de dados, podemos
destacar os casos abaixo:
o
o
Acesso não autorizado ao servidor
Quebra de senha
Inclusão de código SQL
U
N
o
Espionagem na rede
IM
o
o
Vulnerabilidades de configuração do banco
o
Vulnerabilidades de rede
o
Falhas de segurança nativas
o
Desastres naturais
Segundo
o
Centro
de
Orientações
de
Segurança
Microsoft
(MICROSOFT, 2004) as quatro primeiras são consideradas as principais na
segurança de um servidor de banco de dados. A figura 2 ilustra a relação dessas
ameaças em um ambiente computacional de uma empresa.
A
S
29
Figura 2 – Principais ameaças e vulnerabilidades ao servidor de banco de dados.
(Fonte: MICROSOFT. 2004)
IN
Será apresentada uma abordagem sobre cada ameaça citada acima
sem o intuito de esgotar todo o assunto, que é bem amplo em cada situação. O
objetivo é apontar as possibilidades existentes na exploração da segurança do
IM
servidor de banco de dados.
U
N
3.1 – Fundamentos de banco de dados
O conceito universal, reconhecido inclusive por Silberschatz (1999), é
que um banco de dados é um conjunto de dados. Esse conjunto de dados é
gerenciado pelos sistemas de gerenciamento de banco de dados (SGBD’s) que
definem o acesso e manipulação dos dados.
Usando uma linguagem bem técnica, pode-se definir que: "um banco
de dados é um coleção de dados persistentes, usada pelos sistemas de aplicação
de uma determinada empresa" (DATE, 2006, p.10).
Os bancos de dados são classificados pela forma como são
armazenados e acessados pelo usuário, o que é chamado de modelo de dados.
Cada modelo tem ou já teve uma aplicabilidade diferente e específica para a
30
situação em que foi desenvolvido. Dentre os modelos mais comuns destacam-se:
o
Modelo Hierárquico
o
Modelo em Redes
o
Modelo Relacional
o
Modelo Orientado a Objetos
Atualmente, o modelo relacional é o mais comum e adotado pelas
grandes empresas desenvolvedoras de SGBD’s. O Oracle e o SQL Server são
S
exemplos desses sistemas de gerenciamento de banco de dados relacional
(SGBDR) produzidos por grandes empresas (Oracle e Microsoft, respectivamente).
A
O termo relacional, usado por Date (2000, p.23), é essencialmente um
termo matemático para designar uma tabela ou, como na definição original, uma
IN
variável de relação. Date define de forma informal e simplificada que um sistema
relacional é aquele no qual os dados são percebidos pelo usuário como tabelas e os
operadores à sua disposição geram tabelas “novas” a partir de tabelas “antigas”.
Nesse modelo, as tabelas são estruturas lógicas onde estão
IM
armazenados os dados e são originadas do cruzamento de linhas e colunas. Cada
coluna recebe um nome e os dados são armazenados como linhas da tabela. A
figura 3 apresenta um modelo de banco de dados com a representação de tabelas e
U
N
suas respectivas linhas e colunas.
A
S
31
Figura 3 – Tabelas no banco de dados.
IN
(Fonte: Oracle Education. 2006)
IM
3.2 – Espionagem na rede
Visa capturar informações que trafeguem em redes sem criptografia
de dados e que possam ser úteis ao invasor. Geralmente exploram-se redes malconfiguradas e de pouca segurança, por exemplo, que utilizem configurações
U
N
padrões de instalação, controles de acesso abertos e dispositivos sem as devidas
correções de segurança atuais. Em se tratando de segurança de banco de dados,
essa ação busca coletar dados de credenciais de acesso ao banco de dados.
Para tal, são utilizados métodos como adição de sniffers (programas
de varredura de dados de uma rede de computadores) para monitorar todo o
tráfego de rede sem criptografia; seqüestro de sessão para desviar o fluxo de uma
rede para um host desejado pelo invasor; e ataques de negação de serviço para
impedir que um servidor consiga atender a todas as requisições de conexão, vindo
a causar fila de processamento e impedir o usuário legítimo de acessar o ambiente.
Por não ser o foco de atenção desse trabalho, esse tópico não
oferecerá mais detalhes desse caso. Maiores informações sobre segurança em
32
redes podem ser obtidos em artigos específicos sobre esse assunto.
3.3 – Quebra de senha
A interface de login (registro) do sistema requer muita atenção e
segurança, pois é a porta de entrada ao ambiente interno; mas nem sempre obtêm
os devidos cuidados e conscientização dos usuários. As técnicas de quebra de
senha visam explorar exatamente essas fragilidades criadas pelos usuários, onde
de baixa complexidade.
S
utilizam-se de ferramentas e técnicas específicas para a quebra de senhas fáceis e
A
Para atingir o objetivo são utilizadas password-crackers, que são
ferramentas desenvolvidas para que um hacker possa executar mecanismos de
quebra de senha são:
IN
quebra de senha de forma automática. Os principais mecanismos utilizados para
Ataques de dicionário: também denominadas “word-lists” (lista de
palavras); são arquivos de texto contendo diversas palavras comuns como, nomes
IM
de pessoas, de objetos, locais, países, etc. Essas palavras são testadas, linha a
linha, pela ferramenta para a tentativa de efetuar login no sistema.
Força bruta: método muito mais lento e consome muitos recursos de
U
N
processamento, porém eficiente, pois visa realizar todas as combinações de
caracteres e símbolos na tentativa de obtenção da senha de registro no sistema. A
técnica visa realizar uma combinação de várias letras, fazendo permutações entre
estas e formando palavras ou seqüências, até a descoberta da senha utilizada. É
um método poderoso e que conseguirá quebrar a senha do sistema. Mas isso pode
levar bastante tempo, de acordo com a complexidade da senha a ser buscada.
3.4 – Inclusão de código SQL
Permite a um usuário mal-intencionado inserir instruções SQL a serem
executadas arbitrariamente no banco de dados através de fragilidades nas
33
validações de entrada da aplicação, utilizando os privilégios concedidos para logon
do aplicativo.
Caso o usuário utilizado para conectar no banco de dados possua
privilégios altos possibilitará a execução de instruções mais impactantes como a
manipulação de dados e até a exclusão de um banco inteiro.
Um exemplo do funcionamento da técnica de injeção de SQL (do
inglês – SQL Injection) é apresentado na figura 4 abaixo de um código ASP.NET
A
S
(MEIER, 2008):
IN
Figura 4 – Exemplo de código ASP.NET vulnerável à injeção de SQL.
No caso acima, é esperado um valor do tipo nnn-nn-nnnn na variável
SSN.Text, cuja saída de comando esperada para o banco de dados seria:
IM
SELECT au_lname, au_fname FROM authors WHERE au_id = ‘172-32-9999’
Porém, ao inserir a instrução DROP DATABASE no campo de
digitação, o comando a ser executado modifica para uma instrução de remoção de
U
N
banco de dados.
Exemplo de entrada mal-intencionada no campo da aplicação:
‘ ; DROP DATABASE pubs -Instrução SQL modificada:
SELECT au_lname, au_fname FROM authors WHERE au_id = ‘ ’ ; DROP
DATABASE PUBS -- ‘
O caractere aspa simples (‘) do início da instrução mal-intencionada
serve para encerrar a instrução anterior iniciada com uma aspa simples. Na
seqüência, aplica-se a instrução desejada (neste caso, de remoção do banco pubs);
seguida do caractere ponto-e-vírgula (;), não obrigatório em alguns bancos; e os
34
caracteres - - (duplo tracejado) que servem para que o restante da instrução SQL
que houver no código original seja ignorada, inclusive a aspa simples de
fechamento que, de outra maneira, ocasionaria um erro de validação da instrução
SQL no banco de dados.
3.5 – Falhas de segurança nativas
Em toda versão de SGBD, com o decorrer do tempo, é feita a
S
correção de algumas falhas de segurança ou “bugs” do produto pelo fornecedor.
Este encontra falhas ou erros na programação do SGBD, das quais depois de
A
alteradas, são divulgadas aos seus clientes para a aplicação das devidas correções.
Após a divulgação dessas correções, torna-se conhecido as brechas
de segurança que determinada versão possui. Tal situação exige que o ambiente de
IN
banco de dados da empresa seja avaliado para que não esteja exposto a essas
falhas, haja vista que agora são de conhecimento público.
Cada fornecedor cria uma denominação própria para essas correções.
IM
No SGBD Oracle, são os chamados patches ou patchsets; já no SGBD SQL Server
U
N
são denominados de service packs ou hotfixes.
3.6 – Acesso não autorizado ao servidor
Conforme descrito no tópico 9.2 da norma ABNT NBR ISO/IEC 17799,
os equipamentos do ambiente computacional das empresas não devem ficar
expostos em locais de fácil acesso às pessoas não autorizadas. Os equipamentos
ficam vulneráveis a intervenções não autorizadas, correm o risco de sofrerem danos
intencionais ou acidentais, bem como as possibilidades de roubo de informações
serem maiores.
Baseado nisso, o servidor de banco de dados deve seguir a
determinação da norma, pois o nível de criticidade se torna muito maior devido ali
conter informações cruciais e até sigilosas do negócio da empresa. Mas não
35
somente o acesso físico como também o acesso lógico a esse servidor deve ser
devidamente controlado e baseado nos requisitos de acesso, definidos na política
de segurança da empresa.
Mesmo com procedimentos de acesso físico bem definidos e
estabelecidos, se não houver uma boa política de acesso lógico implantada, o
banco de dados acabará tão desprotegido quanto se estivesse ao alcance de
qualquer pessoa. Por isso, é importante que ambas as políticas de acesso sejam
habilitadas, pois são atividades complementares e necessárias ao ambiente
A
3.7 – Vulnerabilidades de configuração
S
computacional de banco de dados.
Tanto ao nível de banco de dados quanto ao nível de sistema
IN
operacional, as configurações destes devem ser específicas para a funcionalidade
da máquina. Ou seja, configurar somente aquilo que realmente será necessário na
operacionalidade do ambiente e restringir ao máximo qualquer possibilidade de
IM
exploração de alguma falha na configuração tanto do servidor quanto do próprio
banco nele instalado.
Situações como contas de usuário do sistema operacional ou da base
de dados com altos privilégios, diversas portas de acesso ao servidor liberadas no
U
N
firewall ou ausência de um firewall, serviços desnecessários ativados no servidor,
compartilhamento de arquivos ou pastas envolvendo servidores de banco de dados;
estas são algumas das configurações a serem observadas no ambiente para uma
boa segurança ao banco.
Em cada sistema operacional seja Microsoft, Linux, Unix ou FreeBSB
(sendo estes apenas exemplos) e SGBD’s Oracle, SQL Server, MySQL ou DB2
(também apenas exemplos) há uma série de requisitos específicos que merecem
atenção quando se aborda questões de configuração de um ambiente de banco de
dados. A relação entre cada tipo ou versão de sistema operacional com os
diferentes SGBD’s terão uma característica própria de configuração que deve ser
observada pelo administrador de banco de dados, no intuito de proteger o ambiente
36
e impedir que brechas de segurança sejam exploradas.
3.8 – Desastres naturais
Garantir que a informação no servidor de banco de dados não seja
afetada por elementos do meio ambiente é de suma importância na segurança do
negócio da empresa.
Assim como define a norma ABNT NBR ISO/IEC 17799, deve-se
projetar e assegurar que o ambiente computacional da empresa não esteja
S
vulnerável á inundações, vazamentos de água do telhado ou piso de subsolo,
terremotos, explosões, incêndios ou qualquer outra forma de desastre natural ou
A
causada pelo homem. Ou seja, um bom planejamento da infra-estrutura das
instalações que abrigarão os equipamentos de TI é o ponto fundamental para
U
N
IM
IN
prevenção de desastres naturais.
37
4 MÉTODOS E PROCEDIMENTOS DE SEGURANÇA À BANCO DE DADOS
A busca da segurança tanto das informações quanto do ambiente
computacional da empresa não é uma tarefa fácil de ser alcançada e, às vezes,
muito árdua em sua conquista. Cercar todo o ambiente interno da organização,
implementar políticas e processos de segurança e manter tudo funcionando pode
envolver a abrangência de diversos pontos e processos para serem configurados.
Conforme citado no capítulo anterior, cada sistema operacional
relacionado com um banco de dados específico irá demandar características
S
distintas de segurança para serem implementadas. Porém, muitas delas possuem
pontos em comum no que tange a segurança de forma macro, por exemplo, em se
A
tratando de políticas de acesso ao servidor, definições de senhas de alta
complexidade ou no monitoramento de uma instância de banco de dados.
IN
Baseado nisso, será abordado abaixo um detalhamento de vários
procedimentos de segurança física e lógica que são bastante importantes na
política de segurança de um servidor de banco de dados. Tais métodos aplicados
poderão prevenir ações maliciosas ou que venham a causar a quebra de sigilo de
IM
dados vitais à empresa.
U
N
4.1 – Segurança física
4.1.1 – Acesso físico não autorizado ao servidor
No caso do ambiente de banco de dados não se deve buscar tão
somente a implantação de processos de segurança ao nível interno do servidor ou
lógico do SGBD; a integridade física da máquina também deve ser observada e
preservada. Definir e proteger o servidor de banco de dados de intervenções físicas
não autorizadas e acessos indevidos de pessoas mal-intencionadas, cujo intuito
visa o roubo, negação de serviço, corrupção de informações ou danos as
instalações físicas da organização.
Baseado na norma ABNT NBR ISO/IEC 17799, a aplicação de
38
segurança física a esses equipamentos da empresa baseia-se na definição de um
perímetro de segurança para a proteção dos recursos e instalações de
processamento de informações críticas ou sensíveis do negócio. Esse perímetro de
segurança deve adotar métodos apropriados para controlar a entrada física de
pessoas não autorizadas em áreas restritas; e também a aplicação de diretrizes de
trabalho específicas para áreas seguras da empresa.
4.1.1.1. Perímetro de segurança física
organizações
que
visam
segurança
nas
instalações
de
S
As
processamento e armazenamento de informações devem definir um perímetro de
segurança, que servirá como primeira barreira de acesso externo aos equipamentos
A
da empresa, inclusive o servidor de banco de dados.
Esses perímetros de segurança devem ser bem definidos e de
IN
edificações sólidas com barreiras físicas, de modo que não possibilite a invasão das
áreas de processamento da informação. A empresa pode utilizar diversas barreiras
físicas como proteção adicional; desse modo a falha de alguma dessas barreiras,
IM
num primeiro instante, não afetará toda a segurança subseqüentemente.
Para isso, os prédios devem possuir paredes externas robustas, todas
as portas de acesso sejam controladas por algum dispositivo de controle – como
alarmes ou fechaduras – e janelas com proteção externa. A utilização de sistemas
U
N
para detectar intrusão e alarmes seja adotada para as todas as áreas do prédio,
inclusive as não ocupadas por computadores ou equipamentos de comunicações, e
testados regularmente, conforme normas regionais, nacionais e internacionais.
Em situações onde se necessite de acesso aos locais ou edifícios de
segurança, que este seja realizado por uma área de recepção que controle o
acesso físico, de modo que somente pessoal autorizado possa acessar os
servidores.
Dentro do prédio, portas corta-fogo integradas ao alarme e paredes
resistentes devem ser monitoradas e testadas de acordo com normas regionais,
nacionais e internacionais, operando conforme códigos locais de prevenção de
incêndios e falhas.
39
4.1.1.2.Controle de entrada física
Após a definição do perímetro de segurança, os controles de entrada
física às áreas de segurança da organização devem ser estabelecidos, de modo
que prestadores de serviço, fornecedores ou clientes não tenham acesso irrestrito
aos equipamentos de processamento da informação. Nesse ponto, a norma ABNT
NBR ISO/IEC 17799 aponta algumas diretrizes a serem adotadas para tratamento
dessas questões.
Uma das diretrizes de controle de entrada visa o registro, com data e
hora de entrada e saída, de todo acesso as áreas de segurança, inclusive com
finalidades específicas.
S
acessos supervisionados ou aprovados antecipadamente e somente para
A
No caso onde se realiza o processamento ou armazenamento de
informações, como servidores de banco de dados, o acesso deve ser restrito aos
IN
profissionais autorizados e controlados por controles de autenticação, como cartões
com números de identificação pessoal, sistemas biométricos ou dispositivos
sensoriais em cartões. Nos ambientes mais críticos da empresa, pode-se adotar o
monitoramento através de circuito interno de TV e equipes de vigilância 24x7. Em
IM
situações de acesso de suporte terceirizado, seja concedido acesso somente
quando necessário. Também é importante que esse acesso seja previamente
U
N
autorizado e monitorado.
4.1.1.3.Trabalho em áreas seguras
Em áreas de segurança da empresa, não somente o controle de
acesso deve ser restrito, como também os procedimentos de trabalho nesses locais
devem seguir exigências de segurança, sempre visando à disponibilidade total dos
serviços e proteção das informações ali armazenadas. Esses procedimentos devem
se estender não somente aos funcionários, como, também, aos prestadores de
serviço e fornecedores, de modo a controlar suas ações nessas áreas.
É interessante que as pessoas da organização tenham ciência da
existência de áreas seguras e do tipo de atividades realizadas naquele determinado
local, somente se for necessário aquele conhecimento. Isto evita que detalhes
40
relevantes da segurança de determinada área de armazenamento e processamento
de dados sejam de domínio público na empresa, por exemplo, a existência de um
servidor de banco de dados, contendo dados financeiros ou sigilosos, em certo
ponto específico do prédio.
Nessas áreas todo o trabalho deve ser supervisionado de alguma
forma, de modo que não possibilite a corrupção de informações do banco ou
qualquer outro tipo de atividade mal-intencionada. Caso as áreas de segurança não
sejam ocupadas, deverão estar isoladas através de trancas nas portas e verificadas
A
4.1.2 Segurança do equipamento
S
periodicamente.
Quando se pensa em segurança para o equipamento em si – nesse
caso para o servidor de banco de dados – visa garantir se que esse servidor terá
IN
toda uma infra-estrutura para o seu correto funcionamento em quaisquer das
condições que possam surgir. Isso porque o ambiente de produção da empresa não
pode ficar indisponível por longos períodos de tempo para a correção ou ajuste de
IM
alguma falha que, porventura, venha a acontecer.
Deve-se preparar desde a infra-estrutura básica, como energia, até os
processos de contingência; a existência de um gerador de energia, por exemplo,
conforme descreve a norma ISO/IEC 17799. Assim como outros equipamentos
U
N
importantes dentro do ambiente computacional, o servidor de banco de dados
requer essa proteção. O que se objetiva com isso é a proteção contra furtos, danos
ou comprometimento das atividades da empresa.
Como recomenda a ISO/IEC 17799 e apresentado na figura 4,
precisa-se garantir o suprimento de energia; geradores de energia, para
circunstâncias de falha no suprimento primário; procedimentos para diminuir o risco
de incêndio ou explosões; proteção contra raios; sistema de ar condicionado para
controlar a temperatura no local de armazenamento e, assim, evitar o super
aquecimento do servidor ou acabe afetando no desempenho do equipamento. O
cabeamento dos servidores não deve estar exposto publicamente, de modo que
facilite a interceptação ou dano, estarem devidamente identificados para evitar
manuseio errado e distante dos cabos de energia para evitar interferência.
U
N
IM
IN
A
S
41
Figura 5 – Representação de uma estrutura física de segurança.
(Fonte: GrupoOrion. 2009)
Uma prática comum em empresas de grande porte é a realização de
manutenções nos equipamentos somente por pessoal especializado e com registro
de todas as atividades preventivas ou corretivas realizadas, bem como as falhas.
Isso facilitará no momento de análise de possíveis falhas no futuro.
42
4.1.3 Desastres naturais
Danos a ambientes computacionais originados a partir de causas
naturais estão ligados a falhas na estrutura física onde os equipamentos da
empresa estão alojados. Situações de umidade, inundações, terremotos ou
maremotos são casos que envolvem um planejamento das condições do prédio de
modo a minimizar o impacto desses incidentes ou impedir que a produção da
empresa seja afetada por algum desses eventos.
Essas definições da infra-estrutura física devem ser pensadas antes
mesmo que o ambiente seja preenchido com equipamentos de informática e estes
S
iniciem suas operações. Caso estas não sejam realizadas antecipadamente, a
adequação do ambiente pode se tornar mais onerosa e até afetar o ambiente
A
operacional da empresa devido a necessidade de remanejo ou ajustes.
Em suma a palavra chave para esse problema é planejamento.
IN
Planejar bem antes o que deverá ser feito para evitar futuros transtornos.
IM
4.2 Falhas de segurança nativas
A maioria dos aplicativos, sistemas e ferramentas tecnológicas
desenvolvidas lançadas comercialmente no mercado vem com falhas ou brechas de
U
N
segurança em sua programação, ou seja, “nasceram” juntamente com o software.
Com isso, os aplicativos desenvolvidos irão requerer ajustes no código do software
posteriormente para a correção dessas falhas nativas, oriundas do código original.
E no caso dos sistemas gerenciadores de banco de dados isso não é diferente.
Os desenvolvedores dos softwares, ao tomarem conhecimento dos
problemas
enfrentados
em
seus
aplicativos criam
as correções
devidas
(comumente chamadas de patches) e as disponibilizam para aplicação em seus
softwares. Dependendo do software, as correções são organizadas em pacotes e
disponibilizadas em formato de um único arquivo ao usuário do aplicativo.
Essas falhas do software (também conhecida como bugs) geralmente
tornam-se públicas no momento da divulgação de suas correções e pelos próprios
43
desenvolvedores do aplicativo. É a partir desse momento que o banco de dados
pode se tornar um alvo potencial, pois até que a correção é aplicada ao banco, este
já poderá ter tido sua vulnerabilidade atestada.
O método consiste em utilizar as falhas de segurança divulgadas nos
pacotes de correções para explorar a segurança dos sistemas de banco de dados,
antes que essas correções sejam de conhecimento do usuário e tenham sido
aplicadas no banco de dados; haja vista que agora terá se um método certo que
ocasionará aquele bug corrigido.
Outra situação crítica pode ser o descobrimento de alguma falha no
S
software pelo próprio cracker e, assim, passar a explorar essa vulnerabilidade para
atacar o banco de dados. Um exemplo para essa situação é a falha explorada pela
A
“verme de computador” (do inglês, worm) W32.Slammer (MICROSOFT, 2008), cujo
objetivo era a negação de serviço de determinadas versões do SQL Server 2000.
Esses são pontos de falha sérios e que merecem muita atenção do
IN
administrador de banco de dados. Por isso, o DBA ou responsável pelo banco deve
estar sempre atualizado quanto à divulgação desses patches e o que está envolvido
no pacote de correção, de modo a averiguar se em seu ambiente computacional
IM
necessitará daquela correção. É possível que, em muitos casos, o analista de
sistemas da empresa deva homologar o funcionamento dos sistemas internos à
empresa juntamente ao patch aplicado, de modo que este não altere o fluxo normal
de processamentos dos dados. Caso o sistema opere normalmente ou alguns
U
N
desvios que, porventura, venham a surgir sejam corrigidos, o patch poderá ser
aplicado no banco de dados de produção.
Cada
empresa
desenvolvedora
de
seu
SGBD
possui
uma
nomenclatura própria para denominar essas correções. Por exemplo, a Oracle
chama as atualizações de patches ou patchset; a Microsoft disponibiliza com o
nome de Service Pack ou Hotfix; já no caso de alguns bancos gratuitos e de código
fonte aberto (do inglês, open-source) são disponibilizadas novas versões –
chamadas releases – desses bancos com correções e novas funcionalidades
englobadas.
44
4.3 Métodos de autenticação deficientes
Diversos ataques realizados em bancos de dados e aplicativos de
sistemas computadorizados ocorrem devido à má configuração dos mecanismos de
autenticação. Isso vem desde a utilização de senhas fáceis pelo usuário, como até
uma fraca configuração do método de autenticação no banco de dados. Com isso, o
cracker terá mais facilidade na invasão do sistema, podendo explorar uma série de
possibilidades, dependendo da base de dados em questão.
Esse ponto é muito importante na definição da política de segurança
S
da empresa, pois a porta de entrada mais tendenciosa a exploração de falhas está
no momento de autenticar no serviço desejado. De posse da relação de usuários do
usuário comum do sistema.
A
sistema ou base de dados, o objetivo é obter uma forma para registrar-se como um
IN
Um dos primeiros pontos de falha refere-se à utilização de senhas
frágeis pelo usuário, onde estes poderão ser vítimas de 02 tipos comuns de invasão
buscando descobrir as senhas dos usuários. São eles:
o
Ataque de dicionário
IM
o
Ataque de força bruta
U
N
4.3.1 Ataque de dicionário
Nesse tipo de ataque o invasor tentará, através de ferramentas
próprias, utilizar todas as palavras de um dicionário na busca da palavra utilizada na
senha do usuário. Esse procedimento pode ser demorado e, nem sempre, atingir
seu objetivo. Isso dependerá da quantidade de palavras presentes nesse dicionário
e também da possível utilização de outros dicionários de línguas diferentes, bem
como da possibilidade do usuário ter colocado uma senha de baixa complexidade.
Um segundo método de ataque de dicionário consiste na modificação
da escrita da palavra, de maneira que possa realizar combinações de caracteres
alfanuméricos. Para exemplificação será apresentado variações de uma palavra
comum do dicionário como: elefante.
45
Segue abaixo as modificações:
Palavra modificada com a inserção de caracteres numéricos no lugar
das vogais: 3l3f4nt3
Palavra modificada com primeiro caractere maiúsculo: Elefante
Nenhum desses 02 métodos apresentados é garantia de sucesso por
ataque de dicionário se o usuário adotar uma senha de alta complexidade
envolvendo, além de caracteres alfanuméricos na palavra, mas também caracteres
S
especiais como “@ ? # $ ! % &”.
Devido a isso, a importância de elaborar bem as senhas utilizadas no
A
ambiente como um todo, nos aplicativos do sistema da empresa, sistema
IN
operacional e banco de dados, de modo a coibir a ação desses ataques.
4.3.2 Ataque de força bruta
Segundo o TECH-FAQ (2008) esse ataque consiste em tentar todas
IM
as combinações possíveis de caracteres e números até que a senha seja
encontrada.
Esse método é certeza de êxito, pois algum dia a senha do
determinado usuário será combinada e validada. Porém, é algo que pode levar um
U
N
longo tempo (cerca de muitos anos) dependendo da complexidade da senha, sendo
até totalmente inviável essa espera.
Tanto no ataque de dicionário como no ataque de força bruta, a
tratativa para esse tipo de caso pode ser a mesma. São medidas que aumentarão
bastante o tempo de quebra da senha buscada.
o
Inserir caracteres especiais como “@ ? # $ ! % &” e numéricos na
palavra da senha para aumentar o nível de dificuldade e complexidade. Por
exemplo: L@b0raT04!o$
o
Aumentar o tamanho da palavra de senha de modo que esta fique
com muitos caracteres, pois assim o número de combinações possíveis
também aumentará exponencialmente. Exemplo: Si5t3m@sDe!nf04#a$4O
46
o
Colocar um tempo de espera de alguns segundos entre as novas
tentativas de autenticação. Isso irá aumentar ainda mais o tempo para
quebra da senha por força bruta;
o
Configurar um bloqueio do usuário após n tentativas sem sucesso,
onde “n” deve ser um número menor que 5, preferencialmente.
Com a adoção das medidas acima, as chances de sucesso em um
ataque de força bruta ou mesmo de ataque de dicionário serão mínimas ou
desprezíveis; uma vez que serão senhas de alta complexidade e muito difíceis de
A
S
serem descobertas ou quebradas por algum programa “hacker”.
4.3.3 Autenticações deficientes em bancos de dados
IN
Mesmo com uma senha forte definida para os usuários que acessam o
banco de dados, é necessário observar se a configuração implantada no SGBD é
segura e restringe acessos não autorizados. Devido a isso, algumas análises
devem ser realizadas para assegurar que as bases de dados não estejam expostas
IM
e passíveis a outros métodos de invasão.
Apesar de alguns SGBD’s possuírem características similares quanto
ao método de autenticação, há particularidades de uma em relação à outra. Abaixo
U
N
serão apresentados alguns detalhes de configuração de segurança e mudanças
que devem ser feitas nas bases de dados.
4.3.3.1.Alteração das senhas padrões
Uma falha de segurança que pode ser explorada pelo invasor é a
tentativa de conectar na base de dados utilizando os usuários e senhas padrões,
que não são alterados após a instalação do banco. Geralmente são senhas de
usuários administradores do serviço de banco de dados, ou seja, possuem
autonomia para realizar qualquer tarefa dentro do banco.
Por se tratarem de senhas conhecidas por qualquer pessoa que
administra a base de dados, essas também serão de conhecimento de um invasor.
47
Daí a importância da troca dessas senhas rapidamente para que tal fragilidade não
seja explorada.
No caso do Oracle (METALINK, 2007), por exemplo, é recomendado
que seja feito a alteração das senhas dos usuários sys e system logo após a
instalação do SGBD. Esses são os usuários principais de uma instância Oracle e
possuem privilégios totais de administração do Oracle. As senhas desses usuários
são universalmente conhecidas e divulgadas pela própria Oracle em sua base de
documentação, ou seja, são de domínio público.
Segue abaixo um exemplo de autenticação ao banco de dados Oracle
U
N
IM
IN
A
S
utilizando as senhas padrões dos usuários sys e system.
Figura 6 – Acesso através de senha padrão do usuário System do Oracle.
A figura 6 demonstra a autenticação numa instância Oracle através do
usuário system e de sua senha padrão ‘manager’. Uma vez efetuado esse acesso,
o invasor tem poderes para alterar privilégios, criar novos usuários, apagar registros
ou até mesmo corromper a base de catálogo do Oracle.
Já no Microsoft SQL Server permite que seja feito durante a instalação
do banco a configuração da senha do usuário administrador, chamado “sa”, e até
mesmo do método de autenticação a ser adotado na instância. Porém, isso não
significa que a segurança será totalmente definida nesse instante; ou seja, casos
importantes deverão ser revisados após a instalação.
IN
A
S
48
Figura 7 – Escolha do método de autenticação durante instalação do SQL Server 2008.
IM
A figura 7 ilustra o ponto onde é feito a escolha do processo de
autenticação do SQL Server. Com a escolha da opção mixed-authentication, o
processo de autenticação poderá será feito utilizando usuários do sistema
U
N
operacional ou através de usuários criados na área de logins do SQL Server.
Na versão Microsoft SQL Server 2005, há opção para utilizar as
políticas de segurança do Windows e, assim, forçar a definição de uma senha mais
complexa, conforme figura 8. Tal medida visa ajudar o administrador na criação de
senhas mais bem elaboradas e que possibilitem maior segurança ao acessar o
banco.
A
S
49
IN
Figura 8 – Usuário administrador do banco com opção para forçar política de senha do
Windows ativada.
Em geral, a senha desse usuário deve ser de conhecimento exclusivo
do DBA ou do responsável pelo ambiente banco de dados. A mesma deve ser uma
IM
“senha forte” (extensa, com caracteres alfanuméricos e especiais), conforme citado
no tópico 4.3.2 desse capítulo.
Já com a opção Windows authentication, o usuário “sa” estará
desabilitado dentro do SQL Server. Nesse caso, a situação da figura 4.4 não será
U
N
apresentada.
Mesmo com a definição do método de autenticação misto (SQL Server
e Windows), ao término da instalação haverá um login, do tipo Windows Group,
denominado “BUILTIN\Administradores” criado no SQL Server. Deve-se analisar a
necessidade de acesso desse login no banco de dados; uma vez que, qualquer
usuário do sistema operacional e que faça parte do grupo de administradores do
servidor terá acesso e privilégio administrativo dentro da base de dados.
Inclusive, segundo nota de segurança do Centro de Orientações de
Segurança Microsoft (MICROSOFT, 2004), é recomendado a remoção do login
“BUILTIN\Administradores” do SQL Server e a configuração manual de cada
usuário do sistema operacional no banco específico ao qual necessite de acesso.
50
4.4 Vulnerabilidades de configuração
Em bases de dados já implantadas é importante estar atento a
detalhes na configuração do ambiente que podem esconder brechas de segurança
do ambiente banco de dados. Algumas dessas brechas são de amplo conhecimento
público, mas pode acabar passando despercebido no dia-a-dia e deixar os dados da
empresa expostos ou passíveis de danos.
Com isso, faz-se necessário a observação de alguns pontos
importantes na manutenção da segurança do SGBD. Geralmente são casos ligados
S
a existência de configurações padrões que não são alteradas pelo DBA, por
exemplo, a existência de usuários e senhas padrões da ferramenta de banco de
A
dados, excesso de privilégios dos usuários do SGBD, serviços desnecessários
habilitados no servidor, acesso fácil de usuários do sistema operacional aos
arquivos físicos do banco, dentre outros. Cada ferramenta de banco possui uma
IN
exigência própria a ser cumprida para maior proteção das informações
armazenadas nas bases de dados.
Na seqüência, serão discutidos alguns desses ajustes na configuração
IM
padrão do banco que são importantes para a segurança do banco.
4.4.1 Remoção de usuários e bancos de exemplo
U
N
Geralmente, após a instalação da ferramenta de banco de dados
pode-se notar a existência de bases e usuários já criados dentro do SGBD. Esses
são conhecidos como banco de dados e usuários de exemplo e destinam-se a
utilização do usuário na realização de testes e outros afins. Apesar de sua utilidade
inicial, os próprios fabricantes recomendam que esses bancos e usuários sejam
removidos do SGBD, assim que o servidor for destinado as suas atividades
operacionais.
Tal medida visa restringir as possibilidades de acesso ao ambiente de
banco de dados através de usuários, senhas e bancos de domínio público, uma vez
que a estrutura desses bancos e a senha dos usuários estão descritos na
documentação do fabricante. No Oracle, por exemplo, há o usuário SCOTT cuja
51
senha é TIGER. Esse usuário possui em seu esquema de banco de dados algumas
tabelas utilizadas basicamente para testes e apresentação do SGBD. A própria
Oracle (METALINK, op. cit.) recomenda que esse usuário seja bloqueado ou tenha
sua senha alterada, de modo que não se obtenha acesso a instância Oracle com a
senha padrão.
Há também outros usuários e senhas padrões como, por exemplo, o
usuário RMAN (proprietário do catálogo de backup via aplicativo RMAN) e o usuário
DBSNMP (utilizado pelo produto Enterprise Manager Intelligent Agent) que podem
ser encontrados numa instância Oracle, dependendo das funcionalidades adicionais
S
que forem instaladas. Para muitos desses usuários é recomendado a troca da
senha imediatamente após a sua instalação. No portal da Oracle (METALINK, 2008)
há a relação de todos os usuários criados e as ações que podem ser executadas
A
para remoção, troca ou bloqueio desses usuários.
Já no SQL Server, pode-se escolher durante a instalação que seja
IN
criada os bancos de exemplo, também conhecidos como sample databases além da
conta do usuário convidado, também conhecido como “guest”. Na versão SQL
Server 2000, esses bancos criados são o Northwind e Pubs; agora na versão 2005,
IM
os bancos criados são o AdventureWorks e AdventureWorksDW.
4.4.1.1.Excesso de privilégios de usuários
U
N
A facilidade com que um usuário qualquer do banco consiga visualizar
ou alterar uma informação pode estar ligada a concessão de privilégios excessivos
para usuários comuns, seja da aplicação ou de pessoas não ligadas ao ambiente de
TI da empresa.
Dependendo de como o aplicativo foi desenvolvido para acesso ao
banco, pode requerer a utilização de somente um login específico no SGBD e que
necessitará de privilégios totais em todos os bancos do ambiente. Bem como,
também pode haver diversos logins necessários para o aplicativo funcionar, porém
com privilégios até em bases de dados ao qual não trabalhará. Nas figuras 9 e 10
abaixo, há dois esquemas que retratam esses casos citados.
IN
A
S
52
Figura 9 – Usuário único de todos os departamentos para acesso à base de dados.
IM
No primeiro esquema, observa-se que há um único login utilizado pelo
aplicativo para acessar toda a base de dados da empresa. O sistema da empresa
depende exclusivamente desse login e corre-se o risco de sua senha ser
compartilhada com diversas pessoas. Daí a segurança das informações entre os
U
N
departamentos estará comprometida, pois dados sigilosos estarão ao alcance de
todos.
A
S
53
IN
Figura 10 – Usuários distintos para cada departamento acessar o banco de dados.
Já no segundo esquema, existem logins distintos para cada módulo do
IM
aplicativo, porém não há uma restrição de acesso ao banco como um todo que
impeça o usuário de visualizar dados alheios a sua designação.
Nesses casos, é importante analisar juntamente com os analistas do
sistema quais são os verdadeiros privilégios que cada login necessita, de modo que
U
N
um módulo do sistema não consiga afetar ou visualizar os dados do outro módulo.
Após esse levantamento pode-se buscar a melhor forma para realizar a segregação
do acesso às bases de dados de modo que não seja prejudicial a regra de negócio
da empresa. Uma dessas formas seria a criação de roles no banco para agrupar
logins com privilégios em comum para tabelas específicas.
Com isso, o departamento de produção da empresa (a fábrica, na
figura 10) não terá acesso às informações do departamento financeiro e vice-versa.
Tal medida será uma barreira lógica dentro do banco de dados e contribuirá
bastante para a segurança do ambiente.
54
4.4.1.2.Serviços desnecessários no servidor
Quando um equipamento é destinado para uma finalidade única, seja
para servidor web, servidor de aplicação ou de banco de dados, a sua configuração
deve ser toda montada para atender àquelas necessidades somente. Ou seja, a
habilitação de serviços que não fazem parte do proposto ao equipamento devem
ser desativados ou não habilitados.
Para um servidor totalmente dedicado para hospedagem de banco de
dados é importante a desativação de serviços como, FTP, TELNET, SMTP, por
exemplo. Até mesmo serviços próprios do SGBD instalados durante a instalação do
posteriormente, então devem ser desativados.
S
software devem ser revistos, uma vez que, se deixar de serem utilizados
A
Tais medidas visam diminuir as possibilidades de algum ataque ao
servidor explorando alguma deficiência que estes produtos possuam e que ainda
IN
não foram corrigidos pelo fabricante.
4.4.1.3.Contas de usuários do sistema operacional
IM
Uma preocupação não somente para um servidor de banco de dados,
mas também para qualquer outra destinação do equipamento refere-se ao controle
das contas de usuários do sistema operacional instalado.
U
N
Tanto em ambientes Unix, Linux ou Windows, a preocupação é a
mesma e precisa ser avaliada com atenção pelo analista de segurança e de
sistemas operacionais. Pois, uma má configuração da conta de usuário pode
conceder privilégios de acesso no SGBD ou aos arquivos armazenados no disco.
No próprio processo de instalação do banco Oracle (ORACLE, 2008)
nos ambientes Unix e Linux é exigido uma pré-configuração da conta do usuário
Oracle sobre a qual será feita a instalação e a operação do banco, visto que o
banco trabalhará somente com aquele usuário. Assim, logo após a instalação
correta do SGBD, esse usuário criado terá privilégios de acesso as pastas da
instalação do software e aos repositórios dos datafiles, control files e redo logs.
A figura 11 ilustra a situação descrita.
55
Figura 11 – Exemplo de configuração de usuário Oracle para instalação e utilização do
SGBD Oracle9i em sistemas operacionais Unix.
S
É importante que, além do usuário Oracle, somente o root tenha
acesso concedido a estrutura de diretórios e arquivos do Oracle. Todos os demais
A
usuários que possuírem esse tipo de acesso deverão ser revistos e seus privilégios
removidos, pois corre-se o risco de algum desses arquivos ou diretórios serem
danificados ou removidos acidentalmente ou intencionalmente.
IN
Já no caso do SQL Server os pontos a serem observados referem-se
a configuração dos logins e grupos que podem estar com privilégios totais no
banco. Tal fato é originado após a instalação do SGBD, onde um grupo do Windows
IM
chamado BUILTIN\Administradores é criado com direitos administrativos no banco,
conforme observa-se na figura 12. Esse grupo do Windows referencia o grupo
“Administradores” do servidor local ou do Active Directory, ilustrado na figura 13.
Com isso, qualquer usuário que faça parte desse grupo no sistema operacional do
U
N
servidor terá então permissões administrativas no SQL Server, podendo operar
qualquer ação no banco.
Figura 12 – Privilégio padrão do grupo BUILTIN\Administradores no SQL Server.
IN
A
S
56
IM
Figura 13 – Grupo “Administradores” do sistema operacional e os respectivos membros
desse grupo.
A Microsoft, através do Centro de Orientações de Segurança
(MICROSOFT, 2006) recomenda a remoção do grupo BUILTIN\Administradores do
U
N
grupo de logins do SQL Server; isso claro, com a concessão de privilégios
administrativos (System Administrator, como é conhecido no SQL Server) a outro
usuário do sistema operacional ou a utilização do usuário “sa” para administração
do banco.
Na figura 14 observa-se o momento de exclusão desse grupo dos
logins do SQL Server.
IM
IN
A
S
57
U
N
Figura 14 – Demonstração de remoção do grupo BUILTIN\Administradores.
4.4.1.4.Portas desnecessárias abertas no servidor
Assim como na configuração somente dos serviços que deverão ser
executados num servidor, também deve-se buscar o mesmo cuidado na restrição
das portas habilitadas desnecessariamente no servidor de banco de dados.
Cada SGBD possui a sua porta padrão na qual responde as
solicitações geradas pela aplicação ou pelas ferramentas cliente instaladas em
outros equipamentos da rede. Nada impede que essa porta seja alterada por outra,
porém o problema reside na existência de outras portas no servidor e das quais o
banco não utiliza e nenhum outro aplicativo do cliente requisite. Um cracker pode vir
a buscar alguma porta aberta no servidor para tentar um ataque, seja de negação
58
de serviço ou corrupção lógica do equipamento.
Diante disso, é importante que essas portas sejam bloqueadas no
sistema operacional ou, em nível maior, no firewall da rede, sendo responsável pelo
barramento de ataques que busquem uma determinada porta de algum serviço
aberta.
4.5 Vulnerabilidades de aplicativos
S
Algumas vezes, configura-se um ambiente de banco de dados
atendendo a todos os requisitos de segurança possíveis: restringe-se acesso direto
A
ao servidor do banco; retira-se privilégios administrativos dos servidores; bloqueiase portas desnecessárias; elimina-se contas inativas de usuários; mas o código da
aplicação destinado a utilização do banco não está devidamente configurado para
IN
se evitar um ataque de injeção de SQL.
Conforme descrito no item 3.3 do capítulo 3, os ataques de injeção de
SQL ocorrem comumente devido à falta de validações de entrada em aplicativos e,
IM
também, usuários dessas aplicações com altos privilégios dentro do banco. Para
isso, algumas ações devem ser tomadas para tratar essas vulnerabilidades e
garantir um código mais seguro e confiável contra esse tipo de ataque.
U
N
Por ser uma falha que explora fragilidades geradas pelo código feito
pelo programador, as ações de tratativa desse ataque são, em sua maioria, tratadas
dentro do próprio código. Só que alterações na estrutura de objetos da base de
dados em questão e, possivelmente, em sua regra de negócio também deverão ser
necessárias para alinhamento com a reescrita do código. Isso diz respeito a adoção
de stored procedures ao invés de se utilizar a instrução SQL toda no código da
aplicação e também uma melhor adaptação dos privilégios de cada usuário na
base.
Cada linguagem de programação apresenta uma forma de barrar
ataques de injeção de SQL e também algumas características em comum. São
elas:
o
Utilização de stored procedures com parâmetros, como método de
59
proteger o código do site e facilitar na definição dos privilégios de execução
no banco;
Evitar caracteres como aspas ( ‘ ‘ ), traços horizontais ( - - ) e ponto-e-
o
vírgula ( ; ), bem como palavras para manipulação de dados (INSERT,
UPDATE, DELETE);
Restrição dos privilégios do usuário que executa a aplicação web, de
o
modo que esse possua privilégios específicos nos objetos que vai manipular;
Fazer tratativa dos erros da aplicação para que não detalhe a
o
estrutura do banco de dados nas mensagens de erro, facilitando a coleta de
A
S
informações para formar um ataque mais bem preciso e perigoso.
4.5.1 Tratativas de segurança em PHP
IN
O próprio manual de segurança do PHP (PHPNET, 2009) já lista
métodos de validação e também algumas funcionalidades nativas da linguagem
para tratativa contra injeção de SQL.
Uma das principais medidas contra esse problema é a validação dos
IM
campos de entrada postados nos aplicativos web. Nesse caso, o desenvolvedor
deve validar cada campo de entrada no aplicativo web, tratando os registros de
entrada dos quais a aplicação precisa. Segue exemplo na figura 15 abaixo:
U
N
<?php
$query = "SELECT id, nome FROM produtos WHERE tamanho = ‘$size’;";
$result = odbc_exec ($conn, $query);
?>
Figura 15 – Exemplo de código escrito em PHP.
Na instrução acima, deve-se validar o tipo de dados esperado e o
tamanho máximo de caracteres para a variável $size. O PHP fornece funções
específicas para validações de tipos de variáveis.
Uma possível correção para o caso acima seria a inclusão da
60
instrução settype para configurar o tipo da variável $size, conforme figura 16 abaixo:
settype($size, 'integer');
Figura 16 – Função PHP para validação de tipos de variáveis.
Ou também a utilização de funções nativas, conforme figura 17:
// O parâmetro %d da função sprintf() define caracter do tipo INTEGER.
$query = sprintf("SELECT id, nome FROM produtos WHERE tamanho = %d ;",
$size);
S
Figura 17 – Função PHP para validação de variáveis numéricas.
A
Caso o tipo de entrada esperada para a opção $size fosse um texto, o
parâmetro seria alterado para %s, e assim sucessivamente com as demais opções.
IN
A função sprintf é bem interessante no quesito de validação de entradas numéricas
em variáveis e trata muitas possibilidades de fraude na instrução SQL.
IM
4.5.1.1.Tratativas de segurança em ASP.NET
Times de especialistas da Microsoft desenvolveram soluções e
divulgaram-nas para tratar vulnerabilidade de aplicativos. Segundo uma nota oficial
registrada pela Microsoft (MSDN, 2005), para validação de entradas de dados em
U
N
páginas web existem determinadas funções, como a RegularExpressionValidator,
que servem para atestar o tipo de dado recebido do campo de entrada da aplicação;
de modo a testar o conteúdo da variável de entrada antes mesmo de sua execução
na base de dados.
Segue abaixo, na figura 18, um exemplo desse caso citado acima,
utilizando essa função do ASP.NET:
61
Figura 18 – Exemplo de código ASP utilizando RegularExpressionValidator. (Fonte: MSDN.
2005)
Outro ponto onde a segurança da aplicação deve tratar bem é a
utilização de stored procedures dentro do próprio código tendo, obrigatoriamente,
parâmetros para serem repassados a essa procedure. Isso porque a sua utilização
sem o envio de um parâmetro de execução não impedirá que uma instrução
maliciosa não seja executada, caso não haja uma boa validação de entrada.
Nesse caso, recomenda-se que o código do procedimento também
não possua instruções que requerem privilégios altos de execução ou mesmo
instruções que permitam execução direta de qualquer parâmetro recebido,
S
conforme exemplificado abaixo. Pois, num ataque de injeção de SQL que consiga
malicioso se tornam maiores.
A
chegar até o código do procedimento, as chances de execução direta do código
A figura 19 ilustra uma stored procedure com código vulnerável:
@comando ntext
AS
IN
CREATE PROCEDURE dbo.ExecutaSQL
GO
IM
exec sp_executesql @comando
U
N
Figura 19 – Exemplo de procedimento com codificação vulnerável.
Mesmo com a não possibilidade de utilização de stored procedures
para melhor controle da segurança do código, ainda pode-se fazer validações das
instruções SQL que recebem parâmetros de entrada através de funções como a
SQLParameterCollection.
A figura 20 ilustra essa situação:
62
S
Figura 20 – Validação de SQL dinâmico através de SQLParameterCollection. (Fonte: MSDN.
2005)
Observa-se no exemplo acima que a variável @au_id é testada tanto
A
pelo seu tipo de dado recebido quanto pelo tamanho máximo esperado (nesse caso
IN
um texto de, no máximo, 11 caracteres).
IM
4.6 Importância do backup
Nas situações onde um desastre foi inevitável; a segurança do banco
de dados foi comprometida; dados foram danificados ou destruídos, torna-se
fundamental a necessidade do backup para a restauração das informações
U
N
perdidas.
A implantação de uma boa política de backup adequada à regra de
negócio da empresa garantirá a recuperação desses dados perdidos sem causar
grande impacto financeiro à empresa. Impacto esse que seria medido através do
volume de informações que seriam perdidas caso não houvesse como recuperá-los,
podendo afetar diretamente a perenidade da empresa.
Diante disso, é fundamental que a política de backup do banco de
dados esteja bem alinhada as necessidades da empresa. Deve-se configurá-la para
atender as necessidades de um restore point-in-time (restauração de dados até
momentos antes do incidente ocorrido) de ambientes críticos e cujos dados são
bastante atualizados; até a execução de somente um backup diário para aquelas
63
bases que sofrem pouca modificação.
Para bom entendimento do que será proposto na seqüência, faz-se
necessário explanar sobre alguns conceitos sobre tipos de backups.
o
Backup full (completo): cópia integral do banco de dados com todos os
seus objetos e dados atualizados ou não atualizados.
o
Backup diferencial: cópia somente daquilo que foi alterado após o
último backup full. Depende desse último backup completo para que seja
utilizado e o banco restaurado, visto que servirá somente de ligação entre o
o
S
backup full e a data de sua execução.
Backup transacional ou archivelog: cópia somente do que está
armazenado dentro do arquivo de log do banco e que foi gerado por alguma
A
transação normal deste. No Oracle o arquivo de backup de log é denominado
archivelog, sendo gerado durante descarga do segmento de undo do banco.
IN
Já no SQL Server é denominado transaction log e é gerado conforme
agendamento feito pelo DBA no plano de manutenção do banco. Em ambos
os SGBDs, deve-se configurar a base de dados para possibilitar a geração
IM
desses backups.
Como estratégias de backup devem ser elaboradas pensando no
negócio, alguns quesitos devem ser observados como:
O que necessita de backup diário e o que não requer?
U
N
Quais são os objetos críticos do banco?
Qual o volume de dados que será feito backup diariamente?
Qual a retenção adequada para esse backup gerado?
Em caso de desastre, o tempo de restauração atende as
necessidades?
Geralmente, nem todas as tabelas de um banco de dados sofrem
alteração diariamente. Por exemplo, em um banco de dados há tabelas onde se
concentram informações financeiras, contábeis, estoque de produtos, ou seja,
64
tabelas que são constantemente alteradas; mas também há tabelas de cadastro de
fornecedores, cadastro de funcionários, códigos fiscais, departamentos da empresa,
ou seja, tabelas que pouco ou raramente sofrem alterações e cujo impacto na perda
de informações seja mínimo. Com isso, a adoção de backup diário de tabelas pouco
atualizadas torna-se desnecessário, além de consumir mais recursos – espaço em
disco, fitas de backup ou qualquer outra mídia similar – para o armazenamento
dessas informações. Nesse caso, a implementação de backup semanal ou
quinzenal já atenderia a esses requisitos.
Em situação contrária a apresentada acima estão as tabelas de
S
registros de fluxo de caixa, estoque de produtos e que atendem ao processo
financeiro da empresa. Em geral, são tabelas que sofrem constantes inserções e
alterações de dados, no qual não somente um backup diário, mas também backups
A
transacionais, que são gerados em intervalos de tempo menores e úteis no
atendimento a restaurações point-in-time. Assim, em caso de perda de dados
evento ocorrido.
IN
durante o dia é possível a restauração dos dados perdidos até momentos antes do
Como pode ocorrer da modelagem da base de dados não possibilitar
IM
essa separação tão explicitamente, então caberá ao DBA definir uma política de
backup igual para todos os objetos do banco. No entanto, a mesma regra definida
para um conjunto de tabelas também pode ser aplicada ao banco todo, por
exemplo, programar apenas 01 (um) backup diário para alguns bancos como
U
N
também backup diário e backups transacionais para outros.
Dependendo do volume de dados de uma base pode ser
desinteressante que toda a massa de dados seja copiada diariamente. Isso porque
poderá demandar mais recursos disponíveis para o armazenamento daquele
backup gerado como, por exemplo, espaço em disco ou maior número de fitas de
backup. Nessas situações, a adoção de backups incrementais é uma alternativa
extremamente viável, pois possibilitará a geração de arquivos menores e que
demandarão menos recursos. No entanto, tal medida deve estar bem alinhada ao
backup full do banco, pois é uma estratégia complementar deste e não substitutiva.
O período de retenção dos arquivos de backup gravados em fita ou
mídias de backup também dependerá do conteúdo dos dados copiados. Por
exemplo, dados de instituições financeiras possuem prazos legais de validade, ou
65
seja, não poderão ser destruídos até seu vencimento legal. Por isso, deve-se avaliar
criteriosamente o tempo de retenção desses backups de acordo com as
necessidades do negócio da empresa.
Segue abaixo alguns cenários e suas políticas de backup propostas
para cada situação. Lembrando que trata-se de propostas e não regras definitivas
para serem implantadas:
Cenário 1:
A
hospital e suas respectivas especialidades.
S
Banco de dados destinado ao armazenamento da listagem de médicos de um
Proposta:
IN
Nesse caso, como a lista de médicos tende a sofrer mudanças mínimas no decorrer
do dia, então um backup full diário desse banco atenderá a necessidade. O período
U
N
IM
de retenção pode ser apenas mensal. A figura 21 representa essa configuração.
Figura 21 – Representação de uma política de backup full diário.
66
Cenário 2:
Banco de dados destinado ao controle de estoque de uma loja revendedora de
peças automotivas.
Proposta:
Nesse caso, como o fluxo de entrada e saída do estoque tende a ser alto, então é
importante a utilização de um backup full diário e backups transacionais no decorrer
S
do dia para possibilitar a restauração de dados até momentos antes de um
desastre, minimizando a possibilidade de diferenças no estoque de peças da loja. O
A
período de retenção também pode ser mensal, tanto para o backup full quanto para
U
N
IM
IN
o backup transacional. Segue, na figura 22, a ilustração da proposta desse cenário.
Figura 22 – Representação de uma política de backup diária, com 01 backup full (completo)
e backups transacionais no decorrer do dia.
Cenário 3:
Banco de dados de uma instituição financeira, onde são armazenadas todas as
transações bancárias do dia como saques, depósitos, transferências, pagamentos,
bem como histórico da movimentação da conta de cada cliente. Bases de dados de
grande porte com elevado volume de dados e muita movimentação diária.
67
Proposta:
Caso crítico, onde é importante não somente pensar na geração dos backups
diários como também nos recursos demandados para o armazenamento dos
backups. Nesse cenário, pode-se adotar backup full uma ou duas vezes na semana,
intercalado com backups incrementais nos demais dias, e adicionado a backups
transacionais no decorrer de cada dia. A retenção nesse caso deverá ser superior a
30 dias, pois se trata de transações financeiras e que requerem maior tempo de
IM
IN
A
S
armazenamento. A ilustração da figura 23 abaixo representa essa proposta.
Figura 23 – Representação de uma política de backup com 02 backups full na semana,
intercalados com backups diferenciais nos demais dias e backups transacionais no decorrer
de cada dia.
U
N
O plano de backup deve ser adequado também ao tempo desejado
para a recuperação das informações, pois a demora no restabelecimento dos dados
perdidos poderá causar perdas ao negócio da empresa impedindo a concretização
de novas oportunidades. Esse tempo desejado é definido baseando-se na
criticidade do banco e dos objetos afetados e o quanto a empresa suporta sem o
ambiente operacional.
Portanto, a política de backup deve ser planejada observando as
características de cada banco, os recursos disponíveis para armazenamento e o
tempo desejado para recuperação de um desastre, visando o menor impacto direto
nas operações da empresa.
68
4.7 Monitoramento do banco
Segundo Pichiliani (2008), o monitoramento do banco de dados é uma
das principais responsabilidades no dia-a-dia de trabalho do DBA, pois envolve
administração, manutenção e melhoria do ambiente.
O monitoramento de um banco de dados não se resume apenas na
monitoria do SGBD em si, mas também do servidor como um todo. Isso deve-se a
S
interação entre diversos aplicativos e as bases de dados que são utilizadas por
eles. Monitorar o ambiente de banco de dados engloba observar o espaço em disco
A
ocupado por este banco, os recursos físicos e lógicos do servidor, os serviços que
executam nele e são importantes para o funcionamento do banco, bem como
algumas ações realizadas dentro da base de dados.
IN
No mercado e também na internet há diversas ferramentas de
monitoramento disponíveis, sejam elas comerciais – Smart da empresa HP, SCOM
(System Center Operation Manager) da Microsoft e o Spotlight da empresa Quest –
IM
ou as ferramentas comumente conhecidas e gratuitas Nagios e JFF.
Deve-se habilitar a monitoria dos serviços principais do SGBD, de
modo que capturem alguma indisponibilidade da base de dados. Juntamente com
os serviços do banco é necessário o monitoramento do espaço em disco destinado
U
N
ao armazenamento das bases de dados e seus arquivos de controle, muito comuns
no Oracle (comumente conhecidos como control files). No caso dos discos do
servidor, primeiramente é importante a definição dos limites para o alarme de área
(também conhecidos como thresholds), de modo que possa haver uma intervenção
no ambiente para tratar o problema antes que o disco sofra estouro de área. Com
isso, definem-se os limites para os alarmes críticos e os alarmes de alerta, sendo
este último evento presente somente em alguns sistemas de monitoramento.
Ambos os aplicativos de monitoramento possuem suas características
próprias de coleta e apresentação dos dados coletados, ficando a critério do DBA a
escolha daquele aplicativo que melhor atender as suas necessidades atuais.
Já na camada de banco de dados também há funcionalidades nativas
69
de cada SGBD para monitoria de eventos que o DBA considerar importante ter o
seu conhecimento e controle. Nesse caso, se destacam as triggers e as
ferramentas de trace no suporte a essas necessidades. O SQL Server 2005, por
exemplo, possui as DDL Triggers (DYE, 2008), que são executadas no banco antes
ou depois de um evento de alteração de objetos da base de dados como CREATE
ou ALTER. Esse tipo de monitoramento pode ser interessante para controlar ou
registrar a criação de objetos na base por pessoas não autorizadas, deixando um
histórico de todas as ocorrências desse tipo registradas, inclusive.
Eventos à nível do banco de dados ou à nível de servidor que podem
S
acionar essas DDL Triggers, cada um com um grupo de comandos específicos. De
posse desses eventos, uma série de combinações de regras de monitoramento
A
pode ser criada, sendo útil para diversas ações que se deseje auditar no ambiente.
Os eventos na camada de banco de dados que podem ser auditados são:
Eventos DDL para tabelas : Create table, Alter table, Drop table
Eventos DDL para visões: Create view, Alter view, Drop view
Eventos DDL para triggers:Create trigger, Drop trigger, Alter trigger
Eventos DDL para sinônimos: Create synonym, drop synonym
Eventos DDL para índices: Create index, Alter index, Drop Index
Eventos DDL para implementar segurança no banco:
o Create User, Drop user, Alter user
o Create role, Drop role, Alter role
o Create application role, Drop application role, Alter Application role
o Create Schema, Drop Schema, Alter Schema
o Grant database access, Revoke database access, Deny Database
access
7. Eventos DDL para Service broker:
o Create Message type, Alter Message type, Drop Message type
o Create contract, Drop contract, Alter contract
o Create Service, Alter service, Drop Service
o Create route, Drop route, Alter route
U
N
IM
IN
1.
2.
3.
4.
5.
6.
Já os eventos na camada do servidor que podem ser auditados são:
1. Create Database, Drop Database
2. Create Login, Drop Login, Alter Login
70
4.8 Auditoria no banco de dados
Como última das atividades de configuração do servidor de banco de
dados é importante a habilitação de auditoria no SGBD. Essa auditoria tem como
finalidade registrar eventos gerados pelo SGBD para que ajudem na identificação
de invasores ou diagnosticar alarmes, sendo de grande utilidade para a segurança
do banco.
S
O objetivo da auditoria não é impedir que eventos de segurança
aconteçam, mas sim deixá-los registrados para que sejam passíveis de análises
A
futuras. Desse modo, será feito as tratativas devidas para impedir que tal evento
ocorra novamente e venha a comprometer o ambiente de banco de dados.
Cada SGBD possui suas formas de auditoria e diversas possibilidades
IN
de auditoria para serem implantadas. Obviamente, muitas dessas são para casos
específicos e dependerão bastante da criticidade da base de dados e do nível de
sigilo das informações inseridas. Também deve ser considerado a questão da área
IM
disponível ou banco de armazenamento dos dados auditados, uma vez que
acabarão demandando espaço para serem gravados.
Numa auditoria básica, é interessante registrar os eventos de falha de
autenticação no banco de dados, para casos de ataque de injeção de SQL (em
U
N
bases com informações sigilosas é viável o registro de todas as autenticações
realizadas); alterações de objetos do banco, também visando controlar intervenções
em ambientes de maior criticidade; até a concessão de privilégios a usuários do
banco de dados. A auditoria pode ser customizada através da criação de triggers ou
uso das opções nativas do SGBD em questão.
No Oracle (METALINK, 2009), para se habilitar auditoria deve-se
iniciar o banco de dados com a opção AUDIT_TRAIL habilitada. De acordo com o
modo de auditoria habilitada, pode-se apontar um local de armazenamento dos
arquivos através do parâmetro AUDIT_FILE_DEST ou então o registro dos dados
na tabela SYS.AUD$ do tablespace SYSTEM. Em caso de sistema operacional
Windows, os dados auditados podem ser registrados no Visualizador de Eventos.
71
Daí em diante, apenas escolhe-se quais os eventos do Oracle que serão auditados
dentre toda a variedade disponibilizada pelo SGBD.
O SQL Server possui em sua console de gerenciamento a opção de
habilitar o registro das autenticações feitas no SGBD. A figura 24 ilustra uma
IM
IN
A
S
auditoria habilitada para armazenar todas as autenticações que apresentaram falha.
U
N
Figura 24 – Tela de propriedades do SQL Server apresentando a opção de “Failure”
marcada no AUDIT LEVEL.
Também pode ser habilitada auditoria através do uso de triggers (SQL
Magazine, 2008). Inclusive, o uso desse objeto do banco permite uma variedade
maior de opções para registro de alterações em objetos, inserção ou remoção de
dados de alguma tabela, dentre outros eventos.
72
5 CONCLUSÃO
Com a valorização cada vez maior da informação dentro das
organizações, o banco de dados torna-se uma ferramenta essencial para a
sobrevivência das empresas, onde os dados ali armazenados podem conter o seu
diferencial perante a concorrência.
realizadas
pela
McAfee
e
Datamonitor
S
Pesquisas
(COMPUTERWORLD, 2007), destacadas no capítulo 2 (página 18), apontaram que
muitas empresas têm sofrido ataques ao seu ambiente computacional e que
A
acarretaram em prejuízos e grandes transtornos. Baseado nisso, a segurança do
ambiente banco de dados deve estar bem aprimorada, de modo que perdas,
IN
corrupção ou roubo de informações não venham a afetar a perenidade da empresa.
A forma de como essa segurança será implantada poderá impedir que situações de
desastre não possam ser contornadas ou, até mesmo, que venham a ocorrer.
IM
Esse trabalho reuniu boas práticas de segurança física e lógica e
dicas importantes de segurança, amplamente divulgadas por especialistas de TI em
sites e fóruns de segurança, bem como também por grandes fabricantes de
softwares como Microsoft e Oracle. Como muitas dessas informações encontram-se
U
N
desagrupadas de outros assuntos de segurança para banco de dados, tanto em
livros quanto em artigos publicados na internet, não se obtêm uma visão mais
ampla de até que ponto deve-se analisar a vulnerabilidade dos dados dentro de
uma empresa. Este trabalho contribuiu para o agrupamento dessas instruções e
possibilita ao analista de segurança e ao DBA, responsável pelas bases de dados
da empresa, confeccionar uma política de segurança mais bem aprimorada e
confiável, do que se estivessem trabalhando separados.
Conforme apresentado neste trabalho, a norma ABNT NBR ISO/IEC
17799:2005 implica que o trabalho do DBA na definição da segurança das
informações tem que estar bem alinhado com o trabalho do analista de segurança.
Ou seja, muitas das definições de segurança que forem implantadas nos servidores
de banco e no próprio banco precisam ser documentadas na política de segurança
73
da empresa; por exemplo, questões relacionadas às medidas de segurança para
acesso lógico de usuários e fornecedores no ambiente computacional da empresa.
Observou-se que, tão importante quanto aplicação de segurança à
nível físico, a adoção de medidas de proteção na camada lógica é fundamental na
proteção das informações dentro de uma base de dados. Para isso, o conhecimento
das ameaças a que estaria exposto um ambiente de banco de dados servirá como
base na construção da segurança física e lógica correta. Dessa forma, consegue-se
proteger adequadamente o ambiente de banco de dados de deficiências de
segurança como: fragilidades de senhas; espionagem na rede através da captura
S
de tráfego não criptografado; serviços e portas abertas desnecessariamente;
ataques de injeção de SQL, que exploram vulnerabilidades de códigos de
aplicações; a falta de atualização dos softwares de banco de dados, que podem
fabricantes; dentre outros.
A
expor o banco de dados a ataques por meios conhecidos e divulgados pelos
IN
Com a implantação das medidas e procedimentos de segurança para
bancos de dados nas camadas físicas e lógicas, descritas no decorrer do capítulo 4,
garante-se que o ambiente de banco de dados estará mais confiável e bem
IM
protegido de ações maliciosas. Nota-se que uma ação de correção isolada não
protege totalmente as informações da base, pois muitas são as alternativas que
abrangem uma segurança bem estruturada.
Por isso, no capítulo 4 estão descritas ações na camada física que
U
N
abrangem desde restrições de acessos físicos ao servidor de banco de dados à
proteção das instalações com redundância de recursos energéticos (figura 4, página
41), dentre outros. Na camada lógica, destacam-se métricas para a definição de
senhas seguras nas bases de dados; a importância das atualizações do SGBD;
dicas para tratativas de códigos de aplicações para impedir ataques de injeção de
SQL; a adoção de uma política de backup adequada para resguardar recuperações
de dados danificados ou perdidos; dentre outras ações que restringem e protegem o
SGBD como um todo.
5.1 Propostas de trabalhos futuros
74
Por se tratar de um trabalho voltado a segurança do ambiente de
banco de dados como um todo e por este ser muito amplo, alguns assuntos
descritos nesse documento não puderam ser aprofundados e trabalhados com alto
nível de detalhamento. Além disso, outros aspectos que abrangem segurança física
ou lógica podem surgir com a evolução dos SGBD’s pelos fabricantes.
De forma a acrescentar mais informações nesse assunto, sugere-se
uma abordagem aprofundada sobre métodos de proteção contra espionagem na
rede das empresas, maiores detalhes à nível de código de aplicações como forma
de impedir ataques de injeção de SQL e também medidas de segurança contra
U
N
IM
IN
A
S
desastres naturais ocasionados pela ação do meio ambiente.
75
REFERÊNCIAS BIBLIOGRÁFICAS
ASSOCIACAO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 17799:2005 –
Tecnologia da informação – Técnicas de segurança – Código de prática para a gestão da segurança
da informação. Rio de Janeiro: ABNT, 2005.
S
COMPUTERWORLD. A perda de dados levará ao próximo grande colapso nas empresas? 2007.
Disponível em: <http://computerworld.uol.com.br/seguranca/2007/07/20/idglead.2007-0720.1196669103>. Acesso em: 24 out 2007.
A
DATE, C.J. Introdução a Sistemas de Banco de Dados. Tradução [da 8. ed. Americana]
Vandenberg Dantas de Souza. Rio de Janeiro. Campus, 2006.
IN
DYE, David. Monitoring Changes in Your Database Using DDL Triggers. 2008. Disponível em:
<http://www.sqlservercentral.com/articles/Auditing/64176>. Acesso em: 24 out 2008.
GRUPO ORION. Ameaças Físicas Associadas à Segurança na Área de TI. 2009. Disponível em:
<http://www.grupoorion.com.br/index2.php?prod=cellsafe>. Acesso em: 02 jun 2009.
IM
MEIER, J.D., et al. Como proteger-se contra a injeção de SQL no ASP.NET. Disponível em:
<http://www.microsoft.com/brasil/msdn/Tecnologias/Seguranca/SQLnoASPNET.mspx> . Acesso em: 22
abr 2008.
U
N
METALINK. All About Security: User, Privilege, Role, SYSDBA, O/S Authentication, Audit,
Encryption, OLS. 2007. Disponível em: <http://metalink.oracle.com>. Acesso em 18 out 2007.
_________. Security Check List: Steps to Make Your Database Secure from Attacks. 2007.
Disponível em: http://metalink.oracle.com. Acesso em 18 out 2007.
MICROSOFT: Centro de orientações de segurança. Ameaças e contramedidas. Disponível em:
<https://www.microsoft.com/brasil/security/guidance/topics/devsec/secmod75.mspx>. Acesso em: 16 abr
2008.
_______________________________. Protegendo seu Servidor de Banco de Dados. Disponível em:
<https://www.microsoft.com/brasil/security/guidance/topics/devsec/secmod91.mspx>. Acesso em: 16 abr
2008.
MSDN: Microsoft Developer Network. Injeção SQL. 2008. Disponível em: <http://msdn.microsoft.com/ptbr/library/ms161953.aspx>. Acesso em: 28 out 2008.
TECHNET. SQL Server 2005 - Security and Protection. 2008. Disponível em:
<http://technet.microsoft.com/en-us/sqlserver/bb331769.aspx>. Acesso em: 03 ago 2008.
76
____________________. Worm: W32.Slammer. 2008. Disponível em:
<http://www.microsoft.com/technet/security/alerts/slammer.mspx>. Acesso em: 12 jul 2008.
ORACLE. Installing Oracle Database 10g Release 2 on Linux x86. Disponível
em:<http://www.oracle.com/technology/pub/articles/smiley_10gdb_install.html>. Acesso em: 08 set 2008.
PHPNET: Injeção de SQL-Manual. 2009. Disponível em:
<http://br.php.net/manual/pt_BR/security.database.sql-injection.php>. Acesso em 24 mar 2009.
PICHILIANI, Mauro. Monitoramento de base de dados. Revista SQL Magazine, n.54, p.52, 2008.
S
SILBERSCHATZ, Abraham et al. Sistemas de banco de dados. São Paulo. Pearson Makron Books,
1999.
A
TECH-FAQ. What is a brute force attack. 2008. Disponível em: <http://www.tech-faq.com/brute-forceattack.shtml>.
Acesso em 07 ago 2008.
IN
_________. What is a dictionary attack. 2008. Disponível em: <http://www.tech-faq.com/dictionaryattack.shtml>. Acesso em 06 ago 2008.
U
N
IM
_________. How do Password Hacking Programs Work. 2008. Disponível em:
<http://www.tech-faq.com/password-hacking-programs.shtml>. Acesso em 06 ago 2008.