Disciplina Banco de Dados II Segurança em BD

SCC0141 - Bancos de Dados e Suas
Aplicações
Prof. Jose Fernando Rodrigues Junior
Segurança em bancos de dados
Introdução
• Uma das maiores preocupações em computação
tem sido segurança da informação
• Nos dias atuais, com o uso da Internet os sistemas
tornam-se onipresentes, entretanto também
vulneráveis a ataques maliciosos
• Portanto, os SGBDs trazem uma camada de
segurança que visa compor o arsenal de segurança
da informação numa corporação
Introdução
• Definição:
– Segurança em Banco de dados diz respeito à
proteção do banco de dados contra
acesso/alteração intensionais ou não intensionais
utilizando-se ou não de meios computacionais
• Áreas envolvidas:
–
–
–
–
roubo e fraude
perda de confidencialidade e privacidade
perda de integridade
perda de disponibilidade
Introdução
• O subsistema de segurança é responsável por
proteger o BD contra o acesso não autorizado.
• Formas de acesso não autorizado:
– leitura não autorizada
– modificação não autorizada
– remoção de dados não autorizada
Introdução
• O DBA (Data Base Administrator, ou super
user) tem plenos poderes para dar e
revogar privilégios a usuários.
– Criação de contas
– Concessão/Revogação de privilégios
– Definição do nível de segurança
Introdução
• Controles de segurança computacionais
– Adiciona-se uma camada à segurança provida pelo SO
– Autorização e autenticação
– Backup e recovery
– Integridade
– Stored procedures
– Criptografia
– Auditoria
– Views
– Procedimentos associados não relacionados ao BD
• e.g. upgrading, virus checking, proxy, firewall, kerberos,
certificados digitais, SSL, SHTTP, etc.
Introdução
• Controles de segurança não computacionais
– Política de segurança e plano de contigência
– Posicionamento seguro de equipamentos
– Controle de acesso físico
– Manutenção
Introdução
•
Duas abordagens para segurança de dados:
– Controle de acesso mandatório:
• Cada dado é rotulado com um certo nível de classificação
– Por exemplo: metadados de sistema só podem ser lidos pelo DBA
• A cada usuário é dado um certo nível de acesso
– Por exemplo: DBA, administradores, usuários avançados e usuários
clientes; cada classe com um determinado conjunto de possibilidades prédefinidas
– Controle de acesso discreto:
• Um dado usuário tem direitos de acesso (privilégios) diferentes em objetos
diferentes
– Por exemplo: o usuário 3521-João só pode ler as tabelas Cliente e Produto
e executar o procedimento CalculaTotalDeCompras
Introdução
• Em SQL temos:
Proteçao
Privilégio
Aplica-se a
Ver
SELECT
Tabelas, colunas,
métodos
invocados
Criar
INSERT
Tabelas, colunas
Modificar
UPDATE
Tabelas, colunas
Remover
DELETE
Tabelas
Referenciar
REFERENCES
Tabelas, colunas
Ativar
TRIGGER
Tabelas
Executar
EXECUTE
Stored procedures
Introdução
• Perante um acesso indevido, o que se espera do SGBD é o
mesmo tratamento dado à tentativa de acesso a uma tabela
inexistente (“no such table”).
• Portanto, se um usuário tentar acessar uma tabela que ele não
tem privilégios para tal o erro será do tipo:
“Either no such table or you have no privilege on the table”
Criação de usuários
• O criador de um objeto é o dono do objeto e assim tem todos os privilégios
sobre o objeto, podendo autorizar a outros usuários alguns (ou todos) destes
privilégios.
• O usuário tem um auth_ID criado pelo DBA:
CREATE USER usuario
IDENTIFIED BY senha
– Alguns SGBDs permitem que o usuário use o mesmo login e senha do SO
– Simplifica a autenticação
• Quando um usuário é criado, ele tem associado a ele um conjunto de objetos
dos quais ele é dono e sobre os quais pode definir o controle de acesso
• Privilégios são atribuídos/revogados para:
– Usuários
– Papéis (Roles)
Criação de usuários
• O criador de um objeto é o dono do objeto e assim tem todos os privilégios
sobre o objeto, podendo autorizar a outros usuários alguns (ou todos) destes
privilégios.
• O usuário tem um auth_ID criado pelo DBA:
Em PostgreSQL:
CREATE USER usuario
IDENTIFIED BY senha
CREATE USER usuario
– Alguns SGBDs
permitem que o usuário use o mesmo login e senha do SO
PASSWORD
'senha';
– Simplifica a autenticação
CREATE SCHEMA esquemaDoUsuario AUTHORIZATION usuario;
• Quando um usuário é criado, ele tem associado a ele um esquema (schema),
ou conjunto de objetos dos quais ele é dono e sobre os quais pode definir o
controle de acesso
• Privilégios são atribuídos/revogados para:
– Usuários
– Papéis (Roles)
Privilégios de Sistema do Usuário
• Depois de criar um usuário, o DBA pode conceder privilégios de
sistema específicos a ele.
GRANT privilegio1 [, privilegio2...]
TO usuario1 [, usuario2 | perfil, PUBLIC...];
• Por exemplo, dois usuários (user25415 e user2398) desenvolvedores
de aplicativos podem ter os privilégios de sistema a seguir:
CREATE SESSION
CREATE TABLE
CREATE SEQUENCE
CREATE PROCEDURE
GRANT CREATE SESSION, CREATE TABLE, CREATE SEQUENCE,
CREATE PROCEDURE TO user25415, user2398
Usuários e Papéis
• Papéis (Roles)
– É um identificador ao qual atribui-se um conjunto de
privilégios; um papel pode ser associado a diferentes usuários
– Pode-se inclusive ao criar um papel usar outros papéis já
cadastrados
Criando, Designando e Mantendo
Atribuições
• Exemplo de criação de papel (ROLE):
CREATE ROLE desenvolvedores;
GRANT CREATE SESSION TO desenvolvedores;
GRANT CREATE TABLE TO desenvolvedores;
GRANT CREATE PROCEDURE TO desenvolvedores;
GRANT SELECT, UPDATE ON tabela01 TO desenvolvedores;
GRANT desenvolvedores TO 3521-João;
--DROP ROLE desenvolvedores;
Criando, Designando e Mantendo
Atribuições
• Exemplo de criação de papel (ROLE):
CREATE ROLE desenvolvedores;
Privilégios
de sistema
GRANT CREATE SESSION TO desenvolvedores;
GRANT CREATE TABLE TO desenvolvedores;
GRANT CREATE PROCEDURE TO desenvolvedores;
Privilégios
de objeto
GRANT SELECT, UPDATE ON tabela01 TO desenvolvedores;
GRANT desenvolvedores TO 3521-João;
DROP ROLE desenvolvedores;
Privilégios de Objeto
Privilégios de
Table
Permite aos usuários
Objeto
View
Sequence
executarem ações que afetam os
dados
ALTER
X
DELETE
X
INDEX
X
INSERT
X
REFERENCES
X
SELECT
X
X
UPDATE
X
X
X
X
X
X
Papéis - ROLES
• Existem papéis padrão na maioria dos SGBD:
CONNECT
CREATE SESSION, CREATE TABLE, CREATE VIEW,
CREATE SYNONYM, CREATE SEQUENCE, CREATE
DATABASE LINK, CREATE CLUSTER, ALTER SESSION
RESOURCE
CREATE TABLE, CREATE PROCEDURE, CREATE
SEQUENCE, CREATE TRIGGER, CREATE TYPE,
CREATE CLUSTER, CREATE INDEXTYPE, CREATE
OPERATOR
SCHEDULER_ADMIN
CREATE ANY JOB, CREATE JOB, EXECUTE ANY
CLASS, EXECUTE ANY PROGRAM, MANAGE
SCHEDULER
DBA (ou superuser)
Inclui a maioria dos privilégios de sistema, várias
outras atribuições. Não deve ser concedida a
usuários que não são administradores.
Regras de Autorização
• Expressam os mecanismos de
relações/visões/ stored procedures
autorização
em
• São compiladas e armazenadas no dicionário de dados
• Uma maneira do SGBD implementar estas regras é usar uma
matriz de autorização, onde cada linha corresponde a um
usuário a um usuário e cada coluna corresponde a um
objeto.
• M[i,j] => conjunto de regras de autorização que se aplica ao
usuário i com relação ao objeto j.
Regras de Autorização
Ex.:
Empregado
Departamento
Projeto
João
Select
Update, select
Select,
delete,
update
Maria
None
None
Select
Pedro
None
None
None
Ana
All
All
All
O DBA fornece/revoga as autorizações de leitura, inserção, atualização e
remoção aos usuários nas diversas tabelas/visões, e estes podem
repassá-los caso recebam autorização para tal.
Regras de Autorização
 O DBA fornece/revoga as autorizações de leitura, inserção,
