我三年前以首席安全工程师身份加入亚马逊云服务（AWS），首个项目是负责Amazon Relational Database Service（Amazon RDS）上PL/Rust的安全工作。这是一个允许用户使用Rust为PostgreSQL编写自定义函数的扩展，这些函数会被编译为原生机器代码。从安全工程师的角度看，“编译为原生机器代码”就像闪烁的霓虹灯标志，指向需要重点关注的Rust工具链。

系统组件

postgrestd是PL/Rust核心的Rust标准库。该库的设计包含防止数据库逃逸的机制，但在当时还较新，未经过大规模生产环境的充分验证。更复杂的是，PL/Rust直接在数据库实例上编译扩展，这要求本地具备完整的工具链。

当扩展拥有完整工具链时，潜在风险随之增加。构造不当的扩展可能影响数据库或主机实例，攻击者可能尝试绕过安全控制或破坏容器的写或执行（W^X）模型。为安全提供PL/Rust功能，我们需要实施一系列缓解措施应对这些新风险。

挑战现有方案

在AWS内部，我们持续优化系统运营方式，专注于自动化和韧性以确保客户承诺。经验反复证明：简单往往是更好选择。大规模运营已足够复杂，不应再增加负担！

SELinux作为多种解决方案的备选项长期备受争议。对不熟悉者而言，SELinux是通过内核特性和工具在Linux子系统实施强制访问控制的机制。通过SELinux策略，可以精确控制系统允许的操作，即使进程所有者拥有权限，也能阻止其写入特定文件。

简而言之，SELinux强制访问控制是在现有授权系统之上的额外保护层。如果进程对文件拥有权限，但策略配置禁止该操作，SELinux将阻止权限执行。这是确保特定操作不会发生的确定性方法。

这种方法能显著提升操作系统安全性，但代价是降低系统操作灵活性，以及配置强制访问控制满足安全需求所需的工作量。与所有安全控制一样，需要权衡收益与潜在缺点。

在PL/Rust案例中，SELinux的收益大于代价。该功能使我们能够以安全方式向客户提供PL/Rust支持。

虽然表述简单，但这实际体现了AWS的文化。作为团队新成员，我提出这个想法后，高级领导者花时间倾听了建议。讨论过程充满挑战，大家深入质疑想法及实施方案。我们文化的重要方面是尝试预见潜在问题。

这种讨论和质疑有助于确保为客户做出正确决策。过程不易，但值得付出。通过这些讨论，我们最终同意尝试SELinux方案。

构建完整解决方案

我们的构建者和运营者搭建了SELinux环境，并创建了适当的强制策略。这是重要的第一步，但并非故事最精彩部分。

我们配置强制访问控制策略，将拒绝消息发送到遥测系统。AWS系统生成大量遥测数据，我们定期利用这些信息了解系统状态并改进运营和设计。

基于此基础设施，我们开始构建处理拒绝消息的响应和调查流程。与蓝队合作，我们为Amazon RDS团队制定了专门的事件响应手册，并开始每季度举行演练日，让红队在系统上模拟攻击，我们则进行响应。

随后，所有团队共同评估和分析响应过程，努力识别瓶颈或改进领域。这种定期实践帮助我们的响应能力快速成熟。

至此，我们拥有了降低PL/Rust启用风险的强大解决方案、深入的系统监控以及经过充分测试的事件响应流程，共同提升了整体设置。

实践应用

功能上线后，我们通过监控系统为每个SELinux拒绝消息自动创建高严重性工单。这种跟进级别确保控制措施按预期工作，并为系统潜在风险提供宝贵洞察。

这种跟踪和调查可能问题的流程帮助团队确保提供客户期望的服务水平。当PostgreSQL或Rust发布新功能，或客户有新数据分析需求时，我们希望安全控制支持而非不必要地阻碍这些工作。

通过调查强制访问控制日志消息建立的反馈循环，帮助团队持续了解环境中尝试进行的活动。这不仅有助于捕获影响预期使用的问题，还充当入侵检测系统。

最近公开的一个案例体现了这种用途。十月份，团队收到基于SELinux拒绝消息自动生成的高严重性工单。

快速确认PL/Rust近期变更后监控标准仍适用后，红队、蓝队和AWS安全团队立即行动。请注意，此活动是由访问尝试失败触发的！系统消息通知我们已阻止某项活动，但按照惯例，我们希望了解尝试的具体内容。

我们验证了SELinux策略已正确执行并阻止了相关活动。确认这一点后，我们继续追查此问题。你可能会问为何要继续处理这个案例？答案很明确：我们持续寻求改进系统效能和效率的机会。

找到信号根本原因并深入了解有助于优化方法。根据情况，我们可能完全避免潜在风险并减少警报量，或者发现推出新功能的机会，帮助客户实现目标而不降低系统安全性。

本次调查确定检测到的活动由Varonis Threat Labs研究团队发起。我们联系了他们，告知检测到其活动，并提议合作——与研究社区协作往往能带来惠及客户的安全改进。

在此情境下，初始阻止和检测验证了我们的安全方案。策略按预期工作，阻止了研究人员尝试完成的活动。

Varonis Threat Labs的研究人员Tal Peleg和Coby Abrams在BlackHat 2025上讨论了此案例，并在Varonis博客发布了工作细节。

作为安全工程师，这极具验证意义。虽然我们会测试和验证实施的控制措施，但看到这些工作如何实际惠及客户的具体案例，令人深感欣慰。