Segurança de arquivos e metadados do Firebird

Se você veio parar nessa página e não sabe nada sobre Firebird, veja este link: www.firebirdsql.org

Este artigo visa discutir a questão de segurança dos arquivos de base de dados do Firebird e, particularmente, o acesso aos metadados armazenados nestes, tendo sido escrito em resposta às frequentes perguntas sobre o tema em listas de discussões. O artigo evita especificações técnicas. Para ler sobre como proteger arquivos no seu sistema operacional, especificamente, procure pela documentação relevante a este sistema operacional. Para ler sobre como configurar a segurança de usuários e objetos em sua base de dados Firebird, procure pela documentação disponível no website do projeto (linkado acima) ou compre o livro Dominando o Firebird (The Firebird Book, no original, em inglês) da autora Helen Borrie.

Para que uma aplicação (usuário) possa acessar um banco de dados Firebird, ela deve conectar-se a um servidor Firebird que contenha este arquivo. Ao receber uma requisição de conexão, o servidor automaticamente verificará as permissões do usuário definidas no arquivo de segurança (normalmente, isc4.gdb). Se a autenticação for bem sucedida, então o servidor dará à aplicação a permissão de acessar qualquer banco de dados que ela requisitar e então, utilizar os privilégios e roles definidos neste banco de dados para garantir um acesso controlado aos objetos nesse banco de dados.

Em momento algum o usuário que conecta ao banco de dados necessita de acesso diretamente ao arquivo em si. Todo o acesso se dá através do aplicativo servidor, que acessa os arquivos conforme necessário para atender às requisições dos clientes. Fica, portanto, a cargo do servidor restringir o acesso aos usuários logados, conforme as permissões definidas para este usuário naquele banco de dados.

Todo servidor Firebird possui um usuário “SYSDBA”, que possui acesso irrestrito a qualquer banco de dados disponível a esse servidor. Os privilégios especificos dos bancos de dados são ignorados quando este é acessado por esse usuário. Quando você copia um banco de dados para dentro de um servidor, você pode utilizar este usuário para determinar os privilégios de acordo com os usuários e as necessidades deste servidor. No entanto, dessa forma, se eu tiver acesso ao arquivo do banco de dados, eu posso copiar esse arquivo para um servidor onde eu saiba a senha do usuário SYSDBA, e obterei acesso irrestrito ao arquivo.

Como você pode notar, a segurança do Firebird presume que seu servidor estará sendo executado em um ambiente de segurança apropriado. O Firebird em si não toma precaução alguma para evitar riscos externos. Se uma pessoa tem acesso físico ao arquivo de banco de dados, não há uma maneira efetiva para prevenir que o usuário leia toda a informação (dados e metadados) contida neste arquivo.

Isto significa que, para uma segurança razoável, toda instalação deve manter os arquivos do banco de dados adequadamente seguros. Na maioria dos casos, isto significa que o servidor Firebird deve rodar em um usuário específico no sistema operacional, e apenas esse usuário (e provavelmente o administrador/root) deve ter acesso direto aos arquivos do banco de dados. Estes arquivos não devem ficar em diretórios compartilhados na rede ou que sejam acessíveis por qualquer pessoa que não o pessoal autorizado.

Para uma segurança ainda mais efetiva, é preferível que o computador que será o servidor fique armazenado em um local físico de acesso restrito, de forma a prevenir que alguém tente acessar os arquivos por trás das restrições do sistema operacional.

No entanto, a explicação acima não necessariamente ajuda desenvolvedores que, tendo desenvolvido um banco de dados para distribuição e instalação em locais remotos, desejam proteger as propriedades intelectuais contidas nestes arquivos. Tais preucupações podem incluir desde os metadados (estruturas, relacionamentos, stored procedures e triggers) até os dados em si, incluídos em algumas tabelas. É este o ponto que representa o foco deste artigo.

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:

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).

