Passwords 在Windows Azure中存储密码的最佳做法

对于那些了解情况的人，对于在Windows Azure配置文件（可通过RoleManager访问）中存储密码，您有什么建议？重要的是：

1） 开发人员应该能够在自己的本地设备上进行测试时连接到所有生产数据库，这意味着使用相同的配置文件

2） 作为开发人员，需要与部署的配置文件相同（或非常相似），密码不应易读

我理解，即使配置中的密码不清晰，开发人员仍然可以调试/监视以获取连接字符串，尽管这是不可取的，但至少是可以接受的。不可接受的是人们能够读取这些文件并获取连接字符串（或其他需要密码的位置）

最佳推荐

谢谢

---

Aaron

嗯，开发人员首先不应该访问生产数据库。这本质上是不安全的，不管它是在Azure上还是在其他地方。对生产数据库执行实时调试是一项危险的工作，因为一个简单的错误很可能会毁掉整个生产。相反，我建议复制生产数据（最终作为一个隔夜过程），让开发人员处理非生产副本。

我认为可以通过一种凭证存储服务部分解决这一问题。 我指的是一种不需要密码的服务，但只允许机器和SSPI认证的白名单用户访问。 该服务可以是一个简单的WebAPI，托管在SSLed服务器下，其原理如下： 0）受保护的部分具有一种ACL，每个命名资源具有IP白名单、基于机器名、基于证书的白名单或混合白名单。 1） 对存储数据的所有更改只能通过RDP访问或SSH对托管服务的服务器进行。 2） 受保护的信息片段只能通过SSL访问，并且此API是只读的。 3） 客户端必须预先确认自己的权限，并通过调用api获得临时令牌，如 3） 客户端必须提供证书，并且机器标识必须与每次调用时资源的逻辑白名单数据相匹配。 4） 请求数据如下所示： 网址： Header:X-Ticket：在步骤3中获得的值，直到过期， 证书：与步骤3使用的证书相同

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

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

---

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

我理解，但核心问题是这些密码应该首先存储在何处/如何存储。例如，开发人员连接到“dev”环境，该环境也应该受到保护。密码等（连接字符串）应该存储在azure包配置文件中。这是合乎逻辑的地方。关于“开发”环境，我认为有两个简单的实践：1）知道你信任的人的凭据；2）当人们退出开发团队时更改凭据。