在过去的三年半里,Kode Vicious 引导了许多困惑的程序员走向清晰和理解。我们希望您珍视他从实践中得出的真理,并将继续阅读专栏,并将您的问题发送给他,因为Queue正在从印刷版过渡到数字版。正如我们的数字订阅者已经知道的那样,给他发送电子邮件就像点击 [email protected] 一样简单。他希望能尽快收到您的来信。
尊敬的 KV,
我刚加入一家公司,该公司将大量数据整理成内部格式,供其自身的应用程序使用。虽然数据定期备份,但我注意到对这些数据的访问安全性不高,这些数据已经积累到几个 PB 的大小。没有加密,虽然从互联网上不容易访问到这些数据,但公司里的每个人都可以随时直接访问这些卷,包括物理和电子方式。我们的数据中心也没有得到特别好的保护,在外部世界和里面的机器之间只有两扇锁着的办公室门。
我曾试图说服我的管理层,我们需要做更多工作来保护数据,但他们认为,一旦数据被整理成内部格式,对其他人来说就没什么用处了;而且只要我们有备份,因此即使发生盗窃也不会遭受中断,我们的安全就足够了。我该如何让他们看到我们拥有的数据的价值,并采取更多措施来保护它?
PB 级的偏执
亲爱的 Peta,
如果这对您来说是安慰,而且我知道人们写信给 KV 是为了寻求安慰,那么您并不孤单。许多人低估了他们的数据,认为这些数据对其他人来说没什么用处。虽然越来越多的人开始理解泄露个人信息数据库(如信用卡和医疗记录)的风险,但许多其他类型的数据仍然没有受到保护。
另一种思考数据价值的方式是问:“如果另一方获得这些数据,会对我和我的公司造成多大的损害?” 在大多数情况下,公司基于其数据所拥有的竞争优势是评估数据价值的最佳方式。
数据会随着时间的推移变得更有价值吗?还是价值会降低?如果数据随着时间的推移价值降低,那么保护它的最佳方法(如果法律没有要求保留它)就是丢弃它。不,我不是指将它全部拖到您桌面上的小垃圾桶或回收站;我的意思是安全地处理数据。如果您感到特别偏执,一些公司会为您销毁磁盘。然而,在大多数情况下,使用安全的擦除命令,例如 FreeBSD 上的 rm -P,就足够了。同样,这完全取决于如果数据被其他人发现,它的价值有多大。
吓唬您的老板让他们保护数据的另一种方法是简单地搜索最近发生的物理数据盗窃案例。许多公司都成为目标,并以这种方式成功遭到攻击,包括那些将其数据存储在安全数据中心的公司。武装抢劫数据的事情确实会发生。
我想说,很难想象在这个时代,人们不理解他们数据的价值,但不幸的是,这种情况太容易想象了。也许您的老板缺乏的不是知识,而是想象力。
KV
尊敬的 KV,
我的小组多年来一直在维护一个旧的 CMS(内容管理系统),我们认为现在是升级的时候了。该系统被一群文字工作者用来管理我们网站上的页面。由于我们是一家网络公司,这是一个非常重要的系统。代码是在内部编写的,但原始团队已经离开了,系统已经处于维护模式五年了。已经尝试过几次替换原始系统,但每次都失败了,通常是因为一些救世主在最后一刻出现并解决了原始系统中的问题或错误。
我被要求评估新的 CMS。有很多可用的系统,包括开源和闭源系统。我发现的一个问题是,许多这些系统似乎是用非常高级的语言编写的,并且运行速度比我们已经拥有的代码慢得多。我无法想象推荐一个比我们现在拥有的系统更新但也更慢的系统。为什么这些新系统会这么慢,当您像这样陷入两难境地时,您该怎么办?
托管内容
亲爱的 MC,
当我陷入两难境地时,我倾向于靠在石头上,因为它能放松我的背部,但这可能不是您需要的建议。
虽然您或许明智地没有列出您正在评估的系统,但我怀疑它们都有一个共同点:每个系统都是在一个框架内编写的框架。我这是什么意思?我只是又在咆哮吗?KV 疯了吗?谁会疯狂到构建递归框架?
虽然,是的,我又在咆哮了,是的,我显然已经疯了,但在这些话中,确实有一个重点。您看到的根本问题不是新系统只是比您的旧内部系统具有更多功能的结果,而是一种在编程世界中普遍存在的疾病的症状。
许多程序员已经走得太远了,远离实际的硬件,达到了如此高的抽象层次,以至于他们忘记了计算机是如何工作的。有些程序员从来没有真正了解计算机在机器级别是如何工作的,因此他们做出的决定不可避免地会阻碍系统性能。
理解计算机的工作原理为什么重要?我发现,那些与软件和硬件的较低层有密切互动的人,总是对他们的选择对系统性能以及调试等其他方面的影响有更好的理解。我越来越难避免诸如“在过去,我们没有花哨的......”这样的陈词滥调。无论花哨的东西是什么,我们都没有。但是,真的,这与年龄无关;这与人们多年来编程方式的变化有关。
在过去的 30 年左右的时间里,人们一直相信“如果我们能够让编程变得容易和更自然,项目就会按时完成。” 事实是,许多使编程更容易和更自然的努力都带来了好处,例如更高级的语言、模块化以及面向对象编程的某些方面。不幸的是,就像任何包含人的努力一样,一些蛇油总是设法偷偷溜进来。许多所谓的改进只是为了给人以进步的假象,然后迅速消失,留下苦涩的余味。
当前朝着这个方向发展的一个潮流是采用特定领域的语言,并尝试用它们构建通用框架或平台。一种旨在做特定事情的语言,例如布局 Web 表单,可以用来做更通用的事情,但这是有代价的。在计算机科学中,我们通常在性能的十字路口与魔鬼共舞,而这正是大多数牺牲发生的地方。
一个似乎没有被吸取的教训是,仅仅因为你能做某事并不意味着你应该做某事。用 PHP 编写操作系统当然是可能的,但你应该这样做吗?可能不应该。你也不应该用汇编语言编写 CMS。您可以在框架中实现框架,但您将付出沉重的代价,因为框架旨在使编写特定程序更容易,但通常不是为编写另一个框架而编写的。如果原始作者想编写第二个框架,他要么会编写第一个具有更多功能的框架,要么会为另一个领域创建第二个特定领域的框架。
优秀的程序员知道,每个额外的层或抽象都会降低系统的整体性能,因此他们只添加绝对必要的额外层或抽象来完成工作。
总而言之,查看引擎盖下,看看是否使用了适当的技术,以及构建系统的人是否真正了解底层发生了什么,或者他们只是知道如何制作酷炫演示的人,这是值得的。
KV
KODE VICIOUS,凡人称之为 George V. Neville-Neil,以网络和操作系统代码为乐和为利。他还教授各种与编程相关的课程。他的兴趣领域是代码探险、操作系统以及重写您的糟糕代码(好吧,也许不是最后一个)。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位,并且是 、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行家,自 1990 年以来就以旧金山为家。
最初发表于 Queue 第 6 卷,第 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 的大小、攻击面以及安全架构师必须考虑的攻击向量。机密计算需要在平台硬件和软件方面进行创新,但这些创新有可能增强对计算的信任,尤其是在由第三方拥有或控制的设备上。机密计算的早期消费者将需要就他们选择信任的平台做出自己的决定。