Qual é a melhor maneira de armazenar string de conexão em DLLs .NET?

Question

A aplicação que minha equipe está desenvolvendo atualmente possui uma DLL que é utilizada para realizar todos os acessos ao banco de dados.O aplicativo não pode usar uma conexão confiável porque o banco de dados está protegido por um firewall e o servidor de domínio não.Portanto, parece que a cadeia de conexão precisa ter um nome de usuário e uma senha do banco de dados.A DLL atualmente tem a string de conexão do banco de dados codificada, mas não quero fazer isso quando iniciarmos, pois o assembly pode ser desmontado e o nome de usuário e a senha estarão abertos.

Um dos requisitos é que a senha seja alterada uma vez a cada poucos meses, portanto, precisaríamos distribuí-la para nossa base de usuários interna.

Existe uma maneira de armazenar a senha criptografada de forma que possamos distribuí-la facilmente para toda a base de usuários sem armazená-la na montagem?

ATUALIZAR:Obrigado a todos que responderam.Vou tentar responder algumas das perguntas de volta para mim...A DLL de dados é usada por ASP.NET WebForms e VB.NET WinForms.Entendo que os aplicativos podem ter seus próprios arquivos de configuração, mas não vi nada sobre arquivos de configuração para DLLs.Infelizmente, não consigo chegar ao posto de Jon Galloway no trabalho, então não posso julgar se isso funcionará.Do ponto de vista do desenvolvimento, não queremos usar serviços web internamente, mas poderemos fornecê-los a terceiros no próximo ano.Não creio que a representação funcione porque não podemos autenticar o usuário através do firewall.Como um usuário (ou ex-usuário) pode ser um invasor, estamos escondendo isso de todos!

Answer 1

Não tenho certeza, mas acredito que você pode colocá-lo em um arquivo de configuração e criptografar o arquivo de configuração.

Atualizar:Veja a postagem de Jon Galloway aqui.

Answer 2

Apenas suponha que os bandidos irão obter as credenciais do seu arquivo de configuração.Isso significa que eles poderão fazer login no seu banco de dados e fazer tudo o que o usuário for capaz.Portanto, certifique-se de que o usuário não possa fazer nada de ruim, como acessar as tabelas diretamente.Torne esse usuário capaz apenas de executar determinados procedimentos armazenados e você estará em melhor forma.Este é um lugar onde os sprocs brilham.

Answer 3

Detesto dizer isso, mas assim que você coloca algo em uma máquina cliente, a segurança desses dados sai pela janela.

Se o seu programa for descriptografar essa string, você precisará assumir que um invasor pode fazer o mesmo.Anexar um depurador ao seu programa seria uma maneira.

Armazenar a string de conexão em um servidor e obtê-la por meio de uma conexão da Web parece bom, até você perceber que também precisa de segurança nessa conexão da Web; caso contrário, um invasor poderá se passar pelo seu programa e se comunicar com a conexão da Web.

Deixe-me fazer uma pergunta.De quem você está escondendo a string de conexão?O usuário ou um invasor?E se for o usuário, por quê?

Answer 4

Existem algumas outras ideias também.Você sempre pode usar a representação.Além disso, você pode usar a Biblioteca Corporativa (Biblioteca Comum).

<section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<enterpriseLibrary.ConfigurationSource selectedSource="Common">
<sources>
  <add name="Common" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
    filePath="Config\Exception.config" />
</sources>

Answer 5

O .NET oferece suporte à criptografia em valores de configuração como este.Você poderia deixá-lo em um arquivo de configuração, mas criptografado.

Answer 6

Você deseja distribuir a DLL com todas as informações de configuração em um local configurável, mas o fato é que você não pode ter um dos úteis arquivos de configuração .NET para uma DLL, a menos que faça algo personalizado.

Talvez você precise repensar qual responsabilidade sua DLL deveria ter.Seria possível ou faria sentido exigir que a string de conexão fosse passada pelo usuário da sua biblioteca?Realmente faz sentido que sua DLL leia um arquivo de configuração?

Answer 7

Se o aplicativo for um aplicativo ASP.NET, basta criptografar a seção de cadeias de conexão do seu web.config.

Se o aplicativo for um aplicativo cliente executado em várias máquinas, em vez de armazenar a cadeia de conexão localmente, considere usar um serviço Web ou algum outro tipo de mecanismo seguro para armazená-la centralmente.Isso facilitaria atualizações no futuro e você não armazenaria a cadeia de conexão localmente.

Apenas alguns pensamentos.

Atualizada: @Lassevk

"Armazenar a cadeia de conexão em um servidor e obtê-la por meio de uma conexão da Web parece bom, até você perceber que também precisa de segurança nessa conexão da Web; caso contrário, um invasor poderá se passar pelo seu programa e se comunicar com a conexão da Web. "

A segurança no serviço web estava implícita.Dependendo do tipo de implantação, existem inúmeras opções...por exemplo, certificados do lado do cliente.

Answer 8

Várias opções:

1. Armazene em web.config e criptografe
2. Armazenar em dll e ofuscar (dotfuscator)
3. Armazene um em web.config (criptografado, é claro) e descanse no banco de dados (se você precisar usar vários e a criptografia/descriptografia se tornar um problema)