Senha no Firebird

Caro Marcos,

Eu utilizo uma lógica de comunicação:
1° tento me conectar com o usuário e senha definido por mim, caso não consiga me conectar, tento o 2°;
2° tento me conectar com o usuário e senha definido "SYSDBA martekey", caso não consiga me conectar, tento o 3°;
3° tento me conectar com o usuário e senha definido no arquivo de conexão "Connections.ini", caso não consiga, digo que não foi possível se comunicar com o banco de dados.

Espero ter colaborado.

Paulista


Não Entendi. Veja bem. Se alguem usar o IBExpert e informar SYSDBA,masterkey poderá alterar qualquer tabela.
Preciso mudar a senha masterkey somente para o meu banco, para que ninguem entre atraves do IBExpert.

vlw

Bom, não sei se você sabe, mas se eu pegar o seu arquivo "Banco.fdb" que foi criado pelo seu usuário e senha, e colocar em uma outra máquina que tem o usuário e senha padrão, eu consigo acessar o seu "Banco.fdb".

Existem maneiras de você criar outras instâncias de instalação do Firebird (Firebird_2_Padrao e Firebird_2_Seu). Mas mesmo assim, se o Firebird_2_Padrao tentar acessar o "Banco.fdb" vai conseguir.

Espero ter colaborado.

Paulista

Então não há problema em deixar a senha padrão né, pois as informações são do cliente e ele é quem será penalizado se alguem fazer uso indevido delas.

Vou deixar como tá.

vlw

os dados são do cliente, mas a propriedade intelectual do seu software pode estar em jogo.

o banco de dados pertence ao desenvolvedor (apesar de os dados serem do cliente).
a inteligência na modelagem e relacionamento das tabelas, na criação das stored procedures e triggers e quaisquer regras de negócio contidas no banco de dados pertencem ao desenvolvedor e não ao cliente.

algumas software-houses bloqueiam totalmente o acesso ao seu banco de dados ou salvam os dados criptografados e, se o cliente precisar dos dados (para uma importação por conta de troca de software, por exemplo), elas extraem os dados para arquivos-texto ou xml e entregam ao cliente.



obs.: há meios de apagar o código-fonte das stored procedures e das triggers, deixando no banco de dados somente o código compilado. pense nisso como uma alternativa para proteger a propriedade intelectual do seu software. MAS ATENÇÃO: SE FIZER ISSO GUARDE O FONTE DAS SP's E TRIGGERS EM LUGAR SEGURO E INVIOLÁVEL, POIS NÃO É POSSÍVEL DESFAZER A OPERAÇÃO.

Vale lembra que se o cliente PERMITIR que alterem um arquivo, como por exemplo "Banco.FDB", seja quem for o responsável pela alteração, a responsabilidade é do cliente, pois você não tem como IMPEDIR que o usuário faça algo com o seu PRÓPRIO arquivo.

Espero ter colaborado.

Emerson

Gostei da sua explanação e estou de acordo com voce, mas como fazer para preservar as informações contidas em um Banco.gdb quando em uma Empresa já existe outra aplicação rodando e usando o Interbase com login e senha padrão?.


Grato a vcs
 

E o uso de Rules, para proteger o banco nao resolve? ou minimiza a possibilidade ? (Bom ... de qualquer forma dá pra quebrar tbm...) mas é mais impecilho pra quem quiser pegar o seu banco...

    ...algumas software-houses bloqueiam totalmente o acesso ao seu banco de dados...     Boa tarde Emerson, fiquei pensando como aplicar está segurança dos fontes, mas confeço que não entendi.     Você poderia explicar como isso funciona ou indicar alguma máterial que fale a respeito disso? Isso seria muito importante pra mim.       Muito Obrigado!

- criptografando os dados (e apagando o código-fonte das stored procedures e triggers)
- usar um SGBDR onde o usuário e senha fiquem gravados no próprio arquivo do banco de dados (SQL SERVER é um deles, me parece que as versões mais novas do FB são/eram pra ser assim também).
- no caso do FB, criar uma instalação (instância) só para o software, usando RULES.

etc...

Emerson, obrigado por responder a minha dúvida!!! Eu estou utilizando o Firebird 2.0 e para administrar o banco IBExpert. Você disse:
"- criptografando os dados (e apagando o código-fonte das stored procedures e triggers)"
É possível apagar o código-fonte das stored procedures e triggers no Firebird?
"-usar um SGBDR onde o usuário e senha fiquem gravados no próprio arquivo do banco de dados (SQL SERVER é um deles, me parece que as versões mais novas do FB são/eram pra ser assim também)."
Pelo menos o que eu sei, até a versão 2.1 do Firebird não é possível gravar a senha no banco.
"- no caso do FB, criar uma instalação (instância) só para o software, usando RULES."
Eu não entendi. Eu já tenho o Firebird instalado no computador.
Marcos me desculpe por estar utilizando o seu tópico, não vou mais incomodar!
 

Emerson, obrigado por responder a minha dúvida!!! Eu estou utilizando o Firebird 2.0 e para administrar o banco IBExpert. Você disse:
"- criptografando os dados (e apagando o código-fonte das stored procedures e triggers)"
É possível apagar o código-fonte das stored procedures e triggers no Firebird?
"-usar um SGBDR onde o usuário e senha fiquem gravados no próprio arquivo do banco de dados (SQL SERVER é um deles, me parece que as versões mais novas do FB são/eram pra ser assim também)."
Pelo menos o que eu sei, até a versão 2.1 do Firebird não é possível gravar a senha no banco.
"- no caso do FB, criar uma instalação (instância) só para o software, usando RULES."
Eu não entendi. Eu já tenho o Firebird instalado no computador.
Marcos me desculpe por estar utilizando o seu tópico, não vou mais incomodar!
 

 Pessoal

 Valeu pelas Dicas.
 O Forum é pra isto mesmo 'Sempre ajudar'.

 vlw

Olá.
É o seguinte no Firebird até a versão 2.5 não existe como bloquear o acesso ao banco, mesmo trocando senhas, adicionando rules etc..ou qualquer outro procedimento não impede que seja copiado o banco de onde ele estiver instalado e depois aberto em um outro servidor com SYSDBA e senha masterkey. Parece que na versão 3.0 do FB isso irá mudar, mas também esta informação não é garantida.