ActiveDelphi

[gustavocco]

Tem algum modo de bloquear que o usuario acesse o banco de dados através da do usuario sysdba... masterkey???

Detalhe teria que bloquear para q o banco de dados nao pudesse ser aberto por qualquer ide do tipo ibconsole, ibexpert, etc.... nem no micro local, nem remotamente.

Sei que tem como alterar e excuir a senha do banco de dados Especial (no kso do ib seria ISC4.GDB), mas ai se o usuario copiar meu db para outra maquina e abrir nela com o usuario sysdba ele acessaria os dados tranquilamente...

Resumindo será q tem como vincular o password sysdba/masterkey ao meu banco de dados, de forma q se eu excluí-lo ninguem mais acesso meu db com este usuario???

Flw ai...
_________________
Top System - www.topsystem.com.br

[mgrasser]

li a respeito uma vez que vc poderia remover o acesso do sysdba à todas as tabelas, procedures, triggers, views, etc... aí o sysdba em qq máquina não conseguiria acesso, mas nunca testei isso.
_________________
<font color="#0000FF">
<strong><marquee bgcolor="#FFAD00" behavior="slide" direction="right" width="600">..:: MGrasser ::.. </marquee><marquee bgcolor="#FFAD00" behavior="slide" direction="left" width="600">..:: MGrasser ::.. </marquee></strong>

[gustavocco]

perfeito... to pensando nesta hipotese pra nao ter q criptografar todos os dados da minha tabela registro a registro... isso tornaria o sistema muito lento... dai a solucao talvez seria remover o usuario padrao, se vc por acaso encontrar este material ou onde leu ele e tiver como passar ficarei grato... senao o esquema vai ser correr atras mesmo hehehehe....

vlw ai...
_________________
Top System - www.topsystem.com.br

[thomazs]

Pessoal, uma forma de proteger suas tabelas e demais objetos do banco de um possível usuário SYSDBA, é, você criar o banco de dados e, todos os demais objetos com um usuário diferente do sysdba. Então crie um Role com esse nome (SYSDBA) e tire todos os privilégios desse Role ( Revoke All Privileges ). Feito isso, tire todos os privilégios da parte pública (Public - Revoke All Priv...). Por fim, para aumentar a proteção de suas procedures e triggers basta executar os códigos abaixo:

Para procedures:
UPDATE rdb$procedures
SET rdb$procedure_source = NULL,
rdb$description =\'Protegido por lei de copyright\'
WHERE ((rdb$system_flag = 0) OR (rdb$system_flag IS NULL))


Para Triggers:
UPDATE rdb$triggers a
SET rdb$trigger_source = NULL,
rdb$description =\'Protegido por lei de copyright\'
WHERE ((rdb$system_flag = 0)
OR (rdb$system_flag IS NULL))
AND NOT EXISTS(
SELECT rdb$trigger_name FROM rdb$check_constraints
WHERE rdb$trigger_name=a.rdb$trigger_name)


Para Views:
UPDATE rdb$relations
SET rdb$view_source = NULL,
rdb$description =\'Protegido por lei de copyright\'
WHERE ((rdb$system_flag = 0) OR (rdb$system_flag IS NULL))

OBSERVAÇÃO: Esses códigos para proteção de triggers, procedures e views devem ser utilizados nas cópias do banco, isso porque é praticamente impossível desfazer essa operação, então, façam isso apenas nos bancos que forem ser distribuídos (mantendo uma cópia original).

Referência: http://www.firebase.com.br/cgi-bin/firebase.cgi/artigo?ID=162
_________________
Suporte e Consultoria em Desenvolvimento de Sistemas
Bacharel em Sistemas de Informação
Especialista em Bancos de Dados
Desenvolvimento: Clipper, Delphi, PHP, Python/Django

[gustavocco]

vlw thomazs... vou fazer os testes como codigo e dicas acimas ... qqr coisa aviso...

vlw novamente...

abraco...
_________________
Top System - www.topsystem.com.br

[mgrasser]

Fabuloso

Eu testei e as soluções são muito boas, o segredo principal da segurança está na criação da regra (rule) com nome sysdba, que faz com que o sysdba não consiga mais acessar o banco de dados, pois retorna um erro dizendo que existe uma regra com o mesmo nome.