atualização e remoção aos usuários nas diversas tabelas/visões, e estes
podem repassá-los caso recebam autorização para tal – WITH GRANT
OPTION.
 Exemplo:
DBA: GRANT SELECT ON tabela_de_produtos TO U2
WITH GRANT OPTION;
U2: GRANT SELECT ON tabela_de_produtos TO U3;
Permissões de Acesso em SQL
• Para revogar a autorização, o comando revoke
é usado. Ele toma a forma quase idêntica
àquela do comando grant:
REVOKE <lista de privilégios>
ON <nome da relação ou visão>
FROM <lista de usuários>
Exemplos
REVOKE SELECT ON AGENCIA FROM U1, U2, U3
REVOKE UPDATE ON DEPOSITO FROM U1
REVOKE REFERENCES (NOME-AGENCIA) ON
AGENCIA FROM U1
Autorização em Banco de Dados
• Com a opção WITH GRANT OPTION, um usuário que tem
concedido algum privilégio pode passar esse privilégio para
outros usuários.
DBA
U1
U4
U2
U5
U3
Revogação de Autorização
• Suponha que o administrador do banco de dados decida
revogar a autorização do usuário U1.
DBA
U1
U4
U2
U5
U3
– Uma vez que o usuário U4 tem a autorização concedida pelo usuário
U1, a sua autorização também será revogada.
– No entanto, U5 mantém sua autorização por ela ter sido concedida
também por U2.
Revogação de Autorização
• Um par de usuário desonestos pode tentar burlar as
regras anteriores de revogação de autorização
concedendo autorização de um para outro.
U1
DBA
U2
U3
Revogação de Autorização
• Se o administrador do banco de dados revogar a
autorização de U2, este manteria sua autorização por
meio de U3.
U1
DBA
U2
U3
Revogação de Autorização
• Se a autorização for revogada subsequentemente de
U3, ele reteria sua autorização por meio de U2.
U1
DBA
U2
U3
Revogação de Autorização
• Para evitar problemas como esse, os SGBDs são
projetados de maneira que todas as arestas em um
grafo de autorização sejam parte de algum caminho
originado no administrador do banco de dados.
U1
DBA
U2
U3
Auditoria
Segurança em banco de dados - Auditoria
• O que é?
– A auditoria é um outro método usado para assegurar a
integridade dos dados do banco
– Informa quais objetos foram acessados, e por quem
Segurança em banco de dados - Auditoria
• Quem faz?
– A auditoria é função do DBA!
– Inclusive o DBA pode ser auditado!
• Como faz?
– A auditoria no banco deve ser habilitada e configurada - é
preciso dizer ao SGBD onde as informações de auditoria serão
armazenadas;
– Com seu uso, o banco guarda as informações de auditoria
seguindo os parâmetros definidos em sua configuração.
Segurança em banco de dados - Auditoria
• Todos os “tipos” de auditoria usam os comandos
audit/noaudit para “ligar”ou “desligar” a auditoria.
• Os tipos de auditoria podem ser:
– Statements – auditoria de “Statements” (comandos);
– Privilege – auditoria de privilégios;
– Schema object – auditoria de esquema de objeto;
– Fine-Grained – auditoria minuciosa;
Segurança em banco de dados – Auditoria
Statement Auditing
• Auditing para “statements”, segue a sintaxe:
AUDIT sql_statement_clause
BY {SESSION | ACCESS}
WHENEVER [NOT] SUCCESSFUL;
• Exemplo:
AUDIT INDEX BY KSHELTON;
CREATE INDEX JOB_TITLE_IDX ON HR.JOBS(JOB_TITLE);
SELECT USERNAME, TO_CHAR(TIMESTAMP,'MM/DD/YY
TIMESTAMP,
OBJ_NAME, ACTION_NAME, SQL_TEXT
FROM DBA_AUDIT_TRAIL
WHERE USERNAME = 'KSHELTON';
HH24:MI')
Segurança em banco de dados – Auditoria
Statement Auditing

O resultado do select…
• Para desabilitar a auditoria sobre o usuário KSHELTON…
– NOAUDIT INDEX BY KSHELTON;
Audit Trail
• Audit trail: componente de todo SGBD que
armazena histórico de informações de auditoria
– Oracle: tabela SYS.AUD$
– DB2: log DB2AUDIT.LOG
– PostgreSQL: PostgreSQL Table Auditing module
– O SO também pode ter um audit trail, podendo ser
usado em conjunto com o do BD.
Audit Trail
•
•
•
•
•
•
•
•
•
Algumas informações do audit trail:
Nome do login do usuário no SO;
Nome do usuário no BD;
Identificador de sessão;
Identificador do terminal;
Nome do objeto do esquema acessado;
Operação executada ou tentada;
Código de conclusão da operação;
Data e hora.
Segurança em banco de dados – Auditoria
Statement Auditing
• Auditando “logins” bem ou mal sucedidos:
– AUDIT SESSION WHENEVER SUCCESSFUL;
– AUDIT SESSION WHENEVER NOT SUCCESSFUL;
• Para acessar os dados gravados…
– SELECT
USERNAME,
TO_CHAR(TIMESTAMP,'MM/DD/YY
HH24:MI')
TIMESTAMP,
OBJ_NAME,
RETURNCODE,
ACTION_NAME, SQL_TEXT
FROM DBA_AUDIT_TRAIL
WHERE ACTION_NAME IN ('LOGON','LOGOFF') AND
USERNAME IN ('SCOTT','RJB','KSHELTON')
ORDER BY TIMESTAMP DESC;
Segurança em banco de dados – Auditoria
Statement Auditing
• O resultado do select…
Diretrizes de Auditoria
1. Avaliar o propósito de auditoria, evitando auditoria
desnecessária.
2. Que tipo de atividade do BD você suspeita?
3. Quem são os suspeitos?
4. Auditar, inicialmente, de forma genérica e ir especializando.
5. Apesar do custo baixo deve-se limitar o número de eventos
auditados o máximo possível para minimizar o impacto de
performance na execução de comandos auditados