none
Trava do tipo "Licença" em Stored Procedures

    Question

  • Caros Experts, boa noite!

    Atualmente trabalho em uma fábrica de software que faz alguns complementos de programas de softwares ERP. Nesses programas, no inicio de nosso projeto como eram processos simples dirigidos a clientes específicos não tinhamos o cuidado em proteger as nossas Stored Procedures; e o resultado disso foi que muitos dos nossos softwares começaram a ser utilizados por espertinhos que sequer pagam o licenciamento.

    A minha pergunta é: Há alguma forma na qual eu possa implementar algum objeto de validação em minhas SP para que a cada 1 ano haja a renovação, e em contra-partida se essa SP for quebrada (validação e verificação) eu consiga dropar o banco de dados e emitir uma mensagem de licenciamento?

    Pensei em algo relacionado a data, na qual no momento de implementação faria uma validação em todos os registros antes de inserir,se encontrasse a SP de validação e a mesma estivesse no prazo ok, se não, dá um drop database e envia uma mensagem de print.   

    Desde já obrigado!

    Abraços []'s

    Friday, July 22, 2011 2:25 AM

Answers

  • Boa Noite,

    Acredito que um código que propositalmente dê um DROP DATABASE seria passível de muitos problemas e processos. O uso não autorizado do software é crime, mas excluir intencionalmente os dados do cliente que não lhe pertencem pode render um processo muito maior do que o não licenciamento. Forçar que o software pare de funcionar é uma coisa, mas excluir os dados é outra bem diferente. Me parece uma penalidade extremamente exagerada.

    O SQL Server 2005 e superiores permitem que as stored procedures sejam assinadas com certificados com data de expiração. Isso permite que possamos descobrir se uma procedure foi ou não alterada. Quando uma stored procedure é assinada e alguém a altera, a assinatura é invalidada e mesmo que o cliente volte o código antigo, a procedure não terá mais assinatura. Isso é muito interessante para descobrir situações onde o cliente altera o código e jura que ninguém "mexeu".

    O DROP Database não é possível, pois, se a stored procedure está no banco e está sendo chamada o banco está em uso e não poderá ser excluído. Você até poderia tentar matar o seu processo para prosseguir com o DROP, mas o SQL Server não permite suicídio, ou seja, você não pode matar o seu próprio processo. Até teríamos contornos como colocar as procedures em um determinado banco e os dados em outro, mas além de ser arquiteturalmente horrível, irá dar outros problemas.

    Se você realmente precisa validar e controlar a licença eu sugiro que você o faça pela sua aplicação e não pelo banco de dados. Validar esse tipo de informação pelo banco de dados é um esforço inútil por duas razões:

    - Se alguém possui o banco, esse alguém possui o controle e nesse caso será muito fácil quebrar seus códigos e retirar qualquer validação. Mesmo que você criptografe o conteúdo da SP, a criptografia dos fontes é facilmente quebrável

    - Mesmo que você conseguisse fazer as implementações que deseja, o dono do banco sempre terá um backup à disposição. Então o DROP poderia ser desfeito quantas vezes o cliente quisesse até que quebrasse os seus códigos

    O máximo que você conseguiria chegar é criptografar os dados com um certificado com data de validade e quando a data expirasse, os dados não poderiam ser descriptografados. Ainda assim, se o cliente for um pouco esperto, pode usar o certificado para descriptografar os dados antes (ou usar um backup de novo).

    Uma solução de ERP não é feita só de banco de dados. Você pode implementar o controle de licenciamento na aplicação. Um bando de dados e procedures não é nada senão há front end para manipulá-los. Então o controle na aplicação é o mais recomendado. No SQL Server você só pode evoluir se criar as procedures em CLR, mas aí o desempenho pode ser sacrificado.

    [ ]s,

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


    Classifique as respostas. O seu feedback é imprescindível
    Friday, July 22, 2011 5:29 AM