Existe apenas uma solução possivel para esses problemas, na realidade: Armazenar o banco de dados em seu próprio computador e usá-lo como servidor remoto, para permitir que os clientes conectem ao banco através da internet. Terminal server (Windows ou Linux/Unix) é uma alternativa interessante para implementar esta estrutura.

Desta forma, você fica com o controle sobre o arquivo de banco de dados e pode restringir o acesso às suas informações utilizando as ferramentas internas de segurança do Firebird (roles e privilégios, etc.).

Há uma versão especial do servidor Firebird chamada de “embedded”. Esta versão é, na verdade, uma biblioteca cliente especial, que inclui o servidor em si. Quando um aplicativo chama essa biblioteca, ela carrega o servidor e permite acesso direto a qualquer banco de dados acessível ao computador local. Dessa forma, não faz uso do banco de dados de segurança. O nome de usuário especificado durante o “logon” (não existe autenticação de senha) é utilizado para gerenciar o acesso aos objetos do banco de dados (por permissões SQL), mas se este usuário for SYSDBA (ou o dono do banco de dados), então, o acesso irrestrito é possível.

As características do servidor embedded são úteis a desenvolvedores que querem criar aplicativos monousuários simples de se distribuir e que não requerem muita segurança.

Dessa breve descrição, pode parecer que ter um aplicativo com servidor embedded instalado em um servidor que esteja armazenando outros bancos de dados pode representar um grave risco à segurança. Na realidade o risco não é maior do que se o servidor embedded não existisse.

Quando um aplicativo carrega o servidor embedded, ele opera no contexto de segurança do aplicativo (e portanto, do usuário). O que significa que o servidor embedded terá acesso apenas aos arquivos que o usuário pode acessar diretamente pelo sistema operacional. Conceder a um usuário suspeito acesso para instalar programas em um servidor seguro já não é boa idéia, mas se você tiver especificado permissões de arquivo apropriadas em arquivos de banco de dados seguros, o servidor embedded não representa uma ameaça.

A ameaça vem de todas as outras coisas que o usuário poderia instalar.

O fato de o servidor embedded existir serve apenas para ressaltar que é possível acessar diretamente as informações de um arquivo de banco de dados, especialmente em um ambiente open source. Se já não existisse, certamente seria possível que alguém compilasse um equivalente.

Várias outras formas de segurança por obscuridade foram propostas. Coisas como eventos especiais que são acionados no login e no logoff para chamar funções de usuários que liberem ou neguem acesso. Essas implementações podem oferecer alguma segurança limitada em sistemas de código fonte proprietário, onde a obscuridade da implementação ajuda a esconder como, exatamente, a informação está sendo protegida. Mas para um sistema open source, basta que se compile uma nova versão do servidor para pular os eventos ou códigos que estão prevenindo o acesso para acessar totalmente a tabela. É muito difícil oferecer obscuridade em um sistema open source.

Considere, por exemplo, o que acontece quando você distribui seus executáveis compilados. Executáveis compilados são ótimos exemplos de obscuridade. Não há uma encriptação (normalmente), e todos os passos do código estão lá para serem analisados por qualquer um que tenha o tempo e o conhecimento, e além disso, ainda existem descompiladores que podem auxiliar o processo. Tão logo uma pessoa descubra com que bibliotecas seu código foi compilado, isolar os resultados para apenas o código “secreto” fica muito fácil. Você já escreveu à Borland, Microsoft ou qualquer outro solicitando algum tipo de encriptação dos binários compilados?

Meus comentários até então se direcionaram a um ideal de forte segurança, e talvez o conceito de segurança por obscuridade tenha sido escrito com algum desprezo. No entato, eventualmente uma baixa segurança é suficiente, quando a informação não é assim tão valiosa. Você quer apenas impedir uma navegação casual e ao menos deixar o trabalho um pouco inconveniente aos “ladrões” mais avançados.

Eu mesmo já utilizei esse tipo de esquema várias vezes. Frequentemente, não tem porque utilizar Twofish, AES ou qualquer outro porque eles são apenas forte encriptação. São pesados, causando sobrecarda do processador e complicação com relação a manter uma forte segurança. Um simples XOR contra uma string conhecida (uma senha) já deve ser suficiente. Se a chave puder ser descoberta pelo ladrão, então não importa se a encriptação é fraca ou forte, a brincadeira de qualquer forma.

