1. Tudo o está escrito aqui sobre o Interbase também se aplica ao Firebird;
2. Farei menção a outros 2 artigos publicados no site, mas com a devida identificação de seus autores, pois é interessante ler ambos os artigos em sua integra para melhorar o entendimento. Versam sobre matéria diferentes, mas interligadas, pois ambas falam sobre segurança dos dados.

Tive problemas sérios de conexão com o Banco de Dados, simplesmente por não saber tirar proveito do poder do Interbase e suas funcionalidades em aplicações Client/Servidor, usando redes ou até mesmo a Internet.

Minha primeira dor de cabeça foi quando fui instalar um aplicativo meu em uma empresa a qual usava um sistema diferente dos já acostumados. É uma solução tecnológica em que apenas 1 PC pode se multiplicar por até 5, simulando uma rede. Esse apenas "um PC" (servidor) faz tudo, e nele são conectados terminais burros, rodando Unix, conectando-se ao Windows através de usuários criados, conhecidos como Thin-Clients.

Resumindo, tinha-se na máquina servidora o usuário Administrador e mais 3 usuários limitados. O servidor era conectado a equipamentos que no “vox popolis” (dito popular) chamamos de TERMINAIS BURROS. Esses equipamentos têm apenas monitor, teclado e mouse, e a conexão entre eles e o servidor é através de um cabo de rede e um tipo de roteador, como se fosse uma rede física normal (não sei como funciona especificamente e também não é o foco de nosso artigo).

Quando é ligado os terminais, eles estão em ambiente Unix. Abre uma tela de login do Windows, onde você se conecta a determinado usuário criado no servidor. Isso permite na máquina servidora, todos os usuários cadastrados usarem o Windows paralelamente, através de suas contas individuais.

Para internet, impressão, textos, planilhas e etc. não notei maiores problemas não, porém na hora de instalar servidores de Banco de Dados... Nossa, foi difícil! Porque tive que entender uma coisa importante: o sistema SIMULA UMA REDE e NÃO A É EXATAMENTE – conclusão curiosa e questionável. Em algumas funções "a coisa" simplesmente ficava louca. Mandava gravar os dados no BD, porém se um outro usuário desconecta-se por último, o Interbase gravava a ultima alteração (muitas informações simplesmente sumiam). O HD do servidor é compartilhado entre todos. Já dá pra imaginar os problemas causados a usuários normais.

Peço desculpas as pessoas especializadas (representantes/analistas) pela minha ignorância quanto ao assunto, porque pelo que entendi, ele usava os mesmos arquivos como se estivesse usando o mesmo executável duas vezes, ou seja, os programadores acostumados a colocar funções não permitindo execução do aplicativo mais de uma vez ficarão triste quando descobrirem nesse sistema não ser possível essas proteções básicas contra usuários (desprovidos de informações para não dizer outra palavrinha de 5 letras quando usada no singular), impacientes de dedos-nervosos pressionando freneticamente com o mouse sobre o ícone do programa porque simplesmente está demorando para abrir....TODO MUNDO JÁ PASSOU POR ISSO.

A solução foi criar uma conexão no Interbase, mas usando a conexão remota. Desse modo, a engine do Interbase se encarrega de processar as informações transmitidas.

Lendo um artigo aqui no site sobre criptografia e segurança com base de dados, achei o artigo denominado Questões de segurança em banco de dados, publicado em uma Segunda-Feira do mês de Novembro de 2005, dia 21 às 11:39 AM GMT, pelo usuário IceMagno. O qual faço questão de reproduzir parte do texto com a devida autorização do mesmo, e é claro para que todos entendam melhor:

(...) Na empresa em que trabalhei, os programadores (e analistas) tinham o péssimo hábito de trabalhar com o Interbase da pior forma possível:

Eles colocavam uma máquina para ser o servidor do Interbase, até aí tudo bem. Depois, acreditem, compartilhavam a pasta onde estava o banco de dados GDB usando o compartilhamento de pastas do Windows. Em seguida, as estações que rodavam o programa, acessavam o banco de dados através do mapeamento de pastas da Microsoft, criando um drive para a pasta compartilhada do servidor e acessando o GDB usando o protocolo local.

Eu considero isto a maior heresia de todos os tempos em se tratando de Interbase... Me perdoem os programadores que lerem este artigo e adotam esta doutrina.

