|
4. Segurança e Integridade
Segurança refere-se à proteção de dados contra a divulgação, alteração ou destruição não-autorizadas. Garante que os usuários tem permissão para fazer o que estiverem tentando fazer.
Integridade refere-se à precisão ou validade dos dados. Garante que as coisas que os usuários estão tentando fazer estão corretas.
4.1. Segurança
Diferentes usuários podem ter diferentes acessos ao mesmo dado. Um determinado usuário pode ter acesso somente de leitura (SELECT), enquanto outro usuário, pode ter acesso tanto para leitura (SELECT) quando para atualização (UPDATE).
Há inúmeros aspectos relativos ao problema de segurança, conforme citados abaixo: 1) Aspectos legais, sociais e éticos, tal como solicitar a consulta do salário de uma determinada pessoa hierarquicamente superior, sem que tenha acesso para verificar tal dado; 2) Controles físicos, relativos aos equipamentos de armazenamento dos dados; 3) Questões políticas de como a empresa decide quem deve ter acesso a que; 4) Problemas Operacionais, através de utilização de senhas e como manter essas senhas em segredo; 5) Controles de Hardware; 6) Segurança do sistema operacional, quanto a destruição dos dados e arquivos de dados no final da utilização do processamento dos mesmos.
Todas as decisões referentes aos direitos que devem ser concedidos a tal usuário são decisões políticas, e não técnicas. Como tais, fogem claramente à competência do SGBD propriamente dita; tudo o que o SGBD pode fazer é reforçar aquelas decisões, uma vez que tenham sido tomadas.
A fim de proteger o banco de dados, medidas de segurança precisam ser tomadas em diversos níveis: · Físico: O local ou locais onde os sistemas de computadores estão localizados precisam estar fisicamente protegidos.
· Humanos: Critérios cautelosos de autorização devem ser dados aos usuários, visando evitar acessos indevidos aos dados e até mesmo as instalações.
· Sistema Operacional: Embora os Banco de dados possa ter várias formas de controle de autorização, o Sistema Operacional também deve estar protegido de forma a impedir que acessos indevidos, por meios não oficiais, permitam a alguém interferir nos dados armazenados, ocasionando perda de segurança.
· Sistema de Banco de Dados: Limites de autorização a porções dos dados armazenados devem ser estabelecidas, de forma a nortear as autorizações e permissões dos usuários sobre os dados armazenados.
v Autorizações
Um usuário pode ter diversas formas de autorização a partes do banco de dados. Pode ter todas, alguma ou nenhuma das autorizações. Entre essas estão as seguintes:
1) Autorização de Leitura: permite somente leitura e não a modificação dos dados; 2) Autorização de Inserção: permite a inserção de novos dados mas não a modificação dos dados existentes; 3) Autorização de Atualização: permite a modificação dos dados existentes; 4) Autorização de Eliminação: permite a eliminação dos dados.
Além das autorizações para Acesso a Dados, pode ser concedida a um usuário autorização para modificar o esquema do banco de dados:
1) Autorização Índice: permite a criação e remoção de índices; 2) Autorização Recursos: permite a criação de novas relações (tabelas); 3) Autorização Alteração: permite a adição ou remoção de atributos em uma relação(tabela); 4) Autorização Remoção: permite a remoção de relações.
Autorização Alteração e Remoção diferem, no sentido de que a Alteração é limitada a remoção de colunas, e se todas as colunas de uma tabela forem eliminadas, a mesma ainda existirá, porém vazia. Já a Remoção elimina a tabela toda.
Quando um determinado usuário possui a Autorização de Recurso, todos os outros privilégios de acesso sobre essa relação também lhe são permitidos.
A Autorização Índice parece desnecessária, mas devemos lembrar que o índice é um dos fatores de controle de desempenho. Além do mais, a criação indiscriminada de índices implica numa maior capacidade de armazenamento da instalação além de aumentar o tempo de atualização nos casos de modificações nos dados do banco de dados.
A forma mais alta de autoridade sobre um Banco de Dados é dada ao DBA - Administrador do Banco de Dados. Cabe ao DBA autorizar novos usuários, reorganizar o banco de dados, etc.
v Especificação de Segurança em SQL
A linguagem de definição de dados SQL inclui comandos para conceder e revogar privilégios:
Para controle dos privilégios o SQL dispõe de duas instruções:
GRANT
O Comando GRANT é usado para conferir autorização.
A forma básica deste comando é: grant <lista de privilégios> on <nome da relação ou visão> to <lista de usuários> Ex1: Autorização de SELECT aos usuários U1 e U2 para a tabela T1 grant select on T1 to U1, U2
Ex1: Autorização de UPDATE aos usuários U1 e U2 para a tabela T1 Parcial: somente para o Atributo A1 de T1 grant update(A1) on T1 to U1, U2 Total: para todos os atributos de T1 grant update on T1 to U1, U2
Para permitir que um usuário (U1) conceda o privilégio que terá para outro usuário (U2), o formato do Grant atribuído a U1 será: grant select on T1 to U1 with grant option
REVOKE O Comando REVOKE é usado para revogar autorizações. A forma básica deste comando é: revoke <lista de privilégios> on <nome da relação ou visão> from <lista de usuários> Ex1: Para revogar os privilégios concedidos acima temos: revoke select on T1 from U1, U2 revoke update(A1) on T1 from U1, U2 revoke update on T1 from U1, U2
v Criptografia
A criptografia é uma das formas complementares de controle de segurança utilizadas no sistema. Ela consiste em alterar alguns dados armazenados (principalmente chaves de acesso) de forma a torná-lo ilegível e dessa forma, o acesso restrito.
v Visões
Uma visão é tanto uma forma de disponibilizar para um determinado usuário, porções do banco de dados, do interesse do mesmo, escondendo, dessa forma, outras partes não necessárias, como também uma forma de simplificar o uso do sistema aumentando assim a segurança do mesmo
Uma visão é definida na SQL usando o comando create view. Para definir uma visão, precisamos dar a ela um nome e definir a consulta que a processa.
Forma: create view <nomevisao> as <expressão de consulta>
onde, <expressão de consulta> é qualquer consulta SQL válida.
Como exemplo, considere a visão consistindo em nomes de agências e de clientes.
Create view todos_clientes as (select Nome_Agencia,Nome from clientes, depositos, agencias where clientes.Cod_Cliente = depositos.Cod_Cliente and depositos.Cod_Agencia = agencias.Cod_Agencia) union (select Nome_Agencia,Nome from clientes, emprestimos, agencias where clientes.Cod_Cliente = emprestimos.Cod_Cliente and emprestimos.Cod_Agencia = agencias.Cod_Agencia)
Nomes de visões podem aparecer em qualquer lugar onde o nome de uma relação possa aparecer. Usando a visão todos_clientes, podemos achar todos os clientes da agência “Princesa Isabel”, escrevendo:
select Nome from Todos_clientes where Nome_Agencia = “Princesa Isabel”
Uma modificação é permitida através de uma visão apenas se a visão em questão estiver definida em termos de apenas uma relação do atual banco de dados relacional.
Ex: Selecionando tuplas de empréstimos.
Create view Emprestimo_Info as (select Cod_Agencia,Numero_Emprestimo, Cod_Cliente from emprestimos)
Uma vez que a SQL permite a um nome de visão aparecer em qualquer lugar em que um nome de ralação aparece, podemos escrever:
insert into Emprestimo_Info values (1,40,7)
Esta inserção é representada por uma inserção na relação emprestimos, uma vez que empréstimos é a relação a partir do qual a visão emprestimo_info foi construída. Devemos, entretanto, ter algum valor para quantia. Este valor é um valor nulo. Assim, o insert acima resulta na inserção da tupla: (1,40,7,null) na relação emprestimos.
Desta mesma forma, poderíamos usar os comandos update, e delete.
É importante observar que podemos usar os comandos de modificação de dados: insert, update e delete sobre uma visão somente quando esta for criada sobre uma única relação.
Para apagar uma visão, usamos o comando:
drop view <nomevisão>
ex: drop view emprestimo_info
4.2. Integridade
Quando fala-se em manter a integridade de dados, considera-se não somente Integridade Física aos arquivos portadores do banco de dados, como também manter a qualidade dos dados armazenados em termos de precisão e consistência.
As restrições de integridade fornecem meios para assegurar que mudanças feitas no banco de dados por usuários autorizados não resultem na perda da consistência dos dados.
v Restrições de Domínio
Domínio é uma lista de valores que precisa estar associada a todo atributo, são a forma mais elementar de restrição de integridade. São facilmente testadas pelo sistema a cada vez que um novo item de dado é inserido no banco de dados.
v Integridade Referencial
Frequentemente, desejamos assegurar que um valor que aparece em uma relação para um dado conjunto de atributos, aparece também para um certo conjunto de atributos em outra relação. Isto é chamado de Integridade Referencial.
Considerando:
Considerando K1 como sendo chave primária de E1 e Kn como sendo chave primária de En, temos em R tuplas que serão identificadas inclusive por K1 e Kn (sendo chaves estrangeiras). Percebe-se que não poderá existir um elemento K1 em R que não faça parte de E1 e nem Kn em R que não faça parte de En.
Seja r1 e r2 relações com chaves primárias K1 e K2, respectivamente. Dizemos que um subconjunto a de r2 é uma chave estrangeira associada a K1, na relação r1, se é garantido que, para todo t2 em r2, existe uma tupla t1 em r1, tal que t1[k]=t2[a]. Exigências desse tipo são chamadas de regras de integridade referencial ou subconjunto dependente. Dessa forma, pode-se escrever a regra de integridade referencial como: pa(r2) Í pk(r1).
v Modificação do banco de dados
As modificações no banco de dados podem causar violações de integridade referencial. Considerações devem ser feitas ao inserir, remover e atualizar tuplas.
Inserir. Se uma tupla t2 é inserida em r2, o sistema precisa assegurar que existe uma tupla t1 em r1 tal que t1[k]=t2[a]. Isto é, t2[a] e pk(r1)
Remover. Se uma tupla t1 é removida de r1, o sistema precisa computar o conjunto de tuplas em r2 que referencia t1:
s a= t1[k](r2)
Se este conjunto não for vazio, o comando remover é rejeitado como um erro, ou as tuplas que se referem a t1 precisam elas mesmas ser removidas. A última solução pode levar a uma remoção em cascata, uma vez que as tuplas precisam referir-se a tuplas que se referem a t1 e assim por diante.
Atualizar. Precisamos considerar dois casos para atualização: a atualização da relação referenciadora (filha - r2) e atualização da relação referenciada (pai - r1).
· Se a tupla t2 é atualizada na relação r2 e a atualização modifica valores para a chave estrangeira a, então é feito um teste similar para o caso de inserção. Digamos que t2 denote o novo valor da tupla t2’. O sistema precisa assegurar que: t’2 [a]Î pk (r1)
· Se a tupla t1 é atualizada em r1, e a atualização modifica valores para a chave primária (K), então é feito um teste similar ao caso remover. O sistema precisa computar: s a = t1[k](r2)
v Integridade Referencial em SQL
A SQL original padrão não incluia instruções para especificar chaves estrangeiras. Um subsequente “recurso de aperfeiçoamento de integridade” foi aprovado como uma adição ao padrão. Este recurso permite a especificação de chaves primárias, candidatas e estrangeiras como parte da instrução create table.
v A cláusula primary key da instrução create table inclui uma lista de atributos que compreende a chave primária; v A cláusula unique da instrução create table inclui uma lista de atributos que compreende a chave candidata; v A cláusula foreign key da instrução create table inclui uma lista de atributos que compreende a chave estrangeira e o nome da relação referida pela chave estrangeira.
Criando as relações clientes, agencias e depósitos para o esquema do banco.
Create table Clientes (cliente_cod int not null, cliente_nome char(30) not null, rua char(30), cidade char(30), primary key (Cliente_Cod))
Create table Agencias (agencia_cod int not null, agencia_nome char(30), agencia_cidade char(30), primary key (Agencia_Cod))
Create table Depositos (agencia_cod int not null, conta_numero char(10) not null, cliente_cod int not null, saldo real, primary key (agencia_cod,Conta_Numero), foreign key (cliente_cod) references clientes, foreign key (agencia_cod) references agencies, Check (Saldo >=0) )
A cláusula Check garante integridade para os valores dos atributos e pode fazer referência, inclusive, a valores de atributos em outras tabelas.
Embora tenhamos incluído a cláusula not null, para os campos que compõem a chave primária de cada tabela, estes não são necessários. A SQL assume que todos os campos chaves não permitam valores nulos.
v Triggers
Triggers (gatilhos) são formas de se garantir que se determinada ação for tomada sobre uma tabela, esta disparará alguns procedimentos automáticos com funções específicas. Serão detalhados no capítulo 6. Exercícios – SQL
Considerando o esquema do banco de dados “NorthWind”, fazer os comandos que se seguem:
Construir as seguintes visões do banco de dados:
1. Consultar todos os clientes em ordem crescente da cidade onde moram. Retornar: código, nome do cliente e a cidade. Dar à visão o nome vw_Clientes 2. Consultar o preço médio dos produtos para cada categoria. Retornar: código da categoria, nome da categoria e o preço médio. 3. Consultar todos os nomes de empresas (clientes e/ou fornecedoras). Após criar as visões, observar no Enterprise Manager como estas fazem parte dos objetos “visões” definidas para o banco Northwind. Fazer consultas SQL, usando as visões recém criadas: 1. Consultar todas os clientes que moram na cidade de 'Caracas'. |