GARANTIR DESCONTO

Fórum Senha no Firebird #376921

04/05/2010

0

Pessoal

Mudei a senha do meu banco para nimguem acessar minhas tabelas, só que agora preciso instalar meu sistema em um micro que já roda outro sistema com a senha masterkey e o meu banco não irá abrir.
Como é feito nos sistemas por ai, todas as senhas são masterkey ? como resolvo isto ??
Grato
Abraços a todos

Marcos Roberto

Marcos Roberto

Responder

Posts

05/05/2010

Wilson Junior

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.
Responder

Gostei + 0

05/05/2010

Marcos Roberto


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

Responder

Gostei + 0

05/05/2010

Wilson Junior

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.
Responder

Gostei + 0

05/05/2010

Marcos Roberto

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

Responder

Gostei + 0

05/05/2010

Emerson Nascimento

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.

Responder

Gostei + 0

05/05/2010

Wilson Junior

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.
Responder

Gostei + 0

05/05/2010

Marcos Roberto

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
 
Responder

Gostei + 0

12/05/2010

Carlos Mazzi

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...
Responder

Gostei + 0

16/05/2010

Rogerio

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.

    ...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!
Responder

Gostei + 0

18/05/2010

Emerson Nascimento

- 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...


Responder

Gostei + 0

18/05/2010

Rogerio

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!
 
Responder

Gostei + 0

18/05/2010

Rogerio

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!
 
Responder

Gostei + 0

18/05/2010

Marcos Roberto

 Pessoal

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

 vlw

Responder

Gostei + 0

12/04/2013

Cristiano

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.
Responder

Gostei + 0

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar