如果您从事网络安全工作,或者与您组织的网络安全团队进行过互动,您可能听过这个问题:“传输中和静态的数据是否都已加密?” 传输中的加密保护移动中的数据,静态加密保护存储中的数据。
在高度监管的行业中,这是标准操作程序。 在监管较少的行业中,处理客户数据时,这仍然是一种谨慎的做法。
但是,很少有人谈论另一种加密领域,那就是使用中的加密。 使用中的加密保护在内存中处理的数据。 实际上,使用中的加密可以防止有权访问服务器的任何人通过内存转储或内存取证来访问数据,这些取证可以在服务器上运行的任何进程上执行。(要真正理解使用中加密的重要性,您应该以您的组织已被入侵的心态来对待它,并且安全性是关于最大限度地减少潜在的损害。)
如今,使用中的加密通常使用客户端加密来完成。 但是,出现了一种新兴技术,称为安全飞地,有望解决客户端加密的许多局限性。
客户端加密,或在应用程序中加密数据然后将其存储在数据库(例如 Redis)中的做法,是实现使用中加密的最广泛采用的方法。
客户端加密还可以防止内部威胁。 减少可以访问您数据的人员,会转变您在开展业务运营时必须信任的人员。 使用客户端加密,您不再需要信任数据库操作系统上的管理员。 同样,客户端加密有助于将第三方从运行应用程序需要信任的对象或事物中移除,这称为受信任的计算基础。 您不再需要信任您的云提供商不会滥用您的数据,因为它有权访问操作系统或虚拟机监控程序,您可以确保云提供商无法访问您的数据。
这些优势适用于客户端加密和安全飞地的使用。
但是,客户端加密有两个很大的局限性。 首先,需要在数据上运行的函数(例如简单的搜索函数、比较和增量操作)不适用于客户端加密。 下面的命令行示例显示了递增加密数字如何失败,因为数据在客户端加密后不再被识别。
$ echo "33" >> secrets.txt
$ openssl aes-256-cbc -a -salt -in secrets.txt -out secrets.txt.enc
$ enter aes-256-cbc encryption password:*****
$ Verifying - enter aes-256-cbc encryption password:*****
$ cat secrets.txt.enc
U2FsdGVkX1+zYi/m14irl+JeZokh75XxRAG4HBA56bk=
$ redis-cli set mysecret U2FsdGVkX1+zYi/m14irl+JeZokh75XxRAG4HBA56bk=
OK
$ redis-cli incrby mysecret 1
(error) ERR value is not an integer or out of range
此外,多个服务通常必须访问同一数据库,这带来了跨多个应用程序管理加密密钥的复杂性和投入。 这增加了部署客户端加密的管理开销。
安全飞地有望帮助减少使用中加密的障碍。 安全飞地是受保护的私有内存分配,免受外部进程的使用。 硬件供应商、云提供商和软件制造商的生态系统现在正在形成,以使软件社区更容易访问安全飞地。 截至 2020 年 4 月,某些本地硬件、Microsoft Azure 虚拟机子集以及阿里云和 IBM Cloud 中的专用硬件实例都支持安全飞地。
那么,安全飞地需要做什么才能取得广泛的成功? 根据创新扩散理论,许多新兴技术都难以跨越吸引早期采用者和在早期大众中取得进展之间的鸿沟。 随着安全飞地技术的发展并找到新的追随者,它正在接近那个鸿沟,而这鸿沟一直是许多有前途的技术的坟墓。 但是,鉴于该技术的势头和围绕它建立的生态系统,我们对安全飞地的前景感到非常兴奋。
安全飞地要成功跨越该鸿沟,必须发生四件关键的事情
Redis 正在与社区中那些开发安全飞地生态系统的人合作。 我们正在努力通过与Anjuna合作,将 Redis 和 Redis Enterprise 引入快速形成的安全飞地生态系统,Anjuna 是一家无需重新编码即可将现有应用程序按原样移入飞地的供应商。虽然我们仍处于创新的早期阶段,但我们的目标是鼓励更广泛的认识,以帮助安全飞地跨越从早期采用到早期大众的鸿沟,并促进该技术的持续成功。
我们看到了安全飞地为 Redis 社区带来的三个主要好处
为了充分保护您的内存中数据,不仅仅是 Redis 中的数据需要加密。 针对 Redis 开发的应用程序服务也必须在安全飞地中开发。 如果您的应用程序不是使用此技术开发的,您仍然会面临内存攻击。
这篇解释旨在为 Redis 社区简化说明安全飞地的优势。与其他新兴技术一样,您应该了解安全飞地的局限性及其功能。
如果您想从技术层面了解更多关于安全飞地的知识,可以从加州大学伯克利分校的论文《利用安全飞地提高云安全性》开始。您还可以访问 英特尔软件保护扩展 (SGX) 网站了解更多信息。