O problema com segurança por obscuridade é que ela precisa ser obscura. Se o Firebird implementasse algum tipo de encriptação em suas rotinas de leitura e escrita em disco, ela não seria obscura, pois este é um projeto Open Source. Não levaria mais que alguns minutos para recompilar o código fonte para descobrir a senha utilizada e então, tudo está perdido.

Então, se você realmente precisa dessa ferramenta, você teria que copiar o código fonte do Firebird, inserir suas próprias rotinas de obscuridade e compilar sua própria variação do servidor Firebird. (O código fonte ainda pode ser descompilado, mas para isso seria necessário um avançado conhecimento de programação.)

Antes de tentar fazer isso, verifique se realmente resolveria o problema se o usuário pudesse obter uma cópia dos executáveis especiais compilados junto com o banco de dados. Ou se ainda seria possível ao usuário extrair os segredos diretamente de seu servidor.

Há também a seguinte questão filosófica: Por que você escolheria um banco de dados Open Source para construir um produto com banco de dados proprietário. Muitas pessoas contribuiram com o projeto com a crença de que a melhor forma de se fazer software é Open Source.

Mais particularmente, quando se trata de armazenamento de informações do usuário, eu acredito que os usuários precisem ter a habilidade de acessar sua própria informação - o que normalmente inclui a necessidade de entender a estrutura e os processos que você construiu (metadados). Se você sair do mercado ou ficar, de alguma forma, indisponível, será de crítica importancia que o usuário consiga ao menos extrair sua própria informação (em formatos apropriados) de forma a conseguir migrar para sistemas alternativos.

Você pode confiar em seus usuários para respeitarem sua propriedade intelectual enquanto você ainda estiver no mercado e disponível? Disponibilize os serviços e facilidades necessários e provavelmente, eles respeitarão. Caso contrário, então há uma grande chance de que não há nada que você possa fazer.

O problema é que muitas pessoas não entendem de segurança e como é difícil fazer bem feito. Lamentavelmente existem muitos softwares que estimulam esses desentendidos por implementar obscuridade no lugar de segurança de verdade. Observe o número de empresas que existem que oferecem serviços de “recuperação de informação”, que na verdade, nada mais é que quebrar a suposta segurança da informação protegida por obscuridade.

Encriptação não é um milagre da segurança. Se você não tiver o controle sobre a estrutura (o hardware, o sistema operacional e todos os softwares neste sistema), você não terá controle sobre a segurança - não importa que esquemas de encriptação você implemente no local. Essa é a situação que você tem quando precisa distribuir seu banco de dados para instalações externas.

Se você realmente precisa proteger as informações (dados e metadados) de seu banco de dados, então você precisa reter o controle do arquivo do banco de dados e da estrutura em que ele será acessado. Nenhuma outra solução oferece o mesmo nível de segurança.

Eu gostaria de agradecer a todas as pessoas que avaliaram e comentaram este artigo. Gostaria também de agradecer as pessoas que contribuem para a lista de suporte do Firebird, que é fonte de grande parte das informações disponíveis neste artigo.

O histórico exato do arquivo - começando na versão 0.5 - é registrado no repositório git 'firebird-documentation'; consulte https://github.com/FirebirdSQL/firebird-documentation

Eu tentei fazer este documento o mais preciso possível no momento de escrita, mas não posso garantir que não hajam enganos. Segurança é um assunto complexo. Onde segurança é importante ao seu produto ou instalação, você deveria procurar orientação profissional.

Eu não imponho nenhuma restrição em particular ao uso deste documento. Você está livre para reproduzir, modificar ou traduzi-lo. No entanto, versões alteradas do documento devem ser anotadas com as alterações efetuadas e o nome do autor (de forma que meu nome não fique associado ao texto que não escrevi). --G.W.