Outorgando privilgios para acesso objetos no Firebird

Pensar em segurana no seu banco de dados, envolve definir direitos de acesso aos elementos disponveis: tabelas, procedimentos e gatilhos. estes direitos de acesso chamamos privilgios, que podem ser concedidos ou revogados a um usurio ou grupo de usurios. Privilgios so outorgados diretamente aos usurios ou roles, atravs do comando SQL GRANT e revogados atravs do comando SQL REVOKE. Ainda muito grande o nmero de desenvolvedores que no utilizam amplamente estes recursos de segurana em seus bancos de dados, talvez por desconhecerem as vantagens que isto representa. Usurios Os usurio de um banco de dados Firebird ficam armazenados em um banco de dados nico (ISC4.GDB), e aplicam-se qualquer banco de dados manipulado pelo servidor, independente do nmero de bancos de dados distintos que iro ser acessados. Ao fazer a conexo ao servidor/banco de dados sempre deve ser informado um usurio vlido para o servidor, atravs do seu nome e senha. Existe um usurio com poderes plenos, chamado SYSDBA, que normalmente o usurio utilizado para criar novos bancos de dados e manipular os direitos para os demais usurios. Sempre que voc ver a expresso public, isto significa TODOS os usurios disponveis no servidor. Usando Roles Uma ROLE um bilhete contendo um conjunto de privilgio(s) para uma ou mais tabelas ou vises. Sempre que um bilhete destes concedido um usurio ele passa a ter todos os privilgios do bilhete. Apenas um bilhete pode ser concedido por usurio. Um usurio ao conectar-se ao servidor pode fornecer uma role, e se esta estiver associada ao usurio, ele passa a obter as concesses desta. Se ele no utilizar a role ele ter apenas os direitos que lhe cabem diretamente ou repassados por outros usurios. O uso de roles no obrigatrio, mas pode ser muito til em ambientes com muitos usurios e uma diversidade ampla de perfis. Notao Uma palavra com a letra final 's' entre parnteses significa uma ou mais entidades daquele tipo. Por exemplo: usuario(s): uma lista de um ou mais usuarios do SGBD (separados por virgula); Uma palavra reservada entre colchetes significa que seu uso opcional. Possveis alternativas para uma parte de um comando sero separadas pela barra vertical: | Palavras reservadas sero escritas simultaneamente em negrito e itlico.

Nomes de objetos criados por usurios sero escritos com a fonte normal.
Usaremos indistintamente minusculas (prefervel) ou maiusculas para palavras reservadas. Por exemplo: GRANT ou grant.

Sintaxe do comando GRANT grant [select | insert | delete | update | references | execute | all] on [table tabela(s)] to [usuario(s) | role(s) | procedures(s) | public] [with [ grant | admin ] option] Tipos de privilgios Privilgios de acesso:

Aplicam-se tabelas e vises do banco de dados. Pode ser dado um grant uma tabela ou viso dos seguintes tipos:
select: direito de consultar, isto , enxergar os dados de uma tabela/viso; insert: direito de inserir dados em uma tabela; delete: direito de excluir dados de uma tabela;

update: direito de alterar dados de uma tabela. Podem ser especificados ainda restries apenas para determinadas colunas da tabela.
references: o privilgio que permite definir numa outra tabela, digamos dependentes, uma chave estrangeira para a Chave Primria da tabela em questo all: Garante todos os privilgios Privilgios de execuo Aplicam-se procedimentos e gatilhos (stored procedures e triggers) atravs da clusula execute. Privilgios relacionados usurios Comearemos exemplificando os privilgios que podem ser concedidos usurios sobre tabelas e colunas. Neste exemplo, todos privilgios so concedidos todos usurios na tabela minhatabela: grant all on minhatabela to public Aqui o usurio "bigboss" recebe o direito de atualizar a coluna salario da tabela funcionarios: grant update salario on funcionarios to bigboss Para permitir que o usurio bob possa definir Chave Estrangeira em sua(s) tabelas(s) referenciando a Chave Primria de Funcionarios: grant references on funcionarios to bob Passos para criar/usar uma role: Para criar uma role usa-se o comando CREATE ROLE com a seguinte sintaxe: create role nomedarole Para conceder privilgios uma role, procede-se da mesma forma como se fosse um usurio comum: grant privilegio(s) on tabela(s) to nomedarole Para conceder uma role um ou mais usurios, usa-se novamente o comando GRANT: grant rolename(s) to user(s) Para conectar-se ao servidor usando uma role (via ISQL): connect bancodedados user usuario password senha role nomedarole

