1、云数据库安全现状及问题
伴随着云基础设施的快速增长和成熟,与之对应的云数据库服务也层出不穷。一方面,受益于云服务的便捷性传统企业加速业务上云,通过充分发挥云数据库特有的轻松部署、高可靠、低成本等优势降低企业运营成本,加速企业应用创新;另一方面,以苹果iCloud服务为代表的存储服务和云计算服务为移动消费者带来应用便捷性,利用云侧的数据库服务存储海量消费者的个人数据。
云数据库俨然已成为数据库业务未来重要的增长点,绝大多数的传统数据库服务厂商正在加速提供更优质的云数据库服务。但无论是传统的线下数据库服务,还是日益增长的云数据库服务,数据库的核心任务都是帮助用户存储和管理数据,在复杂多样的环境下,保证数据不丢失、隐私不泄露、数据不被篡改以及服务不中断。这就要求数据库具备多层次的安全防御机制,用来抵抗来自内部和外部的恶意攻击行为。事实上,经过数据库的长期发展,已经构建了体系化的安全能力,比如通过数据库防火墙的入侵防御以及基于AI的攻击识别及智能防御,做到“攻不破”;通过在数据库服务端实现强认证机制,达到攻击者“进不来”;通过完善的权限管理模型、对象访问控制及校验机制做到恶意用户“拿不走”;通过数据加密存储机制或数据静态脱敏及动态脱敏机制实现对关键数据的保护,确保数据在被非法窃取后攻击者“看不懂”;通过多副本备份,融合区块链思想实现类账本系统能力,做到“改不了”;通过系统内部细粒度审计机制,记录用户操作行为,达到攻击行为“赖不掉”。除了传统数据库厂商本身在提升自己的能力外,许多专业化的评估测试机构也在帮助数据库厂商挖掘产品缺陷,加速完善数据库安全能力的构建,并出具专业化评估报告,作为第三方背书让用户“信得过”。这些成熟的安全技术手段,构建了数据库纵深防御的安全体系,保障数据库在应用中的安全。一个完整的防御架构如图1所示。
图1:传统数据库多层级安全防御架构
虽然数据库安全功能越做越强,但这些安全技术手段都是针对传统数据库所面临的威胁构建的。作为面向开放市场的云数据库服务,其所面临的风险相较于传统数据库更加多样化,更加复杂化,无论是应用程序漏洞、系统配置错误,还是恶意管理员都可能对数据安全与隐私保护造成巨大风险。云数据库,其部署网络由“私有环境”向“开放环境”转变,系统运维管理角色被拆分为业务管理员和运维管理员。业务管理员拥有业务管理的权限,属于企业业务方,而运维管理员属于云服务提供商。数据库运维管理员虽然被定义成系统运维管理,其实际依旧享有对数据的完全使用权限,通过运维管理权限或提权来访问数据甚至篡改数据;再者由于开放式的环境和网络边界的模糊化,用户数据在整个业务流程中被更充分的暴露给攻击者,无论是传输、存储、运维还是运行态,都有可能遭受来自攻击者的攻击。因此对于云数据库场景,如何解决第三方可信问题,如何更加可靠的保护数据安全相比传统数据库面临着更大挑战,其中数据安全、隐私不泄露是整个云数据库面临的首要安全挑战。
当前云数据库数据安全隐私保护是针对数据所处阶段来制定保护措施的,如在数据传输阶段使用安全传输协议SSL/TLS,在数据持久化存储阶段使用透明存储加密,在返回结果阶段使用RLS(Row Level Security)或者数据脱敏策略。这些传统技术手段可以解决单点风险,但不成体系,且对处于运行或者运维状态下的数据则缺少有效的保护。面对越来越复杂的云环境,我们需要一种能够彻底解决数据全生命周期隐私保护的系统性解决方案。事实上,近年来学术界以及工业界陆续提出了许多创新思路:数据离开客户端时,在用户侧对数据进行加密,且不影响服务端的检索与计算,从而实现敏感数据保护,此时即便数据库管理员也无法接触到用户侧的密钥,进而无法获取明文数据。这一思路被称为全密态数据库解决方案,或全加密数据库解决方案。
2、全密态数据库与数据全生命周期保护
全密态数据库,顾名思义与大家所理解的流数据库、图数据库一样,就是专门处理密文数据的数据库系统。数据以加密形态存储在数据库服务器中,数据库支持对密文数据的检索与计算,而与查询任务相关的词法解析、语法解析、执行计划生成、事务ACID、数据存储都继承原有数据库能力。
在全密态数据库机制下,一个用户体验良好的业务数据流图如下图1所示。假定数据列c1已以密文形态存放在数据库服务端,用户发起查询任务指令。用户发起的查询任务无需进行特殊化改造,对于查询中涉及的与敏感数据c1相关联的参数,在客户端按照与数据相同的加密策略(加密算法,加密密钥等)完成加密,如图1中关联参数“123”被加密成“0xfe31da05”。参数加密完成后整个查询任务被变更成一个加密的查询任务并通过安全传输通道发到数据库服务端,由数据库服务端完成基于密文的查询检索。检索得到的结果仍然为密文,并最终返回客户端进行解密。
图2:全密态数据库核心业务数据流
根据该业务数据流可以看出,全密态数据库的核心思想是:用户自己持有数据加解密密钥且数据加解密过程仅在客户侧完成,数据以密文形态存在于数据库服务侧的整个生命周期过程中,并在数据库服务端完成查询运算。
由于整个业务数据流在数据处理过程中都是以密文形态存在,通过全密态数据库,可以实现:(1)保护数据在云上全生命周期的隐私安全,无论数据处于何种状态,攻击者都无法从数据库服务端获取有效信息;(2)帮助云服务提供商获取第三方信任,无论是企业服务场景下的业务管理员、运维管理员,还是消费者云业务下的应用开发者,用户通过将密钥掌握在自己手上,使得高权限用户无法获取数据有效信息;(3)使能合作伙伴,通过全密态数据库可以让合作伙伴借助全密态能力更好的遵守个人隐私保护方面的法律法规。
3、全密态数据库核心思路与挑战
正如全密态数据库定义所描述的那样,全密态数据库的核心任务是保护数据全生命周期安全并实现基于密文数据的检索计算。在加密算法足够安全的情况下,外部攻击者及内部管理员均无法获取有效的数据信息。
对于用户来说,从已有数据库服务切换成全密态数据库或者直接将应用部署于全密态数据库,需要解决三个主要的问题:(1)如何保障密态计算机制的安全性,全密态数据库从原理上可以有效保障数据安全,但这要求密文数据检索及运算的算法在机理和工程上要达到该原理要求;(2)如何进行业务的无缝迁移或者轻量化迁移,全密态数据库最显著的特征是数据存储信息的变更,那与加密数据相关的各类参数都要同步进行变更,否则会因为计算数据形态的不对等导致查询紊乱;(3)如何避免服务切换所带来的性能损耗,本质上需要将加密算法实现和工程实现所产生的性能回退控制在一个合理的范围内,避免因为不合理的数据加解密和数据存储膨胀带来性能急速下降。只有解决这三个关键问题,才能真正的推动全密态数据库落地。
目前,全密态数据库在学术界和工业界均有研究和尝试,主要聚焦于两种解决方案:(1)密码学解决方案,或称为纯软解决方案,通过设计满足密文查询属性的密码学算法来保证查询的正确性,如已知常见的OPE(Order Preserving Encryption)算法,数据加密后仍保留顺序属性;(2)硬件方案,通过可信执行环境(TEE, Trusted Execution Environment)来处理REE(Rich Execution Environment,REE与TEE相对应)环境中的密文数据运算,图3展示了ARM架构下的TEE与REE的对应关系。无论是密码学解决方案还是现有的硬件方案都有他们各自的优缺点。
图3:REE与TEE逻辑关系图
密码学方案的核心思路是整个运算过程都是在密文状态,通过基于数学理论的算法来直接对密文数据进行检索与计算。该方案需要解决在用户不感知的条件下,实现密文数据的安全、高效检索与计算,当前的主要挑战在两个方面:一方面学术界当前主要的密码学算法,大部分都是基于功能实现及安全能力的考虑,对于内外存储、网络吞吐、计算消耗等性能指标都会有不同的劣化,甚至有些性能完全脱离了实际场景,因此如何能在数据密文状态下实现检索和计算,并且满足性能要求,是密码学方案的最大挑战;另一方面,通常一种数学算法只能解决部分业务场景,如何将多种密码学算法融合,以实现数据库查询和计算的主要功能,也是密码学方案的一大挑战。
硬件方案的核心思路是将存放于REE侧的加密数据传递给TEE侧,并在TEE侧完成数据解密和计算任务(见图3),依赖TEE的“隔离性”或“对REE侧应用的不可见性”实现数据计算过程的安全保护。一方面,受限于TEE空间的大小(如SGX v1仅提供128MB可用空间、基于ARM TrustZone方案一般也仅提供几十MB空间),难以处理大量数据和复杂操作,这就要求TEE内仅关注关键敏感数据的查询操作,降低攻击面;另一方面由于REE与TEE运行切换和数据交互带来额外的开销,因此需要解决整个运算过程中的REE与TEE的计算资源分配与高效调度问题,也是硬件方案面临的一大挑战。
4、GaussDB(openGauss)全密态数据库解决方案
4.1 开创性自适应架构打造首款支持软模式密态计算
全密态数据库中的软件方案和硬件方案目前均已取得了很多进展,特别的,工业界已开始在逐步采用硬件方案。借助诸如Intel SGX等安全硬件的TEE空间,对数据计算空间进行物理或逻辑隔离,实现数据对REE的“不可见”。但硬件方案目前存在两个较大的缺陷:首先由于数据在TEE内部均为明文存在,因此数据的安全性完全依赖于硬件本身的安全性。目前针对硬件的攻击方式如侧信道攻击等越来越多,但是一般硬件设备更新迭代周期较长,一旦出现漏洞无法及时更新修补,将直接导致用户数据长时间暴露在风险之下。其次用户在使用该特性时,密钥需要离开客户端环境发送给TEE使用,而该传输过程的安全直接依赖于硬件设备厂商的证书签名,恶意的硬件设备厂商人员完全有能力攻击并窃取用户的数据及密钥,因此硬件方案,也需要用户在使用过程中,持续信任硬件设备厂商。
全密态数据库的软件方案目前在学术界发展较快,通过一系列数学算法在密文空间直接对密文进行查询运算,保障数据隐私不泄露。软件方案可以不依赖于硬件能力,也不需要在服务侧获取密钥对数据进行解密,但当前也存在着在第三章节提到的巨大挑战。
图4:GaussDB全密态数据库架构
在华为全连接大会上,华为正式发布基于GaussDB的全密态数据库解决方案,该方案结合软件模式与硬件模式各自的优缺点,推出融合策略,实现硬件模式和软件模式的自由切换,该方案支持全场景应用,包括公有云、混合云以及终端智慧业务,更为重要的是对终端用户透明无感知。
在硬件模式下,GaussDB首先支持多硬件平台能力,如Intel CPU的SGX能力,以及业内首创的华为自主研发鲲鹏ARM TrustZone能力。其次GaussDB实现了最小粒度的隔离级别,使得攻击面最小化,并且通过一系列的密钥安全保障机制,如多层密钥管理体系、可信传输通道、会话级密钥管理机制等,实现了硬件环境中的数据及密钥安全,从而降低因硬件安全问题而导致的用户数据及密钥泄露风险。
由于硬件模式依赖于硬件及其生产厂商的安全和信誉,且用户在实际使用过程中需要依赖特性硬件环境,GaussDB还开创性的支持了软件模式的密态查询能力,通过对多种密码学算法的深度性能优化,构建出不同的密态查询引擎,以完成不同的检索和计算功能,实现数据等值查询、范围查询、保序查询、表达式计算等特性。特别的,通过引入确定性加密机制,实现了数据的增删改查、表字段关联、等值检索等基本操作;基于GS-OPE算法的密文索引技术,实现了数据密态保序查询、表达式大小比较等常规操作;通过Range-Identify算法,实现数据密态范围查询。
GaussDB 全密态数据库解决方案创新性的解决了多个技术难点,实现了对用户无感知、数据加密无泄漏等核心竞争力。
4.2 全自动加密驱动实现用户数据库操作无感知
要实现在客户端进行加解密,无疑需要在客户端进行大量维护管理,包括数据密钥管理,敏感数据加密,解析和修改SQL语句等。如果仅仅提供数据加密工具,由用户来对数据进行显式加密,一方面会增加用户的开发成本,另一方面用户也容易因数据加密不到位而造成数据泄露。
GaussDB将这一系列的复杂操作,全部封装在客户端加密驱动中,实现了完全自动化的敏感信息加密替换,同时在数据库中存储了所有加密相关的元信息,使得数据库可以很好的识别和处理对应的加密数据。如图5所示,由于SQL语句中与敏感信息相关的参数也被加密处理,使得发送至数据库服务侧的查询任务(图中ciphertext query)也不会泄露用户查询意图,减少客户端的复杂安全管理及操作难度,实现用户应用开发无感知。另外,GaussDB提供一系列的配置接口,满足用户对加密字段、加密算法、密钥安全存储等不同场景的需要。GaussDB全密态数据库的透明性使得用户在任务迁移时将获得极大的便捷性。
图5:全自动客户端加密驱动
4.3 利用算子级隔离显著降低安全风险
当密文查询进入数据库内核之后,就需要依赖现有的查询处理模块来完成数据运算。对数据库这种高度复杂的系统,在硬件模式下,如何将敏感数据的检索、计算等核心功能解耦隔离,放在安全环境中独立运行,从而最小化敏感数据计算面临的安全风险,一直是GaussDB的一个重大难题。
图6:主流硬件隔离方案
当前业界主要有三种TEE隔离计算方案:数据库级隔离、模块级隔离、算子级隔离。这三种方案从攻击面和工程实现维度来看,有显著的差异。
数据库级隔离,是在TEE中完整的建立一个特殊的数据库引擎,将敏感数据的查询请求直接发送给该数据库进行全部的解析和执行处理。该方案的架构比较清晰,实现简单,安全性和可靠性直接依赖于TEE中数据库的能力。然而,由于TEE中数据库引擎的代码规模较大,因此数据库实例需要消耗更多的TEE侧资源,且一旦由于潜在代码缺陷导致在执行过程出现严重错误,将导致出现TEE环境崩溃等严重后果。
模块级隔离,是将SQL执行器放到TEE中,实现对语句的执行过程进行保护。执行器是数据库查询语句的查询任务执行模块,与数据库级隔离相比,这种方式减小了TEE中的代码规模,其安全性主要依赖于执行模块的安全能力。但该方式下仍有大量与敏感数据计算无关的操作将在TEE中运行,而这些操作都可能接触到明文数据,故而容易引入错误或者无意泄露敏感数据,留下安全攻击隐患。
算子级隔离。算子是机密数据计算的最小、最核心功能单元,如数据排序算子、表达式计算等。通过将密文算子放在TEE中执行,可以针对性的对敏感数据进行重点保护,排除非敏感数据操作带来的潜在风险,具有最小规模的代码实现。但是其难度和挑战并存:首先,数据库的复杂性决定了将敏感数据的单一算子执行过程进行解耦存在较大的挑战性,传统的pipeline执行流程意味着单个算子执行过程的连续性,针对算子执行过程中的核心计算流程进行解耦就需要进行定向梳理;其次单个查询语句通常涉及多个算子运算,整个查询运算流程需要根据算子运算需求多次切换到TEE侧环境,对性能造成影响。
为了追求极致的安全,GaussDB选择了算子级隔离策略。为了解决算子级隔离的两大问题,GaussDB全密态数据库通过精心设计,成功实现了最小粒度的敏感数据检索和计算模块。同时,从多个层面对REE与TEE之间的world switch的性能和数据传输方式进行深度优化,将性能影响降到最低。从而在显著减小安全风险的同时,也有力地保障了数据库系统的高效运行。
4.4 高强度密钥体系保障密钥安全
整个全密态数据库解决方案中除数据本身具有敏感性质外,最为敏感的信息就是数据加解密密钥,一旦密钥泄露,将给用户数据带来严重风险。特别是在硬件模式下,密钥需离开用户侧,传输到云侧可信硬件环境中,其安全保护至关重要。GaussDB通过实现三层密钥体系,让各层密钥各司其职,真正做到密钥高强度的安全保护。
图7:GaussDB高强度密钥体系
第一层为数据密钥,做到了字段级别,即针对不同的字段将采用不同的密钥,同时对相同字段不同数据采用不同的盐值,以实现不同字段之间的加密隔离,即使某一列数据的加密密钥被泄露,也不会影响到其他数据安全,提升整体数据的安全性。
第二层为用户密钥,对不同用户将使用不同的密钥,以实现用户之间的加密隔离,而且用户密钥永远不会离开用户可信环境;使得包括管理员在内的其他用户,即便窃取了数据的访问权限,也无法解密最终数据。
第三层为设备密钥,即对不同的密钥存储设备或工具,使用不同的密钥进行保护,实现设备间的加密隔离,大大增加了攻击用户密钥存储设备或工具破解密钥的难度。
不仅如此,由于在硬件模式下,需要将字段级密钥传输给硬件TEE环境使用。GaussDB在该场景下进行了更高强度的保护措施:首先,通过ECCDH协议安全协商和TEE内置证书签名校验,构建用户侧与TEE环境之间的可信通道,保证密钥安全可信的加密传输,防止中间人攻击;其次,密钥不会以任何形式离开TEE环境,只在会话期间存在,结束立刻释放,最小化数据密钥生命周期,防止因代码漏洞或异常情况引起的密钥泄露。
5、全密态数据库的未来
全密态数据库技术理念抛开了传统的多点技术单点解决数据风险的问题,通过系统化思维建立了一套能够覆盖数据全生命周期的安全保护机制。这套机制使得用户在无感知的情况下就解决了数据的安全隐私保护,对于攻击者和管理者来说都无法获取有效信息。全密态数据库是数据库安全隐私保护的高级防御手段,但全密态数据库在当前仍存在一定的局限性,仍需要突破算法安全性和性能损耗等相关问题。
全密态数据库在实际应用中建议仅针对敏感数据进行使用,通过借助于数据库本身提供的多方位数据保护机制,为不同等级的数据提供不同层级的安全机制,从而构建全方位的数据安全保护机制。未来GaussDB会将该能力逐步开源到openGauss,与社区共同推进和完善全密态数据库解决方案,一起打造数据库安全生态。
