none
criar um Database central com Criptografia RRS feed

  • Pergunta

  • Boa Noite....

    Saber aquela postagem minha, sobre criptografar os mdf..

    1º de Tudo: Gostaria de saber, se é possivel criar um database central com segurança e outras proteções, para quando eu vender o meu software, para não ter varios databases em cada pprograma.

    Entendeu a minha pergunta?

    2º : será é possivel, criar um database central, onde supondo que eu tenho 10 softwares, e quero criar uma database ponde ele armazenará estes dados deste 10 softwares?

    Obrigado pela Atenção.

     

    quarta-feira, 20 de abril de 2011 22:52

Respostas

  • Rafael:

    Internamente no SGDB você pode criar um usuário com acesso limitado ao banco que a sua aplicação utiliza. Você pode, por exemplo, conceder acesso somente leitura a determinadas tabelas e acesso de update e insert para outras (é claro, existem outras possibilidades e combinações). O fato é que uma recomendação básica é que sua aplicação utilize um usuário que possua a menor permissão possível (nada de usar SA para acessar ao banco). Isso você deve fazer como boa prática.

     

    A dica do Junior com relação às permissões de pasta é uma boa, mas é um controle que dependerá do administrador da rede e como você irá distribuir sua aplicação para clientes, creio que esse não seja o caminho.

     

    Quanto à proteção com criptografia, quero deixar o link abaixo para você dar uma lida:

    http://www.devmedia.com.br/post-4402-Criptografia-no-SQL-Server-2005.html

    É possível criptografar uma coluna, uma tabela ou o banco inteiro. É claro, que no último caso o esforço será bem maior. Aconselho-te a ler o link e qualquer coisa me retorne.

     

     


    SQL SERVER sempre
    domingo, 17 de abril de 2011 17:56
  • Bom Dia,

    Ao meu ver atender essa necessidade é um pouco utópico. A partir do momento em que seu banco de dados está no cliente, você não terá mais controle sobre diversos fatores que podem facilitar o acesso não autorizado. Criptografia pode ajudar, mas não irá resolver. Se o cliente desejar abrir o banco, basta que ele pare o serviço e copie os arquivos desejados, ou até faça um backup e restaure em outro local.

    Mesmo as chaves de criptografia não podem impedir que o cliente "mexa" se ele quiser. Se as concessões foram feitas com base em privilégios, basta ele promover-se a SA e conseguirá abrir as chaves de criptografia. Se as mesmas foram concedidas com base em senha, basta rodar um Profiler e ver a senha que a aplicação usou para abrí-las.

    Temos de fazer de tudo para tornar a aplicação mais segura contra acesso não autorizado, pois, seria muito ruim o cliente reclamar que foi invadido por conta de uma falha na aplicação ou no banco, mas se o cliente realmente quiser mexer, acredite. Ele vai mexer.

    O que vejo tradicionalmente as empresas de software fazerem não é criptografar os dados propriamente, mas simplesmente criar milhares de tabelas com nomes estranhos e colocar toda a lógica na aplicação. Como o cliente não conseguirá quebrar o fonte da aplicação, ao tentar abrir o banco também não entenderá nada do modelo de dados.

    Isso funciona, mas estou certo que diminui muito a produtividade da solução bem como o seu desempenho, acompanhado quase sempre do aumento do custo do software. Normalmente esses artifícios são empregados quando o software não possui muitos concorrentes (não seria o caso de um ERP por exemplo)

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 21 de abril de 2011 12:50

