在Windows Azure中存储密码的最佳实践

嗯,开发人员本来就不应该访问生产数据库。这本质上是不安全的,无论是在Azure上还是在其他地方。对生产数据库执行实时调试是一项风险很大的业务,因为一个简单的错误可能会毁掉整个生产。相反,我建议复制生产数据(最终作为一个过夜的过程),让开发人员针对非生产副本工作。

我认为这可以通过一种凭证存储服务来部分解决。 我的意思是一种不需要密码的服务,但是只允许机器和SSPI认证的用户访问,这些用户是白名单。 0)安全块具有一种ACL,该ACL具有IP白名单、基于计算机名的白名单或每个命名资源的基于证书的白名单,或混合使用。 2) 受保护的信息片段只能通过SSL访问,并且此API是只读的。 3) 客户端必须预先确认自己的权限,并通过调用类似于api的 https://s.product.com/ 3) 客户端必须提供证书,并且每次调用时计算机标识必须与资源的逻辑白名单数据匹配。 4) 请求数据看起来是这样的: https://s.product.com/resource-name Header:X-Ticket:在步骤3中获得的值,直到它过期,

因此,它可以在连接字符串中存储此类安全资源的别名,而不是用户名和密码,在代码中,该别名将被从步骤4获得的真实用户名密码替换为Sql连接工厂中的用户名密码。别名可以指定为特殊格式的用户名,如obscreded@s.product.com/product1/dev/resource-name

Dev和prod实例可以有不同的凭据别名,如product1.Dev/resource1和product1/staging/resource1等等。

因此,只有通过调试prod服务器、嗅探其通信量或在编译时嵌入日志-电子邮件代码,才能知道实际安全资源的生产凭据。