TRIGGER e SEGURANÇA. Prof. Edson Thizon

Transcrição

1 TRIGGER e SEGURANÇA Prof. Edson Thizon 1

2 Restrição de Integridade Restrição de integridade Uma regra que deve ser obedecida por todos estados da base de dados que são considerados consistentes. Especificação do maior número possível de restrições de integridade: É possível evitar que o usuário leve a base de dados inadvertidamente a um estado inconsistente. 2

3 Tipos de regras em um SGBD Considerando um determinado SGBD, as restrições de integridade podem ser classificadas em três categorias: Implícitas Nesta categoria, enquadram-se todas as restrições que podem ser declaradas (de forma não procedural) na DDL. No caso da abordagem relacional: Explícitas chave primária, integridade referencial, domínio, Nesta categoria, enquadram-se todas as restrições que devem ser explicitamente especificadas no SGBD em questão, quer através de programação, quer através de instruções especiais. Inerentes à abordagem São restrições de integridade inerentes à abordagem em questão e que não necessitam ser especificadas (na abordagem relacional, o fato de um atributo somente ter um valor) 3

4 Restrições estáticas - Restrições dinâmicas Restrições estáticas (de estado) São restrições sobre um estado da base de dados. Para verificá-las basta observar o estado atual da base de dados. Exemplos: Restrições de domínio Restrições de chave Restrições de relacionamento entre diferentes atributos (o salário do empregado não pode ser maior que o de seu gerente) 4

5 Restrições estáticas - Restrições dinâmicas Restrições dinâmicas (de transição) São restrições cuja verificação exige dois estados da base de dados, um anterior e um posterior à transição. Exemplo: O estado civil de uma pessoa, não pode mudar de casado para solteiro, mas pode mudar de viúvo para casado. Nos SGBD comerciais, normalmente não são oferecidas facilidades para garantir este tipo de restrições. O controle da restrição fica por conta de quem desenvolve as aplicações. 5

6 Restrições explícitas de integridade Definição procedural por codificação explícita Neste método, o usuário deve incluir dentro de cada transação de alteração o código correspondente a verificação da restrição. Significa: Incluir código em cada transação de inclusão, exclusão ou alteração de atributos. Uma única restrição de integridade pode ficar espalhada dentro de diversas transações Exemplo: Conseqüência: Integridade referencial entre empregado e departamento: Ao incluir um empregado, verificar se o departamento existe. Ao excluir um departamento, verificar se o mesmo está vazio. Ao alterar o departamento de um empregado, garantir que o mesmo existe. Quando restrições de integridade mudam, todos trechos de código referentes à restrição devem ser modificados. 6

7 SQL definição de restrições de integridade explícitas CHECK CONSTRAINT ASSERTION TRIGGER 7

8 CHECK CONSTRAINT Especificação declarativa de uma expressão booleana que deve ser verdadeira para todas linhas de uma tabela (valores de uma coluna) Mesma sintaxe da cláusula WHERE do SELECT Exemplo: ALTER TABLE Cliente ADD CONSTRAINT ValidaCampos CHECK (TipoCli= Pessoa Física AND CIC IS NOT NULL AND CGC IS NULL) OR (TipoCli= Pessoa Jurídica AND CIC IS NULL AND CGC IS NOT NULL) 8

