面向云服务的GaussDBopenGa
1、云数据库安全现状及问题
伴随着云基础设施的快速增长和成熟,与之对应的云数据库服务也层出不穷。一方面,受益于云服务的便捷性传统企业加速业务上云,通过充分发挥云数据库特有的轻松部署、高可靠、低成本等优势降低企业运营成本,加速企业应用创新;另一方面,以苹果iCloud服务为代表的存储服务和云计算服务为移动消费者带来应用便捷性,利用云侧的数据库服务存储海量消费者的个人数据。
云数据库俨然已成为数据库业务未来重要的增长点,绝大多数的传统数据库服务厂商正在加速提供更优质的云数据库服务。但无论是传统的线下数据库服务,还是日益增长的云数据库服务,数据库的核心任务都是帮助用户存储和管理数据,在复杂多样的环境下,保证数据不丢失、隐私不泄露、数据不被篡改以及服务不中断。这就要求数据库具备多层次的安全防御机制,用来抵抗来自内部和外部的恶意攻击行为。事实上,经过数据库的长期发展,已经构建了体系化的安全能力,比如通过数据库防火墙的入侵防御以及基于AI的攻击识别及智能防御,做到“攻不破”;通过在数据库服务端实现强认证机制,达到攻击者“进不来”;通过完善的权限管理模型、对象访问控制及校验机制做到恶意用户“拿不走”;通过数据加密存储机制或数据静态脱敏及动态脱敏机制实现对关键数据的保护,确保数据在被非法窃取后攻击者“看不懂”;通过多副本备份,融合区块链思想实现类账本系统能力,做到“改不了”;通过系统内部细粒度审计机制,记录用户操作行为,达到攻击行为“赖不掉”。除了传统数据库厂商本身在提升自己的能力外,许多专业化的评估测试机构也在帮助数据库厂商挖掘产品缺陷,加速完善数据库安全能力的构建,并出具专业化评估报告,作为第三方背书让用户“信得过”。这些成熟的安全技术手段,构建了数据库纵深防御的安全体系,保障数据库在应用中的安全。一个完整的防御架构如图1所示。
图1:传统数据库多层级安全防御架构虽然数据库安全功能越做越强,但这些安全技术手段都是针对传统数据库所面临的威胁构建的。作为面向开放市场的云数据库服务,其所面临的风险相较于传统数据库更加多样化,更加复杂化,无论是应用程序漏洞、系统配置错误,还是恶意管理员都可能对数据安全与隐私保护造成巨大风险。云数据库,其部署网络由“私有环境”向“开放环境”转变,系统运维管理角色被拆分为业务管理员和运维管理员。业务管理员拥有业务管理的权限,属于企业业务方,而运维管理员属于云服务提供商。数据库运维管理员虽然被定义成系统运维管理,其实际依旧享有对数据的完全使用权限,通过运维管理权限或提权来访问数据甚至篡改数据;再者由于开放式的环境和网络边界的模糊化,用户数据在整个业务流程中被更充分的暴露给攻击者,无论是传输、存储、运维还是运行态,都有可能遭受来自攻击者的攻击。因此对于云数据库场景,如何解决第三方可信问题,如何更加可靠的保护数据安全相比传统数据库面临着更大挑战,其中数据安全、隐私不泄露是整个云数据库面临的首要安全挑战。
当前云数据库数据安全隐私保护是针对数据所处阶段来制定保护措施的,如在数据传输阶段使用安全传输协议SSL/TLS,在数据持久化存储阶段使用透明存储加密,在返回结果阶段使用RLS(RowLevelSecurity)或者数据脱敏策略。这些传统技术手段可以解决单点风险,但不成体系,且对处于运行或者运维状态下的数据则缺少有效的保护。面对越来越复杂的云环境,我们需要一种能够彻底解决数据全生命周期隐私保护的系统性解决方案。事实上,近年来学术界以及工业界陆续提出了许多创新思路:数据离开客户端时,在用户侧对数据进行加密,且不影响服务端的检索与计算,从而实现敏感数据保护,此时即便数据库管理员也无法接触到用户侧的密钥,进而无法获取明文数据。这一思路被称为全密态数据库解决方案,或全加密数据库解决方案。
2、全密态数据库与数据全生命周期保护
全密态数据库,顾名思义与大家所理解的流数据库、图数据库一样,就是专门处理密文数据的数据库系统。数据以加密形态存储在数据库服务器中,数据库支持对密文数据的检索与计算,而与查询任务相关的词法解析、语法解析、执行计划生成、事务ACID、数据存储都继承原有数据库能力。
在全密态数据库机制下,一个用户体验良好的业务数据流图如下图1所示。假定数据列c1已以密文形态存放在数据库服务端,用户发起查询任务指令。用户发起的查询任务无需进行特殊化改造,对于查询中涉及的与敏感数据c1相关联的参数,在客户端按照与数据相同的加密策略(加密算法,加密密钥等)完成加密,如图1中关联参数“”被加密成“0xfe31da05”。参数加密完成后整个查询任务被变更成一个加密的查询任务并通过安全传输通道发到数据库服务端,由数据库服务端完成基于密文的查询检索。检索得到的结果仍然为密文,并最终返回客户端进行解密。
图2:全密态数据库核心业务数据流根据该业务数据流可以看出,全密态数据库的核心思想是:用户自己持有数据加解密密钥且数据加解密过程仅在客户侧完成,数据以密文形态存在于数据库服务侧的整个生命周期过程中,并在数据库服务端完成查询运算。
由于整个业务数据流在数据处理过程中都是以密文形态存在,通过全密态数据库,可以实现:(1)保护数据在云上全生命周期的隐私安全,无论数据处于何种状态,攻击者都无法从数据库服务端获取有效信息;(2)帮助云服务提供商获取第三方信任,无论是企业服务场景下的业务管理员、运维管理员,还是消费者云业务下的应用开发者,用户通过将密钥掌握在自己手上,使得高权限用户无法获取数据有效信息;(3)使能合作伙伴,通过全密态数据库可以让合作伙伴借助全密态能力更好的遵守个人隐私保护方面的法律法规。
3、全密态数据库核心思路与挑战
正如全密态数据库定义所描述的那样,全密态数据库的核心任务是保护数据全生命周期安全并实现基于密文数据的检索计算。在加密算法足够安全的情况下,外部攻击者及内部管理员均无法获取有效的数据信息。
对于用户来说,从已有数据库服务切换成全密态数据库或者直接将应用部署于全密态数据库,需要解决三个主要的问题:(1)如何保障密态计算机制的安全性,全密态数据库从原理上可以有效保障数据安全,但这要求密文数据检索及运算的算法在机理和工程上要达到该原理要求;(2)如何进行业务的无缝迁移或者轻量化迁移,全密态数据库最显著的特征是数据存储信息的变更,那与加密数据相关的各类参数都要同步进行变更,否则会因为计算数据形态的不对等导致查询紊乱;(3)如何避免服务切换所带来的性能损耗,本质上需要将加密算法实现和工程实现所产生的性能回退控制在一个合理的范围内,避免因为不合理的数据加解密和数据存储膨胀带来性能急速下降。只有解决这三个关键问题,才能真正的推动全密态数据库落地。
目前,全密态数据库在学术界和工业界均有研究和尝试,主要聚焦于两种解决方案:(1)密码学解决方案,或称为纯软解决方案,通过设计满足密文查询属性的密码学算法来保证查询的正确性,如已知常见的OPE(OrderPreservingEncryption)算法,数据加密后仍保留顺序属性;(2)硬件方案,通过可信执行环境(TEE,TrustedExecutionEnvironment)来处理REE(RichExecutionEnvironment,REE与TEE相对应)环境中的密文数据运算,图3展示了ARM架构下的TEE与REE的对应关系。无论是密码学解决方案还是现有的硬件方案都有他们各自的优缺点。
图3:REE与TEE逻辑关系图密码学方案的核心思路是整个运算过程都是在密文状态,通过基于数学理论的算法来直接对密文数据进行检索与计算。该方案需要解决在用户不感知的条件下,实现密文数据的安全、高效检索与计算,当前的主要挑战在两个方面:一方面学术界当前主要的密码学算法,大部分都是基于功能实现及安全能力的考虑,对于内外存储、网络吞吐、计算消耗等性能指标都会有不同的劣化,甚至有些性能完全脱离了实际场景,因此如何能在数据密文状态下实现检索和计算,并且满足性能要求,是密码学方案的最大挑战;另一方面,通常一种数学算法只能解决部分业务场景,如何将多种密码学算法融合,以实现数据库查询和计算的主要功能,也是密码学方案的一大挑战。
硬件方案的核心思路是将存放于REE侧的加密数据传递给TEE侧,并在TEE侧完成数据解密和计算任务(见图3),依赖TEE的“隔离性”或“对REE侧应用的不可见性”实现数据计算过程的安全保护。一方面,受限于TEE空间的大小(如SGXv1仅提供MB可用空间、基于ARMTrustZone方案一般也仅提供几十MB空间),难以处理大量数据和复杂操作,这就要求TEE内仅
转载请注明：http://www.sinoeverlife.com/glscf/12762.html
