Trabalho com SQL Server 2016 e precisarei enviar os scripts gerados em algumas releases para nosso cliente, para que possam instalar o pacote em UAT e Production. Gostaria de enviar os scripts em formato DLL ou EXE, para que eles não vejam o conteúdo. É possível? Preciso de alguns aplicativos de terceiros? Se sim, quais?
relate perguntas
-
SQL Server - Como as páginas de dados são armazenadas ao usar um índice clusterizado
-
Preciso de índices separados para cada tipo de consulta ou um índice de várias colunas funcionará?
-
Quando devo usar uma restrição exclusiva em vez de um índice exclusivo?
-
Quais são as principais causas de deadlocks e podem ser evitadas?
-
Como determinar se um Índice é necessário ou necessário
Isso é tecnicamente impossível, mas pode ser implementado dependendo de qual é o seu modelo de ameaça. O problema é que o distribuível resultante deve ser capaz de descompactar/decodificar/descriptografar os scripts de modo que possa submetê-los ao SQL Server, de modo que deve conter todos os algoritmos e chaves necessários.
Se o seu modelo de ameaça envolve tentar impedir que um determinado bisbilhoteiro (talvez um concorrente, ou um chapéu preto procurando encontrar buracos aos quais instalações ainda não corrigidas ainda sejam vulneráveis) de ver o código, isso é impossível com um simples distribuível. Não importa quantas camadas você adicione, elas podem simplesmente desfazê-las analisando o distribuível.
Em segundo lugar, se você criar problemas suficientes para que eles não queiram fazer isso, eles têm outra rota de inspeção: eles podem simplesmente interceptar a comunicação com o SQL Server e observar o código enquanto ele flui. Sim, os fluxos TDS geralmente são criptografados, mas eles estão executando o pacote em seu servidor SQL para que controlem o cliente e o servidor para que possam controlar (e, portanto, interromper para seus próprios propósitos) essa criptografia. Em terceiro lugar, eles sempre podem apenas olhar no banco de dados e comparar o atual com um backup pré-patch se isso tornar as alterações mais óbvias, a única maneira de contornar isso é você hospedar o banco de dados talvez executando seu produto em um SaaS- única maneira.
Se sua preocupação é apenas uma espionagem mais oportunista, então existem muitos empacotadores de instalação [1] por aí que suportam a criação de executáveis auto-extraíveis que executariam um programa no arquivo para executar os scripts também no arquivo e limpar da melhor maneira possível possível depois, e suporta a criptografia ou ofuscação do conteúdo em trânsito.
[1] Não vou mencionar os específicos, pois existem muitos (gratuitos, gratuitos, OpenSource e comerciais), não sei o suficiente sobre nenhum especificamente para compará-los com autoridade, não sei nada sobre seus ambientes de desenvolvimento e produção (outros do que eles incluem o SQL Server) e, de qualquer forma, perguntas/respostas de compras/recomendações são desencorajadas no StackExchange por motivos explicados em detalhes em outro lugar.
Eu recomendaria não usar esse tipo de ferramenta para esse propósito: você está adicionando uma camada de complicação que é desnecessária e pode tornar a depuração de problemas de instalação que podem ocorrer mais problemáticos para você e, portanto, para seu cliente (o que não parecerá bom) .
Se você usar um produto desse tipo, faça-o por conveniência: tornando a instalação um processo de etapa única (ou pelo menos mínima) para seus clientes, a fim de reduzir o risco de erro humano, em vez de uma medida de segurança.
Se sua preocupação for mais "fatores humanos" , como linguagem imprópria em comentários de código ou outras fontes de constrangimento, então a disciplina e a falta de revisões de código são o problema, não a segurança da distribuição, e isso precisa ser corrigido mais cedo em seu processo.
Como uma observação lateral: se com isso você quer dizer que está gerando scripts do SQL Server para distribuir, talvez seja necessário melhorar seu processo de desenvolvimento. Você deve ser capaz de construir tudo, incluindo pacotes de atualização do controle de origem, em vez de gerar scripts de seus bancos de dados dev. Isso pode exigir esforço para que a configuração funcione sem problemas, mas pode salvá-lo de uma coleção de tipos de falhas no futuro.
Sugiro construir um programa shell. Você precisará codificar o script sql nele e construí-lo como arquivo exe. Então, forneça um comando para o cliente executar.
Ou outra maneira de usar a camada de dados no servidor sql. MSDN: https://learn.microsoft.com/en-us/sql/relational-databases/data-tier-applications/data-tier-applications