É uma boa prática definir strings de conexão em uma configuração da web?

14

Recentemente eu tenho uma discussão com alguns dos meus colegas no meu trabalho porque eles disseram que é melhor ter em um .DLL uma conexão de string criptografada. E eu disse por que não usar a conexão de string definida no web.config criptografado? é o mesmo e é melhor porque o framework de entidade, por exemplo, procura pelo nome da conexão na configuração web do aplicativo, agora eu quero saber de um ponto de segurança o que é melhor ou qual a melhor prática ??

    
por Jorge 08.11.2011 / 23:22
fonte

3 respostas

18

Não há nenhuma diferença substancial, exceto que você terá que realmente construir um binário se você quiser fazer uma mudança de configuração se você colocá-lo em uma DLL, enquanto que um administrador pode apenas modificar a configuração com uma cópia bem entendida. -shelf ferramentas se está na configuração. Já existe um mecanismo para criptografar strings de configuração e orientações adicionais sobre o MSDN . As versões atuais do Asp.Net podem ter mecanismos alternativos, então faça algumas pesquisas adicionais antes de se comprometer com uma abordagem.

Só porque algo está em uma DLL, isso não a torna mais segura. Um editor de texto também pode abrir arquivos binários, ferramentas como o Reflector podem fornecer uma interface melhor para navegar em uma DLL .Net; uma DLL não fornecerá nenhuma criptografia "extra".

    
por 08.11.2011 / 23:30
fonte
12

Não importa onde os dados criptografados são armazenados, é importante como é criptografado.

As seções criptografadas em um web.config normalmente são criptografadas com a API de proteção de dados , que é extremamente difícil de quebrar sem comprometer toda a máquina. Você também pode usar um contêiner de chave RSA, que é semelhante (difícil de tirá-los da máquina).

Se você quiser armazenar a string criptografada na DLL, tudo bem, eu acho, embora não seja inerentemente mais seguro que um web.config criptografado (qualquer pessoa pode espiar essa DLL com Reflector ), e é obviamente mais difícil de alterar (você precisará recompilar). Mas, novamente, o que é muito mais importante é como essa string criptografada foi gerada; presumivelmente você não está usando os mesmos provedores como faria para um web.config criptografado, então o que você está usando?

Um esquema de criptografia é tão strong quanto a chave privada ou o segredo compartilhado. Se essa chave é também armazenada em sua montagem, você também pode não ter nenhuma criptografia. Se for armazenado em algum banco de dados externo, isso levanta a questão de como a cadeia de conexão do banco de dados é protegida. Isso pode realmente levar a uma segurança mais fraca no geral.

Por outro lado, se você fosse um provedor de serviços e a string de conexão fosse criptografada com uma senha usuário , isso seria mais seguro do que usar uma máquina estática chave. Então, novamente, se você estiver usando senhas de usuário para criptografar, é muito improvável que você codifique permanentemente os dados criptografados em seu assembly, já que ele precisa ser gerado e armazenado em resposta à ação do usuário (não do desenvolvedor). / p>

Realmente não consigo pensar em muitas situações em que a codificação rígida de uma cadeia de conexão (criptografada) na DLL é mais segura do que a criptografia da seção web.config relevante. Na melhor das hipóteses, é só acrescentar inconveniência, na pior das hipóteses, é confiar em alguma segurança personalizada escrita desajeitadamente e cheia de buracos. Faça um favor e faça o que a Microsoft recomenda - apenas criptografe seu web.config se houver dados sigilosos.

    
por 08.11.2011 / 23:38
fonte
2

A melhor prática para o ASP.NET é colocar todas as configurações / configurações no arquivo web.config ou no arquivo app.config (para outros tipos de projeto).

Sobre a criptografia e o motivo para usá-la em suas cadeias de conexão, é preciso ser um caso muito especial. Como na maioria dos casos, até 99%, você não precisa criptografar suas strings de conexão. Os próprios aplicativos corporativos da Microsoft têm sua sequência de conexão exposta no arquivo web.config / app.config. Eu acho que você está complicando demais a segurança.

Mais uma coisa, codificar suas strings de conexão é uma prática ruim. Por exemplo, não coloque nenhuma string de conexão (aka connectionstring) em uma DLL ou .aspx / .ascx / .cshtml ou code-behind.

    
por 08.11.2011 / 23:39
fonte