Aula 01 - 147 Slides

Segurança em Banco de Dados
Prof: Thiago Moraes Martins
Bacharel em Sistemas de Informação
Pós-Graduação Software Livre Aplicado
Pós-Graduação Analista de Sistemas
Pós-Graduação Metodologia do Ensino Superior
Mestrado Engenharia de Software (Andamento)
Certificado ITIL
Certificado COBIT
Certificado CWSP
www.asassoftwares.com.br/1102/sbd01.zip
1
Segurança em Banco de Dados
Ementa
 A disciplina oferece aos alunos uma visão ampla dos
diversos aspectos que envolvem a segurança de um
sistema computacional de uma organização, com foco
nos SGBDs. Segurança física e lógica dos SGBDs.
Montagem de uma auditoria. Falhas prováveis que
podem ser encontrados nos SGBDs. A internet e sua
vulnerabilidade aos SGBDs.
2
Segurança em Banco de Dados
Objetivo da Disciplina





Estimular o conhecimento sobre segurança da
informação.
Desenvolver uma política de segurança para SGBDs.
Conhecer técnicas de ataque aos SGBDs.
Aplicar a auditoria aos banco de dados.
Analisar as soluções possíveis, considerando as
diversas variáveis que podem dificultar ou facilitar a
implantação de segurança nos SGBDs.
3
Segurança em Banco de Dados
Ementa:

1 ESTRATÉGIAS PARA SEGURANÇA DA INFORMAÇÂO









Fundamentos sobre segurança
Segurança na Web
A Informação – porque necessita de segurança?
2 SEGURANÇA NOS SGBDs
2.1 O papel do DBA na segurança dos SGBDs
2.2 Backup e Recovery
2.3 Infra estrutura adequada visando a segurança dos
SGBDs
2.4 Controle de acesso discreto e mandatório
2.5 Roles
4
Segurança em Banco de Dados








2.6 Proteção de usuários x proteção de objetos do
SGBD
2.7 Comandos SQLs para segurança
2.8 Regras de Autorização
3 POLÍTICAS DE SEGURANÇA PARA OS SGBDs
3.1 O que é uma política de segurança
3.2 Montagem de uma política de segurança eficaz
4 ROUBO DE DADOS
4.1 Quem está sujeito a perda (roubo) de dados
4.2 Cases
5
Segurança em Banco de Dados








5 A WEB E A SEGURANÇA DOS SGBDs
5.1 Diferenças da segurança de banco de dados na
Web
5.2 Prováveis ataques
5.3 Montagem de um plano para dificultar os
ataques
6 AUDITORIA
6.1 Auditoria nos SGBDs
6.2 Opções de auditoria
6.3 Audit Trail
6
Segurança em Banco de Dados
 Bibliografia Indicada



DATE, C. J. Introdução a sistemas de banco de dados. Rio
de Janeiro: Elsevier, 2003.
ELMASRI, R.; NAVATHE, S. B. Sistemas de bancos de
dados: fundamentos e aplicações. 4. ed. São
Paulo:
Pearson Education, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.;
SUDARSHAN, S. Sistema de banco de dados. Tradução da
5ª Edição. São Paulo: Campus, 2006.
 Bibliografia Opcional

