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

Question

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

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

2）由于开发人员需要与部署相同的配置文件（或非常相似），密码不应该清晰。

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

最佳推荐？

谢谢，

亚伦

Answer 1

嗯，开发人员不应该首先访问生产数据库。这本质上是不安全的，无论是在Azure上还是在其他地方。对生产数据库执行实时调试是一项有风险的业务，因为一个简单的错误可能会破坏整个生产。相反，我建议复制生产数据（最终作为一夜之间的过程），并让开发人员反对非生产副本。

Answer 2

我认为它可能部分由一种凭证存储服务解决。 我的意思是一种不需要密码的服务，但只允许访问白名单的机器和经过SSPI身份验证的用户。 此服务可以是在SSLed服务器下托管的简单WebAPI，具有如下简单原则： 0）安全件具有一种ACL，其具有IP白名单，或基于机器名称，或基于证书的每个命名资源的白名单，或者是混合的。 1）对存储数据的所有更改仅通过RDP访问或SSH连接到托管服务的服务器。 2）只能通过SSL访问受保护的信息，并且此API是只读的。 3）客户必须预先确认自己的权限并获得一个临时令牌，并调用api之类的 https://s.product.com/ 3）客户端必须提供证书，并且机器身份必须与每次呼叫的资源的逻辑白名单数据匹配。 4）请求数据如下所示： 网址：https://s.product.com/resource-name 标题：X-Ticket：在步骤3获得的值，直到它到期， 证书：与步骤3中使用的证书相同。

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

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

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