Uma dúvida muito comum em empresas, é se existe segurança de guardar a connection String no Web.Config.
Segue alguns links abaixo e mais alguns comentários meus:
Storing Database Connection Strings Securely
http://msdn.microsoft.com/vcsharp/downloads/samples/default.aspx?pull=/library/en-us/dnnetsec/html/secnetch12.asp?frame=true#storingdatabaseconnectionstrings
How To: Store an Encrypted Connection String in the Registry
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT11.asp
de
Building Secure ASP.NET Applications
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp
Caso seja um nível de segurança apenas para o usuário, não vejo problemas em
colocar as informações de conexão no Web.Config.
A não ser que descubram um meio de fazer download do Web.Config via browser,
assim como faziamos antigamente no IIS 4 com o Global.asa do servidor
(http://www.endereco.com.br/global.asa+.htr).
Esse é um risco que devemos correr, mas se o seu SQL Server não permitir
conexões remotas (de fora do domínio/rede interna), não vejo problemas, pois
a dificuldade para se conectar ao seu SQL Server aumenta bastante já que a
pessoa teria que se autenticar em sua rede para utilizá-lo.
Como tudo é feito internamente dentro do servidor, também não seria possível
a monitoração de pacotes.
Caso o seu problema seja também com a segurança interna da empresa, ou seja,
usuários e/ou alguns desenvolvedores não podem ter acesso a essa senha, a
solução é criar um método que criptografe e descriptografe a senha dentro de
uma classe fechada e desenvolvida pelo responsável.
Outra forma, é utilizar um usuário sem permissões de drop, truncate e delete
no banco de dados.
Também poderíamos criar dois ambientes, desenvolvimento e o ambiente de
produção, onde, no ambiente de produção só alguns usuários teriam acesso de
leitura no diretório onde o Web.Config ficaria, e uma ou algumas pessoas
responsáveis teriam acesso a este diretório.
0 comentários:
Postar um comentário