9 ASSERTION Especificação declarativa de uma expressão booleana que deve ser verdadeira para toda a base de dados (pode envolver várias tabelas) CREATE ASSERTION ValidaSalario (NOT EXISTS SELECT * FROM emp WHERE emp.sal< (SELECT sal FROM emp AS ger WHERE ger.cod_emp=emp.cod_emp_ger) Implementação em SGBD é restrita (problema de performance) 9

10 TRIGGER Stored procedure que é executada automaticamente quando da atualização de uma tabela Pode ser usado para: Atualizações em cascata Verificação de restrições de integridade que não podem ser verificadas pelas restrições implícitas nem pela cláusula CHECK 10

11 Trigger Um trigger contém três partes: evento (p.ex., atualizar um campo) condição (p.ex.., uma consulta que faz um teste) ação (p.ex., exclusão, inclusão,, RAISEERROR) Quando o evento ocorre, 1. Sistema testa condição e 2. Executa ação Observação: triggers podem ter efeitos em cascata Fornecedores de SGBD não esperaram os padrões 11

12 Opções de Trigger Eventos possíveis incluem INSERT ON table DELETE ON table UPDATE [OF column] ON table INSTEAD OF Trigger pode ser ativado por FOR EACH ROW Ação é executada para cada linha modificada FOR EACH STATEMENT Ação é executada uma vez somente para todas linhas modificadas pela operação Ação de modificação pode ser executada AFTER ou BEFORE o evento (normalmente antes) 12

13 Variáveis usadas em Trigger OLD NEW A linha modificada antes da ocorrência do evento. A linha modificada após da ocorrência do evento. OLD_TABLE Uma tabela virtual que contém todas linhas modificadas no estado de antes da ocorrência do evento NEW_TABLE Uma tabela virtual que contém todas linhas modificadas no estado de após da ocorrência do evento 13

14 Exemplo de Trigger Row level CREATE TRIGGER AFTER UPDATE OF REFERENCING OLD AS OldTuple NEW AS NewTuple FOR EACH ROW NoLowerPrices preco ON Produto WHEN (OldTuple.preco > NewTuple.preco) UPDATE Produto SET preco = OldTuple.preco WHERE nome = NewTuple.nome Todos produtos com o mesmo são atualizados quando um deles é atualizado Exemplo de tratamento de redundância 14

15 Exemplo de Trigger - For each statement CREATE TRIGGER MatriculAutomaticaIntroducao AFTER INSERT ON Aluno REFERENCING NEW_TABLE AS novosalunos FOR EACH STATEMENT INSERT INTO Matricula SELECT CodigoAl, Intro001 FROM novosalunos WHERE CodigoAl NOT IN (SELECT CodigoAl FROM Matricula WHERE CodigoDisc = Intro001 ) Matricula alunos novos em Intro001 automaticamente 15

16 Exemplo de Trigger For each statement CREATE TRIGGER average-price-preserve INSTEAD OF UPDATE OF preco ON Produto REFERENCING OLD_TABLE AS OldStuff NEW_TABLE AS NewStuff FOR EACH STATEMENT WHEN (1000 < (SELECT AVG (preco) FROM ((Produto EXCEPT OldStuff) DELETE FROM Produto UNION NewStuff)) WHERE (nome, preco, empresa) IN OldStuff; INSERT INTO Produto (SELECT * FROM NewStuff) Se a média de preços cai abaixo de 1000, alteração é desprezada 16

17 Exemplo de Trigger Before Update CREATE TRIGGER ImpedeAumentoExagerado BEFORE UPDATE OF salario ON Empregado REFERENCING OLD AS o NEW AS n FOR EACH ROW WHEN (n.salario > 1.5 * o.salario) SET n.salario = 1.5 * o.salario Impede aumentos de salário de mais de 50% Observar que o conteúdo de NEW é alterado 17

18 Exemplo de Trigger - Validação CREATE TRIGGER OneSupplier BEFORE UPDATE OF CodFornec ON Embarq REFERENCING NEW AS N FOR EACH ROW WHEN (N.CodFornec IS NULL) SIGNAL SQLSTATE '70005' ( Código do fornecedor deve ser fornecido') Exemplo de Trigger para verificar restrição de integridade Forma de sinalizar erro varia de SGBD para SGBD 18

19 Trigger detalhes de implementação Chamada recursiva Ação de um trigger pode disparar outro Pode entrar em um laço infinito Interação com o teste de restrições de integridade pelo SGBD Quando testar se um trigger viola uma restrição: Após a execução de um BEFORE trigger O trigger pode consertar a violação Antes de um AFTER trigger AFTER triggers podem ver o efeito de por exemplo exclusões em cascata causadas por restirções de integridade referenciais (Baseado no DB2 cada produto tem sua política própria) 19

20 Segurança e controle de acesso A base de dados deve ser protegida contra acesso, intencional ou não, por usuários não autorizados. O controle de acesso envolve especificar ao SGBD que usuário pode realizar que tipo de operação sobre que objetos da base de dados. Além disso são necessários mecanismos de autorização, isto é, mecanismos para que o DBA delegue autorização a outros usuários para estabelecer privilégios de acesso Os mecanismos oferecidos por SGBD comerciais são normalmente fracos e não são suficientes para evitar acesso não autorizado intencional. 20

21 Criação de Usuários No Oracle o usuário DBA é o SYSTEM e a senha default é MANAGER. Para criar usuário utilize o seguinte comando: CREATE USER NOME_USUARIO IDENTIFIED BY SENHA_USUARIO; OBS: PODE SER UTILIZADO A FERRAMENTA ENTRERPISE CONSOLE OU DBA STUDIO DA ORCALE. 21

22 Segurança em SQL SQL possui uma instrução na forma: GRANT <lista de privilégios> ON <nome de tabela ou visão> TO <lista de usuários> A <lista de privilégios> permite especificar os seguintes tipos de privilégios: RESOURCE SELECT Especifica que o usuário pode criar tabelas e visões Especifica que o usuário pode ler os dados das tabelas ou visões listadas 22

23 Segurança em SQL (continuação) DELETE INSERT UPDATE Especifica que o usuário pode excluir linhas das tabelas ou visões listadas Especifica que o usuário pode incluir linhas das tabelas ou visões listadas Especifica que o usuário pode alterar linhas das tabelas ou visões listadas Este privilégio é atribuído a colunas específicas: GRANT UPDATE(saldo) ON depósito TO u1,u2 23

24 Segurança em SQL (continuação) REFERENCES Permite que um usuário crie tabelas que contém uma chave estrangeira de uma chave especificada. Também é atribuído a colunas específicas: GRANT REFERENCES(código) ON depto TO u1,u2 especifica que os usuários podem criar tabelas que referencia a chave primária da tabela de departamentos Por exclusão, um usuário não pode conceder os privilégios recebidos a outros usuários, a menos que possua autorização explícita para tal GRANT SELECT ON DEPT TO u1,u2 WITH GRANT OPTION A cláusula WITH GRANT OPTION especifica que o usuário pode também conceder seus privilégios a outros usuários 24

25 Segurança em SQL (continuação) Para revogar os direitos de acesso de um usuários é usada a instrução: REVOKE <lista de privilégios> ON <nome de tabela ou visão> FROM <lista de usuários> Quando um usuário perde um privilégio, todos os usuários que dele receberam este privilégio também o perdem. 25

26 AUDITORIA DE DADOS Para auditar informações em um banco de dados pode-se utilizar ferramentas de terceiros (como a própria auditoria fornecida por alguns SGBD) ou podemos construir a nossa própria auditoria. A seguir veremos 2 maneiras de construir auditoria de dados nos Banco de Dados utilizados pelas aplicações. 26

27 1- Auditoria sem informações históricas Esta é a maneira mais fácil e com melhor performance de termos auditoria de informações nos Banco de Dados, porém com esta implementação não teremos a história das atualizações realizadas. Para implementarmos esta auditoria criaremos alguns campos adicionais em todas as tabelas que queremos auditar no Banco de Dados. Os campos são: Data e Hora de inserção; Usuário que inseriu a informação; Data e Hora da última alteração; Usuário que alterou por último a informação; Data e hora de deleção; Usuário que deletou a informação; 27

28 1- Auditoria sem informações históricas (cont...) Exemplo: EMPREGADO CODEMP NOME SALARIO JOÃO MARIA PEDRO 1000, , ,00 Tabela empregado com colunas adicionais para auditoria CODEMP NOME SALARIO DT_INSERT USER_I DT_UPDATE USER_U DT_DEL USER_D JOÃO MARIA PEDRO 1000, , ,00 28

29 1- Auditoria sem informações históricas (cont...) EMPREGADO CODEMP NOME SALARIO DT_INSERT USER_I DT_UPDATE USER_U DT_DEL USER_D 1 JOÃO 1000,00 10/08/2004 PAULO 11:00 2 MARIA 2000,00 10/10/2004 JOSÉ 12/10/2004 PAULO 13:45 15:00 3 PEDRO 3000,00 15/10/2004 ELIZA 16/10/2004 JOSÉ 14:00 10:00 Com as colunas que acrescentamos na tabela empregado podemos descobrir que o usuário PAULO inseriu a informação do empregado João e alterou as informações do empregado Maria, também sabemos que o usuário JOSÉ inseriu as informações do empregado Maria e excluiu o empregado Pedro. Em todas estes informações sabemos a data e o horário que foi feito, porém não temos como saber quantas vezes já foram alterados os dados do empregado Maria, sabemos que o último que fez a alteração foi o usuário PAULO. Com estas colunas temos várias informações, porém não temos a história das atualizações realizadas. 29

30 2- Auditoria com informações históricas Esta é uma maneira de implementar auditoria com a história de todas as atualizações realizadas. Para implementarmos esta auditoria criaremos trigger em todas as tabelas que queremos auditar e uma tabela chamada AUDITORIA com os seguintes campos: Data e Hora; Operação (Insert, Delete ou Update); Usuário; Tabela; Dados; 30

31 2- Auditoria com informações históricas(cont...) Exemplo: EMPREGADO CODEMP NOME JOÃO MARIA PEDRO SALARIO 1000, , ,00 Tabela AUDITORIA TABELA EMPREGADO EMPREGADO EMPREGADO EMPREGADO EMPREGADO DATA 10/08/ :00 10/10/ :45 15/10/ :00 12/10/ :00 16/10/ :00 OPERACAO I I I U D USUARIO PAULO JOSÉ ELIZA PAULO JOSÉ DADOS (MEMO) (MEMO) (MEMO) (MEMO) (MEMO) Com a tabela AUDITORIA podemos descobrir que o usuário PAULO inseriu a informação do empregado João e alterou as informações do empregado Maria, também sabemos que o usuário JOSÉ inseriu as informações do empregado Maria e excluiu o empregado Pedro. Em todas estes informações sabemos a data e o horário que foi feito. Também teremos como saber quantas vezes já foram alterados os dados do empregado pois assim temos a história de todas as atualizações realizadas. 31

32 2- Implementação da auditoria com informações históricas(cont...) Criação da tabela AUDITORIA: CREATE TABLE AUDITORIA ( TABELA VARCHAR2(50) NOT NULL, DATA DATE NOT NULL, OPERACAO CHAR(1) NOT NULL, USUARIO VARCHAR2(50) NOT NULL, DADOS VARCHAR2(2000) NOT NULL); Criação da Trigger na tabela EMPREGADO: CREATE TRIGGER TRG_AUDIT_EMPREGADO AFTER DELETE OR INSERT OR UPDATE ON EMPREGADO FOR EACH ROW DECLARE DADOS VARCHAR2(2000); BEGIN IF DELETING THEN DADOS := 'CÓDIGO : ' :OLD.CODEMP NOME : ' :OLD.NOME SALÁRIO : ' :OLD.SALARIO; INSERT INTO AUDITORIA VALUES('EMPREGADO',SYSDATE,'D',USER,DADOS); END IF; IF INSERTING THEN DADOS := 'CÓDIGO : ' :NEW.CODEMP NOME : ' :NEW.NOME SALÁRIO : ' :NEW.SALARIO; INSERT INTO AUDITORIA VALUES('EMPREGADO',SYSDATE,'I',USER,DADOS); END IF; IF UPDATING THEN DADOS := 'CÓDIGO OLD: ' :OLD.CODEMP NOME OLD: ' :OLD.NOME SALÁRIO OLD: ' :OLD.SALARIO 'CÓDIGO NEW: ' :NEW.CODEMP NOME NEW: ' :NEW.NOME SALÁRIO NEW: ' :NEW.SALARIO; INSERT INTO AUDITORIA VALUES('EMPREGADO',SYSDATE,'U',USER,DADOS); END IF; END; 32

33 Referência Bibliográfica HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4ª Edição. Ed. Sagra, Capítulo: Restrições de Integridade. FERNANDES, Lúcia. Oracle 9i para desenvolvedores : Oracle developer 6i curso completo. Rio de Janeiro : Axcel Books, p. 33