Criptografia de Dados no Interbase/Firebird
Caros colegas,
Em um teste efetuado e como já é bem conhecido no meio o Interbase/Firebird tem uma deficiencia de Segurança, pois mesmo que troquemos a senha do SYSDBA, para que uma pessoa não autorizada acesse os dados do banco é somente ela copiar o banco para uma maquina que contenha o Interbase/Firebird instalada e que ela conheça a Senha do SYSDBA...
Exemplo:
Digamos que você, possua o Banco de Dados Confidencial.gdb e que tenha trocado a Senha do SYSDBA, Eu simplesmente copio o Arquivo Confidencial.gdb para minha maquina e tenho acesso aos dados...
Estou querendo propor que nos unamos para efetuar essa alteração no Firebird, incluindo a criptografia dos dados no Banco, assim mesmo que tenhamos o Arquivo de Banco de Dados, senão estivermos com a senha correta não consiguiremos ler os dados....
Que vocês acham....
Devemos ou não colocar a ´mão na massa´
Em um teste efetuado e como já é bem conhecido no meio o Interbase/Firebird tem uma deficiencia de Segurança, pois mesmo que troquemos a senha do SYSDBA, para que uma pessoa não autorizada acesse os dados do banco é somente ela copiar o banco para uma maquina que contenha o Interbase/Firebird instalada e que ela conheça a Senha do SYSDBA...
Exemplo:
Digamos que você, possua o Banco de Dados Confidencial.gdb e que tenha trocado a Senha do SYSDBA, Eu simplesmente copio o Arquivo Confidencial.gdb para minha maquina e tenho acesso aos dados...
Estou querendo propor que nos unamos para efetuar essa alteração no Firebird, incluindo a criptografia dos dados no Banco, assim mesmo que tenhamos o Arquivo de Banco de Dados, senão estivermos com a senha correta não consiguiremos ler os dados....
Que vocês acham....
Devemos ou não colocar a ´mão na massa´
Bolus
Curtidas 0
Respostas
Vieira_alex
29/02/2004
Amigo desculpe estar respondendo sua enquete, mas pelo que sei o interbase/Firebird são bds client/server , e neste caso toda sua segurança deverão ser definidas no seu servidor e sistema operacional, tenho certeza que se vc. usar desta forma pessoas ñ autorizadas jamais levarão seu banco para outras máquinas.
Mais um vez, desculpa.
Mais um vez, desculpa.
GOSTEI 0
Afarias
29/02/2004
O colega vieira_alex citou bem:: NÃO há falha de segurança no IB (ou no FB) -- eles funcionam exatamente da mesma forma q qualquer SGBD C/S -- a segurança está no servidor!
A ´criptografia´ dos dados fica por conta do sistema de arquivos do SO, se o banco tivesse seu próprio sistema de criptografia, a performance sofreria muito!
------------------------------------
|Em um teste efetuado e como já é bem conhecido no meio o
|Interbase/Firebird tem uma deficiencia de Segurança,
Não há tal falha no IB e no ´meio´ isso é bem conhecido!
|é somente ela copiar o banco para uma maquina que contenha o
|Interbase/Firebird instalada e que ela conheça a Senha do SYSDBA...
Isso é com qualquer banco C/S -- agora reflita:: quem deixaria seu banco de dados exposto para que qualquer um pudesse copia-lo??
|Eu simplesmente copio o Arquivo Confidencial.gdb para minha maquina
|e tenho acesso aos dados...
Ai o problema é do administrador do servidor! De outra forma, COMO alguem pode ter acesso ao arquivo de dados??
|Estou querendo propor que nos unamos para efetuar essa alteração no
|Firebird, incluindo a criptografia dos dados no Banco, assim mesmo que
|tenhamos o Arquivo de Banco de Dados, senão estivermos com a senha
|correta não consiguiremos ler os dados....
Isso não rola... não para bancos de dados C/S (pode ser até uma opção em alguns, mas muito pouco utilizada)
T+
A ´criptografia´ dos dados fica por conta do sistema de arquivos do SO, se o banco tivesse seu próprio sistema de criptografia, a performance sofreria muito!
------------------------------------
|Em um teste efetuado e como já é bem conhecido no meio o
|Interbase/Firebird tem uma deficiencia de Segurança,
Não há tal falha no IB e no ´meio´ isso é bem conhecido!
|é somente ela copiar o banco para uma maquina que contenha o
|Interbase/Firebird instalada e que ela conheça a Senha do SYSDBA...
Isso é com qualquer banco C/S -- agora reflita:: quem deixaria seu banco de dados exposto para que qualquer um pudesse copia-lo??
|Eu simplesmente copio o Arquivo Confidencial.gdb para minha maquina
|e tenho acesso aos dados...
Ai o problema é do administrador do servidor! De outra forma, COMO alguem pode ter acesso ao arquivo de dados??
|Estou querendo propor que nos unamos para efetuar essa alteração no
|Firebird, incluindo a criptografia dos dados no Banco, assim mesmo que
|tenhamos o Arquivo de Banco de Dados, senão estivermos com a senha
|correta não consiguiremos ler os dados....
Isso não rola... não para bancos de dados C/S (pode ser até uma opção em alguns, mas muito pouco utilizada)
T+
GOSTEI 0
Vinicius2k
29/02/2004
Colega bolus,
Pense bem... o que vc propõe é incluir em um banco de dados C/S, projetado para rodar sob a segurança do S.O, seja Linux/Unix ou Windows Server, obedecendo as regras de segurança da rede, aspectos encontrados em bancos desktop como Access e Paradox...
Segurança de rede é coisa muito séria e a responsabilidade é e, no meu ponto de vista, deve continuar sendo do S.O... acho transfererir esta responsabilidade para o banco de dados não faz nenhum sentido...
T+
Pense bem... o que vc propõe é incluir em um banco de dados C/S, projetado para rodar sob a segurança do S.O, seja Linux/Unix ou Windows Server, obedecendo as regras de segurança da rede, aspectos encontrados em bancos desktop como Access e Paradox...
Segurança de rede é coisa muito séria e a responsabilidade é e, no meu ponto de vista, deve continuar sendo do S.O... acho transfererir esta responsabilidade para o banco de dados não faz nenhum sentido...
T+
GOSTEI 0
Bolus
29/02/2004
Caros colegas,
o que vocês alegaram, realmente é correto, mas como não vivemos em um muito perfeito onde os computadores (servidores ) estão em ambiente protegido de acesso de estranhos, ou até funcionários não autorizados. E como sabemos existem hoje SO CD Live, como o Linux Kurumin, assim alguem não autorizado poderia acessar oServidor e Bootar com um CD Live e pegar somente o arquivo GDB e levar embora, podendo abrir posteriormente em sua residencia, sem problemas....
O que estava querendo verificar, é se poderia ser criada uma rotina que atualizaria a base criptografada, tentando assim dar uma maior segurança nos dados. Como qualquer implementação existe 3 pontos a verificar
Performance
Segurança
Custo (Tempo)
Existem clientes que preferem sacrificar um pouco a performance por uma segurança maior, bem como o contrario...
Esta implementação poderia ser um parametro na criação do Banco, assim teriamos a opção de ter ou não a criptografia no banco...
O que acham????
Todas as opniões são validas principalmente que queremos a mesma coisa, segurança e performance melhores....
o que vocês alegaram, realmente é correto, mas como não vivemos em um muito perfeito onde os computadores (servidores ) estão em ambiente protegido de acesso de estranhos, ou até funcionários não autorizados. E como sabemos existem hoje SO CD Live, como o Linux Kurumin, assim alguem não autorizado poderia acessar oServidor e Bootar com um CD Live e pegar somente o arquivo GDB e levar embora, podendo abrir posteriormente em sua residencia, sem problemas....
O que estava querendo verificar, é se poderia ser criada uma rotina que atualizaria a base criptografada, tentando assim dar uma maior segurança nos dados. Como qualquer implementação existe 3 pontos a verificar
Performance
Segurança
Custo (Tempo)
Existem clientes que preferem sacrificar um pouco a performance por uma segurança maior, bem como o contrario...
Esta implementação poderia ser um parametro na criação do Banco, assim teriamos a opção de ter ou não a criptografia no banco...
O que acham????
Todas as opniões são validas principalmente que queremos a mesma coisa, segurança e performance melhores....
GOSTEI 0
Afarias
29/02/2004
|E como sabemos existem hoje SO CD Live, como o Linux Kurumin,
|assim alguem não autorizado poderia acessar oServidor e Bootar com {...}
Bom, ainda q ache a situação um pouco fantasiosa (até pq o cara iria simplesmente derrubar o servidor pra fazer isso e... pra passar por isso tudo, tinha q ser um grande criminoso), eu poderia citar::
1 - Portas para a sala do servidor ;)
2 - Gabinetes protegidos por fechadura (aqueles com chavinha)
3 - Servidores sem CDROM :)
4 - Mesmo q se dê boot pelo outro linux não quer dizer q a pessoa tenha acesso aos dados, lembre-se q o proprio sistema operacional possui recursos de criptografia -- basta utilizá-los
T+
|assim alguem não autorizado poderia acessar oServidor e Bootar com {...}
Bom, ainda q ache a situação um pouco fantasiosa (até pq o cara iria simplesmente derrubar o servidor pra fazer isso e... pra passar por isso tudo, tinha q ser um grande criminoso), eu poderia citar::
1 - Portas para a sala do servidor ;)
2 - Gabinetes protegidos por fechadura (aqueles com chavinha)
3 - Servidores sem CDROM :)
4 - Mesmo q se dê boot pelo outro linux não quer dizer q a pessoa tenha acesso aos dados, lembre-se q o proprio sistema operacional possui recursos de criptografia -- basta utilizá-los
T+
GOSTEI 0
Analista1968
29/02/2004
Acho interessante, já que tenho clientes que utilizam em um pen drive um sistema que contem informações confidênciais, e eles tem medo de perder ou serem roubados e essas informações que estão salvas no pen drivre acabem em mão erradas; é um sistema que controla alguns dados financeiros sigilosos; então se o Banco de dados lá contido fosse criptografado eles ficariam mais tranquilos;
GOSTEI 0
Lindomar Sousa.
29/02/2004
Caro coleta, está equivocado... Há uma maneira sim de modificar essa segurança. Basta fazer uma autenticação com outra (security2.fdb)... Nossa empresa por exemplo, o banco de dados só abre com nossa (security2.fdb)... Essa aí, você define outra senha... Por padrão, ela vem com USER: SYSDBA and PWD: masterkey.... Podemos criar a nossa própria e aí nosso banco só abre com as credenciais que estiverem nela... Sugiro que pesquise: "Como criar outra security2.fdb" e encontrarás o que procura...
GOSTEI 0