在开发人员的便携式计算机上存储关键数据库的良好安全实践是什么？

我们有一些建议：

1. 开发人员需要在其机器上复制生产数据库。
2. 开发人员在App.config文件中具有所述数据库的密码。
3. 我们不想破坏所说数据库中的数据。

一些建议的解决方案及其缺点：

1. 全盘加密。这样可以解决所有问题，但会降低笔记本电脑的性能，而且我们是一家初创企业，因此没有钱购买动力强劲的产品。
2. 使用加密的硬盘创建虚拟机，并将数据库存储在该虚拟机上。它运行良好，但并没有太大帮助，因为Web.Config中有一个密码。
3. 解决方案2 +要求开发人员在每次运行任何操作时都要键入数据库密码。它解决了所有问题，但是对于开发人员而言，有时一分钟多次启动应用程序确实很麻烦。另外，我们有多个连接到同一数据库的应用程序，并且每个密码屏幕的实现都必须有所不同。

因此，我的问题是，是否有针对此类问题的通用解决方案，或有关如何使上述解决方案可行的建议？

您不仅不想要生产数据库的副本，而且实际上可能是非法的。例如，在美国，如果生产数据包含受管制的信息（例如个人健康数据，财务数据甚至可能用于身份盗窃的数据），则不能将其移出生产环境。如果这样做，您可能会被罚款，失去合规性，因此将受到更积极的审核，甚至被提起诉讼。

如果您需要生产规模的数据进行测试，则有两种选择：

1. 生成所有伪数据。这比听起来要棘手。生成合理的虚构数据非常困难且费力。
2. 匿名化您的生产数据。这可能更容易，但请谨慎行事。

对于选项2

• 在生产环境中，授权的数据库管理员将复制生产数据。
• 仍然在生产环境中，同一授权管理员运行一个例程，以匿名化所有敏感数据。如有疑问，请匿名。
• 只有这样才能将数据移至另一个环境。

您是否至少可以为数据中心中的开发人员VM提供RD，以便他们可以完成这项工作？尽管他们确实应该处理非生产数据，但这将是更安全的，直到您到达那里为止，因为数据不会存储在容易被盗的笔记本电脑上。

如有可能，请更改工作方式。

正如其他人指出的那样：

• 使用生产数据进行开发不是一个好习惯。
• 用纯文本存储密码不是一个好习惯。

这两种方法都使您面临巨大风险，应尽可能进行更改。您至少应该认真评估进行这些更改的成本。如果这是您无权更改的外部依赖项，请考虑将其作为拥有此权力的人的关注点。

但是，在现实世界中，实际上可能无法更改此设置。假设您所做的是合法的，则您可能不得不接受这种安排（至少是暂时的）。

如果确实需要这样做，则只需执行全盘加密。

鉴于风险，您需要使用最佳可用的安全选项，就是这样。如果对性能有影响，请忍受。这是处理敏感数据的成本。

如果我是您的客户，那么您决定不对我的数据使用最佳的安全选项，将不会给我留下深刻的印象，因为这会使您的笔记本电脑速度稍慢。

Corbin March的答案非常好，我将添加一个额外的细节，即您的生产数据库中通常有两类数据：系统/应用程序元数据；和客户端用户数据/交易数据。后者绝对不能按原样在开发环境中使用。

实际上，您需要实际的生产客户信息来进行开发的确很少见。

但是，如果OP在此描述的问题涉及商业机密数据或其他不涉及客户数据的高度专有的系统数据，那么开发人员就需要...安全方法必须涉及一种不具有数据库密码以明文形式保存在资源文件中的某个位置。例如，需要一种机制来重新生成未存储在磁盘上的每日密码。

您没有说明哪个数据库和哪个环境。

如果可以使用集成安全性，那么只有以该用户身份登录后才能访问该数据库。是的，如果数据位于硬盘上，则可以对其进行黑客入侵，但这是一级防御。

App.config使我认为这可能是.NET。将配置放入拇指驱动器中，然后从拇指驱动器中读取它。如果驱动器不存在，请让用户输入密码。

有没有一种方法可以在密码第一次被所有人输入和读取时将其存储在内存中。同样，您不声明环境。 内存映射文件

使用某些TDE，您可以将密钥存储在单独的设备上，以便它们仅在启动数据库服务器时提供密钥。

一种可能的选择是制作数据库副本，并使用脚本清理该副本，以便最终获得与实际生产中不同的数据。您最终不会获得与生产相同的数据，但是您将拥有相同的规模。