Não fossem todos os problemas com o banco de dados que esta prática causa, ela afeta diretamente a segurança do banco, visto que o Interbase protege os dados a nível de servidor, ou seja, toda a segurança do interbase se baseia na premissa de que o cliente não acessará o arquivo diretamente, mas sim através da engine do servidor, que aplicará os métodos de segurança elaborados pelo DBA (users e roles).

Tudo isso significa que, o banco de dados, na forma de arquivo, não possui capacidade para se proteger. Caso o arquivo GDB seja copiado para outro servidor, o SYSDBA poderá acessar os dados da mesma forma (ou usuários com os mesmos nomes). Então, basta instalar um servidor Interbase com a senha padrão do SYSDBA e colocar lá o GDB que se quer invadir.

Obviamente, se o GDB está em uma pasta compartilhada, não será necessário colocar senhas nos programas nem no banco de dados, pois serão inúteis...

Uma outra prática muito usada pelos programadores, talvez por desconhecer o uso correto da conexão IB, é usar o formato \\<IP>\Pasta\Arquivo.GDB como DatabaseName do IBDataBase.

Este formato também força o cliente a conectar-se ao banco em modo LOCAL, visto que esta é uma convenção de nomes de rede para compartilhamento de pastas, o que indica que o servidor não estará sendo usado.

Neste caso, o formato correto seria: <IP>:<DRIVE>:\Caminho\Arquivo.GDB
Sendo "DRIVE" e "caminho" fazendo referência ao sistema de arquivos do SERVIDOR.
Este método é muito eficiente e permite que o IB seja conectado até através da internet, pois dispensa o uso do NetBios. (...)

Bem, espero que todos tenham entendido o recado, ou seja, se você compartilha a pasta aonde está o arquivo GDB, aonde está a proteção??? O "cara" pode simplesmente acessar a pasta através do Windows Explorer, copiar o GDB e fazer a festa!!! Por isso resolvi escrever este artigo e, acabar de uma vez por todas com as dúvidas sobre conexão remota do Interbase. Os conceitos aqui apresentados também servirão para ser aplicados ao novo Windows Vista – também estou tendo problemas de performance com o mesmo por causa de compatibilidade.

Para testarmos, vamos fazer de 2 formas: conectando o Ibconsole e depois um aplicativo qualquer através de conexão remota usando 2 máquinas em rede.

Partiremos dos seguintes princípios:

1. Ambas as máquinas estão configuradas para rede, ou seja, já tem o protocolo TCP/IP instalado;
2. Ambas as máquinas deverão ter um IP de rede fixo para facilitar os testes.
3. O grupo de trabalho o qual as máquinas pertencem não interessa. O importante é a classe de IP, ou seja, ambas as máquinas devem estar na mesma faixa de IP para então se reconhecerem. Exemplo:
   Maquina 1 -> IP 169.200.200.1
   Maquina 2 -> IP 169.200.200.2
4. Instale o Servidor do Interbase em ambas as máquinas, assim poderemos conectar de uma para o outro permitindo o teste de várias formas;

Uma observação importante: lembre-se, o Windows XP e superiores tem um Firewall interno. Configure-o para aceitar as conexões usando a opção de exceções. No meu caso, eu uso também o Zone Alarm, configuro para que ambos os Firewall´s aceitem conexões pela Net ou Rede dando as devidas permissões. Para facilitar, desative temporariamente o Firewall de ambas as máquinas envolvidas nesse teste.

Configurações Iniciais

1. Crie uma pasta na Máquina 1 chamada C:\Positivo e dentro dela coloque um banco de dados do interbase de sua preferência.
2. Crie uma pasta na Máquina 2 chamada C:\ActiveDelphi e dentro dela coloque o mesmo BD ou outro qualquer.

Faremos a conexão de Banco de Dados de ambas as máquinas sem precisar compartilhar nenhuma pasta na rede. Isso é segurança no arquivo GDB.

Primeiro Passo: configurar o IBCONSOLE para conectar remotamente a um BD.

No primeiro teste será feito uma conexão a um arquivo GDB na Máquina 2, chamada CADMOBILE (Meu laptop). Esse nome é aquele dado para identificação da máquina em uma rede. Para isso, abra o IBConsole e escolha a opção Interbase Servers. Aparecerá a seguinte opção:

Figura 1 - Registrando um Servidor

Escolha Remote Server e preencha conforme abaixo:

Server Name: Nome da máquina aonde está o arquivo gdb (CADMOBILE).
NetWork Protocol: TCP/IP
Alias Name: TesteConexaoRemota (ou nome de sua preferência).
Description: Minha primeira conexão remota no Interbase (ou uma informação de sua preferência).
Save Alias information: deixe marcada esta opção
User Name: Nome do usuário do BD (SYSDBA ou o usuário autorizado para trabalhar no banco de dados escolhido)
Password: ****** (masterkey ou sua senha, é claro)

