O Problema

Um desenvolvedor cria um banco de dados (e, normalmente, um aplicativo cliente que o acompanha) para instalação em locais remotos. Nestes locais, é natural que ao menos uma pessoa de lá tenha acesso irrestrito ao computador no qual o servidor Firebird será executado - para poder executar tarefas como backup's e manutenção. Como descrito no tópico acima, acesso direto aos arquivos permitem que se ganhe acesso completo e irrestrito a toda a informação das tabelas (dados e metadados).

Nestes casos, o desenvolvedor pode não confiar que os usuários deste local respeitarão a propriedade intelectual que este banco de dados representa. Então, fica o receio de que o usuário faça a engenharia reversa do banco de dados por interesse próprio, ou que não haja, neste local, uma preocupação real em manter seguros os arquivos a acesso de terceiros.

Isto nos leva às frequentes perguntas nas listas de Firebird como:

“Eu quero—”: “—proteger os metadados de meu banco de dados (estruturas, stored procedures, triggers etc.) de todos os usuários em uma instalação remota. Como posso fazer isso com Firebird?”
“Eu quero—”: “—impedir que qualquer usuário de uma instalação remota tenha acesso a estas tabelas em particular. Elas contêm informação proprietária que é usada internamente pelo aplicativo.”

O Firebird (pelo menos até a v1.5) não oferece nenhuma facilidade integrada de encriptação. A resposta simples às questões acima é que isto não pode ser feito com as atuais capacidades do Firebird. Um usuário que tem acesso direto ao arquivo, tem acesso irrestrito às informações dele.

Na primeira questão, nenhum arranjo pode ser feito, porque o servidor em si deve ser capaz de ler os metadados da tabela. Na segunda questão, é possível implementar rotinas de encriptação/desencriptação no aplicativo cliente, mas neste caso, você perde a capacidade de fazer um uso efetivo dos índices e das facilidades de busca do Firebird - e o gerenciamento de senhas de encriptação torna-se um problema ainda maior (mais adiante).