mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge pull request #17343 from hopefully2333/master
translated by hopefully2333
This commit is contained in:
commit
66fb055417
@ -1,76 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (hopefully2333)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (What's HTTPS for secure computing?)
|
||||
[#]: via: (https://opensource.com/article/20/1/confidential-computing)
|
||||
[#]: author: (Mike Bursell https://opensource.com/users/mikecamel)
|
||||
|
||||
What's HTTPS for secure computing?
|
||||
======
|
||||
Security by default hasn't arrived yet.
|
||||
![Secure https browser][1]
|
||||
|
||||
Over the past few years, it's become difficult to find a website that is just "http://…" This is because the industry has finally realised that security on the web is "a thing," and also because it has become easy for both servers and clients to set up and use HTTPS connections. A similar shift may be on its way in computing across cloud, edge, Internet of Things, blockchain, artificial intelligence, machine learning, and beyond. We've known for a long time that we should encrypt data at rest (in storage) and in transit (on the network), but encrypting it in use (while processing) has been difficult and expensive. Confidential computing—providing this type of protection for data and algorithms in use using hardware capabilities such as trusted execution environments (TEEs)—protects data on hosted systems or vulnerable environments.
|
||||
|
||||
I've written several times about [TEEs][2] and, of course, the [Enarx project][3] of which I'm a co-founder with Nathaniel McCallum (see [_Enarx for everyone (a quest)_][4] and [_Enarx goes multi-platform_][5] for examples). Enarx uses TEEs and provides a platform- and language-independent deployment platform to allow you safely to deploy sensitive applications or components (such as microservices) onto hosts that you don't trust. Enarx is, of course, completely open source (we're using the Apache 2.0 licence, for those with an interest). Being able to run workloads on hosts that you don't trust is the promise of confidential computing, which extends normal practice for sensitive data at rest and in transit to data in use:
|
||||
|
||||
* **Storage:** You encrypt your data at rest because you don't fully trust the underlying storage infrastructure.
|
||||
* **Networking:** You encrypt your data in transit because you don't fully trust the underlying network infrastructure.
|
||||
* **Compute:** You encrypt your data in use because you don't fully trust the underlying compute infrastructure.
|
||||
|
||||
|
||||
|
||||
I've got a lot to say about trust, and the word "fully" in the statements above is important (I added it on re-reading what I'd written). In each case, you have to trust the underlying infrastructure to some degree, whether it's to deliver your packets or store your blocks, for instance. In the case of the compute infrastructure, you're going to have to trust the CPU and associated firmware, just because you can't really do computing without trusting them (there are techniques such as homomorphic encryption, which are beginning to offer some opportunities here, but they're limited and the technology still immature).
|
||||
|
||||
Questions sometimes come up about whether you should fully trust CPUs, given some of the security problems that have been found with them, and also about whether they are fully secure against physical attacks on the host on which they reside.
|
||||
|
||||
The answer to both questions is "no," but this is the best technology we currently have available at scale and at a price point to make it generally deployable. To address the second question, nobody is pretending that this (or any other technology) is fully secure: what we need to do is consider our [threat model][6] and decide whether TEEs (in this case) provide sufficient security for our specific requirements. In terms of the first question, the model that Enarx adopts is to allow decisions to be made at deployment time as to whether you trust a particular set of CPUs. So, for example, if vendor Q's generation R chips are found to contain a vulnerability, it will be easy to say "refuse to deploy my workloads to R-type CPUs from Q, but continue to deploy to S-type, T-type, and U-type chips from Q and any CPUs from vendors P, M, and N."
|
||||
|
||||
I think there are three changes in the landscape that are leading to the interest and adoption of confidential computing right now:
|
||||
|
||||
1. **Hardware availability:** It is only over the past six to 12 months that hardware supporting TEEs has started to become widely available, with the key examples in the market at the moment being Intel's SGX and AMD's SEV. We can expect to see other examples of TEE-enabled hardware coming out in the fairly near future.
|
||||
2. **Industry readiness:** Just as cloud use is increasingly becoming accepted as a model for application deployment, regulators and legislators are increasing the requirements on organisations to protect the data they manage. Organisations are beginning to clamour for ways to run sensitive applications (or applications that handle sensitive data) on untrusted hosts—or, to be more accurate, on hosts that they cannot fully trust with that sensitive data. This should be no surprise: the chip vendors would not have invested so much money into this technology if they saw no likely market for it. Formation of the Linux Foundation's [Confidential Computing Consortium][7] (CCC) is another example of how the industry is interested in finding common models for the use of confidential computing and encouraging open source projects to employ these technologies.[1][8]
|
||||
3. **Open source:** Like blockchain, confidential computing is one of those technologies where it's an absolute no-brainer to use open source. If you are going to run sensitive applications, you need to trust what's doing the running for you. That's not just the CPU and firmware but also the framework that supports the execution of your workload within the TEE. It's all very well saying, "I don't trust the host machine and its software stack, so I'm going to use a TEE," but if you don't have visibility into the TEE software environment, then you're just swapping one type of software opacity for another. Open source support for TEEs allows you or the community—in fact, you _and_ the community—to check and audit what you're running in a way that is impossible for proprietary software. This is why the CCC sits within the Linux Foundation (which is committed to the open development model) and is encouraging TEE-related software projects to join and go open source (if they weren't already).
|
||||
|
||||
|
||||
|
||||
I'd argue that this triad of hardware availability, industry readiness, and open source has become the driver for technology change over the past 15 to 20 years. Blockchain, AI, cloud computing, webscale computing, big data, and internet commerce are all examples of these three meeting at the same time and leading to extraordinary changes in our industry.
|
||||
|
||||
Security by default is a promise that we've been hearing for decades now, and it hasn't arrived yet. Honestly, I'm not sure it ever will. But as new technologies become available, security ubiquity for particular use cases becomes more practical and more expected within the industry. It seems that confidential computing is ready to be the next big change—and you, dear reader, can join the revolution (it's open source, after all).
|
||||
|
||||
* * *
|
||||
|
||||
1. Enarx, initiated by Red Hat, is a CCC project.
|
||||
|
||||
|
||||
|
||||
* * *
|
||||
|
||||
_This article was originally published on [Alice, Eve, and Bob][9] and is reprinted with the author's permission._
|
||||
|
||||
Get a sneak peek at Daniel Roesler's Texas Linux Fest talk, "If you're not using HTTPS, your...
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/1/confidential-computing
|
||||
|
||||
作者:[Mike Bursell][a]
|
||||
选题:[lujun9972][b]
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/mikecamel
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/secure_https_url_browser.jpg?itok=OaPuqBkG (Secure https browser)
|
||||
[2]: https://aliceevebob.com/2019/02/26/oh-how-i-love-my-tee-or-do-i/
|
||||
[3]: https://enarx.io/
|
||||
[4]: https://aliceevebob.com/2019/08/20/enarx-for-everyone-a-quest/
|
||||
[5]: https://aliceevebob.com/2019/10/29/enarx-goes-multi-platform/
|
||||
[6]: https://aliceevebob.com/2018/02/20/there-are-no-absolutes-in-security/
|
||||
[7]: https://confidentialcomputing.io/
|
||||
[8]: tmp.VEZpFGxsLv#1
|
||||
[9]: https://aliceevebob.com/2019/12/03/confidential-computing-the-new-https/
|
@ -0,0 +1,75 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (hopefully2333)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (What's HTTPS for secure computing?)
|
||||
[#]: via: (https://opensource.com/article/20/1/confidential-computing)
|
||||
[#]: author: (Mike Bursell https://opensource.com/users/mikecamel)
|
||||
|
||||
用于安全计算的 HTTPS 是什么?
|
||||
======
|
||||
在默认的情况下,网站的安全性还不足够。
|
||||
![Secure https browser][1]
|
||||
|
||||
在过去的几年里,寻找一个只以 "http://…" 开头的网站变得越来越难,这是因为行业终于意识到,网络安全是 “一件事”,同时也是因为客户端和服务端之间建立和使用 https 连接变得更加容易了。类似的转变可能正以不同的方式发生在云计算、边缘计算、物联网、区块链,人工智能、机器学习等领域。长久以来,我们都知道我们应该对存储的静态数据和在网络中传输的数据进行加密,但是在使用和处理数据的时候对它进行加密是困难且昂贵的。可信计算-使用例如受信任的执行环境(TEEs)这样的硬件功能来提供数据和算法这种类型的保护-保护主机系统中的或者易受攻击的环境中的数据。
|
||||
|
||||
我已经写了几次关于 TEEs 的文章,当然,还有我和 Nathaniel McCallum 共同创立的 Enarx 项目(要看 Enarx 项目的所有人(一个任务)和 Enarx 的多平台示例)。Enarx 使用 TEEs 来提供独立于平台和语言的部署平台,以此来让你能够安全地将敏感应用或者敏感组件(例如微服务)部署在你不信任的主机上。Enarx 当然是完全开源的(或许会有人感兴趣,我们使用的是 Apache 2.0 许可证)。能够在你不信任的主机上运行工作程序,这是可信计算的承诺,它为静态敏感数据和传输中数据的使用扩展了常规做法:
|
||||
|
||||
* **存储:** 你要加密你的静态数据,因为你不完全信任你的基础存储架构。
|
||||
* **网络:** 你要加密你正在传输中的数据,因为你不完全信任你的基础网络架构。
|
||||
* **计算:** 你要加密你正在使用中的数据,因为你不完全信任你的基础计算架构。
|
||||
|
||||
|
||||
|
||||
关于信任,我有非常多的话想说,而且,上述说法里的单词“完全”是很重要的(在重新读我写的这篇文章的时候,我新加了这个单词)。在所有的情况下,你必须在一定程度上信任你的基础设施,无论是传递你的数据包还是存储你的数据块,例如,对于计算基础架构,你必须要去信任 CPU 和与之关联的固件,这是因为如果你不信任他们,你就无法真正地进行计算(现在有一些诸如同态加密一类的技术,这些技术正在开始提供一些机会,但是它们依然是有限的,这些技术还不够成熟)。
|
||||
|
||||
你在考虑是否应该完全信任 cpu 时,问题有时也会随之一起到来,还会同时发现一些安全问题,并且是否无论主机在哪都应该完全免受物理攻击。
|
||||
|
||||
这两个问题的回答都是“不”,但是在考虑到大规模可用性和普遍推广开的成本,这已经是我们当前拥有的最好的技术了。为了解决第二个问题,没有人去假装这项技术(或者任何的其他技术)是完全安全的:我们需要做的是思考我们的威胁模型并确定这个情况下的 TEEs 是否为我们的特殊需求提供了足够的安全防护。关于第一个问题,Enarx 采用的模型是在部署时就对你是否信任一个特定的 CPU 组做出决定。举个例子,如果供应商 Q 的 R 代芯片被发现有漏洞,可以很简单地说“我拒绝将我的工作内容部署到 Q 的 R 代芯片上去,但是仍然可以部署到 Q 的 S 型号,T 型号和 U 型号的芯片以及任何 P,M 和 N 供应商的任何芯片上去。”
|
||||
|
||||
我认为这里发生了三处改变,这些改变引起了人们现在对机密计算的兴趣和采用。
|
||||
|
||||
1. **硬件可用性:** 仅仅在过去的 6 到 12 个月里,支持 TEEs 的硬件才开始变得广泛可用,这会儿市场上的主要例子是 Intel 的 SGX 和 AMD 的 SEV。我们期望在未来可以看到支持 TEE 的硬件的其他例子。
|
||||
2. **行业准备:** 就像上云越来越多地被接受作为应用程序部署的模型,监管机构和立法机构也在提高各类组织保护其管理的数据的要求。组织开始强烈呼吁在不受信任的主机-或者更确切地说,在他们不能完全信任且带有敏感数据的主机上运行敏感程序(或者是处理敏感数据的应用程序)的方法。这应该是不足为奇的:如果芯片制造商看不到这项技术的市场,他们就不会投太多的钱在这项技术上。Linux 基金会的机密计算联盟(CCC)的成立就是一个行业如何有志于发现使用加密计算的公共模型并且鼓励开源项目使用这些技术的案例。
|
||||
3. **开源:** 就像区块链一样,加密计算是使用起来绝对不费吹灰之力的开源技术之一。如果你要运行敏感程序,你需要去信任正在为你运行的程序。不仅仅是 CPU 和固件,同样还有在 TEE 内支持你工作扩展的框架。可以很好地说,“我不信任主机机器和它上面的软件栈,所以我打算使用 TEE,”但是如果你不够了解 TEE 软件环境,那你就是将一种不透明的软件换成另外一种。TEEs 的开源支持将允许你或者社区-实际上是你和社区-以一种专有软件不可能实现的方式来检查和审计你所运行的程序。这就是为什么 CCC 位于 Linux 基金会(这个基金会致力于开放式开发模型)并鼓励 TEE 相关的软件项目加入且成为开源项目(如果他们还没有成为开源)。
|
||||
|
||||
|
||||
|
||||
我认为,在过去的 15 到 20 年里,硬件可用性,行业准备和开源已成为推动技术改变的驱动力。区块链,人工智能,云计算,互联网计算,大数据和互联网商务都是这三个点同时发挥作用的例子,并且在行业内带来了巨大的改变。
|
||||
|
||||
在一般情况下,安全是我们这数十年来听到的一种承诺,并且其仍然未被实现。老实说,我不确定它未来会不会实现。但是随着新技术的到来,特定用例的无处不在的安全变得越来越实际,并且在业内受到越来越多的期待。这样看起来,机密计算似乎已准备好成为成为下一个重大变化-而你,我亲爱的读者,可以一起来加入到这场革命(毕竟它是开源的)。
|
||||
|
||||
* * *
|
||||
|
||||
1. Enarx,是红帽发起的,是一个 CCC 项目。
|
||||
|
||||
|
||||
|
||||
* * *
|
||||
|
||||
这篇文章最初是发布在 Alice, Eve, and Bob 上的,这是得到了作者许可的重发。
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/1/confidential-computing
|
||||
|
||||
作者:[Mike Bursell][a]
|
||||
选题:[lujun9972][b]
|
||||
译者:[hopefully2333](https://github.com/hopefully2333)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/mikecamel
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/secure_https_url_browser.jpg?itok=OaPuqBkG (Secure https browser)
|
||||
[2]: https://aliceevebob.com/2019/02/26/oh-how-i-love-my-tee-or-do-i/
|
||||
[3]: https://enarx.io/
|
||||
[4]: https://aliceevebob.com/2019/08/20/enarx-for-everyone-a-quest/
|
||||
[5]: https://aliceevebob.com/2019/10/29/enarx-goes-multi-platform/
|
||||
[6]: https://aliceevebob.com/2018/02/20/there-are-no-absolutes-in-security/
|
||||
[7]: https://confidentialcomputing.io/
|
||||
[8]: tmp.VEZpFGxsLv#1
|
||||
[9]: https://aliceevebob.com/2019/12/03/confidential-computing-the-new-https/
|
Loading…
Reference in New Issue
Block a user