A outra solução de apagar o descritivo das triggers, procedures e views já era conhecida, e tem como objetivo principal proteger o código e não os dados.

_________________
<font color="#0000FF">
<strong><marquee bgcolor="#FFAD00" behavior="slide" direction="right" width="600">..:: MGrasser ::.. </marquee><marquee bgcolor="#FFAD00" behavior="slide" direction="left" width="600">..:: MGrasser ::.. </marquee></strong>

[ricars01]

Também testei e funcionou perfeitamente...

Realmente muito útil. :present:


___________________________________________________
:yltype: [i] \"Programar também é uma expressão artística.\" [/i] :yltype:
_________________
<b>Nova assinatura em elaboração... ainda!! Esta é a versão "alfa"</b>

[mgrasser]

ops , já era, não é difícil acessar os dados da base, já consegui burlar a proteção...

vc não consegue acessar com o sysdba mas com o usuario criado para acessar a base vc tem acesso, e pra conseguir o nome desse usuario basta acessar o servidor com IBConsole.

Daí no novo servidor vc cria o usuario com o mesmo nome e usar qualquer senha que vc vai conseguir abrir os dados do banco ...

Sinto muito
_________________
<font color="#0000FF">
<strong><marquee bgcolor="#FFAD00" behavior="slide" direction="right" width="600">..:: MGrasser ::.. </marquee><marquee bgcolor="#FFAD00" behavior="slide" direction="left" width="600">..:: MGrasser ::.. </marquee></strong>

[mgrasser]

a maior proteção que vc pode ter em banco de dados Firebird é trocar a senha do sysdba no servidor e nunca deixar o arquivo do BD acessível (em pasta compartilhada). isso restringirá quem pode abrir a base a quem tem a senha de administrador do servidor...
_________________
<font color="#0000FF">
<strong><marquee bgcolor="#FFAD00" behavior="slide" direction="right" width="600">..:: MGrasser ::.. </marquee><marquee bgcolor="#FFAD00" behavior="slide" direction="left" width="600">..:: MGrasser ::.. </marquee></strong>

[thomazs]

Olá... claro que não é impossível de se burlar... é até bem simples, porém protege de usuários inexperientes e/ou iniciantes....

Uma outra dica, seria você usar a conexão para o banco de daods de segurança, verificando o usuário... se existir, ou se o banco de segurança for alterado, o sistema simplesmente dá uma mensagem de que o banco de dados foi corrompido, e não permite a abertura... dessa forma o proprio usuário (quem pagou para usar o sistema) ficará mais atento e não deixará qualquer um mecher na base.

Pra quem quiser ver isso funcionando, baixem o SEFIP (www.caixa.gov.br) e tentem alterar alguma coisa no banco. Não é difícil de se conseguir alterar, porém, ao tentar abrir novamente o SEFIP ele diz que o sistema está corrompido. Também não estou dizendo que é impossível de se burlar isso (tem um pequeno macete ), mas melhora muito a questão da segurança e integridade dos dados.

Mas claro que a melhor segurança para os dados, é a segurança do servidor, ou seja, não permitir que qualquer pessoa possa ter acesso ao banco, pois já vi pessoas pegarem um banco de dados de grande porte (DB2), copiarem a pasta equivalente aos dados, para uma outra máquina, e alterarem a senha do banco (por saberem a senha da máquina atual). Ou seja, a segurança é praticamente a mesma.

Mas as dicas acima, creio que darão um pouco de trabalho pra quem irá tentar burlar esses dados.
_________________
Suporte e Consultoria em Desenvolvimento de Sistemas
Bacharel em Sistemas de Informação
Especialista em Bancos de Dados
Desenvolvimento: Clipper, Delphi, PHP, Python/Django

[gustavocco]

Olah.. fiz alguns testes aqui... ficou interessante.. nao era 100% do q queria mas jah foi um bom comeco....

obrigado a todos q ajudaram ai...

flw...
_________________
Top System - www.topsystem.com.br

[adriano_servitec]

Olah pessoal, lendo este post, gostaria de saber se desde Nov/2005 que foi lançado o post ateh nos dias de hoje, se ja foi melhorado a respeito de segurança em bancos de dados firebird.

Tambem estou precisando proteger certas tabelas do banco de dados.

Sobre o SEFIP que o Thomaz mencionou acima, me pareçe que ele faz isso