O Firebird é um SGDB (Sistemas Gerenciadores de Bancos de Dados) relacional ainda bastante utilizado, principalmente por desenvolvedores Delphi e Lazarus, quando o projeto esta relacionado a pequenas ou médias aplicações destinadas a desktop ou redes locais. De forma geral o Firebird possui alguns pontos positivos, pincipalmente após a versão 3.0, onde melhorias significativas foram implementadas. Uma grande melhoria se refere a possibilidade de criação de "User Functions" (funções do usuário) sem a necessidade de utilização de bibliotecas externas, os antigos UDFs. Mas um ponto bastante discutível com relação ao Firebird esta relacionado à segurança das informações quando se tem acesso físico aos seus arquivos. Mesmo com a possibilidade de se alterar a senha do usuário padrão (SYSDBA) durante o processo de instalação, que antes da versão 3.0 ficava restrito a "masterkey", a sua segurança ainda é bastante frágil neste tipo de situação. Basta que o usuário copie o arquivo de banco de dados para uma instalação onde ele próprio tenha definido a senha de super usuário para que o acesso seja irrestrito.

Desta forma pretendemos com este artigo apresentar alguma dica onde, se não garante uma segurança absoluta e irrestrita, ao menos dificulta o acesso não autorizado às nossas bases de dados.

Uma solução já bastante conhecida é a criação de uma "ROLE" com nome de "SYSDBA". Isto é útil quando se utiliza um segundo usuário como owner (proprietário) das tabelas, views, procedures e qualquer outro recurso da base de dados. Caso um usuário estranho ao sistema tente acesso utilizando o super usuário SYSDBA o servidor gera um erro provocado pelo conflito entre o nome de usuário pretendido e a existência de uma ROLE com o mesmo nome. Mas tenha certeza, esta é uma medida paliativa, não garante de forma alguma que sua base não será acessada.

Uma possível solução que gostaríamos de apresentar é a criação de uma "Database Trigger" que verifique alguns parâmetros e conforme o resultado libere ou não o acesso à base de dados. As triggers tradicionais são bastante utilizadas, até mesmo sem a percepção dos usuários menos experientes. A criação de chaves primárias (autoincrement), por exemplo, faz uso de uma trigger e um generator para manter a ordem crescente do código de identificação de registros. Estas triggers tradicionais são disparadas normalmente quando alguns eventos específicos ocorrem na tabela à qual a prórpia trigger foi associada. Os eventos são: inserting, updating ou deleting. Ou seja, estas triggers são disparadas quando algo é inserido, atualizado ou excluído da tabela à qual a trigger foi vinculada. Já as "Database Triggers" são disparadas quando eventos específicos ocorrem com o próprio banco de dados. Estes eventos são: connect, disconnect, transaction start, transaction commit e transaction roolback. Para nossa dica de hoje vamos focar no evento "connect", ou seja, criaremos uma database trigger que será disparada quando uma nova conexão for feita com nosso arquivo de banco de dados.

Vejamos o vídeo que ilustra nossa dica.

De forma resumida, como visto no vídeo, nossa implementação de segurança utiliza uma "database trigger" vinculada ao evento "connect" do banco de dados. Durante a execução da database trigger é verificado o valor da variável de contexto "CURRENT_USER". Se esta variável traz a informação de um usuário diferente daquele que de fato pode fazer acesso à base de dados uma exception é disparada, mesmo caso o usuário seja um super usuário (SYSDBA). Desta forma o acesso fica restrito a somente usuários autorizados. Podemos ainda utilizar outros recursos dentro de nossa trigger, como por exemplo, dados das tabelas de monitoramento do Firebird, no caso, a MON$ATTACHMENTS. Comparando estas informações com aquelas que de fato são permitidas podemos restringir ainda mais o acesso aos recursos de nossa base de dados. 

Esperamos que a dica seja útil.

Artigos relacionados