CHESWICK, R. W.; BELLOVIN, S. M.; RUBIN, A. D. Firewalls e
segurança na Internet. 2. ed. ,2005. 400p.
7
Segurança em Banco de Dados
Segurança em banco de dados
8
Segurança em Banco de Dados
O banco de dados de uma empresa contém uma grande quantidade de
dados e geralmente um grande número de usuários. A maioria destes
usuários não tem a necessidade de acessar todos os dados.
Assim, permitir o acesso irrestrito a todos os dados pode ser
indesejável e o SGBD deve prover mecanismos para controlar este
acesso.
O banco de dados de uma empresa contém uma grande quantidade de
dados e geralmente um grande número de usuários. A maioria destes
usuários não tem a necessidade de acessar todos os dados. Assim,
permitir o acesso irrestrito a todos os dados pode ser indesejável e
o SGBD deve prover mecanismos para controlar este acesso.
9
Segurança em Banco de Dados
Controle de acesso discricionário
10
Segurança em Banco de Dados
SGBDs controlam o acesso aos dados através do controle de acesso
discricionário. Esse controle é baseado no conceito de direitos de
acesso ou privilégios e a maneira de conceder estes privilégios aos
usuários. Um privilégio permite que um usuário acesse o dado de
certa maneira (por exemplo, lendo ou escrevendo o dado).
Um usuário que cria um objeto automaticamente adquire todos os
direitos sobre o mesmo. A partir de então, o banco de dados guarda
todos os privilégios que são concedidos a outros usuários e desta
forma, garante que apenas os usuários autorizados possam acessar
este objeto.
11
Segurança em Banco de Dados
Em praticamente todos os bancos de dados, o controle de acesso
discricionário é implementado através do uso dos comandos GRANT
e REVOKE.
O comando GRANT concede privilégios sobre os objetos
do banco de dados (tabelas e visões, dentre outros) a outros usuários
enquanto que o comando REVOKE revoga os privilégios concedidos.
Para um melhor entendimento do mecanismo de acesso discricionário,
é importante compreender a definição de privilégios, objetos e
usuários:
12
Segurança em Banco de Dados
• Usuários: são as pessoas que estão representadas por um nome de
autorização. Os usuários podem ser classificados em grupos de acordo
com um perfil ou nível de autorização. Um usuário que pertence a um
grupo, implicitamente, recebe os privilégios relacionados ao grupo que
ele pertence;
• Privilégio: define uma permissão individual associada a um nome
autorizado, habilitando-o a acessar ou modificar um recurso do banco
de dados. Os privilégios também podem ser concedidos a grupos
de usuários;
• Objetos: os usuários necessitam de privilégios para acessar os
objetos guardados no banco de dados. Os privilégios variam de acordo
com a natureza do objeto. Por exemplo, uma tabela possui uma lista de
privilégios diferente das visões. São exemplos de objetos: tabelas,
visões, índices, triggers, entre outros.
13
Segurança em Banco de Dados
Comando GRANT
14
Segurança em Banco de Dados
A sintaxe do comando GRANT é a seguinte:
GRANT privilégios ON objeto TO usuários [WITH GRANT OPTION]
Onde:
• Privilégios: denota, por modelar:
o SELECT: o direito de leitura sobre as colunas da tabela
especificada;
o INSERT: o direito de inserir linhas;
o UPDATE (nome-da-coluna, ...): o direito alterar valores na
coluna especificada da tabela indicada como objeto;
15
Segurança em Banco de Dados
o DELETE: o direito de excluir linhas de uma tabela especificada
como objeto;
o INDEX: direito de criar um novo índice sobre a tabela. Este
privilégio aplica-se somente a tabelas;
• Objeto: geralmente uma tabela ou visão;
• Usuários: usuário ou lista de usuários que receberão o privilégio.
16
Segurança em Banco de Dados
Se um usuário recebe o privilégio com a opção GRANT OPTION, ele
pode passar esse privilégio para outro usuário através do comando
GRANT.
Um usuário que cria uma tabela automaticamente herda todos os
privilégios aplicáveis à tabela juntamente com o direito de conceder
estes privilégios para outros usuários. O usuário que cria uma visão
tem os mesmos privilégios sobre ela.
Apenas o dono de um esquema (um esquema é a descrição do banco de
dados) pode executar os comandos de definição de dados CREATE,
ALTER e DROP do mesmo.
O direito de executar estes comandos não pode ser concedido ou
revogado.
17
Segurança em Banco de Dados
Exemplos do uso do comando GRANT
18
Segurança em Banco de Dados
GRANT SELECT, INSERT ON tb_cep TO user1;
GRANT SELECT ON tb_cep TO PUBLIC;
GRANT SELECT ON funcionario to admuser WITH GRANT
OPTION;
GRANT ALL ON tb_cep TO admuser WITH GRANT OPTION;
19
Segurança em Banco de Dados
O comando Revoke
20
Segurança em Banco de Dados
Para revogar privilégios concedidos utiliza-se o comando
REVOKE. Sua sintaxe é:
REVOKE privilégios ON objeto FROM usuários { RESTRICT
| CASCADE }
21
Segurança em Banco de Dados
Exemplos do uso do comando REVOKE
22
Segurança em Banco de Dados
REVOKE SELECT ON tb_cep FROM PUBLIC;
REVOKE SELECT ON funcionario FROM admuser RESTRICT;
REVOKE ALL ON tb_cep FROM admuser CASCADE;
23
Segurança em Banco de Dados
A opção de RESTRIC significa que o comando recusa remover a tabela
se existirem objetos dependentes. Este é o padrão no banco de dados
DB2.
Já a opção CASCADE remove automaticamente os objetos que
dependem da tabela (como visões), ou seja, faz uma remoção em
cascata.
24
Segurança em Banco de Dados
Gráfico de autorização
25
Segurança em Banco de Dados
O efeito de uma série de comandos GRANT pode ser descrito através
de um gráfico de autorização no quais os nós são usuários e as
setas/arcos indicam como os privilégios são passados.
Por exemplo, existe uma seta do usuário1 para o usuário2 se usuário1
executou um comando GRANT passando um privilégio para o usuário2.
A seta será rotulada com o descritor para este comando GRANT.
Para os comandos da Listagem 3 foi criado o gráfico de autorização
apresentado na Figura 1:
26
Segurança em Banco de Dados
• Note que o usuário Jose é o criador da tabela Item e herda o
privilégio SELECT do SGBD. Esta operação é demonstrada pela
introdução de um nó de sistema (SYSTEM), desenhando uma seta
deste nó para o nó de Jose (Ação 1).
• Vera recebe os privilégios de Jose (Ação 2).
• Subseqüentemente Rob recebe o mesmo privilégio através de
Vera (Ação 3).
• Como o gráfico claramente indica, o GRANT de Artur para Rob e
de Rob para Artur (do mesmo privilégio) cria um ciclo (Ação 4).
27
Segurança em Banco de Dados
Listagem 3. Concedendo e revogando privilégios.
GRANT SELECT ON Item TO Artur WITH GRANT OPTION;
(executed by Jose)
GRANT SELECT ON Item TO Vera WITH GRANT OPTION;
(executed by Jose)
GRANT SELECT ON Item TO Rob WITH GRANT OPTION;
(executed by Vera)
GRANT SELECT ON Item TO Rob WITH GRANT OPTION;
(executed by Artur)
28
Segurança em Banco de Dados
GRANT SELECT ON Item TO Artur WITH GRANT OPTION;
(executed by Rob)
REVOKE SELECT ON Item FROM Artur CASCADE ;
(executed by Jose)
29
Segurança em Banco de Dados
Figura 01
30
Segurança em Banco de Dados
Dados Criptografados
31
Segurança em Banco de Dados
Como sabemos, os aspectos de segurança em uma rede são
fundamentais para garantia de confiabilidade e execução dos serviços.
A tecnologia de banco de dados trabalha com vários fatores para
garantir a integridade e segurança dos dados. Além do acesso
discricionário, existem outros fatores que podem auxiliar na
segurança de um banco de dados. Um destes fatores diz respeito
à criptografia dos dados como veremos no tópico a seguir.
32
Segurança em Banco de Dados
Verificando o tráfego na rede
33
Segurança em Banco de Dados
O funcionamento de uma rede consiste basicamente em envio e
recebimento de dados. Qualquer informação que trafegue pela rede,
seja uma mensagem de correio eletrônico, um arquivo de texto ou um
comando de consulta qualquer, é dividida em pequenas unidades de
dados chamadas pacotes.
Além de uma parte do conteúdo da mensagem original, cada pacote
recebe informações adicionais que incluem o endereço IP de destino e
o conteúdo do pacote.
Para verificar o conteúdo de um pacote de informações em uma LAN
basta o usuário ter o acesso interno a ela e possuir um programa
específico para realizar esta captura. Com isso se torna simples
localizar e visualizar o conteúdo de um pacote.
34
Segurança em Banco de Dados
Capturando pacotes de informações
35
Segurança em Banco de Dados
Buscando encontrar e analisar o movimento dos pacotes de informações
referentes aos comandos e informações do nosso banco de dados
utilizou-se um software chamado Ethereal (). O Ethereal (Figura 2)
é um analisador de tráfego de rede com uma interface intuitiva e
simples capaz de capturar pacotes específicos relacionados a um
endereço IP ou um cliente de rede que esteja efetuando transações
ativas.
Este software não só permite ver os pacotes que são destinados ao
nosso computador como os que são destinados aos restantes
(e que em geral o nosso computador ignora).
Este tipo de aplicação costuma ser chamado de analisador de
protocolos ou também de sniffer.
36
Segurança em Banco de Dados
37
Segurança em Banco de Dados
A análise feita sobre um componente de tráfego de rede foi
estabelecida através da captura de um pacote de informação no exato
momento de sua movimentação pela rede. Com isso, foi possível
executar uma análise prévia dos resultados e dos comandos emitidos
pelo cliente para o banco de dados, nesse exemplo, chamado de
DBCRIPT.
O usuário utilizado para a conexão de exemplo foi db2admin com a
senha criptografia.
Na Listagem 8 podemos observar uma descrição de uma parte do
pacote de informações capturado durante o teste. Este pacote de
informações esta trafegando sem qualquer tipo de criptografia.
38
Segurança em Banco de Dados
Listagem 8. Pacote de dados sem criptografia.
DBCRIPT
D!
db2admin
NULLID
SYSSH200
SYSLVL01
criptÐogrÐafiaÐ
$ WITH HOLD
ÿ ]ÐC W$ MSELECT A.ID_APLICACAO, C.COD_
RESTRICAO, B.*
FROM APLICACOES A LEFT
JOIN RESTRICOES_APLIC B
INNER JOIN
RESTRICOES C
ON B.ID_RESTRICAO = C.ID_
RESTRICAO AND
C.TIPO_RESTRICAO IN (‘Q’,
‘D’)
ON A.ID_APLICACAO = B.ID_APLICACAO
WHERE A.ID_APLICACAO = ? ORDER BY
A.ID_
APLICACAO, C.COD_RESTRICAO
ÿ SÐA
M
D! DBSM
NULLID
SYSSH200
SYSLVL01
!F/ aÐQ / [
MSELECT
A.ID_APLICACAO,
C.COD_RESTRICAO,
B.*
FROM
APLICACOES A
LEFT JOIN
RESTRICOES_APLIC B
INNER JOIN RESTRICOES
39
Segurança em Banco de Dados
Considere as informações abaixo para entender a Listagem 8.
Nome do Banco de Dados
Usuário do Banco de Dados
Senha do Usuário do Banco de Dados
40
Segurança em Banco de Dados
Comando executado
41
Segurança em Banco de Dados
Conforme a legenda acima, podemos observar que este pacote contém
informações vitais para a segurança de uma empresa. Normalmente
estes pacotes de informações transitam livremente sem nenhum tipo
de segurança. Basta um simples software de captura e uma análise
superficial para podermos ter em mãos dados confidenciais e
importantes do dia a dia da empresa.
Podemos também recuperar facilmente um usuário que tem permissão
total para modificações no banco de dados.
42
Segurança em Banco de Dados
Ativando criptografia no DB2
43
Segurança em Banco de Dados
O DB2 possui um parâmetro que permite ao DBA aplicar mais
segurança nestes pacotes de informações com a ativação de
criptografia. Para isso é preciso alterar as configurações do banco
de dados.
Basta aplicar o comando DB2 GET DBM CFG e alterar o parâmetro
Database manager authentication como podemos observar abaixo:
Database Manager Configuration
Database manager authentication
(AUTHENTICATION) = SERVER_ENCRYPT
44
Segurança em Banco de Dados
Depois de efetuado a configuração do parâmetro de autenticação, é
preciso modificar as opções de segurança em cada máquina cliente que
possui acesso ao banco de dados. Para isso, basta acessarmos o
Assistente de Configuração de Banco de Dados do DB2 e selecionarmos
a opção Autenticação do Servidor (SERVER) e Ativar criptografia
(ver Figura 3).
45
Segurança em Banco de Dados
Figura 3. tela assistente
46
Segurança em Banco de Dados
Depois de efetuadas as modificações no banco, repetimos o mesmo
processo de captura de pacotes com o mesmo comando executado da
mesma máquina cliente. O resultado pode ser visto na Listagem 9.
Listagem 9. Pacote de dados com criptografia.
°ÐA ª A n ^‘?¥?¦K…§…@@@@@@@@@@@ðöõøðöÁôððð
`ðððñÁãÒÉÕâÖÕ@@@@@@@@@@@@@@@@@@@@@@ÄÂâÔã
ÙÅÉ 14 /
$
t $@
GØÄÂòaÕã
mÕÂÄðó ZâØÓðøðñõ JÐ
Dm¢
! ÄÂâÔãÙÅÉ@@@@@@@@@@
$ ܶ òjêáý‹6çàöN¼·ÏWåjFÒ]êÞ¸³ ‰Ó Ô hÐC
b C
^„‚ò‰•¢£ñ„‚ò?‡…•£ððððóòÂöð 14 /
$
t $47
Segurança em Banco de Dados
Como podemos observar, os dados em questão estão completamente ilegíveis, pois já estão
atuando com a criptografia ativa. Com isso, tende-se a dificultar as possibilidades de qualquer
tipo de invasão ou de obtenção de informações confidenciais dentro e fora da empresa.
48
Segurança em Banco de Dados
Conclusão
No teste realizado, monitoramos apenas alguns minutos do gargalo de entrada do banco de
dados DBCRIPT e geramos apenas alguns arquivos de exemplo para análise. O mais
interessante neste teste foi a facilidade de obtenção de um usuário e uma senha para
acesso ao banco de dados. Esta aparece com a forma um pouco “confusa”, mas mesmo assim
pode-se chegar à senha correta com facilidade.
Verifique se o servidor de banco de dados que você utiliza fornece criptografia para trânsito
de dados e não deixe de usar esse recurso fundamental para a segurança das informações de
sua empresa.
49
Segurança em Banco de Dados
O uso do ethereal é simples e intuitivo – siga o roteiro abaixo para realizar seus primeiros
passos com o aplicativo:
1) Baixe o instalador em www.ethereal.com. A instalação não solicita nenhum tipo de
configuração e é baseada em ‘next-next-next’ (se você marcou a opção ‘Start WinPcap
service at startup, será necessário reiniciar o micro);
2) Inicie o aplicativo e selecione a interface de conexão (placa ou conexão de rede). Para isso,
clique no menu Capture-Interfaces (Figura 4). Em seguida, clique no botão ‘Capture’ da placa
de rede correspondente (Figura 5);
50
Segurança em Banco de Dados
51
Segurança em Banco de Dados
3) Uma janela com o status do tráfego de dados pela rede será aberta (Figura 6). Deixe a
janela rodando durante algum tempo e clique em ‘Stop’;
52
Segurança em Banco de Dados
4) Por último o aplicativo exibirá os pacotes capturados na janela principal, divididos em três
categorias. Para visualizar os dados de um pacote, clique em uma das linhas no painel superior
(que exibe o cabeçalho do pacote) e visualize o conteúdo do pacote no terceiro painel.
Observe que o pacote aparece em dois formatos: byte e ascii (Figura 7). Veja também que o
cabeçalho do pacote exibe diversas informações importantes, tais como endereço IP de
origem, endereço IP de destino, protocolo e tipo da aplicação que enviou o pacote
(na coluna info).
53
Segurança em Banco de Dados
54
Segurança em Banco de Dados
Exemplo de Role no Sql Server 2005
55
Segurança em Banco de Dados

Verificando propriedades do login SA.
56
Segurança em Banco de Dados

O seu Server Roles está apontado para o fixed sysadmin.
57
Segurança em Banco de Dados
Databases Roles
- São aplicados ao usuário
Server Roles
- São aplicados aos logins
Os logins possuem permissões administrativas no servidor e os usuários possuem
permissões nos objetos do banco de dados.
58
Segurança em Banco de Dados

Criando um novo Login.
59
Segurança em Banco de Dados
60
Segurança em Banco de Dados


O sysadmin é um role especial, pois toda vez que é colocado o login como sysadmin,
ele automaticamente se torna um db_owner para todos os bancos, pois este é um login
que se pode fazer tudo.
Desta forma tem uma relação entre os fixed Server roles conforme abaixo com os
database role db_owner que é o mais poderoso.
61
Segurança em Banco de Dados
Criação do login John e mapeando o mesmo ao usuário J
62
Segurança em Banco de Dados

Associar o usuário ao banco de dados DB_PERM
- Server Roles são utilizados para servidores.
- Database Role são utilizados para banco de dados.
- Existem 10 database role por padrão conforme figura acima, que são
denominados fixed database role.
63
Segurança em Banco de Dados
- Cada database role possui uma permissão já por padrão. Os database role são
relativos ao usuário e não ao login, pois o login utiliza os server roles.
- Um pouco sobre cada um dos database role:

db_accessadmin
•

db_backupoperator
•

Permite ao usuário efetuar gravações como update, delete e insert.
db_ddladmin
•

Permite ao usuário efetuar apenas o comando select, ou seja, somente leitura do banco de
dados.
db_datawriter
•

O usuário pode fazer backup/restore.
db_datareader
•

O usuário tem permissão de criação ou não de login.
Pemite a criação de objetos como o create table, drop view, alter procedure, ou seja, criação de
objetos de DDL.
db_denydatareader
•
Nega a permissão de leitura ao banco de dados.
64
Segurança em Banco de Dados

db_denydatawriter
•

db_owner
•

É um recurso especial, pois toda vez que colocar o usuário como db_owner, o mesmo pode fazer
todo o tipo de operação no banco de dados.
db_securityadmin
•

Nega a permissão de gravação ao banco de dados.
É relacionado as permissões de GRANT, DENY, REVOKE.
Public
•
É igual ao db_owner, são 2 roles especiais. O public é um role especial que não é possível ser
removido. Pois toda a vez que um login do SQL Server é mapeado ao banco de dados, como por
exemplo, o login John está sendo mapeado ao usuário J, ele automaticamente pertence ao role
public.
•
O role public pertence a todos os banco de dados e por padrão ele não possui nenhuma
permissão.
65
Segurança em Banco de Dados

db_denydatawriter
•

db_owner
•

É um recurso especial, pois toda vez que colocar o usuário como db_owner, o mesmo pode fazer
todo o tipo de operação no banco de dados.
db_securityadmin
•

Nega a permissão de gravação ao banco de dados.
É relacionado as permissões de GRANT, DENY, REVOKE.
Public
•
É igual ao db_owner, são 2 roles especiais. O public é um role especial que não é possível ser
removido. Pois toda a vez que um login do SQL Server é mapeado ao banco de dados, como por
exemplo, o login John está sendo mapeado ao usuário J, ele automaticamente pertence ao role
public.
•
O role public pertence a todos os banco de dados e por padrão ele não possui nenhuma
permissão.
66
Segurança em Banco de Dados


Exibindo o usuário J criado.
Obs.: Conforme figura anterior, o usuário J não foi associado a nenhuma role, a não ser
a padrão public que não possui permissão.
67
Segurança em Banco de Dados
Criação do login Mary e mapeando o mesmo ao usuário M
68
Segurança em Banco de Dados
69
Segurança em Banco de Dados

Associar o usuário ao banco de dados DB_PERM
70
Segurança em Banco de Dados

Não será marcado nenhum fixed Server role.
71
Segurança em Banco de Dados

Login John e Mary
Usuário J e M
» AMBOS NÃO POSSUEM PERMISSÃO ALGUMA!
72
Segurança em Banco de Dados





Crie 3 abas clicando no botão Query e efetue a autenticação de cada aba aos usuários
criados .
Aba 01 -> Usuário SA
Aba 02 -> Usuário John
Aba 03 -> Usuário Mary
Digite o comando SQL para apontar para o banco DB_PERM conforme abaixo. Deverá
ser feito para cada uma das abas.
73
Segurança em Banco de Dados


Com o usuário SA funciona perfeitamente o SELECT, pois o login SA faz parte do fixed
role sysadmin que é mapeado ao usúário db_owner em todos os bancos de dados.
Desta forma, todos os usuários que estiverem dentro do ROLE SA, conseguirão efetuar
o select.
74
Segurança em Banco de Dados

Efetuando o mesmo select com o John e Mary, o mesmo possui apresenta erro.
75
Segurança em Banco de Dados

Após a criação do ROLE e atribuição do GRANT de SELECT, o usuário SA continua
conseguindo executar a consulta.
76
Segurança em Banco de Dados

O usuário J (John) ainda não consegue efetuar a consulta select, pois o mesmo não
está ainda dentro do ROLE.
77
Segurança em Banco de Dados

O usuário M (Mary) ainda não consegue efetuar a consulta select, pois o mesmo não
está ainda dentro do ROLE.
78
Segurança em Banco de Dados

Após a inclusão do usuário J (John) ao ROLE, o mesmo já consegue efetuar a consulta.
79
Segurança em Banco de Dados

Como J (John) já está dentro do grupo, o mesmo já consegue efetuar a consulta.
80
Segurança em Banco de Dados

Após a inclusão do usuário M (Mary) ao ROLE, o mesmo já consegue efetuar a consulta.
81
Segurança em Banco de Dados

Como M (Mary) já está dentro do grupo, o mesmo já consegue efetuar a consulta.
82
Segurança em Banco de Dados

Todo o usuário que estiver dentro do grupo SALES, terá permissão correspondente ao
ROLE atribuído.

Porém, pode ser feito também uma permissão individual dentro do grupo. Desta forma,
qual permissão prevalecerá? A permissão do grupo ou a permissão individual?
83
Segurança em Banco de Dados



Em caso de conflito de restrições, a que vale é a mais restritiva.
No caso anterior, atribuímos a permissão do ROLE a permissão de SELECT para todos
os usuários que estavam no grupo. Se eu efetuar a negação de SELECT a um usuário
específico, o mesmo não poderá efetuar a consulta e sim somente os outros usuários
do grupo.
Veja a negação da permissão de SELECT para o usuário J.
84
Segurança em Banco de Dados

O usuário J (John) não consegue mais efetuar a consulta.
85
Segurança em Banco de Dados

O usuário M (Mary) ainda consegue efetuar a consulta, pois não possui ainda nenhuma
negação.
86
Segurança em Banco de Dados

Removendo o usuário M (Mary) do grupo SALES.
87
Segurança em Banco de Dados

Como o usuário M (Mary) não está mais no grupo SALES, a mesma não tem permissão
mais de SELECT.
88
Segurança em Banco de Dados

Visualizando informações do usuário J (John).
89
Segurança em Banco de Dados

Visualizando informações do usuário M (Mary).
90
Segurança em Banco de Dados

O comando abaixo retorna os membros de um determinado ROLE.
91
Segurança em Banco de Dados
92
Segurança em Banco de Dados

Contextualização
93
Segurança em Banco de Dados
94
Segurança em Banco de Dados

Auditoria
95
Segurança em Banco de Dados
96
Segurança em Banco de Dados
97
Segurança em Banco de Dados
98
Segurança em Banco de Dados
99
Segurança em Banco de Dados

Introdução
100
Segurança em Banco de Dados

Recurso Sql Server Audit
101
Segurança em Banco de Dados
102
Segurança em Banco de Dados

Server Audit Specification
103
Segurança em Banco de Dados

Database Audit Specification
104
Segurança em Banco de Dados

Target
105
Segurança em Banco de Dados

Uso do Sql Server Audit
106
Segurança em Banco de Dados

Criando Sql Server Audit
107
Segurança em Banco de Dados

Criando Sql Specification
108
Segurança em Banco de Dados
109
Segurança em Banco de Dados

Testando a Auditoria
110
Segurança em Banco de Dados

Editando a Auditoria
111
Segurança em Banco de Dados

Auditoria aplicada a Rollback
112
Segurança em Banco de Dados

Carregando os dados de auditoria em uma tabela
113
Segurança em Banco de Dados
114
Segurança em Banco de Dados
115
Segurança em Banco de Dados

Considerações
116
Segurança em Banco de Dados
Segurança no SQL Server 2005
117
Segurança em Banco de Dados
Integridade e segurança são duas dentre as muitas razões para o armazenamento de
informações em um banco de dados. Entende-se por integridade não somente a garantia de
que um dado está fisicamente armazenado no banco de dados, mas de que o dado foi inserido,
alterado, apagado ou acessado somente por aqueles que possuem permissões adequadas.
Entende-se por segurança o controle de usuários, objetos e os relacionamentos de permissões
existentes entre eles. É função de um sistema gerenciador de banco de dados fornecer um
modelo de segurança capaz de garantir a integridade lógica e segurança dos dados
armazenados. É de responsabilidade do administrador de banco de dados conhecer este
modelo e suas formas de implementação.
118
Segurança em Banco de Dados
No modelo de segurança do SQL Server 2005. O SQL Server 2005 é aderente ao conceito
de “trustworth computing” da Microsoft que segue as seguintes linhas de pensamento:
• Seguro na arquitetura: a Microsoft esforçou-se para diminuir a área de ataque do SQL
Server 2005 através da análise dos vetores de ataques mais comuns;
• Seguro por padrão: uma instalação padrão do SQL Server 2005 não implementa todas as
funcionalidades e alguns serviços não são instalados. Alguns exemplos são: a stored procedure
XP_CMDSHELL que vem desabilitada por padrão e, a base de teste AdventureWorks (que
substitui as bases Pubs e Northwind) que também não é instalada por padrão.
• Seguro na instalação: o SQL Server 2005 agregou ferramentas para a configuração de
segurança, monitoramento e auditoria do banco. Dentre as novas ferramentas estão o Surface
Area Configuration - que permite configurar funcionalidades e serviços ativos no
SQL Server 2005 – triggers de auditoria e políticas de senha para usuários SQL.
119
Segurança em Banco de Dados
O SQL Server 2005 implementa um novo modelo de segurança baseado na hierarquia de
objetos e fundamentado em três conceitos:
• Principals: é qualquer entidade autenticada que pode possuir permissões para acessar um
objeto no sistema de banco de dados. Principals podem existir em três níveis: Windows,
SQL Server e banco de dados. A Tabela 1 apresenta os principals do SQL Server 2005.
Tabela 1. Principal
120
Segurança em Banco de Dados
Securables: objetos que recebem permissões são chamados de Securables. Securables são ,
organizados de forma hierárquica em grupos (Scopes). Os três escopos dos objetos
securables são: Server, database e schema (ver Tabela 2).
Tabela 2. Securables e escopos
121
Segurança em Banco de Dados
• Permissions: permissões são as regras que controlam o nível de acesso que os principais
possuem nos securables.
Permissões podem ser dadas, revogadas ou proibidas. O SQL Server 2005 mantém os comandos
GRANT, REVOKE e DENY para o controle de permissões dos principais nos securables.
Alem destes comandos, outros novos comandos foram inseridos e estão apresentados
na Tabela 3.
Tabela 3. Novas permissões do SQL Server 2005
122
Segurança em Banco de Dados
Surface Area Configuration
123
Segurança em Banco de Dados
Surface Area Configuration (SAC) é a nova ferramenta de gerenciamento de segurança do
SQL Server 2005. O SAC permite maior controle de segurança sobre serviços, conexões e
funcionalidades do SQL Server 2005 e pode ser acessado através do grupo Configuration Tool
no grupo de programas do SQL Server 2005. O SAC está dividido em “Configurações de
Serviços e Conexões” e “Funcionalidades”. Através das Configurações de Serviços e Conexões
é possível desabilitar/habilitar serviços do SQL Server 2005 como Database Engine, SQL
Server Agent, Full Text Search e SQL Server Browser.
Também é possível configurar as permissões de conexões como somente local, TCP/IP, named
pipes ou TCP/IP e named Pipes.
A Figura 1 apresenta a tela de configuração do Surface Area Configuration for
Services and Connections.
124
Segurança em Banco de Dados
Figura 1. Surface Area Configuration for Services e Connections.
125
Segurança em Banco de Dados
A configuração de funcionalidades permite habilitar ou desabilitar funcionalidades específicas
do SQL Server 2005. As funcionalidades que podem ser configuradas são: AD hoc remote
queries, execução de código .Net no SQL Server, conexão dedicada do administrador,
database mail, suporte nativo a XML Web Services, automação OLE, SQL Mail, assistente
WEB e xp_cmshell. Todas essas funcionalidades vêem desabilitadas na instalação padrão do
SQL Server 2005 reforçando o conceito de seguro por padrão.
A Figura 2 apresenta a tela de configuração do Surface Área Configuration for Features.
126
Segurança em Banco de Dados
Figura 2. Surface Área Configuration for Features.
127
Segurança em Banco de Dados
Políticas de senha para usuários SQL
O SQL Server 2005 continua a suportar os dois modelos de autenticação existentes no SQL
Server 2000: Windows e SQL. Na autenticação Windows o usuário e senha, incluindo a sua
complexidade e expiração, são gerenciados pelo controlador de domínio. Na autenticação SQL
o usuário e a senha são gerenciados pelo próprio SQL Server. Até a versão do SQL Server
2000 não era possível aplicar políticas de controle de senha nos usuários SQL.
O SQL Server 2005 permite que as mesmas políticas de senhas existentes no domínio
Windows sejam aplicadas aos usuários SQL. Esta funcionalidade é possível através da API
NetValidate-PasswordPolicy(), disponível somente no Windows 2003.
O comando utilizado para a criação de um usuário SQL é o CREATE LOGIN. Este comando
substitui o comando SP_ADDLOGIN, que continua a existir por questões de compatibilidade.
O comando CREATE LOGIN pode ser utilizado para a adição de logins com Segurança Integrada
(autenticação Windows) e SQL Server Authentication. Quando o comando CREATE LOGIN é
utilizado para a adição de usuários SQL, estão disponíveis as configurações listadas na
Tabela 4.
128
Segurança em Banco de Dados
Tabela 4. Opções do comando CREATE LOGIN.
129
Segurança em Banco de Dados
A Listagem 1 ilustra a criação de um login SQL com política de senha e a obrigatoriedade de
troca de senha no primeiro login.
listagem 1. criação de um login com política de senha.
create login [foobar]
with password=n’pass@word1’ must_change,
check_expiration=on,
check_policy=on
----------------------------------------------------command(s) completed successfully.
130
Segurança em Banco de Dados
Quando a senha de um usuário expira, utiliza-se o comando ALTER LOGIN para a liberação da
senha. A Listagem 2 apresenta o comando que deve ser executado para a liberação da senha
do usuário.
listagem 2. liberação de um login bloqueado.
alter login [foobar]
with password= n’pass@word1’ unlock
----------------------------------------------------command(s) completed successfully.
131
Segurança em Banco de Dados
Triggers de DDL
132
Segurança em Banco de Dados
Triggers de DDL (ver Nota 1) assim como todas as triggers, executam comandos na
ocorrência de um evento específico. No entanto, triggers de DDL respondem a eventos de
CREATE, ALTER ou DROP que ocorrem tanto no escopo do servidor de banco de dados quanto
no escopo do database. Elas podem ser utilizadas para evitar, registrar ou proibir a execução
de comandos DDL no servidor de banco de dados.
Dois escopos são possíveis para execução das DDL Triggers:
• Server: abrange o servidor como um todo;
• Database: atua no database.
133
Segurança em Banco de Dados
Nota 1. DDL – Data Definition Language
Linguagem de definição de dados. Utilizada para a criação, alteração
e exclusão de objetos em servidores de banco de dados.
Os eventos que podem ocorrer no nível do servidor estão organizados no grupo
DDL_SERVER_LEVEL_EVENTS e os eventos que podem ocorrer no nível do banco de dados
são organizados no grupo DDL_DATABASE_LEVEL_EVENTS.
A Figura 3 apresenta os dois grupos e seus respectivos eventos.
134
Segurança em Banco de Dados
Figura 3. Eventos que disparam Triggers de auditoria.
135
Segurança em Banco de Dados
A sintaxe de criação de uma DDL Trigger é muito parecida com a criação de triggers: uma
das mudanças é a utilização da opção ON ALL SERVER ou ON DATABASE que especifica se o
escopo da trigger é no servidor ou somente no banco de dados.
O script da Listagem 3 cria um DDL trigger para armazenar todos os eventos de CREATE,
ALTER ou DROP LOGIN que venham a ocorrer no servidor SQL Server 2005.
136
Segurança em Banco de Dados
listagem 3. criação de uma ddl trigger.
use master
go
-- cria tabela de log
create table tb_ddl_trigger_log
(horario datetime, usuario nvarchar(100), evento
nvarchar(100), objeto nvarchar(255))
go
--cria trigger que responderá a eventos relacionados
--a login (create,alter e drop login)
create trigger tg_ddl_trigger_log
on all server
for ddl_login_events
as
declare @data xml
set @data = eventdata()
insert tb_ddl_trigger_log
(horario, usuario, evento, objeto)
values
(getdate(),
@data.value(‘(/event_instance/loginname)[1]’,
’nvarchar(100)’),
@data.value(‘(/event_instance/eventtype)[1]’,
‘nvarchar(100)’),
@data.value(‘(/event_instance/objectname)[1]’,
‘nvarchar(2000)’)) ;
go
137
Segurança em Banco de Dados
-- testa o funcionamento da trigger
create login foo with password=’foobar’;
drop login foo
go
-- seleciona os dados da tabela de log para
-- visualizar os eventos de login
select * from tb_ddl_trigger_log
go
----------------------------------------------------horario usuario evento objeto
2005-12-08 21:44:15.967 geekmobile\carlos create_login foo
2005-12-08 21:44:31.700 geekmobile\carlos drop_login foo
138
Segurança em Banco de Dados
O evento DDL é capturado no escopo da trigger por uma função chamada EVENTDATA(),
que retorna dados no formato XML. Para se obter os valores desejados, declarase uma variável
do tipo XML chamada @data e o resultado da função EVENTDATA() é armazenado nesta
variável. Os valores de LoginName, tipo de evento e nome do objeto são obtidos através da
pesquisa, utilizando-se Xquery, na variável @data.
139
Segurança em Banco de Dados
SQL Injection em ambientes Web
140
Segurança em Banco de Dados
Em um cenário onde existem informações armazenadas em bancos de dados e que podem
ser acessados via web, tem-se a possibilidade do ataque do tipo SQL injection.
SQL injection é um tipo de ataque muito simples, que baseia-se na execução de comandos
SQL, sejam comandos de manipulação de dados - DML (select, insert, update, delete)
ou comandos de definição de dados - DDL (create, drop, alter). Estes comandos são
executados através das entradas de formulários web, ou seja, no local destinado para
digitação de informações pelo usuário, onde são passados comandos SQL, que por falhas
nas aplicações acabam por resultar em alterações no banco de dados ou no acesso
indevido à aplicação.
A figura 1 apresenta um exemplo clássico de tal prática numa tela de autenticação:
141
Segurança em Banco de Dados
142
Segurança em Banco de Dados
O problema ocorre devido a autenticação do usuário ser validada internamente pela
aplicação com a seguinte instrução, que verifica se existe um usuário com o respectivo
login e senha:
SELECT * FROM tabela_usuarios WHERE login = 'campo_login' AND
senha = 'campo_senha'
143
Segurança em Banco de Dados
Normalmente, seriam digitados o login e a senha, que resultaria em uma consulta ao banco
de dados para verificar se os mesmos conferem mas na figura acima foi passado parte
de um comando SQL no campo reservado para senha, que internamente resultará na
seguinte instrução:
SELECT * FROM tabela_usuarios WHERE login = '123' AND senha = ' ' or '1' = '1'
144
Segurança em Banco de Dados
Observe que o comando passado no campo da senha fez com que independente do login e
senha informados, a condição seja sempre verdadeira, permitindo assim o acesso do
usuário à aplicação sem o mesmo possuir a devida permissão.
Existem diversas possibilidades de comandos que podem ser executados indevidamente
através da passagem de parâmetros, onde alguns exemplos podem ser observados na
tabela 1:
SQL esperado
Parâmetros informados
Campo_login
marcos’;--
SELECT *
FROM
tabela_usuarios
WHERE login =
'campo_login' AND
senha = 'campo_senha'
' OR 1=1 --
123'; DROP
TABLE produtos; -
SQL resultante
Comantário
SELECT * FROM
tabela_usuarios
WHERE login =
'marcos';--' AND senha
= 'campo_senha'
Se o usuário já souber o
login (no caso, login do
usuário marcos) então
consegue logar sem senha,
já que os caracteres “--“ são
comentários no SQL
SELECT * FROM
tabela_usuarios
WHERE login = '' OR
1=1--' AND senha =
'campo_senha'
Neste caso, não é
necessário saber nem o
login nem a senha, pois a
condição “OR 1=1” sempre
vai ser satisfeita e todos os
comandos posteriores são
comentados pelos
carecteres “--”
SELECT * FROM
tabela_usuarios
WHERE login = '123';
DROP TABLE
produtos;-- ' AND
senha = 'campo_senha'
Este caso é muito parecido
com o primeiro mas um
comando para apagar uma
tabela é executado antes do
comentário. Na verdade
aqui o objetivo era somente
apagar a tabela, por isso foi
passado um login qualquer.
Campo_senha
Tabela 1 – Passagem de parâmetros SQL injection
145
Segurança em Banco de Dados
Considerações Finais
Sistemas Desktop e Web ainda permanecem como alvos vulneráveis, apesar da
disponibilidade de ferramentas e de procedimentos que dificultam a ocorrência de ataques.
A fragilidade desses sistemas muitas vezes é potencializada pelo desconhecimento que os
programadores possuem sobre a programação segura e também sobre os cenários nos quais
esses ataques ocorreram e foram bem sucedidos.
146
Segurança em Banco de Dados
Trabalho em grupo
Tema: Auditoria no SQL SERVER 2005
•O trabalho deverá ser feito em grupo de 4 ou 5 pessoas;
•Cada grupo deverá preparar sua própria apresentação em PPT;
•O tempo de apresentação é de 20 a 30 minutos.
•O trabalho deverá seguir as normas da ABNT;
•Poderá ser consultada qualquer fonte desejada, porém nada deverá ser copiado e SIM escrito
com suas próprias palavras o entendimento sobre o assunto.
•Qualquer tipo de CÓPIA invalidará o trabalho.
•Deverá conter no mínimo 7 e no máximo 10 páginas;
•Data de Entrega: Ainda será definida.
•Pontuação
•15 Pontos da parte escrita
•5 Pontos de apresentação
147