Autor
Mensagem
Postado em: 4/5/2010 10:26:53 PM
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
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
País: Brasil
Estado: RS
Cidade: Caxias do Sul
Mensagens: 1574
Postado em: 5/5/2010 07:51:54 AM
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.
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.
Postado em: 5/5/2010 09:36:34 AM
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
País: Brasil
Estado: RS
Cidade: Caxias do Sul
Mensagens: 1574
Postado em: 5/5/2010 09:47:19 AM
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.
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.
Postado em: 5/5/2010 10:46:27 AM
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
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
Postado em: 5/5/2010 12:46:38 PM
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.
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.
País: Brasil
Estado: RS
Cidade: Caxias do Sul
Mensagens: 1574
Postado em: 5/5/2010 01:14:24 PM
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.
Espero ter colaborado.
Postado em: 5/5/2010 01:35:52 PM
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
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
Postado em: 12/5/2010 07:08:14 PM
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...
Postado em: 16/5/2010 01:40:07 PM
Citação:
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!
Postado em: 18/5/2010 08:45:35 AM
- 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...
- 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...
Postado em: 18/5/2010 10:53:04 AM
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!
Postado em: 18/5/2010 10:53:07 AM
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!
Postado em: 18/5/2010 03:12:36 PM
Pessoal
Valeu pelas Dicas.
O Forum é pra isto mesmo 'Sempre ajudar'.
vlw
Valeu pelas Dicas.
O Forum é pra isto mesmo 'Sempre ajudar'.
vlw
Postado em: 12/4/2013 11:07:57 AM
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.
É 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.
