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