Fonte: www.activedelphi.com.br
Uma das principais preocupações nos dias de hoje é com a segurança das informações que estão armazenadas nos bancos de dados dos sistemas dos nossos clientes.
Para tanto, os desenvolvedores gastam muito tempo com o desenvolvimento de mecanismos que protejam estas informações, como senhas de acesso, níveis de segurança nos programas e políticas de usuários nos bancos de dados.
O que muitos analistas ou desenvolvedores não sabem ou não levam em consideração, é a segurança, não do sistema, não do banco de dados como um servidor, mas dos ARQUIVOS que compões este banco de dados.
Em muitas vezes, enquanto enumerava os benefícios que meu sistema traria a empresa, caso ele substituísse o sistema em uso, eu mostrava esta fragilidade, disfarçada em fortes esquemas de proteção via software.
No início, eram as tabelas PARADOX. Elas, aparentemente, podiam proteger os dados utilizando uma senha "embutida" diretamente nas tabelas. O sistema, contendo entrincados meios de autenticar os usuários, "abriam" estas tabelas com a senha pré-definida.
A principal falha deste método reside no fato de que a senha está em algum ponto no executável, e com um editor de arquivos que mostre hexadecimal, poderá ser encontrada.
Os programadores, motivados pela perspicácia dos invasores, resolveram codificar a senha, mas a necessidade de se obter informações sempre é mais forte, e os invasores começaram a ver que:
"A corrente parte sempre em seu elo mais fraco"
Como os programas estavam cada vez mais protegidos, as atenções se voltaram para os bancos de dados. Afinal, o objetivo é roubar a informação e não invadir o programa.
Recuperar dados de um sistema não é a coisa mais difícil do mundo quando o programador se apoia somente na segurança do sistema operacional e do servidor de banco de dados. No caso do PARADOX, eu lembro quando recebi um desafio de pegar os dados de uma pessoa em um sistema de cadastro que possuía vários métodos de segurança.
O sistema realmente era bem montado, com senha e políticas de segurança, e o banco continha senha.
Um pouco de tempo na internet e eu consegui acessar todos os dados, com um programa de quebra senhas de tabelas PARADOX, o que mostrou que este tipo de banco de dados não é muito seguro se não for bem estruturado.
Para efeito de didática, eu disponibilizo o programinha em meu site.
Clique aqui para baixar...
Por favor, não o use em bancos de dados de terceiros.
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 pemissa 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 \\\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:::\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.
A primeira vista, soluções simples poderão ser adotadas para proteger os dados e dar um pouco mais de trabalho para a pessoa que desejar roubar informações.
A principal premissa a se assumir é:
"Meu servidor sempre estará exposto de alguma forma"
No caso do PARADOX, eu desaconselho o uso. Nada contra o banco de dados, mas eu não acho que ele tenha sido criado para sistemas que estão em produção. Comparando com os servidores SQL atuais de baixo custo (e até grátis), ele não é a melhor solução.
No caso do Interbase, é obvio que o GDB jamais poderá cair em mãos erradas.
Para evitar, ou diminuir o risco, o ideal é, acima de tudo, utilizar o protocolo de rede para acessar o servidor.
Uma aproximação mais eficiente seria utilizar camadas de acesso ao servidor.
Este método só traria vantagens para o usuário e para o programador.
Para melhorar ainda mais a segurança, a rede em que está localizado o servidor poderia ser diferente da rede onde estão os usuários (não fisicamente, mas logicamente).
Um computador com duas placas de rede (e dois endereços IP) poderia conter a camada de acesso, que é visível aos usuários. Esta camada receberia os usuários por uma interface de rede e se comunicaria com o servidor pela outra. Esta abordagem tornaria o servidor simplesmente inacessível diretamente aos usuários, pois ele estaria em uma faixa de IP incompatível com a rede deles.
Caso o programador não tenha acesso aos métodos descritos, seria ideal utilizar a criptografia para proteger os dados. Escrevi alguns artigos na revista (foram matéria de capa das edições 14 e 20) e alguns artigos no site que descrevem como melhorar a segurança dos dados sem confiar esta tarefa ao servidor ou a máquina onde o servidor foi instalado.
Seguem os links destes artigos:
http://www.activedelphi.com.br/modules.php?op=modload&name=News&file=article&sid=236
http://www.activedelphi.com.br/modules.php?op=modload&name=News&file=article&sid=145
http://www.activedelphi.com.br/modules.php?op=modload&name=News&file=article&sid=127
http://www.activedelphi.com.br/modules.php?op=modload&name=News&file=article&sid=123
Uma outra saída, e talvez a mais eficiente, seria manter o nível de paranóia acima do normal (indicado como seguro pelos médicos) e criptografar tudo o que ver pela frente.
Isto inclui todos os dados do banco nas tabelas e também o tráfego na rede!
Eu já ultrapassei a barreira da sanidade ao fazer isso, como um bom gestor de segurança da informação...
Caso o leitor queira chegar a estas fronteiras, faça o download do servidor de SQL que estou aprimorando (sim, é um derivado do FlashFiler da TurboPower). Este servidor de SQL tem todos os componentes para o Delphi e com a vantagem de criptografar tudo o que é armazenado nas tabelas e também criptografar o que é transmitido entre o servidor e os clientes.
A desvantagem é que será uma má notícia para o DBA quando ele descobrir que não lembra da senha do banco ao retornar de férias...
Para tanto, os desenvolvedores gastam muito tempo com o desenvolvimento de mecanismos que protejam estas informações, como senhas de acesso, níveis de segurança nos programas e políticas de usuários nos bancos de dados.
O que muitos analistas ou desenvolvedores não sabem ou não levam em consideração, é a segurança, não do sistema, não do banco de dados como um servidor, mas dos ARQUIVOS que compões este banco de dados.
Em muitas vezes, enquanto enumerava os benefícios que meu sistema traria a empresa, caso ele substituísse o sistema em uso, eu mostrava esta fragilidade, disfarçada em fortes esquemas de proteção via software.
No início, eram as tabelas PARADOX. Elas, aparentemente, podiam proteger os dados utilizando uma senha "embutida" diretamente nas tabelas. O sistema, contendo entrincados meios de autenticar os usuários, "abriam" estas tabelas com a senha pré-definida.
A principal falha deste método reside no fato de que a senha está em algum ponto no executável, e com um editor de arquivos que mostre hexadecimal, poderá ser encontrada.
Os programadores, motivados pela perspicácia dos invasores, resolveram codificar a senha, mas a necessidade de se obter informações sempre é mais forte, e os invasores começaram a ver que:
"A corrente parte sempre em seu elo mais fraco"
Como os programas estavam cada vez mais protegidos, as atenções se voltaram para os bancos de dados. Afinal, o objetivo é roubar a informação e não invadir o programa.
Recuperar dados de um sistema não é a coisa mais difícil do mundo quando o programador se apoia somente na segurança do sistema operacional e do servidor de banco de dados. No caso do PARADOX, eu lembro quando recebi um desafio de pegar os dados de uma pessoa em um sistema de cadastro que possuía vários métodos de segurança.
O sistema realmente era bem montado, com senha e políticas de segurança, e o banco continha senha.
Um pouco de tempo na internet e eu consegui acessar todos os dados, com um programa de quebra senhas de tabelas PARADOX, o que mostrou que este tipo de banco de dados não é muito seguro se não for bem estruturado.
Para efeito de didática, eu disponibilizo o programinha em meu site.
Clique aqui para baixar...
Por favor, não o use em bancos de dados de terceiros.
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 pemissa 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 \\
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:
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.
A primeira vista, soluções simples poderão ser adotadas para proteger os dados e dar um pouco mais de trabalho para a pessoa que desejar roubar informações.
A principal premissa a se assumir é:
"Meu servidor sempre estará exposto de alguma forma"
No caso do PARADOX, eu desaconselho o uso. Nada contra o banco de dados, mas eu não acho que ele tenha sido criado para sistemas que estão em produção. Comparando com os servidores SQL atuais de baixo custo (e até grátis), ele não é a melhor solução.
No caso do Interbase, é obvio que o GDB jamais poderá cair em mãos erradas.
Para evitar, ou diminuir o risco, o ideal é, acima de tudo, utilizar o protocolo de rede para acessar o servidor.
Uma aproximação mais eficiente seria utilizar camadas de acesso ao servidor.
Este método só traria vantagens para o usuário e para o programador.
Para melhorar ainda mais a segurança, a rede em que está localizado o servidor poderia ser diferente da rede onde estão os usuários (não fisicamente, mas logicamente).
Um computador com duas placas de rede (e dois endereços IP) poderia conter a camada de acesso, que é visível aos usuários. Esta camada receberia os usuários por uma interface de rede e se comunicaria com o servidor pela outra. Esta abordagem tornaria o servidor simplesmente inacessível diretamente aos usuários, pois ele estaria em uma faixa de IP incompatível com a rede deles.
Caso o programador não tenha acesso aos métodos descritos, seria ideal utilizar a criptografia para proteger os dados. Escrevi alguns artigos na revista (foram matéria de capa das edições 14 e 20) e alguns artigos no site que descrevem como melhorar a segurança dos dados sem confiar esta tarefa ao servidor ou a máquina onde o servidor foi instalado.
Seguem os links destes artigos:
http://www.activedelphi.com.br/modules.php?op=modload&name=News&file=article&sid=236
http://www.activedelphi.com.br/modules.php?op=modload&name=News&file=article&sid=145
http://www.activedelphi.com.br/modules.php?op=modload&name=News&file=article&sid=127
http://www.activedelphi.com.br/modules.php?op=modload&name=News&file=article&sid=123
Uma outra saída, e talvez a mais eficiente, seria manter o nível de paranóia acima do normal (indicado como seguro pelos médicos) e criptografar tudo o que ver pela frente.
Isto inclui todos os dados do banco nas tabelas e também o tráfego na rede!
Eu já ultrapassei a barreira da sanidade ao fazer isso, como um bom gestor de segurança da informação...
Caso o leitor queira chegar a estas fronteiras, faça o download do servidor de SQL que estou aprimorando (sim, é um derivado do FlashFiler da TurboPower). Este servidor de SQL tem todos os componentes para o Delphi e com a vantagem de criptografar tudo o que é armazenado nas tabelas e também criptografar o que é transmitido entre o servidor e os clientes.
A desvantagem é que será uma má notícia para o DBA quando ele descobrir que não lembra da senha do banco ao retornar de férias...
Nenhum comentário:
Postar um comentário