Capítulo 15
Controlando o acesso
Centralizados ou distribuídos, homogêneos ou heterogêneos, bancos de dados constituem um ponto de referência e de intercâmbio de dados para diversas aplicações. Em função disso, é co- mum que um banco de dados tenha dezenas, centenas e até milhares de usuários, de diferentes categorias. Um usuário pode ser alguém que trabalha diariamente com o banco de dados, sendo responsável pela execução de operações críticas, como pode ser um ilustre desconhecido que, eventualmente, busca informações de caráter geral.
Sendo assim, o controle de acesso num banco de dados é extremamente importante, porque é preciso evitar que os usuários, intencionalmente ou não, extrapolem suas atribuições. Um ban- co de dados, sem esse controle, poderia permitir o acesso a informações confidenciais, a altera- ção indevida de dados críticos ou até mesmo a remoção de registros históricos.
Este capítulo aborda o tratamento dos aspectos de segurança de bancos de dados através de co- mandos SQL.
15.1 O QUE É UMA PERMISSÃO ?
O controle de segurança dos bancos de dados está calcado no modelo usuário × privilégio × recurso. Cada usuário que executa uma determinada operação sobre um certo recurso deve ter o devido privilégio para tal. Suponha que o usuário Pedro deseje inserir um novo registro na tabela ALUNO. Neste caso, Pedro (usuário) deve ter o privilégio insert para a tabela ALUNO (recur- so).
Uma permissão é a outorga de um privilégio, para um certo usuário, sobre um determinado recurso. Em princípio, todas as ações sobre todos os recursos, para todos os autores, estão ve- dadas e é preciso permissões para realizá-las. Permissões lidam com cinco tipos de elementos:
usuários, grupos de usuários, roles (papéis), recursos e privilégios.
Usuários
São as entidades que, em última análise, têm acesso ao banco de dados e aos seus recursos. Um usuário é identificado por um código (ou logon), e pode ter uma senha a ele associada. Um usuário pode ser cadastrado no âmbito do gerenciador do banco de dados apenas ou no âmbito do sistema operacional do computador que hospeda a base de dados. Neste caso, deve haver um protocolo de confiança entre o SGBD e o sistema operacional, de modo que o primeiro reconhe- ça os usuários do segundo. O reconhecimento de usuários do sistema operacional é bastante útil, uma vez que o cadastro de usuários necessário para que se tenha acesso às redes como aos demais recursos computacionais, como programas aplicativos e impressoras, pode ser utlizado no âmbito dos bancos dados.
Grupos de usuários
São conjuntos de usuários com características semelhantes e que, portanto, podem ser tratados coletivamente. Permissões atribuídas a um grupo valem para todos os usuários que o compõem. Grupos de usuários, normalmente, são definidos no âmbito do sistema operacional e reconhecidos pelo gerenci-
ador do banco de dados. Criar grupos de usuários, ou aproveitar grupos definidos no contexto do sistema operacional é interessante quando há um número grande de usuários com caracterís- ticas semelhantes. No nosso exemplo, certamente haveria uma política de registro de alunos, professores e funcionários que poderia ser aproveitada para definir o acesso ao banco de dados.
Recursos
Recursos constituem um conceito central num sistema de segurança. No contexto dos sistemas gerenciadores de bancos de dados, recursos são dados, programas, definições ou qualquer outro tipo de objetos ou procedimentos que possam ser alvo de alguma ação, ou acesso, por parte dos usuários de um SGBD. Embora haja um conjunto de recursos que são típicos para todos os bancos de dados, tais como tabelas e views, cada implementação define o plantel de recursos que devem estar sujeitos à política de proteção.
Privilégios
Caracterizam as ações ou procedimentos que necessitam de permissões para sua consecução. Privilégios são definidos com referência aos recursos que fazem parte do sistema de proteção. Para uma tabela, por exemplo, a possibilidade de ler, inserir, atualizar e remover registros são tipos de privilégios característicos.
Esse privilégios são identificados e atribuídos separadamente. Para ler os dados de uma tabela é preciso ter o privilégio selet sobre a mesma; inserir, atualizar e remover registros correspondem aos privilégios insert, update e delete, respectivamente. Cada tipo de recurso pode ter diferentes tipos de privilégio, dependendo da implementação.
Roles ou papéis
São conjuntos de permissões que podem ser coletivamente atribuídas. Se a um usuário ou grupo de usuários é atribuído um papel, então passam a valer para esse usuário, ou grupo, todas as permissões que caracterizam esse papel.
Roles são definidos no âmbito do banco de dados e, em certas situações, as- semelham-se aos grupos de usuários e podem substituí-los quando o agrupa- mento existente no sistema operacional não é adequado para a política de segurança do banco de dados.
Permissões podem ser garantidas explícita ou implicitamente. Uma permissão é garantida ex- plicitamente quando é direcionada diretamente a um usuário e é garantida implicitamente quan- do sua atribuição é conseqüência das regras de transitividade estabelecidas para grupos de usuá- rios, ou papéis; uma permissão atribuída a um grupo de usuários estende-se a todos os usuários desse grupo.
Como o sistema de segurança á baseado num sistema de permissões que são concedidas de uns usuários para outros, é preciso ter um ponto de partida, ou seja, um usuário que possua poderes de iniciar um processo de concessões. Todos os gerenciadores de bancos de dados, ao serem cinstalados, definem tal usuário com um logon e uma senha previamente conhecidos. A partir daí, cabe aos administradores da instalação alterar essas senhas e emitir comandos que habilitem outros usuários a utilizar os bancos de dados. Também é comum a existência prévia de grupos de usuários e/ou roles que facilitam a administração da política de segurança. Esses grupos e/ou roles pré-definidos caracterizam perfis usualmente necessários numa instalação de bancos de dados, tais como administradores de dados (DBA), pessoal de operação e manutenção, usuários read only, usuários visitantes, etc.
ESTUDO DE CASO
Embora haja semelhanças conceituais marcantes nos comandos de segurança dos diversos fabri- cantes de bancos de dados, há diferenças significativas na sua sintaxe, tornado difícil a tarefa de unificar os comandos num exemplo que possa ser de fato utilizado. Por este motivo, diferente- mente de como foi feito até aqui, vamos organizar o presente capítulo em torno de um exemplo genérico, que será adaptado para cada uma das quatro implementações SQL analisadas neste
O que é uma permissão ? 205 livro. Com isso, o exemplo será o ponto de referência, sendo que as possibilidades de imple- mentação serão exploradas separadamente em cada caso1.
Com base no nosso banco de exemplos, as premissas utilizadas para a política de segurança são as seguintes:
• Há 18 usuários que têm acesso ao banco de dados, distribuídos em 3 grupos. O primeiro grupo, Alunos, reúne todos os alunos, o segundo grupo, Docentes, reúne os professores e o ter- ceiro grupo, Funcionários, é formado pelos funcionários, técnicos e administrativos, da escola.
A tabela a seguir mostra a composição de cada grupo, os nomes dos usuários e seus logons indi- viduais aqui utilizados.
Grupo de usuários Usuários Logon
Alunado Ricardo Biondi Maria Rita Colatti Oscarito Vianna Barbara Carlito Carlos Maradona Sacadura Miranda Maria Lucia da Silva
Ricardo MariaR Oscarito Barbara CarlosM Sacadura MariaL Docentes Olivia Straw
Carlos Azambuja Marina Azambuja Pedro Amarante Zenubio Siqueira Lenira Rocha Silvia Ferreira
Olivia CarlosA Marina Pedro Zenubio Lenira Silvia Funcionários Deise Cavalcanti
Caju Rocha Alberto Takano
Sistema Registro Acadêmico
Deise Caju Alberto Sistema
• Foram identificados 6 perfis de utilização, que podem ser interpretados como roles, ou pa- péis. Cada um desses perfis é apresentado na tabela a seguir, juntamente com suas característi- cas, além da lista de usuários que se enquadram em cada categoria.
Papéis Descricão do papel Participantes
role_Alunos Define o perfil de permissões de um aluno. Permite consultar todos os dados, tanto das tabelas como pelas views; alterações são permitidas somente na coluna nascimento da tabela Aluno; remover registros não é permitido em tabela alguma.
Ricardo MariaR Oscarito Barbara CarlosM Sacadura MariaL role_Docentes Define o perfil dos professores. Permite consultar
todos os dados mas não podem fazer alterações, exceto atribuir notas (coluna nota da tabela Inscrição)
Olivia CarlosA Marina Pedro Zenubio Lenira Silvia role_Administrativos Define o papel dos usuários administrativos, da Secre-
taria da escola. Permite consultar e alterar o banco de dados, incluindo, alterando e removendo registros em todas as tabelas. Views somente podem ser lidas.
Deise
1 Alguns desenvolvedores preferem embutir nos aplicativos um sistema de proteção para os menus, telas e controles que cada usuário pode acionar. Neste caso, os programas têm acesso ao banco de dados como um tipo de usuário genérico, com permissões suficientes para cobrir todas as possíveis ações decorrentes de suas operações. A maior parte dos usuários é controlada no âmbito do aplicativo, ficando impedida de ter acesso ao banco de dados diretamente. No nosso exemplo, vamos explorar primordialmente um sistema de permissões calcado nas facilidades presentes nos bancos de dados.
role_Operadores Define o papel dos operadores do banco de dados.
Permite as tarefas de manutenção, tal como backup e recuperação do banco, alocação de espaço, etc.
Caju Alberto role_Manutenção Define o papel do pessoal de manutenção. Permite
ler e escrever em todas as tabelas e views, criar tabelas, views e constraints, backup e recuperação do banco de dados
Alberto
role_Aplicativo Define o papel dos programas aplicativos. Permite operar sobre todas as tabelas, ler views e atribuir permissões.
Sistema
role_DBA Define o papel do administrador do banco de dados.
Permite qualquer operação sobre qualquer recurso, inclusive criar e remover bancos de dados.
DBA
• Os recursos do banco de dados que são objeto de proteção são as tabelas ALUNO,CURSO,DISCI- PLINA,PROFESSOR,INSCRIÇÃO e a view v_aluno_status, além do próprio banco de dados. Os privilé- gios requeridos, além das operações básicas de inserção, alteração e remoção de registros sobre as tabelas relacionais, incluem outros que são comumente necessários para a manipulação de um banco de dados, tais como a extração de backups, os procedimentos de recuperação, a atribui- ção de permissões, a criação de tabelas, entre outros.
As próximas seções mostram a implantação dessa política de segurança em cada caso.
15.2 CONTROLANDO O ACESSO NO ACCESS
No Access, a manipulação dos comandos de segurança não pode ser feita através de comandos SQL, mas somente pela interface do sistema. Mesmo assim, é interessante conhecer os recursos disponíveis, descritos s seguir.
CARACTERÍSTICAS GERAIS DOS COMANDOS DE SEGURANÇA NO ACCESS
O Access admite dois tipos básicos de segunrança. O primeiro tipo é do tipo tudo ou nada.
Define-se uma senha secreta para o banco de dados que é solicitada no momento do acesso. O usuário que tem a senha pode ter acesso e total permissão para todos os componentes desse ban- co.
No segundo tipo, Access permite a criação de grupos de usuários que, na realidade, asseme- lham-se bastante ao conceito de papéis. As permissões podem ser atribuídas tanto para usuá- rios, individualmente, como para esse grupos. Uma permissão atribuída a um grupo de usuários é válida para todos os usuários desse grupo. Usuários podem pertencer a vários grupos e, op- cionalmente, ter senhas de acesso. Grupos podem ser criados em qualquer número, embora haja dois grupos default: administradores e usuários. No primeiro, há um usuário default, chamado administrador, criado sem senha alguma. O grupo administrador tem todas as permissões sobre todos os recursos. Cada banco de dados pode estar associado a um sistema independente de proteção, com seus próprios usuários e grupos. Para utilizar o sistema de segurança é preciso que o banco de dados passe por um processo preparatório, acionado a partirda interface de ge- renciamento do Access.
Os recursos que podem ser objeto das permissões são: o banco de dados, as tabelas, as consul- tas, os formulários, os relatórios, as macros e os módulos. Nestes, é possível escrever procedi- mentos e funções, na linguagem VBA2, acessíveis no âmbito do SQL.
A tabela a seguir mostra a aplicabilidade das permissões em relação aos tipos de recursos dispo- níveis.
2 Visual Basic for Applications, que é a linguagem de programação aceita pelo Access para codificação de procedimentos e funções.
Controlando o acesso no Access 207
Recursos
Permissão Finalidade Novas
tabelas e consultas
BD Tabelas Consultas
Abrir/executar Acesso ao banco de dados ✓
Abrir exclusivo Acesso exclusivo ao banco de dados; sem acesso exclusivo não é possível executar certas operações como, por exemplo, a com- pactação da base
✓
Ler estrutura Acesso à definição da tabela ✓ ✓
Modificar estrutura Modificação da definição de tabelas e consul- tas
✓ ✓
Administrador Este privilégio varia de acordo com o objeto ao qual é aplicado:
Para bancos de dados, permite a criação de objetos e manipulação de recursos críticos;
somente administradores podem atribuir permissões
Para tabelas e consultas, permite a alteração da estrutura e remoção de tabelas, além das operações normais sobre os dados (ler, atuali- zar e remover)
✓ ✓ ✓
Ler dados Acesso aos dados ✓ ✓
Atualizar dados Atualização dos dados ✓ ✓
Inserir dados Inserção de registros ✓ ✓
Remover dados Remoção de registros ✓ ✓
SOLUÇÃO PARA O CASO EM ESTUDO
Embora não haja um script definido para a implantação da política de segurança do nosso e- xemplo, os quadros a seguir mostram, para cada grupo de usuários e cada objeto Access, o con- junto de permissões que devem ser atribuídas através da interface de gerenciamento.
No primeiro quadro aparecem as permissões para o banco de dados, a consulta v_alunos_status e a referência a novas tabelas e consultas. Este último é um recurso imaterial do Access, que permite adiantar as permissões para novas tabelas e consultas que eventualmente venham a ser criadas.
Objetos
Grupo Access BD v_alunos_status Novas tabelas
Novas consultas role_Alunos Abrir/executar Ler dados Ler dados role_Docentes Abrir/executar Ler dados Ler dados role_Administrativos Abrir/executar Ler dados Ler dados role_Operadores Abrir/executar
Abrir exclusivo Ler dados Ler dados role_Manutenção Administrador Administrador Administrador
role_DBA Administrador Administrador Administrador
O segundo quadro mostra as permissões atribuídas aos grupos de usuários em relação às tabelas do banco de exemplos. As três tabelas grupadas têm permissões idênticas, embora as atribui- ções devam ser feitas separadamente.
Objetos
Grupo Access Aluno Curso
Disciplina Professor
Inscrição
role_Alunos Ler dados Ler dados Ler dados
Atualizar dados
Role_Docentes Ler dados Ler dados Ler dados Atualizar dados Role_Administrativos Ler dados
Atualizar dados Remover dados
Ler dados Atualizar dados Remover dados
Ler dados Atualizar dados Remover dados Role_Operadores Ler dados Ler dados Ler dados Role_Manutenção Administrador Administrador Administrador
Role_DBA Administrador Administrador Administrador
COMENTÁRIOS SOBRE A SOLUÇÃO ADOTADA
Além das tabelas e da consulta, é preciso expressar as permissões válidas para o prórpio banco de dados. As permissões sobre as tabelas ALUNO e INSCRIÇÃO não podem ser implementadas con- forme planejado. No Access, não é possível distinguir uma coluna isolada quando da atribuição de uma permissão sobre uma tabela. Por essa razão, optamos por conceder os privilégios Ler dados e Atualizar dados para aquelas duas tabelas.
15.3 CONTROLANDO O ACESSO NO MYSQL
O gerenciamento de segurança no MySQL é feito a partir de dois comandos básicos: grant e
revoke.
COMANDOS DISPONÍVEIS
<comando grant> :=
grant <privilégio> { [ ( <coluna>,... ) ] },...
on { <tabela> | * | *.* | <banco de dados>.* } to { <conta> [ identified by '<senha>' ] },...
[ require none | [ { ssl | x509 } ] [ cipher cipher [ and ] ] [ issuer issuer [ and ] ] [ subject subject ] ] [ with { grant option
| max_queries_per_hour <número>
| max_updates_per_hour <número>
| max_connections_per_hour <número> }... ]
<comando revoke> :=
revoke <privilégio> { [ ( <coluna>,... ) ] },...
on { <tabela> | * | *.* | <banco de dados>.* } from <conta>,...
∴
Os privilégios disponíveis e o emprego de cada um deles são mostrados a seguir.
Privilégio Descrição/finalidade all [ privileges ] Refere-se coletivamente a todos os privilégios, exceto a possibilidade de atribuir
permissões (privilégio grant) a outros usuários alter Alteração da definição de uma tabela
create Criação de tabelas; criação de bancos de dados; implica no privilégio insert, indireta- mente, para todas as tabelas no âmbito da permissão
create temporary tables Criação de tabela temporária delete Remoção de registros de uma tabela drop Utilização do comando drop table
execute Execução de stored procedures (para versão posterior)
file Utilização de arquivos como recepiente de resultados ou carga de dados grant option Atribuição de permissões para outros usuários
index Criação e eliminação de índices insert Inserção de registros numa tabela
Controlando o acesso no MySQL 209
lock tables Criação de locks em uma tabela
process Utilização do comando show full processlist references (reservado)
reload Utilização do comando flush
replication client Aplicável em procedimentos de replicação replication slave Aplicável em procedimentos de replicação select Utilização do comando select show databases
show databases Utilização do comando show para todos os bancos de dados shutdown Encerramento do programa de gerenciamento
super Estabelecimento de conexão mesmo quando os limites de conexão estiverem esgota- dos; execução dos comandos change master, kill thread, mysqladmin debug, purge master logs e set global
update Atualização dos registros de uma tabela
usage Privilégio inócuo, utilizado como um recurso sintático para criar usuários num coman- do grant
CARACTERÍSTICAS GERAIS DOS COMANDOS DE SEGURANÇA NO MYSQL
MySQL não reconhece a existência de roles, nem de grupos de usuários. Cada permissão deve ser definida separadamente, usuário por usuário.
∴
As informações sobre usuários são mantidas na tabela user, do banco mysql, que pode ser refe- renciada pelo nome mysql.user. Pode-se manipular o registro de usuários alterando-se direta- mente os registros dessa tabela, ou através dos comandos grant e revoke.
∴
Na instalação do MySQL, o usuário denominado root é criado automaticamente, sem senha de acesso, com plenos privilégios (inclusive grant) sobre todos os bancos de dados. Também é criado um usuário “anônimo” (cujo nome é uma string vazia), que contém todos os privilégios para qualquer banco de dados de nome test. Para implementar uma política de segurança, deve- se remover o usuário anônimo e providenciar um senha secreta para o usuário root.
∴
Para examinar as permissões atribuídas a um certo usuário, pode-se utilizar o comando show grants. No exemplo, abaixo, são mostradas as permissões do usuário root no servidor local.
show grants for root@localhost
As atribuições para os usuários default do MySQL podem ser verificadas com o comando
show grants for root
ou
show grants for ''
∴
Um usuário é criado quando é referenciado pela primeira vez num comando grant, ou pela in- clusão de um novo registro na tabela mysql.user. Assim, não há comandos específicos para criar usuários. Nomes de usuários podem ter até 16 caracteres.
∴
Num comando grant ou revoke, os nomes dos usuários são sempre referenciados no formato
<usuário>@<servidor>. Neste último, pode-se empregar os caracteres _ (sublinhado) e % (percentual) como curingas. Com isso, um comando grant como
grant ... on ... to maria@"%"
aplica-se à usuária de nome maria em todos os servidores. Comandos como
grant ... on ... to maria@"%.ufrj.br"
grant ... on ... to maria@"146.164.%.%"
também são válidos e referem-se, respectivamente, à usuária maria em todos os servidores cujo domínio termina com “.ufrj.br” e todos os servidores de uma certa subrede.
∴
A cláusula identified by serve para definir uma senha para o usuário. As senhas dos usuários podem ser alteradas pelo comando set password. Por exemplo, o comando
set password for root@"%" = password ('rabuda' )
muda a senha do usuário root em todos os servidores. A função password é utilizada para que a nova senha seja gravada em modo criptografado na tabela de controle do MySQL.
∴
MySQL permite que as permissões possam ser de caracter global, através da cláusula on no comando grant. Como pode ser observado na sintaxe apresentada, há quatro maneiras de ex- pressar o escopo de uma permissão, descritas a seguir.
<tabela> a permissão aplica-se tão somente à tabela identificada;
<banco de dados>.* a permissão aplica-se a todos os recursos do banco de dados identifica- do;
*.* a permissão aplica-se a todos os recursos de todos os bancos de dados;
* se houver um banco de dados corrente (vide comando use), a permissão aplica-se a todas as tabelas deste banco; em não havendo um banco corrente, a permissão aplica-se a todos os bancos (o mesmo que *.*).
Os caracteres _ (sublinhado) e % (percentual) podem ser usados como caracteres curinga na identificação de bancos de dados num comando grant. Um comando da forma
grant ... on teste%.* to ...
teria o efeito de atribuir algum privilégio para todos os bancos de dados cujos nomes iniciassem como a string “teste”. Se um banco de dados contém algum desses caracteres curinga no seu nome, deve-se usar o caracter de escape \ (barra invertida).
∴
Nomes de tabelas, colunas, servidores e bancos de dados referenciados em comandos grant devem ter, no máximo, 60 caracteres.
∴
A revocação de privilégios deve ser feita através do comando revoke. Entretanto, o comando deve seguir a mesma estrutura do comando grant utilizado para conceder tais privilégios. Por exemplo, considere os comandos a seguir.
grant create on *.* to maria@localhost grant select on mysql.* to maria@"%"
O primeiro atribui o privilégio create para a usuária maria na máquina local; o segundo, o privi- légio de leitura nas tabelas do banco de dados de controle mysql. O comando
revoke all on *.* to maria@"%"
não remove os privilégios de maria na máquina local, mesmo que o comando determine a re- moção de todos os privilégios em todas as máquinas. Para cancelar a atribuição do dois coman- dos acima, seria necessários dois comandos, como
revoke create on *.* to maria@localhost revoke select on mysql.* to maria@"%"
Também poderiam ser usados comandos como
revoke all on *.* to maria@localhost revoke all on mysql.* to maria@"%"
∴
Para eliminar um usuário, basta remover todos seus privilégios e executar o comando delete sobre a tabela do sistema que o contém.
Controlando o acesso no MySQL 211
revoke all on *.* to maria@localhost revoke all on mysql.* to maria@"%"
delete from mysql.user where user= 'maria' ;
∴
Sempre que as permissões são alteradas diretamente na tabela mysql.user, é preciso atualizar as permissões em vigor no sistema. Isso pode ser feito com o comando
flush privileges
que tem o efeito de carregar novamente os dados das tabelas de controle, colocando em vigor as eventuais mudanças efetuadas no esquema de segurança.
∴
Qualquer comando grant pode ser acompanhado da cláusula with grant option. Isto significa que o usuário que recebe determinado privilégio tem permissão para atribuí-lo a outros usuários.
Podem também, ser utilizadas as cláusulas with max_queries, max_queries_per_hour,
max_updates_per_hour e max_connections_per_hour, que limitam o número de acessos e operações um usuário pode emitir. Somente uma delas pode estar num comando grant. Um recurso usual é emitir vários comandos grant com o privilégio usage, que é praticamente inó- cuo, um para cada uma dessas opções.
∴
MySQL não suporta o conceito de grupos de usuários e nem o de papéis. Com isso, é preciso atribuir as permissões separadamente para cada usuário.
∴
Se um usuário tem o privilégio insert para uma tabela, os registros por ele incluídos terão, ne- cessariamente, os valores default nas colunas onde não há tal permissão.
∴
Prilégios e tabelas têm vidas independentes no MySQL. Isto significa que se uma tabela for removida, os privilégios para a mesma podem não ser removidos, a menos que isso seja feito explicitamente com um comando revoke (ou pela manipulação das tabelas de controle do MyS- QL). O mesmo ocorre para usuários e privilégios: a remoção de um usuário não implica na remoção de seus privilégios. A eventual reinclusão do mesmo usuário reativa os privilégios
“adormecidos”.
∴
As demais opções listadas na sintaxe do comando grant tratam de aspectos operacionais e não são cobertas neste livro.
SCRIPT PARA O CASO EM ESTUDO
A política de segurança descrita acima é implementada no MySQL com os comandos abaixo.
--- Criação dos usuários, ainda sem privilégio algum
grant usage on exemplos.* to ricardo@localhost identified by 'ricardo' ;
--- (aqui devem ser incluídos os comandos de criação de usuário para os demais alunos) grant usage on exemplos.* to olivia@localhost identified by 'olivia' ;
--- (aqui devem ser incluídos os comandos de criação de usuário para os demais professores) grant usage on exemplos.* to deise@localhost identified by 'deise' ;
grant usage on exemplos.* to alberto@localhost identified by 'alberto' ; grant usage on exemplos.* to caju@localhost identified by 'caju' ; grant usage on exemplos.* to sistema@localhost identified by 'sistema' ; grant usage on exemplos.* to dba@localhost identified by 'dba' ; --- Permissões para Corpo discente
grant select on exemplos.* to ricardo@localhost ; grant update (nascimento) on exemplos.aluno to ricardo@localhost ;
--- (aqui devem ser incluídos os comandos que repetem essas permissões para os demais alunos) --- Permissões para Professores
grant select on exemplos.* to olivia@localhost ; grant update (nota) on exemplos.inscricao to olivia@localhost ;
--- (aqui devem ser incluídos os comandos que repetem essas permissões para os demais professores) --- Permissões para Secretaria
grant select, insert, delete on exemplos.* to deise@localhost ; grant update on exemplos.aluno to deise@localhost ; grant update on exemplos.curso to deise@localhost ; grant update on exemplos.disciplina to deise@localhost ; grant update on exemplos.professor to deise@localhost ; grant update (coddisciplina) on exemplos.inscricao to deise@localhost ; grant update (matricula) on exemplos.inscricao to deise@localhost ; --- Permissões para Manutencao
grant create temporary tables, file, index, lock tables, process,
show databases, shutdown, super on exemplos.* to alberto@"%" ; grant select, insert, update, delete on exemplos.* to alberto@"%" ; --- Permissões para Operacao
grant process, show databases, shutdown,
super, index on exemplos.* to caju@localhost ; --- Permissões para Aplicativo
grant all on exemplos.* to sistema@"%" identified by 'sistema' with grant option;
--- Permissões para DBA
grant all on exemplos.*to dba@"%" identified by 'dba' with grant option ; COMENTÁRIOS SOBRE A SOLUÇÃO ADOTADA
Como o MySQL não reconhece grupos de usuários do sistema operacional, nem implementa o conceito de roles, cada usuário é criado e tem suas permissões atribuídas separadamente.
As primeiras linhas do script servem para criar os usuários e determinar a senha de cada um. O privilégio usage, nesse caso, apenas permite que o usuário tenha acesso aos recursos do banco de dados exemplos, porém ainda sem privilégios operacionais. Os alunos e professores são cri- ados como usuários locais, ou seja, suas permissões valem para o servidor onde o bancos de dados está instalado. Alguns dos demais usuários são criados no âmbito dos servidores.
Somente um dos alunos, Ricardo, teve seus privilégios atribuídos, uma vez que todos os demais alunos têm características idênticas. Os comandos
--- Permissões para Corpo discente
grant select on exemplos.* to ricardo@localhost ; grant update (nascimento) on exemplos.aluno to ricardo@localhost ;
determinam o privilégio de select para todos os recursos do banco exemplos e o privilégio upda- te para a coluna nascimento da tabela ALUNO. Com isso, os alunos podem atualizar suas datas de nascimento, apenas. Esses privilégios não podem ser repassados pelos alunos, pois não foram atribuídos com a opção with grant option.
Para a professora Olivia, os privilégios são semelhantes, sendo possível atualizar apenas a colu- na nota da tabela Inscrição. Os demais professores devem receber permissões equivalentes.
O conjunto de permissões do pessoal de secretaria é mais abrangente.
--- Permissões para Secretaria
grant select, insert, delete on exemplos.* to deise@localhost ; grant update on exemplos.aluno to deise@localhost ; grant update on exemplos.curso to deise@localhost ; grant update on exemplos.disciplina to deise@localhost ; grant update on exemplos.professor to deise@localhost ; grant update (coddisciplina) on exemplos.inscricao to deise@localhost ; grant update (matricula) on exemplos.inscricao to deise@localhost ;
Os privilégios de select, insert, delete valem para todos os recursos do banco exemplos. Para a tabela INSCRIÇÃO, duas colunas podem ser atualizadas (matrícula e coddisciplina), mas a coluna nota, não. Nesse caso, é necessário atribuir coluna por coluna o privilégio de update.
As permissões para o pessoal de Manutenção e Operação inclui operações realizadas sobre o banco de dados.
Controlando o acesso no Oracle 213
--- Permissões para Manutencao
grant create temporary tables, file, index, lock tables, process,
show databases, shutdown, super on exemplos.* to alberto@"%" ; grant select, insert, update, delete on exemplos.* to alberto@"%" ; --- Permissões para Operacao
grant process, show databases, shutdown,
super, index on exemplos.* to caju@localhost ;
Além de permitir qualquer operação sobre os dados das tabelas, operações com arquivos (privi- légio file), índices (index) e outras passama a ser permitidas.
Para os programas de aplicação, todos os privilégios são concedidos, inclusive o direito de atri- buir permissões para outros usuários. Isto faz com que o programa de aplicação, dependendo do usuário que o utiliza, possa atribuir permissões sob demanda, na abertuda de uma sessão de utilização do banco.
--- Permissões para Aplicativo
grant all on exemplos.* to sistema@"%" identified by 'sistema' with grant option;
O mesmo ocorre para o usuário DBA, que é o responsável pela manutenção dos banco de dados.
15.4 CONTROLANDO O ACESSO NO ORACLE
Lkjlaksjdas SYS
When any database is created, the user SYS, identified by the password CHAN- GE_ON_INSTALL, is automatically created and granted the DBA role.
All of the base tables and views for the database's data dictionary are stored in the schema SYS.
These base tables and views are critical for the operation of Oracle. To maintain the integrity of the data dictionary, tables in the SYS schema are manipulated only by Oracle; they should never be modified by any user or database administrator, and no one should create any tables in the schema of the user SYS. (However, you can change the storage parameters of the data dictio- nary settings if necessary.)
Most database users should never be able to connect using the SYS account. You can connect to the database using this account but should do so only when instructed by Oracle personnel or documentation.
SYSTEM
When a database is created, the user SYSTEM, identified by the password MANAGER, is also automatically created and granted all system privileges for the database.
The SYSTEM username creates additional tables and views that display administrative informa- tion, and internal tables and views used by Oracle tools. Never create in the SYSTEM schema tables of interest to individual users.
The DBA Role
A predefined role, named "DBA", is automatically created with every Oracle database. This role contains all database system privileges. Therefore, it is very powerful and should be granted only to fully functional database administrators.
Privilégios de sistema
CLUSTERS
create cluster Create clusters in grantee's schema
create any cluster Create a cluster in any schema. Behaves similarly to CREATEANYTABLE. alter any cluster Alter clusters in any schema
drop any cluster Drop clusters in any schema CONTEXTS
create any context Create any context namespace drop any context Drop any context namespace DATABASE
alter database Alter the database
alter system Issue ALTERSYSTEM statements
audit system Issue AUDITsql_statements statements DATABASE LINKS
create database link Create private database links in grantee's schema create public database link Create public database links
drop public database link Drop public database links DIMENSIONS
create dimension Create dimensions in the grantee's schema create any dimension Create dimensions in any schema alter any dimension Alter dimensions in any schema drop any dimension Drop dimensions in any schema DIRECTORIES
create any directory Create directory database objects drop any directory Drop directory database objects indextypes
create indextype Create an indextype in the grantee's schema create any indextype Create an indextype in any schema alter any indextype Modify indextypes in any schema drop any indextype Drop an indextype in any schema execute any indextype Reference an indextype in any schema ÍNDICES
create any index Create in any schema a domain index or an index on any table in any schema alter any index Alter indexes in any schema
drop any index Drop indexes in any schema
query rewrite Enable rewrite using a materialized view, or create a function-based index, when that
Controlando o acesso no Oracle 215
materialized view or index references tables and views that are in the grantee's own schema
global query rewrite Enable rewrite using a materialized view, or create a function-based index, when that materialized view or index references tables or views in any schema
LIBRARIES
create library Create external procedure/function libraries in grantee's schema create any library Create external procedure/function libraries in any schema drop library Drop external procedure/function libraries in the grantee's schema drop any library Drop external procedure/function libraries in any schema MATERIALIZED VIEWS
create materialized view Create a materialized view in the grantee's schema create any materialized view Create materialized views in any schema
alter any materialized view Alter materialized views in any schema drop any materialized view Drop materialized views in any schema
query rewrite Enable rewrite using a materialized view, or create a function-based index, when that materialized view or index references tables and views that are in the grantee's own schema
global query rewrite Enable rewrite using a materialized view, or create a function-based index, when that materialized view or index references tables or views in any schema
on commit refresh Create a refresh-on-commit materialized view on any table in the database. Alter a refresh-on-demand materialized on any table in the database to refresh-on-commit OPERATORS
create operator Create an operator and its bindings in the grantee's schema create any operator Create an operator and its bindings in any schema drop any operator Drop an operator in any schema
execute any operator Reference an operator in any schema OUTLINES
create any outline Create public outlines that can be used in any schema that uses outlines alter any outline Modify outlines
drop any outline Drop outlines
select any outline Create a clone private outline from a public outline PROCEDURES
create procedure Create stored procedures, functions, and packages in grantee's schema create any procedure Create stored procedures, functions, and packages in any schema alter any procedure Alter stored procedures, functions, or packages in any schema drop any procedure Drop stored procedures, functions, or packages in any schema
execute any procedure Execute procedures or functions (standalone or packaged) Reference public package variables in any schema
PROFILES
create profile Create profiles alter profile Alter profiles drop profile Drop profiles ROLES
create role Create roles
alter any role Alter any role in the database drop any role Drop roles
grant any role Grant any role in the database
ROLLBACK SEGMENTS
create rollback segment Create rollback segments alter rollback segment Alter rollback segments drop rollback segment Drop rollback segments SEQUENCES
create sequence Create sequences in grantee's schema create any sequence Create sequences in any schema alter any sequence Alter any sequence in the database drop any sequence Drop sequences in any schema select any sequence Reference sequences in any schema SESSIONS
create session Connect to the database alter resource cost Set costs for session resources alter session Issue ALTERSESSION statements
restricted session Logon after the instance is started using the SQL*Plus STARTUPRESTRICT state- ment
SNAPSHOTS. SEE MATERIALI- ZED VIEWS
SINÔNIMOS
create synonym Create synonyms in grantee's schema create any synonym Create private synonyms in any schema create public synonym Create public synonyms
drop any synonym Drop private synonyms in any schema drop public synonym Drop public synonyms
TABELAS Note: For external tables, the only valid privileges are CREATEANYTABLE, AL- TERANYTABLE, DROPANYTABLE, and SELECTANYTABLE. create table Create tables in grantee's schema
create any table Create tables in any schema. The owner of the schema containing the table must have space quota on the tablespace to contain the table.
alter any table Alter any table or view in any schema
backup any table Use the Export utility to incrementally export objects from the schema of other users delete any table Delete rows from tables, table partitions, or views in any schema
drop any table Drop or truncate tables or table partitions in any schema insert any table Insert rows into tables and views in any schema lock any table Lock tables and views in any schema
select any table Query tables, views, or materialized views in any schema update any table Update rows in tables and views in any schema TABLESPACES
create tablespace Create tablespaces alter tablespace Alter tablespaces drop tablespace Drop tablespaces
manage tablespace Take tablespaces offline and online and begin and end tablespace backups
unlimited tablespace Use an unlimited amount of any tablespace. This privilege overrides any specific quotas assigned. If you revoke this privilege from a user, the user's schema objects remain but further tablespace allocation is denied unless authorized by specific tablespace quotas.
You cannot grant this system privilege to roles.
Controlando o acesso no Oracle 217
TRIGGERS
create trigger Create a database trigger in grantee's schema create any trigger Create database triggers in any schema
alter any trigger Enable, disable, or compile database triggers in any schema drop any trigger Drop database triggers in any schema
administer database trigger Create a trigger on DATABASE. (You must also have the CREATETRIGGER or
CREATEANYTRIGGER privilege.) TIPOS DE DADOS
create type Create object types and object type bodies in grantee's schema create any type Create object types and object type bodies in any schema alter any type Alter object types in any schema
drop any type Drop object types and object type bodies in any schema
execute any type Use and reference object types and collection types in any schema, and invoke methods of an object type in any schema if you make the grant to a specific user. If you grant
EXECUTEANYTYPE to a role, users holding the enabled role will not be able to invoke methods of an object type in any schema.
under any type Create subtypes under any nonfinal object types.
USUÁRIOS
create user Create users. This privilege also allows the creator to: 1)Assign quotas on any tablespa- ce 2) Set default and temporary tablespaces 3)Assign a profile as part of a CREATE USER statement
alter user Alter any user. This privilege authorizes the grantee to: 1) Change another user's pass- word or authentication method 2) Assign quotas on any tablespace 3) Set default and temporary tablespaces 4) Assign a profile and default roles
become user Become another user. (Required by any user performing a full database import.)
drop user Drop users
VIEWS
create view Create views in grantee's schema create any view Create views in any schema drop any view Drop views in any schema
under any view Create subviews under any object views DIVERSOS
analyze any Analyze any table, cluster, or index in any schema
audit any Audit any object in any schema using AUDITschema_objects statements comment any table Comment on any table, view, or column in any schema
exempt access policy Bypass fine-grained access control Caution: This is a very powerful system privilege, as it lets the grantee bypass application-driven security policies. Database administrators should use caution when granting this privilege.
force any transaction Force the commit or rollback of any in-doubt distributed transaction in the local databa- se. Induce the failure of a distributed transaction
force transaction Force the commit or rollback of grantee's in-doubt distributed transactions in the local database
grant any privilege Grant any system privilege resumable Enable resumable space allocation
select any dictionary Query any data dictionary object in the SYS schema. This privilege lets you selectively override the default FALSE setting of the
O7_DICTIONARY_ACCESSIBILITY initialization parameter. Note: This privi- lege must be granted individually. It is not included in GRANTALLPRIVILEGES,
nor can it be granted through a role.
sysdba Perform STARTUP and SHUTDOWN operations; ALTERDATABASE: open, mount, back up, or change character set; CREATEDATABASE; ARCHIVELOG
and RECOVERY; CREATESPFILE Includes the RESTRICTEDSESSION
privilege
sysoper Perform STARTUP and SHUTDOWN operations ALTERDATABASEOPEN | MOUNT | BACKUP ; ARCHIVELOG and RECOVERY ; CREATESPFILE
; Includes the RESTRICTEDSESSION privilege
15.5 CONTROLANDO O ACESSO NO SQLSERVER
A implementação das políticas de segurança no SQL Server é feita através dos comandos grant,
revoke e deny, cuja sintaxe é mostrada a seguir.
<comando grant privilégio-comando> :=
grant { all | <privilégio-comando>,... } to <conta>,...
<comando grant privilégio-objeto> :=
grant { all [ privileges ] | <privilégio-objeto>,... } {
[ ( <coluna>,... ) ] on { <tabela> | <view> } | on { <tabela> | <view> } [ ( <coluna>,... ) ] | on { <stored procedure> | <extended procedure> } }
to <conta> ,...
[ with grant option ] [ as { <grupo> | <role> } ]
<privilégio-comando> :=
{ create database | create default | create procedure | create rule | create table | create view | backup database | backup log }
<privilégio-objeto> :=
{ select | update | insert | delete | references | execute }
<comando deny privilégio-comando> :=
deny { all | <privilégio-comando>,... } to <conta>,...
<comando deny privilégio-objeto> :=
deny { all [ privileges ] | < privilégio-objeto>,... } {
[ ( <coluna>,... ) ] on { <tabela> | <view> } | on { <tabela> | <view> } [ ( <coluna>,... ) ] | on { <stored procedure> | <extended procedure> } } to <conta> ,...
[ cascade ]
<comando revoke privilégio-comando> :=
deny { all | <privilégio-comando>,... } to <conta>,...
<comando revoke privilégio-objeto> :=
revoke [ grant option for ] { all [ privileges ] | < privilégio-objeto>,... } { [ ( <coluna>,... ) ] on { <tabela> | <view> }
| on { <tabela> | <view> } [ ( <coluna>,... ) ] | on { <stored procedure> | <extended procedure> }
Controlando o acesso no SQL Server 219
}
{ to | from } <conta> ,...
[ cascade ]
[ as { <grupo> | <role> } ]
O comando grant serve para outorgar as permissões, e o comando revoke serve para retirá-las.
Uma permissão pode ser aplicada a quatro tipos de contas: usuários e roles registrados no servi- dor SQL Server, usuários e grupos de usuários registrados no Windows. Na sintaxe acima,
<conta> representa o recipiente da permissão.
O comando deny, por sua vez, serve para negar permissões que são concedidas implicitamente, para certos usuários, porém sem cancelar essas mesmas permissões os demais usuários de gru- pos ou roles. Por exemplo, suponha que um grupo de usuários A, B, C tenha as permissões X e Y. Com o comando deny é possível negar a permissão X ao usuário A sem afetar as permissões dos demais componentes do grupo.
O SQL Server possui alguns roles pré-definidos, que podem ser utilizados mas não modificados.
Há dois tipos: os roles que valem no âmbito do servidor (para todos os bancos de dados) e os que valem somente para um banco de dados específico.
Os roles pré-definidos que valem no âmbito de um servidor SQL Server são mostrados a seguir.
Roles (Servidor) Descrição/finalidade
sysadmin Execução de qualquer comando no servidor serveradmin Configuração dos parâmetros do servidor
setupadmin Gerenciamento de servidores vinculados e execução de algumas stored procedures securityadmin Gerenciamento da segurança no servidor
processadmin Gerenciamento dos processos que são executados no servidor dbcreator Criação e alteração de bancos de dados
diskadmin Gerenciamento dos discos e arquivos utilizados no servidor
Os roles listados acima possuem permissões para execução de comandos de acordo com a o quadro a seguir.
Roles (Servidor) Comandos que
podem ser execu- tados
serveradmin setupadmin securityadmin processadmin dbcreator diskadmin
alter database ✓
create database ✓
dbcc ✓
deny ✓
grant ✓
kill ✓
reconfigure ✓
restore ✓
revoke ✓
shutdown ✓
Os papéis setupadmin e diskadmin não possuem permissões para comandos, mas apenas para algumas stored procedures. Não é possível criar novos papéis fixos no âmbito do servidor, somente no âmbito de um banco de dados.
Os roles pré-definidos no âmbito dos bancos de dados são mostrados abaixo.
Roles (BD) Descrição
db_owner Este privilégio engloba todas as permissões positivas dos demais roles (execto os nega- tivos) de bancos de dados, além de algumas tarefas de manutenção e configuração db_accessadmin Gerenciamento de acesso para usários do Windows (grupos e usuários simples) e
usuários do servidor
db_datareader Leitura de todos os dados no banco de dados
db_datawriter Inserção, alteração e remoção para todos os dados do banco de dados