Todas as Respostas

  • Bom Dia....

    Gostaria de saber, se é possível criptografar um teste.mdf com AES ou outras, chaves simetricas para proteger o meu database?

    E se é possível criar um SytemDatabase, para ficar junto com o Master, model estes databases.

    Obrigado pela a sia atenção.

    sábado, 16 de abril de 2011 13:45
  • Boa Tarde,

    De quem propriamente você está querendo proteger o Database ? De alguém logar por fora da aplicação e acessá-lo ? Do DBA mexer sem o seu consentimento ? Existem algumas alternativas, mas preciso entender exatamente o que você está querendo fazer.

    Não é possível criar um System Database. Eles já vem definidos junto com o produtos e não é possível adicionar novos.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    sábado, 16 de abril de 2011 15:26
  • Boa Tarde....

    Eu estou desenvolvendo uma aplicação, para eu comercializá-la e ouvi dizer que tem pessoas que invadem o seu database e pegam a suas informações.

    Ou seja, queria proteger para ninguem modificá-la e armazene dos dados sem ninguem mexer.

    O meu software é uso de empresas, que estou desenvolvendo.

    Obigado pela atenção.

    sábado, 16 de abril de 2011 16:12
  • Rafael,

    Cara sinceramente, nada é 100% seguro, e sempre teremos alguém tentando fazer este tipo de procedimento.

    No SQL Server 2005 quando falamos de criptografia podemos implementar recursos como Master Database key, Chaves Simétricas e Assimétricas, Certificados, Algoritmo Hashing!!!

    Em relação a segurança o que você poderia é pensar em limitar os acessos aos seus bancos de acordo com as permissões de acesso e manipulação, outro detalhe importante, você também deverá limitar os acessos arquivos de banco de dados .mdf e .ldf através das permissões de pastas.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
    sábado, 16 de abril de 2011 23:46
    Moderador
  • Bom Dia....

    Realmente, gostaria de saber, 

    limitar os acessos do meu bancos de acordo com as minhas permissões de acesso e manipulação, e também  limitar os acessos arquivos de banco de dados .mdf e .ldf através das permissões de pastas.

    É Possível?

    Eu nunca mexi om criptografia de database....

    Obrigado pela Atenção.

    domingo, 17 de abril de 2011 14:00
  • Rafael:

    Internamente no SGDB você pode criar um usuário com acesso limitado ao banco que a sua aplicação utiliza. Você pode, por exemplo, conceder acesso somente leitura a determinadas tabelas e acesso de update e insert para outras (é claro, existem outras possibilidades e combinações). O fato é que uma recomendação básica é que sua aplicação utilize um usuário que possua a menor permissão possível (nada de usar SA para acessar ao banco). Isso você deve fazer como boa prática.

     

    A dica do Junior com relação às permissões de pasta é uma boa, mas é um controle que dependerá do administrador da rede e como você irá distribuir sua aplicação para clientes, creio que esse não seja o caminho.

     

    Quanto à proteção com criptografia, quero deixar o link abaixo para você dar uma lida:

    http://www.devmedia.com.br/post-4402-Criptografia-no-SQL-Server-2005.html

    É possível criptografar uma coluna, uma tabela ou o banco inteiro. É claro, que no último caso o esforço será bem maior. Aconselho-te a ler o link e qualquer coisa me retorne.

     

     


    SQL SERVER sempre
    domingo, 17 de abril de 2011 17:56
  • Rafael,

    No meu blog eu disponibilizei alguns artigos e apresentações sobre criptografia, faça um acesso: pedrogalvaojunior.wordpress.com

     


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
    terça-feira, 19 de abril de 2011 17:59
    Moderador
  • Bom Dia,

    Ao meu ver atender essa necessidade é um pouco utópico. A partir do momento em que seu banco de dados está no cliente, você não terá mais controle sobre diversos fatores que podem facilitar o acesso não autorizado. Criptografia pode ajudar, mas não irá resolver. Se o cliente desejar abrir o banco, basta que ele pare o serviço e copie os arquivos desejados, ou até faça um backup e restaure em outro local.

    Mesmo as chaves de criptografia não podem impedir que o cliente "mexa" se ele quiser. Se as concessões foram feitas com base em privilégios, basta ele promover-se a SA e conseguirá abrir as chaves de criptografia. Se as mesmas foram concedidas com base em senha, basta rodar um Profiler e ver a senha que a aplicação usou para abrí-las.

    Temos de fazer de tudo para tornar a aplicação mais segura contra acesso não autorizado, pois, seria muito ruim o cliente reclamar que foi invadido por conta de uma falha na aplicação ou no banco, mas se o cliente realmente quiser mexer, acredite. Ele vai mexer.

    O que vejo tradicionalmente as empresas de software fazerem não é criptografar os dados propriamente, mas simplesmente criar milhares de tabelas com nomes estranhos e colocar toda a lógica na aplicação. Como o cliente não conseguirá quebrar o fonte da aplicação, ao tentar abrir o banco também não entenderá nada do modelo de dados.

    Isso funciona, mas estou certo que diminui muito a produtividade da solução bem como o seu desempenho, acompanhado quase sempre do aumento do custo do software. Normalmente esses artifícios são empregados quando o software não possui muitos concorrentes (não seria o caso de um ERP por exemplo)

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 21 de abril de 2011 12:50
  • Boa Tarde.....

    Li o respeito da segunte frase: "O que vejo tradicionalmente as empresas de software fazerem não é criptografar os dados propriamente, mas simplesmente criar milhares de tabelas com nomes estranhos e colocar toda a lógica na aplicação. Como o cliente não conseguirá quebrar o fonte da aplicação, ao tentar abrir o banco também não entenderá nada do modelo de dados.".

    Na verdade....

    Se eu criar um database sql, ex: cujo nome é teste, e eu criar tabelas por exemplo: possso usar caracteres, numeros e letras? Como vc falou, ter nomes estranhos... no Banco de dados criado.

    Se eu fizer isto, como seria a logia para eu aplicar?

     

    Obrigado pela Atenção. 

    quinta-feira, 21 de abril de 2011 19:52