| Firebird Documentation Index → Segurança arquivos e metadados → A Solução |
|
|
|
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.).
É importante ressaltar que você pode encontrar dificuldades até mesmo nesta situação, se sua intenção é proteger a estrutura do banco de dados.
Muitas das bibliotecas de acesso a banco de dados fazem consultas aos metadados da tabela, como chave primária, domínio e outras informações da estrutura, visando tornar o desenvolvimento das aplicações clientes uma tarefa mais simples. Se impedimos os usuários de acessar os metadados da tabela, consequentemente, impedimos também a aplicação de recuperar as informações que precisa.
Isto nos leva a duas alternativas:
permitir que seus metadados “escapem” do servidor através de uma sofisticada interface de acesso; ou
gastar o tempo necessário para se desenvolver uma aplicação utilizando uma biblioteca de acesso menos sofisticada.
Há também o problema de que muitas aplicações clientes, inerentemente, deixam escapar informações sobre a estrutura do banco de dados com a qual interagem. É muito raro encontrar uma aplicação de banco de dados que tenha uma interface que não revele detalhes sobre a estrutura das tabelas que usa.
Alguns detalhes podem ser escondidos por meio de Views e Stored Procedures, mas definir essas ferramentas apenas para tentar esconder a informação da estrutura é uma tarefa frustrante. Provavelmente será inútil, pois alguns detalhes escaparão, não importa o que você tente.
Antes de continuar discutindo questões relacionadas à encriptação das informações do banco de dados, eu gostaria de ressaltar que é perfeitamente possível proteger as informações dos usuários por meio de encriptação. Não serve para desenvolvedores que queiram esconder informações de usuários legítimos, mas pode servir para suprir as necessidades de privacidade que seus clientes possam querer com relação ao banco de dados.
Existem algumas situações em que é impraticável colocar o servidor Firebird sob uma infra-estrutura adequadamente segura. Em períodos em que o escritório esteja funcionando, é bem pouco provável que alguém poderá acessar o computador para copiar os arquivos do banco de dados (ou até mesmo roubar o computador ou disco rígido para obter os arquivos posteriormente). No entanto, fora do horário normal de trabalho (noites e finais de semana), a situação pode ser um pouco diferente. Alguém poderia conseguir entrar no escritório e roubar o disco rígido do computador (ou levar o computador inteiro) e levar a algum lugar onde possa obter acesso ao banco de dados.
O Firebird em si não disponibiliza nenhuma ferramenta de encriptação integrada, mas existem excelentes produtos que podem fornecer essa solução. Você poderia instalar um software que crie uma partição virtual encriptada em seu computador e colocar os arquivos do banco de dados (e qualquer outra informação confidencial) nessa partição. Dessa forma, toda a informação ficará armazenada em um arquivo encriptado e ninguém poderá acessá-la a menos que tenha a senha. Sempre que você iniciar o computador, terá que montar a partição virtal encriptada e fornecer a senha secreta para poder acessar as informações. Esse processo manual de inicialização pode ser um pouco inconveniente, mas pode proporcionar uma excelente segurança a computadores que não são constantemente vigiados.
Alguns softwares com essas características são: TrueCrypt (www.truecrypt.org), Bestcrypt da Jetico (www.jetico.com) e PGPDisk (www.pgpi.org/products/pgpdisk/– note que este link te levará a uma antiga versão gratuita. Nesta mesma página existem links para as versões comerciais mais novas). Existem outros, mas estes dois últimos são os que eu mesmo usei.
Devido às necessidades descritas anteriormente, é muito comum encontrar usuários pedindo que o Firebird, em um versão futura, tivesse a capacidade de encriptar metadados, dados do usuário, ou até mesmo o banco de dados todo. Como não sou um desenvolvedor do núcleo do Firebird, não posso afirmar categoricamente que não vai acontecer. Mas a questão aqui não é realmente se a encriptação é praticável ou útil, mas se o gerenciamento de senhas de encriptação proporcionaria uma solução para os problemas que estamos examinando.
A encriptação em si pode apenas ser tão boa quanto a senha de desencriptação. Pode ser ainda pior, mas não pode ser melhor. Existem diversos excelentes algoritmos de encriptação disponíveis que poderiam ser utilizados. Quando a encriptação é boa, os ataques costumam centralizar-se contra a senha e não contra a encriptação em si.
Então vamos analisar como funcionariam as coisas se o Firebird proporcionasse maneiras de encriptar metadados no banco de dados...
Antes que um banco de dados pudesse ser acessado, a senha deveria ser fornecida. Dar a senha ao usuário seria irrelevante, pois nos levaria de volta ao problema original. Então podemos presumir que, sempre que o cliente reiniciar o servidor, teria que chamar o desenvolvedor, que poderia então entrar com a senha. Mesmo que isso fosse praticável, não necessariamente resolveria o problema. Por exemplo: o cliente poderia instalar algum tipo de software para monitorar o servidor e roubar a senha.
Existem soluções baseadas em hardware para proporcionar a senha para o processo de desencriptação. Mas novamente, este dispositivo precisaria ficar sob a posse do cliente, e se não confiamos nele, não podemos impedí-lo de obter acesso ao banco de dados em outro computador onde a senha do usuário SYSDBA é conhecida.
O Firebird é um produto Open Source. Se as facilidades de encriptação forem nativas ou através de bibliotecas adicionais também open source, seria possível aos usuários desenvolverem suas próprias versões do servidor ou da biblioteca que não apenas providencie as capacidades de encriptação e desencriptação do banco de dados, mas também possa mostrar a senha na tela ou simplesmente mostre os resultados desencriptados diretamente. O desenvolvedor, que não tem o controle do servidor, não pode detectar e nem prever tal atividade.
Você pode vir a considerar a construção de sua própria versão do Firebird server, com a senha de desencriptação escondida no executável. Mas descompiladores são facilmente encontrados. Não levaria muito tempo para descobrir a senha por uma simples comparação das versões descompiladas da sua versão do servidor e da versão normal.
Existem vários bancos de dados que existem com o propósito de proporcionar uma forte encriptação. Talvez a encriptação seja forte, mas a menos que o gerenciamento de senhas sesteja no local para suportar essa ferramenta, a encriptação não alcançará o efeito desejado. Pode até encorajá-lo a acreditar que está protegido, mas você precisa estudar o gerenciamento de senhas para descobrir se é realmente verdade.
A dura realidade é que, se você não tem o controle sobre o hardware no qual o processo de encriptação e desencriptação ocorre, nunca estará protegido. Se a senha de desencriptação não pode ser mantida em segurança, então até mesmo as melhores encriptações tornan-se apenas um pouco mais que segurança por obscuridade.
Algumas pessoas pedem a encriptação dos dados, para que eles possam tentar limitar a disseminação destes. Elas não se importam com o fato de que um usuário autorizado em particular veja a informação, mas querem, no entanto, limitar a capacidade deste usuário de distribuir essa informação a outras pessoas.
Vamos imaginar por um momento que todos os problemas com o gerenciamento de senhas descritos acimas foram resolvidos, então torna-se impossível ao usuário apenas copiar o banco de dados para poder obter as informações. Nestes casos, o usuário poderia simplesmente escrever um pequeno programa que extraísse as informações que lhe forem interessantes (através do servidor legítimo, instalado) e copiá-las para seu próprio arquivo ou banco de dados.
Eu acredito que seja possível que o Firebird proporcione, no futuro, algum tipo de sistema de autenticação da aplicação que poderia limitar essa maneira de extrair as informações, mas ainda assim, os mesmos problemas persistem. Se você não tem controle sobre o servidor, não pode prevenir que o usuário instale uma versão que não requer esta autenticação.
Várias vezes, algumas pessoas sugeriram que remover o acesso do usuário SYSDBA a esse banco de dados poderia ser a solução. A idéia por trás desta solução é que mover um banco de dados para um outro servidor onde a senha do usuário SYSDBA é conhecida não ajuda em nada, pois o usuário SYSDBA não tem acesso às tabelas. Algumas pessoas relataram um limitado sucesso nesse contexto, criando uma role SQL com o nome de SYSDBA e assegurando que ela não terá acesso aos objetos do banco de dados.
Mas isso não resolve realmente o problema. O arquivo do banco de dados pode ser visualizado com um editor hexa-decimal ou similar e a lista de usuários disponíveis, descoberta (Descobrir os nomes dos usuários donos dos objetos seria particularmente útil). Dessa forma, estes nomes podem ser adicionados ao novo servidor e usados diretamente.
E um arranjo ainda mais simples seria utilizar a versão embedded do servidor Firebird (mais adiante) ou compilar uma versão própria que ignore as diretivas de segurança.
Também houveram sugestões de permitir que o nome de usuário SYSDBA seja alterado. Esta solução poderia oferecer alguma proteção limitada contra ataques de força bruta contra a senha do SYSDBA, visto que o ataque teria que adivinha tanto o nome de usuário quanto sua senha. Mas não ajuda em nada a proteger o sistema de uma pessoa que tenha acesso direto ao arquivo.
Quando você escreve e define uma Stored Procedure ou Trigger para o banco de dados Firebird, o servidor armazena uma cópia quase completa do código fonte juntamente com a cópia compilada, chamada de BLR (Binary Language Representation). É a BLR que é executada pelo servidor, o código fonte não é utilizado.
Alguns desenvolvedores tentam proteger ao menos uma parcela de seus metadados deletando o código fonte antes de distribuir o banco de dados (apenas um update direto nos campos relevantes da tabela de metadados). Eu recomendo não adotar esta prática por duas razões:
BLR é uma codificação muito simples do código fonte. Não seria muito difícil decodificar o BLR de volta para uma forma legível a humanos. A decodificação não traria comentários ou formatação, mas as SQL's que vão em SP's ou Triggers são raramente tão complicadas a ponto de isso causar problemas. Então, a proteção oferecida pela remoção do código fonte não é muito significante.
O código fonte pode ser útil para outros propósitos. Ele permite que correções sejam aplicadas diretamente no banco de dados, sem precisar trazer de volta o código fonte completo de algum outro lugar (e então, lembrar de remover novamente após aplicar as correções). O código fonte é também utilizado em vários utilitários, como o meu DBak - uma ferramenta de backup alternativa ao “gbak”. Eu não me importei em escrever meu próprio decodificador de BLR neste momento, portanto, DBak depende da disponibilidade do código fonte para conseguir criar o script DDL para reconstruir o banco de dados.
|
| Firebird Documentation Index → Segurança arquivos e metadados → A Solução |