保护公司最重要的资产

GitHub 和 Runbook 安全

亲爱的 KV，
我正在与我们 IT 安全部门的一个人打交道，你会称他为白痴（一个我在工作场合不能用的词）。这个“人”单方面决定保护我们公司的 GitHub，其中有许多代码库和多年的历史。保护像公司代码这样重要的东西是一项我会赞扬的任务，但前提是分配到这项任务的人曾经使用过 GitHub，或者编写和部署过软件，但令人惊讶的是，做这件事的人都没有做过这些事情。像我们 IT 部门的许多员工（我犹豫是否使用工程师这个词）一样，这个人似乎带着一份通用的清单来的。每当我们的开发团队询问关于这个人想要保护系统的事情时，他们都会茫然地看着你，就像受惊的鹿一样，或者像看着迎面而来的火车的人一样。我一直在想，这不可能是现代安全的做法，但也许我遗漏了什么。

哎呀，我的天啊

亲爱的哎呀我的天啊，

几年前，我收到一封来自某人的信，他正在与一位有问题的 CSO（首席安全官）打交道，这位 CSO 只购买新玩具，认为只要花钱，他们就会安全，这让我创造了支票簿安全这个词（https://queue.org.cn/detail.cfm?id=3357152）。你这里遇到的完全是另一种动物；这是Runbook 安全。

在我开始批评我有多讨厌这种事情之前，让我提醒大家，我是文档的忠实粉丝，多年来我写的许多回复都谈到了为什么要编写和欣赏文档。现在，深呼吸...

正如有好代码和坏代码，好文档和坏文档一样，也有好的 runbook 和坏的 runbook。好的 runbook 用清晰的散文写成，清楚地描述了每个步骤或项目，最好的 runbook 会给出关于为什么该步骤重要的背景信息。事实上，好的 runbook 可以成为每个使用它的人的优秀教育工具。不幸的是，这样的 runbook——实际上，一般的这种文档——很少见。

还存在保护像开发工作流程这样可变且无定形的东西的挑战。每个软件都有其自身的历史、缺陷和陷阱，这使得在源代码系统中管理它的方式有些独特。即使是 Rust 社区的成员，他们以向使用该语言开发的人员提供良好的流程和实践而闻名，也无法预测大型复杂系统（即使是纯 Rust 系统）将如何构建。你可以从他们的工具和工作流程的设计中看到，他们希望能够做到这一点，而 KV 经常希望——好吧，不是真的希望，更像是痛苦地尖叫——希望有一个系统能够让构建大型系统更容易。

但就目前而言，我们背负着各种遗留系统和混杂的构建工作流程，它们与源代码控制的交互方式常常违背逻辑和理性。我相信我们技术人员会继续努力解决这些问题；我只是希望我能活得足够长，看到一个我实际上并不讨厌的系统。

通常，runbook 的问题不在于 runbook 本身，而在于 runbook 的执行者。Runbook 或清单应该作为记忆的辅助工具，而不是替代仔细和独立的思考。但我们的行业就是这样——一个人们喜欢偷工减料，把事情简单化，以便“任何人都能做到！”的地方——我们现在看到人们把这些东西推向了不合逻辑的极端，我认为这就是你与当地 runbook 执行者遇到的问题。

据说，他们在安全方面很精通，这就是他们被雇佣的原因，或者也许他们只是在他们的 LinkedIn 页面上有一些荒谬的认证，而这就是他们获得这份工作所需要的一切——好吧，还有脉搏。如果你正在与安全 Runbook 僵尸打交道，我可能无法提倡对这个人做他们在电影中对僵尸做的事情，但我可以告诉你，你还有很长的路要走。

如果我心情好，我会建议让一个真正了解你的公司或开发团队如何使用 GitHub 的人与你的 IT 安全团队的人坐下来，一起过一遍事情的运作方式，演示整个工作流程，然后逐项讨论 runbook 或清单或任何东西，看看它是否对保护你的系统有意义。

所有优秀的人在安全互动期间都会问的关键问题仍然是，“你想解决什么问题？” 如果你的僵尸无法回答这个问题，那么你就遇到了真正的问题，你可能不得不向上级管理层反映，要求分配一个新的僵尸与你的团队合作。如果你发现你可以与你的僵尸合作，那可能会更好，因为最终，通过足够的关心和喂养，当然还有更多的头脑，你将拥有一个既了解安全又了解如何应用于保护可能是公司最重要的资产的人。

Kode Vicious，凡人称之为 George V. Neville-Neil，以网络和操作系统代码为乐，并从中获利。他还教授各种与编程相关的课程。他的兴趣领域是代码探险、操作系统和重写你的坏代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学计算机科学学士学位，并且是、Usenix Association 和 IEEE 的成员。Neville-Neil 与 Marshall Kirk McKusick 和 Robert N. M. Watson 合著了 The Design and Implementation of the FreeBSD Operating System (second edition)。他是一位狂热的自行车爱好者和旅行家，目前居住在纽约市。

最初发表于 Queue vol. 20, no. 3—
在数字图书馆中评论这篇文章

更多相关文章

Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用保密联邦学习的可信 AI
安全性、隐私性、问责制、透明度和公平性原则是现代 AI 法规的基石。经典 FL 的设计非常强调安全性与隐私性，但牺牲了透明度和问责制。CFL 通过将 FL 与 TEE 和承诺相结合，弥补了这一差距。此外，CFL 还带来了其他理想的安全特性，例如基于代码的访问控制、模型机密性和推理期间的模型保护。保密计算的最新进展，例如保密容器和保密 GPU，意味着现有的 FL 框架可以无缝扩展以支持 CFL，且开销较低。

Raluca Ada Popa - 保密计算还是密码计算？
通过 MPC/同态加密与硬件飞地进行安全计算，需要在部署、安全性和性能之间进行权衡。关于性能，您脑海中的工作负载非常重要。对于简单的求和、低阶多项式或简单的机器学习任务等简单工作负载，这两种方法都可以在实践中随时使用，但对于复杂的计算（例如复杂的 SQL 分析或训练大型机器学习模型），目前只有硬件飞地方法对于许多实际部署场景来说才足够实用。

Matthew A. Johnson, Stavros Volos, Ken Gordon, Sean T. Allen, Christoph M. Wintersteiger, Sylvan Clebsch, John Starks, Manuel Costa - 保密容器组
此处展示的实验表明，Parma（驱动 Azure 容器实例上的保密容器的架构）增加的额外性能开销不到底层 TEE 增加的额外性能开销的百分之一。重要的是，Parma 确保了容器组所有可达状态的安全不变性，这根植于证明报告中。这允许外部第三方与容器安全地通信，从而实现广泛的容器化工作流程，这些工作流程需要对安全数据进行保密访问。公司获得了在云中运行最机密工作流程的优势，而无需在其安全要求上妥协。

Charles Garcia-Tobin, Mark Knight - 使用 Arm CCA 提升安全性
保密计算具有提高通用计算平台安全性的巨大潜力，通过将监管系统从 TCB 中移除，从而减小 TCB 的大小、攻击面和安全架构师必须考虑的攻击向量。保密计算需要在平台硬件和软件方面进行创新，但这些创新有可能增强对计算的信任，尤其是在第三方拥有或控制的设备上。保密计算的早期消费者将需要就他们选择信任的平台做出自己的决定。