2

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

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

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

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

最好的建议？

谢谢，

亚伦

4

2 回答 2

1

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

于 2009-09-11T13:48:38.190 回答
0

我认为它可以通过一种凭证存储服务来部分解决。我的意思是一种不需要密码的服务，但只允许机器和经过 SSPI 身份验证的白名单用户访问。该服务可以是托管在 SSLed 服务器下的简单 WebAPI，其简单原则如下： 0) 受保护的部分具有一种带有 IP 白名单的 ACL，或基于机器名称的 ACL，或每个命名资源的基于证书的白名单，或混合。1) 对存储数据的所有更改只能通过 RDP 访问或 SSH 访问托管服务的服务器。2) 受保护的信息只能通过 SSL 访问，并且此 API 是只读的。3) 客户必须预先确认自己的权限并通过调用 api 获取临时令牌，例如 https://s.product.com/ 3) 客户端必须提供证书，并且机器身份必须与每次调用的资源的逻辑白名单数据匹配。4) 数据请求如下所示： Url: 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 服务器，嗅探其流量，或通过在编译时嵌入日志 - 电子邮件代码，才有可能知道实际安全资源的生产凭证。

于 2013-09-25T15:42:06.073 回答