Kode Vicious - @kode_vicious
PDF毫无意义的 PKI
虽然 Kode Vicious 有点尖刻，但他实际上很喜欢阅读您的评论，甚至可能会在印刷版中回复。但真正赋予专栏生命力的是您的编程问题。所以不要害羞，请将您最新的难题发送至 [email protected]。如果我们的专栏刊登了您的问题，您不仅可以获得 KV 的明智建议，还能得到一个非常酷的 Queue 咖啡杯。
尊敬的 KV，
我在一家大型网络公司工作，我们正在寻找一种方法来保护我们的流量安全。与大多数公司不同，我们不是为了保护远程办公室之间的流量，而是为了保护公司内部的所有流量，包括前端 Web 服务器和后端数据库之间的流量。过去我们曾遇到过内部泄露问题，管理层认为保护信息的唯一方法是在传输过程中对其进行加密。我们不会对数据进行加密存储，因为要让所有人重写他们的应用程序太难了。构建这样一个系统绝非易事，因为我们的系统运行涉及到数千台服务器。我正在构建一个 PKI 系统来处理所有必要的密钥——我们提供的每项服务都对应一个密钥——我想知道您是否有什么关于如何保护公司内部数据安全的建议，而不是使服务本身安全。
对安全充满疑问
尊敬的 Keyed，
是的，您说的没错，构建这样一个系统绝非易事，而最糟糕的是，即使您成功了，它也将是完全没有意义的。您的信中有些事情让我感到困惑，所以我将尝试从逻辑上解决这些问题，这比我对您的管理层所能说的要多，他们似乎处于所谓的“被动模式”，而我则称之为“鸵鸟心态”（或者更糟）。
我猜您所说的“内部泄露”是指一些员工一直在盗取您的数据。内部泄露和泄漏在任何公司都存在风险——而且公司规模越大，风险就越大。您涉及的人员越多，就越有可能最终雇用一些不该雇用的人。您如何防止这些可恶的内部人员对他们不应该接触的数据做手脚？我可以告诉您，加密所有流量并不能起到太大作用。内部攻击者不太可能在网络上放置数据包嗅探器，收集一天或一周的数据，然后带着它离开。筛选如此大量的信息工作量太大，而且，您已经给他们提供了一个更容易的目标。
如果您的公司将数据存储在后端数据库中，那么内部攻击者就会去那里获取数据。为什么要去筛选数据包跟踪，而只需几条 SQL 语句和一个 DVD 刻录机或快速连接就可以获得更好的数据呢？如果您存储的是敏感数据，那么需要保护的是数据本身，而不是网络！如果攻击者带着备份走了怎么办，就像最近发生的几起案例一样？如果数据库中的数据没有受到保护——即哈希或加密——那么拥有备份的人就拥有了数据。
在这种系统中，大多数人都不理解的另一个问题是“需要知道”的概念。政府和军队（实际上是同一枚硬币的两面）试图建立这样的系统：敏感数据只能被实际需要处理这些数据的人看到或修改，因此就有了“需要知道”的概念。数据库和其他计算机系统也可以以类似的方式设置，只有少数需要处理特定数据位的人才能实际处理这些数据。诚实的人不会在意他们无法访问所有数据，因为他们拥有完成工作所需的数据，而不诚实的人将访问更少的数据，从而降低泄露的风险。
人们在建立安全系统时常犯的一个错误是加密所有内容。如果您加密所有数据，那么每个人都必须拥有密钥，而密钥可能会丢失或被盗，从而导致泄露。只加密为了确保业务安全而必须加密的内容；这样只有少数人需要密钥或访问敏感数据。
最后，您在信中没有提及任何关于审计的内容。在您的系统中找到不诚实人员的最佳方法不是加密所有通信，而是审计何时读取、修改或删除敏感数据。记录“谁对谁做了什么”，并定期审查该日志，是找到系统滥用者的最佳方法。
很抱歉我没有告诉您如何实施一个好的 PKI 系统。这是一个引人入胜的话题，但它对您没有任何帮助，除了让您的公司老板感觉更安全，但实际上他们并不会更安全。
KV
尊敬的 KV，
我阅读了关于海森堡 bug（“Kode Vicious Bugs Out”，2006 年 4 月）的评论，我很惊讶您没有提到在解决这些特殊 bug 时最有效的方法。这种方法是随机路过的人，他们看看您的肩膀，然后立即指出错误。
路过
尊敬的路过：
您所指的调试方法是我所说的“愚蠢的程序员技巧”。实际上有两种不同的版本。您提到的那种实际上是两种版本中不太可靠的一种，因为它取决于偶然的相遇。
我更喜欢的另一种版本是，我走到一位同事面前——可以是任何人，不一定是工程师，只要有人站在那里，然后不停地说“嗯哼”——然后开始解释我遇到的问题。甚至可以是市场部的人，但那样我就得请他们喝酒，这会削减我自己的饮料预算。
要使用这个技巧，您需要开始解释您的问题，并指向您用来思考问题的代码或图表。如果您正在与有头绪的人交谈，您可能会很幸运，那个人可能会找到 bug，或者至少会问您一个好问题。但在某个时候，砰的一声，您拍了一下额头——因为我是秃顶，所以我经常这样做；它会发出清脆的拍击声——然后说：“尤里卡！”并从浴缸里跳出来。不，等等，那是别人。无论如何，您会感受到找到问题的愉快感觉。谢谢您提醒我。
KV
尊敬的 KV：
我阅读了您对 Hungry Reader（2006 年 4 月）的回应，我确实拥有您列出的所有书籍，除了 Raj Jain 的《计算机系统性能分析的艺术》（Wiley，1991 年），这本书我打算去买。我想再补充一本我认为必不可少的书：《人月神话》，作者是 Frederick P. Brooks（Addison-Wesley，1975 年；1995 年再版）。最好也给您的经理买一本。您觉得怎么样？这本书应该列在您的清单上吗？
怀念 PDP-11
尊敬的怀旧者：
冒着因推荐旧书而被网友评论为古董的风险，是的，您的建议很好。我最初回复的重点是技术书籍，而《人月神话》是一本管理书籍，尽管与我当地书店管理类的大多数书籍相比，它给我的反胃感要少得多。
我对这本书的印象很好，原因有几个。它的结论对于在软件公司工作超过五分钟的任何人来说都是显而易见的，但您仍然可以用它来敲打愚蠢的经理的脑袋。它经受住了时间的考验，原因有两个：一是它写得很好，这是一种罕见的品质；另一个原因是，在过去的 50 年里，人们在管理大型项目方面并没有变得更聪明。关于《人月神话》的另一个好处是，它足够短，我可以读完并在截止日期前退回，从大学书店收回全额退款。我用这笔钱为 7 月 4 日的派对买了啤酒。不，我不是在开玩笑。所以，我已经没有这本书了，但我确实有一些美好的，如果说是有点混乱的，回忆。
KV
KODE VICIOUS，凡人称为 George V. Neville-Neil，以网络和操作系统代码为乐，并以此营利。他还教授各种与编程相关的课程。他的兴趣领域是代码探查、操作系统和重写您的糟糕代码（好吧，也许不是最后一个）。他毕业于马萨诸塞州波士顿的东北大学，获得计算机科学学士学位，并且是 、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行者，自 1990 年以来一直以旧金山为家。
最初发表于 Queue 第 4 卷，第 6 期——
在 数字图书馆 中评论本文
更多相关文章
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 的大小、攻击面以及安全架构师必须考虑的攻击向量。机密计算需要在平台硬件和软件方面进行创新，但这些创新有可能增强对计算的信任，尤其是在第三方拥有或控制的设备上。机密计算的早期消费者将需要自行决定他们选择信任的平台。
© 保留所有权利。