Obs.: Caso o usuário escolhido não seja o SYSDBA, lembre-se de registrar o usuário na opção Server/User Security, antes de fazer esta conexão.

Pressione OK e o Ibconsole irá criar uma nova conexão com uma diferença: essa faz conexões remotas a DB´s localizados em outras máquinas na Rede/Internet. O Interbase permite criar várias conexões remotas, diferente de conexões locais o qual o Ibconsole só permite uma: a famosa Local Server, Como na figura:

Figura 2 - Servidores Registrados

Agora é necessário registrar o seu BD remoto, ou seja, iremos nos conectar ao seu BD localizado na máquina 2. Escolha a conexão remota criada e clique com o botão direito do mouse na opção Databases, em seguida a opção Register. Aparecerá a seguinte tela:

Figura 3 - Registrando o Banco de Dados.

Preencha conforme abaixo:

File: Coloque o caminho do seu BD, mas lembre-se, por ser uma conexão remota, não é necessário indicar IP ou nome da máquina onde reside o arquivo GDB, pois já indicamos no passo anterior e o Interbase já sabe aonde o arquivo está.
Alias Name: Um nome para você identificar esta conexão diante de outras. Pode ser qualquer nome de sua preferência.
Save Alias information: deixe marcada esta opção
User Name: Nome do usuário do BD
Password: ******
Character Set: None

Pressione OK e pronto, seu banco de dados pode ser conectado agora até pela internet.

Não esqueça: Ambas as máquinas estão ligadas fisicamente (cabo) na mesma rede e o IP está na mesma faixa. Se ocorrer algum erro até aqui, refaça todos os passos com cautela.

Se der algum erro de conexão, Host Unavaliable, inacessível e etc, é porque tem Firewall bloqueando ou a rede não está configurada corretamente. Verifique sua rede testando se é possível compartilhar pastas e impressoras. LEMBRE-SE, NÃO É NECESSÁRIO COMPARTILHAR A PASTA AONDE ESTÁ O SEU BANCO DE DADOS, a segurança baseia-se na premissa que somente o usuário administrador da REDE tem acesso fisicamente ao arquivo GDB. O arquivo que compõe a base de dados não é capaz de proteger-se sozinho. Isso é segurança.

Antes de passarmos para a próxima etapa, faça o mesmo processo inverso da Máquina 2 conectando-se na Máquina 1. Lembre-se de criar uma pasta chamada C:\ActiveDelphi, e nela coloque o seu arquivo GDB.

Segundo Passo: configurar a conexão de seu aplicativo com o Banco de Dados.

Dentro do seu projeto, vá no local aonde está seu objeto de conexão com o Interbase e faça as seguintes alterações (nesse exemplo usei os da Palheta IBX - IBDatabase):

Figura 4 - Conectando o programa ao banco de dados - Clique duplo sobre o IBDataBase

Escolha a opção Remote e configure conforme abaixo:

Server: CADMOBILE (lembra, é a máquina 2 com o arquivo GDB)
Protocol: TCP
Database: endereço físico do arquivo GDB (C:\Positivo\DBLOC.GDB);
User Name: SYSDBA
Password: *****
Character Set: None
Login Prompt: Desmarcado

Clique em Test e se aparecer a mensagem “Successful Connection”, PARABÉNS! Você acaba de criar uma conexão remota com o seu Banco de dados.

Veja as possibilidades:

Você pode colocar o programa aplicativo em uma máquina e o arquivo do BD em outra a qual ninguém tem acesso. Toda a conexão, tráfego de dados, permissões serão administrados pelo servidor do BD, ou seja, esse é o modo correto de usar o Interbase em Rede.

Uma dica para conexão em tempo real é colocar aquela velha opção de arquivos *.ini guardando o caminho do Banco de Dados.

Figura 5 - Interface de exemplo de uma tela para configuração do caminho do banco de dados.

Quando for conectar em Runtime, use o formato <IP>:<DRIVE>:\Caminho\Arquivo.GDB, sendo que "DRIVE" e "caminho" fazem referência ao sistema de arquivos do SERVIDOR. No exemplo acima foi utilizado ainda um IBDataBabaseInfo conectado ao IBDatabase, coletando o nome do usuário e o nome do servidor do Banco de Dados, assim eu sei a qual servidor (máquina na rede) estou conectado.

