对于知情人士，对于将密码存储在 Windows Azure 配置文件（通过 RoleManager 访问）中，您有什么建议？重要的是：
1) 开发人员应该能够在自己的本地机器上进行测试时连接到所有生产数据库，这意味着使用相同的配置文件，
2) 作为开发人员，需要与部署的配置文件相同（或非常相似），密码不应该清晰可见。
我了解，即使配置中的密码不清晰，开发人员仍然可以调试/监视以获取连接字符串，虽然这是不可取的，但至少是可以接受的。不能接受的是人们能够读取这些文件并获取连接字符串（或其他需要密码的位置）。
最佳建议？
谢谢，
亚伦
【问题讨论】：
嗯，开发人员一开始就不应该访问生产数据库。这本质上是不安全的，无论是在 Azure 上还是其他地方。对生产数据库执行实时调试是一项有风险的业务，因为一个简单的错误可能会破坏您的整个生产。相反，我建议复制生产数据（最终作为一个通宵的过程），并让开发人员针对非产品副本进行工作。
【讨论】：
我认为它可以通过一种凭证存储服务部分解决。 我的意思是一种不需要密码的服务，但只允许被列入白名单的机器和经过 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 Header: X-Ticket: 在第 3 步获得的值，直到过期， 证书：与第 3 步使用的证书相同。
因此，可以在连接字符串中存储此类安全资源的别名，而不是用户名和密码，并且在代码中，此别名将替换为在 Sql 连接工厂中从第 4 步获得的真实用户名-密码。别名可以指定为特殊格式的用户名，例如 obscured@s.product.com/product1/dev/resource-name
Dev 和 prod 实例可以有不同的凭证别名，例如 product1.dev/resource1 和 product1/staging/resource1 等等。
因此，只有通过调试 prod 服务器、嗅探其流量或通过在编译时嵌入日志记录 - 通过电子邮件发送代码，才有可能知道实际安全资源的生产凭据。
【讨论】：