Passagem de privilgios de um usurio para outro Inicialmente somente o criador de um objeto (tabela, view, stored procedure, trigger, etc) possui todos os privilgios sobre o objeto e ningum mais. O criador pode ento conceder privilgios (discriminadamente) a outros usurios com um dos comandos vistos anteriormente. O direito de passar privilgios adiante pode ser concedido caso o criador inclua a opo with grant option no final do comando grant. Exemplo: grant all on minhatabela to martina with grant option Vemos que a usuria martina adquire o direito de passar a qualquer usurio os privilgios de acesso que tenha (no caso todos) sobre a tabela minhatabela De forma semelhante, uma role pode ser passado adiante se foi concedido pelo seu criador com a opo with admin option: grant rolename(s) to user(s) with admin option Privilgios relacionados com stored procedures e triggers Para que usurios possam executar uma stored procedure, o seu criador deve conceder o privilgio de execuo (execute) dessa stored procedure a esses usuarios via comando: grant execute on procedure procedure(s) to usuario(s) Para que outras storeds procedures ou triggers possam chamar esta stored procedure o criador dela deve emitir o comando: grant execute on procedure procedure to outraprocedure(s)| outratrigger(s) Para permitir que uma stored procedure ou trigger possa executar operaes de acesso/atualizao sobre uma tabela o criador da tabela (ou o criador da stored procedure, caso tenha o(s) privilgio(s) apropriados sobre a tabela) deve executar o comando: grant privilegio(s) on [table] tabela(s) to procedure procedure Revogao de privilgios Atravs do comando SQL revoke. Sintaxe: revoke privilgio(s) on [table] tabela from usuario(s)| procedure(s)| trigger(s)| role(s) Restries gerais sobre revogao de privilgios: Apenas o usurio que outorgou privilgio(s) (via grant ) pode revog-lo(s) de um ou mais usurios. Privilgio(s) outorgados por outros usurios (mesmo que idnticos) no so afetados, ou seja, privilgios so cumulativos. Por exemplo: se ambas, Ana e Beatriz, outorgaram um privigio a Clara atravs do comando: grant insert on departments to Clara, e posteriormente Ana revoga o privilgio de Clara via comando: revoke insert on departments from Clara, Clara continua podendo inserir linhas em departments pois ainda retm o privilgio concedido por Beatriz.

Ao revogar de um usurio joao privilgio(s) concedido(s) com grant option, o(s) privilgio(s) (so) automaticamente removido(s) de todos os usurios a quem joao tenha repassado esse(s) privilgio(s) Obs: no padro SQL2 este efeito conseguido acrescentando a palavra reservada cascade; se, no entanto, a palavra reservada restrict fosse acrescentada, o comando falharia caso houvesse privilgios repassados por joao outros usurios. Privilgio(s) concedidos a todos os usurios via grant ... to public s podem ser revogados de public. Isto implica que se o mesmo privilgio foi concedido individualmente a um usurio, ele continua retendo-o, pela regra 2 acima. Alm disso, revogar de public no afeta privilgios outorgados stored procedures. Tambm a opo with grant option pode ser revogada sem afetar os privilgios recebidos no mesmo comando grant. Obs: isto pode causar uma possvel inconsistncia caso o usurio joao de quem estamos revogando o grant option, tenha repassado privilgios a outros usurios, e que os manteriam; veja os comentrios acima sobre o tratamento dado pelo padro SQL2. Exemplos: revoke execute on procedure minhaprocedure from joao revoke minharole from mario revoke update on minhatabela from minharole revoke grant option for all on minhatabela from christian revoke insert, update on accounts from procedure money_transfer, act_maint trigger show_user revoke grant option for select on departments from Ana Facilitando sua vida Realmente havemos de convir que a manuteno de direitos, usurios e roles, uma tarefa penosa, especialmente se tiver que ser executada manualmente. Por isto, altamente recomendvel que alm de uma boa documentao sobre usurios disponveis, perfis (atravs de roles), e um mapeamento de tabelas/procedures restritas, uma ferramenta grfica facilitar em muito suas tarefas. Existem vrias opes, algumas gratuitas (esto disponveis no site da Comunidade Firebird de Lngua Portuguesa para download), para administrao de segurana, escolha a sua e mos obra! Trabalhando com usurios Firebird nas aplicaes Para um correto manejo dos usurios no Firebird, ser preciso escolher uma sute de componentes que acesse a API do Firebird, manipulando diretamente as funes de criao, alterao e excluso de usurios e privilgios. Entre estas poderamos destacar a FIB+ e IBO que oferecem recursos adicionais ao desenvolvedor. Voc pode (e deve) balancear a sua segurana entre usurios do Firebird e usurios cadastrados pela aplicao. Para mais informaes sobre esta e outras tcnicas de segurana, recorra ao artigo Uma viso prtica de segurana em Aplicaes com Firebird.

Artigo Original Paulo Vaz

(Colaborador da CFLP)

paulo@multi-informatica.com.br

Comunidade Firebird de Lngua Portuguesa Visite a Comunidade em: http://www.comunidade-firebird.org

A Comunidade Firebird de Lngua Portuguesa foi autorizada pelo Autor do Original para divulgar este trabalho