Conseguimos esta informação através do código:

  if dm1.IBDatabase1.Connected = True then
  begin
    edservername.Text:=(dm1.IBDatabaseinfo1.DBSiteName);
    ednmusuario.text:=copy(dm1.IBDatabase1.Params.Strings[0],11,Length(dm1.IBDatabase1.Params.Strings[0]));
  end;

Uma atenção especial:

NUNCA EXIBA O NOME DO USUÁRIO DO PROPRIETÁRIO QUE FAZ CONEXÃO COM O BANCO DE DADOS! ESSA É UMA SEGURANÇA QUE VOCÊ TEM EM SUA ESTRUTURA. Apenas coloquei para ilustrar o exemplo de como funciona. Mudando os parâmetros é possível até exibir a senha utilizada para conexão no BD. Portanto, ATENÇÃO ao Artigo "Segurança com Firebird" - Publicado pelo usuário rodrigobarros, na Terça-feira, 23 de Janeiro de 2007:

(...) não forneça a ninguém o nome do usuário proprietário do banco de dados. O nome do usuário deve ser mais secreto que a própria senha. Se um usuário externo souber o nome do proprietário do banco de dados terá acesso a todos os objetos (...).

Espero ter ajudado com esse pequeno esclarecimento e não estranhem em ser citado um artigo tão antigo, porém nem um pouco menos importante. Achei-o no site faz mais de 1 ano procurando informações sobre criptografia de dados assimétrica e Hash. Vejam a importância do conhecimento sobre segurança de dados com o tipo de conexão. Usando da forma anterior (sem ser com NOMEDOSERVIDOR:C:\ARQUIVO.GDB), tive vários problemas de corrupção de dados por causa de vários usuários acessando a mesma Base de Dados de formas diferentes, com aplicativos e máquinas diferentes e tudo ao mesmo tempo. Desenvolvi 3 formas de cópias de segurança para tentar diminuir o problema:

1. Cópia do arquivo físico usando o Shell do Windows e substituindo-o a cada fechamento do software;
2. Usando o próprio gbak do Interbase com cópias diárias diferenciadas através da data, assim sempre terei uma cópia do por diferença do dia;
3. A mais "louca", Gbak+compactação zip+envio por Ftp para um site;

Tudo pela segurança dos dados. Depois que descobri a verdadeira funcionalidade do Interbase não tive mais esses problemas de corrupção de DB.

Em tempo:

Não é recomendado usar programas usando TCP/IP (internet, rede) sem um Firewall habilitado. Ele irá proteger você e seus dados de um invasor. O firewall acoplado ao Windows XP, apesar de ser considerado como chato por alguns é bastante útil. Confesso gostar dele, constatando realmente o bloqueio dos acessos.

Para funcionar com o Interbase em rede vá em Iniciar/Configurações/Painel de Controle/Firewall do Windows.

Escolha a opção Exceções/Adicionar Programa. Localize o arquivo ibserver.exe na pasta "Arquivos de Programas/Borland/Interbase/Bin". Pronto, o Windows XP estará com o Firewall ligado porém, irá permitir conexões pelo interbase em rede.

Figura 6 - Configurando o Firewall do Windows

Apêndice:

A questão da faixa de IP é engraçada, pois fiz alguns testes e notei o seguinte: quanto mais próximos os ip´s estiverem, mais rápido é sua conexão. As máquinas em questão tinham o início do IP como 169.254.200, e o último conjunto de caracteres deve ser diferente um do outro para não haver confusão de máquinas (ex. 1,2,3,4,5). Fiz testes em outras máquinas em faixas de IP´s um pouco diferentes e com grupo diferente (como disse anteriormente, o grupo não é impecilho para conexão via IP).

Meu laptop tinha o IP 169.254.200.2 e as demais máquinas tinham o IP 169.254.100.x. Notaram a diferença? Não precisam estar na mesma faixa de IP nos 2 últimos conjuntos de caracteres! Para maiores informações, procure na Internet sobre IP´s e suas classe.

Bem, espero ter ajudado todos aqueles usuários iniciantes em Interbase e estão lutando para conseguir uma conexão remota. Li recentemente em alguns artigos sobre o Windows Vista e Firebird uma certa incompatibilidade para rodar em modo de protocolo local. Todos recomendam usar a conexão pelo TCP. Então, acredito que isso vá ajudar em melhoras de performance e pode até ser utilizado como padrão para todas os aplicativos usando Interbase/Firebird.

Abraços e até a próxima!

André - invdjhack@ig.com.br