All replies

  • Iniciante,

     

    Se teoricamente ninguem pode mexer no banco, não poderia simplismente disponibilizar um usuario com permissao de leitura e escrita para seus cliente? assim eles nao teriam permissao para mexer em seu sistema?


    Fabrizzio A. Caputo
    Certificações:
    Oracle OCA 11g
    MCITP SQL Server 2008 Implementation and Maintenance
    MCTS SQL Server 2008
    Developer Blog Pessoal: www.fabrizziocaputo.wordpress.com
    Blog Empresa: www.tripletech.com.br/blog
    Twitter: @FabrizzioCaputo
    Email: fabrizzio.antoniaci@gmail.com
    Friday, July 22, 2011 2:48 AM
  • Boa Noite,

    Acredito que um código que propositalmente dê um DROP DATABASE seria passível de muitos problemas e processos. O uso não autorizado do software é crime, mas excluir intencionalmente os dados do cliente que não lhe pertencem pode render um processo muito maior do que o não licenciamento. Forçar que o software pare de funcionar é uma coisa, mas excluir os dados é outra bem diferente. Me parece uma penalidade extremamente exagerada.

    O SQL Server 2005 e superiores permitem que as stored procedures sejam assinadas com certificados com data de expiração. Isso permite que possamos descobrir se uma procedure foi ou não alterada. Quando uma stored procedure é assinada e alguém a altera, a assinatura é invalidada e mesmo que o cliente volte o código antigo, a procedure não terá mais assinatura. Isso é muito interessante para descobrir situações onde o cliente altera o código e jura que ninguém "mexeu".

    O DROP Database não é possível, pois, se a stored procedure está no banco e está sendo chamada o banco está em uso e não poderá ser excluído. Você até poderia tentar matar o seu processo para prosseguir com o DROP, mas o SQL Server não permite suicídio, ou seja, você não pode matar o seu próprio processo. Até teríamos contornos como colocar as procedures em um determinado banco e os dados em outro, mas além de ser arquiteturalmente horrível, irá dar outros problemas.

    Se você realmente precisa validar e controlar a licença eu sugiro que você o faça pela sua aplicação e não pelo banco de dados. Validar esse tipo de informação pelo banco de dados é um esforço inútil por duas razões:

    - Se alguém possui o banco, esse alguém possui o controle e nesse caso será muito fácil quebrar seus códigos e retirar qualquer validação. Mesmo que você criptografe o conteúdo da SP, a criptografia dos fontes é facilmente quebrável

    - Mesmo que você conseguisse fazer as implementações que deseja, o dono do banco sempre terá um backup à disposição. Então o DROP poderia ser desfeito quantas vezes o cliente quisesse até que quebrasse os seus códigos

    O máximo que você conseguiria chegar é criptografar os dados com um certificado com data de validade e quando a data expirasse, os dados não poderiam ser descriptografados. Ainda assim, se o cliente for um pouco esperto, pode usar o certificado para descriptografar os dados antes (ou usar um backup de novo).

    Uma solução de ERP não é feita só de banco de dados. Você pode implementar o controle de licenciamento na aplicação. Um bando de dados e procedures não é nada senão há front end para manipulá-los. Então o controle na aplicação é o mais recomendado. No SQL Server você só pode evoluir se criar as procedures em CLR, mas aí o desempenho pode ser sacrificado.

    [ ]s,

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


    Classifique as respostas. O seu feedback é imprescindível
    Friday, July 22, 2011 5:29 AM
  • Olá Fabricio, bom dia!

    Então essa opção não está disponível, pois a grande maioria dos sistemas ERP que trabalho, todos se conectam através da aplicação com a senha do SA.

    Obrigado!

    Abs![]

    Saturday, July 23, 2011 1:06 PM
  • Olá Gustavo!

     

    Primeiramente obrigado pela preocupação e a resposta! A priori fizemos alguns testes, e colocamos no DB uma procedure "Easter Egg" que fazia Shrink e Truncate e drop nas procedures após uma determinada data; mais isso traria problemas de recuperação posteriores, então decidimos deixar só no nosso ambiente.

    De toda maneira, vamos pensar nessa solução via aplicação que você recomendou. Mesmo assim obrigado e sucesso! 

    Abs[]'s

    Saturday, July 23, 2011 1:11 PM