短暂数据暴露的神秘事件

虽然我们通常不会主动监控客户账户中的发现项与告警，但最近有一位客户联系我们，希望我们在其迈向自动化修复的过程中扮演更主动的角色。应该客户的要求，我们持续关注着若干事项，而此时……有趣的事情发生了。

我们的 CTO 收到一条告警，提示 AWS 中存在一个对外公开的 RDS 实例。然而，当他与客户核实时，该实例已不复存在。更奇怪的是，每晚都会创建一个公开的 RDS 实例，并在 50 分钟后被终止。这类活动在定时评估中极易被忽略。我们的 CTO 随即通知了客户，并从我们的资产清单中调取了已终止实例的元数据。在对触发事件和实例配置进行彻底（且快速，仅用了几分钟）的调查后，他发现系统每晚都会基于另一个数据库的最新快照备份创建一个公开实例。该实例随后被暴露给一小批已知的企业 IP 地址（这是个好消息），并在不久后被终止。

调查过程
客户开展了自己的调查，发现这属于在数据中心运行的 ETL 自动化流程的一部分。云端的一个定时作业负责将该临时实例创建为公开状态，并将访问限制在少数几个 IP 地址（5 个，这个数量看起来仍然偏多），随后数据中心会连接过来提取数据。我们始终没有查明实际的数据转换发生在何处，但这一点与本次情况关系不大。

这给安全团队带来了一个有趣的难题——告警是有效的，但当下并不存在真正的安全问题（尽管相比公开的 RDS 实例，处理这种情况显然有更安全的方式）。将该实例列入豁免并不可行，因为每晚都会创建一个新实例。将整个账户从该检查项中豁免同样存在风险，因为这可能导致真正暴露的 RDS 实例被忽视。即便基于标签进行豁免也有风险，因为有人可能轻易修改流程，将实例暴露给不受信任的 IP 地址。

经验总结
我的建议是着力修正底层流程，而不是让评估环节变得更复杂。事实是，从流程角度看这种做法并不理想——允许公开的 RDS 实例从来都不是良好实践。有时确实需要它们，但那应当只是最后的手段。更合适的做法是将其置于私有子网中，并通过专用连接或基于 VPN 的连接从所需位置进行访问。

尽管这最终并非一次安全暴露事件，但仍有一些值得借鉴的经验。首先，我把它称为“虚假的误报”，因为该告警针对的是一种确实需要关注的真实状况，只是在这一特定场景中未必构成风险。并没有发生实际的数据泄露，但如果不展开调查并与负责该资源和流程的团队沟通，客户无从得知这一点。

其次，这种情况很难通过服务控制策略（Service Control Policies）完全预防。目前既没有可用于阻止公开 RDS 实例的条件键，也没有可用于阻止在安全组中开放数据库端口（或任何端口）的条件键。

第三，这些实例的短暂性意味着，除非您以实时方式或极短的周期开展检测，否则可能会错过此类暴露。我在事件响应培训中专门讲过这一主题，因为在许多情形下，某些资产可能在很短的时间窗口内被暴露并遭到数据提取，随后被销毁以消除证据。这正是事件响应人员始终需要具备直接进入部署环境的能力，并应能访问支持回溯查询的资产清单（例如 AWS Config 或像我们这样的第三方工具）的原因。仅凭 API 调用可能无法充分揭示正在发生的情况，因为它们缺乏上下文。在本例中，您可以检测到暴露，但随后需要直接查看数据库实例（或资产清单），以了解哪些端口向何处开放。

第四，由于可用的预防性手段有限，必须借助检测性和纠正性控制措施。在本例中，您可以直接检测 CreateDBInstance API 调用，并检查其中的 PubliclyAccessible=True 参数。此外，强烈建议使用 CSPM（同样，可来自您的云服务商或像我们这样的厂商）对公开的 RDS 实例进行持续监控。在修复方面，一种选择是在检测到实例创建后即将其终止。不过，更好的做法或许是使用 ModifyDBInstance 移除 PubliclyAccessible 参数。若采用这种方式，重要的是仅在您确信不会允许公开 RDS 实例的部署环境中实施此类自动化。当您因为没有与相关团队沟通，而中断了一条已运行 3 年、既在预期之内又获得授权的数据库连接时，那一天大概也是该拿出简历的日子了。

归根结底，这一事件并未给该客户带来安全风险。但它确实凸显了建立更安全流程的必要性，客户目前正在积极探索以更安全的方式处理相关工作的方案。我认为这个案例格外值得关注，因为短暂性的数据暴露、泄露和外泄都是真实存在的隐患，而我们最初发现的现象与一次真正的攻击几乎无从区分。只有在深入排查之后，我们以及客户的安全团队才意识到这属于预期流程的一部分。与各团队紧密协作以培养良好习惯至关重要，同时要确保您的监控能够应对云环境高度多变的特性，并认识到：当出现此类异常情况时，与负责该部署的人员沟通是关键所在。

在云环境中，有时区分误报与严重问题的唯一方法，就是向直接相关的人员求证。正如我在 《薛定谔的错误配置》一文中所写，攻击者使用的是相同的 API 调用，并且遗憾的是，还有相同的身份，而非依赖某种零日漏洞。

特邀演讲人

Rich Mogull

FireMon 云安全高级副总裁
Rich 是 FireMon 的云安全高级副总裁，专注于前沿云安全研究与实践落地。他通过 FireMon 对 DisruptOps 的收购加入公司；DisruptOps 是一个云安全自动化平台，源自他担任 Securosis 首席执行官期间的研究成果。他拥有超过 25 年的安全从业经验，目前专攻云安全与 DevSecOps，并在近 10 年前就开始亲身投入云领域的实践工作。在创办 Securosis 和 DisruptOps 之前，Rich 曾在 Gartner 安全团队担任研究副总裁。