我正在寻找一种模式来将包含敏感信息的配置文件存储在半可信的托管环境中。在这种情况下，半信任意味着我一般信任他们，但不信任此信息（密码）。
在这种情况下，我正在编写一个简单的守护程序来监视文件夹的更改，并将这些更改推送到托管在其他地方的数据库。我宁愿不在这个半可信环境中以明文形式存储该数据库的详细信息，因为我不确定管理员自己是否会恶意使用它。
我最初的计划是在不受信任的环境中设置必要的报告脚本，然后从受信任的位置远程执行它们，在每次执行时发送配置变量。然而，他们似乎记录了在他们的服务器上执行的所有命令，所以这是不行的，因为他们可以简单地查看这些日志。
或者，我可以有一个第二层数据库，我将其凭据存储在他们的服务器上。该数据库将充当中间的角色，允许不受信任环境中的一组脚本向其推送数据，并允许信任环境中的另一组脚本从中提取数据并将其移动到最终目的地。我不太担心他们恶意破坏数据，如果他们访问这个数据库，这没什么大不了的，因为它与我的主要数据存储完全分开。
这种方法相当繁琐且不完全安全，所以如果可以的话，我宁愿避免它。
不幸的是，离开这个不受信任的环境不是一种选择。
如果您担心管理员会主动窥探您的应用程序，那么除了永远不要将他们的系统用于任何敏感数据之外，您无能为力。无论您的程序如何解密或检索凭据，它们也可以执行。出于同样的原因，您需要信任他们不允许任何不值得信任的第三方对其系统进行管理访问。
有一些空间可以降低风险的一个领域是发生违规时的反应时间。在那里很难给出一般性建议，因为这是可用性和保密性之间的折衷——如果发生“奇怪”的事情，你是否想尽快关闭系统（并在服务前呼叫你来整理整个混乱可以恢复），还是您想尽可能长时间地继续运行并通知您可能有问题？请注意，即使尽最大努力，您也永远无法确保不会在未被发现的情况下发生违规行为。
您可以通过远程存储凭据并在每个连接上或在短时间内检索它们来稍微降低风险。为了获得更好的结果，请使用每隔几分钟自动更改一次的密码。这样，如果服务器受到攻击，但攻击者最初并未跟踪您的应用程序，您可能会有一点反应时间来决定是否关闭服务——只需关闭凭据访问即可。这不是万无一失的。如果攻击者在您的应用程序之后，他将在您做出反应之前开始使用凭据。无论如何，请确保您可以在破坏其他任何内容之前快速更改凭据（因此无需在 20 个不同的地方更改共享密码）。
另一种降低风险的方法是给予这个半可信系统尽可能少的特权。在您的情况下，半可信系统只需要将更改推送到其他地方的数据库中，因此不要给半可信系统任何允许其直接访问数据库的凭据。只授予它将记录附加到一个表或类似表的权限。使用代理应用程序（在完全受信任的环境中运行）而不是直接访问数据库来执行此授权检查，并使其记录它所做的一切。这样，如果半可信系统受到威胁，您最终可能会得到虚假记录（连同时间戳和其他可能让您从虚假记录中分类好记录的信息），但任何不是从这些记录中派生出来的记录仍然是安全的。
不要在这上面浪费你的时间。你无能为力。 您将数据放在不属于您的服务器上，管理该服务器的人员可以访问您的数据。
假设您找到了安全存储数据库凭据的最佳方式。您的服务器管理员有一个 DBA 帐户，无论如何都可以访问您的数据库。你做什么都解决不了这个问题，即使是 VPS（虚拟专用服务器）。所以这里有你的选择：
获得高速连接和服务器级硬件，并在家中、办公室或任何受信任的位置构建您自己的服务器。
向经过严格审查且可靠的网络主机注册。
如果站点可以访问它，则管理员可以访问它。如果他们愿意，他们可以简单地更改您的网站以显示配置信息。如果站点需要访问它，您无法保护它。唯一的选择是迁移到受信任的环境。如今，虚拟专用服务器非常便宜。