上篇内容从openGauss安全机制概览、openGauss安全认证、openGauss角色管理机制等方面介绍了openGauss安全（上）中的内容，本篇将围绕openGauss审计与追踪、openGauss数据安全技术、openGauss云安全技术、openGauss智能安全机制对openGauss安全的其他方面进行介绍。

四、openGauss审计与追踪

openGauss在部署完成后,实际上会有多个用户参与数据管理。除了管理员用户外,更多的是创建的普通用户直接进行数据管理。用户的多样性会导致数据库存在一些不可预期的风险。如何快速发现和追溯到这些异常的行为,则需要依赖审计记录机制和审计追踪机制。

（一） 审计记录机制

审计记录的关键在于:

• 定义何种数据库操作行为需要进行日志记录。
• 记录的事件以何种形式展现和存储。

只有有效地记录了所关心的行为信息,才能依据这些行为进行问题审计和追溯,实现对系统的一个有效监督。

正如在“三权分立模型”中描述的,进行权限分离后,就出现了审计管理员(当然也可以使用普通角色管理模型中的系统管理员来担当)。审计管理员最重要的作用在于对管理员以及普通用户所有关心的行为进行记录和审计追溯。审计首先要定义审计哪些数据库行为,其次需要定义审计内容记录在什么文件中以及何种目录下,最后需要定义清楚应提供何种接口供审计管理员进行审计查询。

openGauss针对用户所关心的行为提供了基础审计能力,包括事件的发起者、发生的时间和发生的内容。openGauss的审计功能受总体开关audit_enabled控制,默认开启。该开关不支持动态加载,需要重启数据库后才可以使功能的性质发生改变。在总体开关的基础上,openGauss增加了每一个对应审计项的开关。只有相应的开关开启,对应的审计功能项才能生效。

不同于总体开关,每一个对应的子审计项都支持动态加载,在数据库运行期间修改审计开关的值,不需要重启数据库即可支持。审计的子项目包括如下部分:

• audit_login_logout:用户登录、注销审计。

• audit_database_process:数据库启动、停止、恢复和切换审计。

• audit_user_locked:用户锁定和解锁审计。

• audit_user_violation:用户访问越权审计。

• audit_grant_revoke:授权和回收权限审计。

• audit_system_object:数据库对象的 CREATE、ALTER和 DROP操作审计。

• audit_dml_state:具体表的INSERT、UPDATE和 DELETE操作审计。

• audit_dml_state_select:SELECT 查询操作审计。

• audit_copy_exec:复制行为审计。

• audit_function_exec:审计执行 FUNCTION 操作。

• audit_set_parameter:审计设置参数的行为。

定义完审计记录行为后,当数据库执行相关的操作时,内核独立的审计线程就会记录审计日志。

传统的审计日志保存方法有两种:记录到数据库的表中及记录到 OS文件中。前一种方法由于表是数据库的对象,在符合权限的情况下就可以访问到该审计表,当发生非法操作时,审计记录的准确性难以得到保证。而后一种方法虽然需要用户维护审计日志,但是比较安全,即使一个账户可以访问数据库,但不一定有访问 OS这个文件的权限。

与审计日志存储相关的配置参数及其含义定义如下:

• audit_directory:字符串类型,定义审计日志在系统中的存储目录,一个相对于“/data”数据目录的路径,默认值为/var/log/opengauss/perfadm/pg_audit,也可以由用户指定。

• audit_resource_policy:布尔类型,控制审计日志的保存策略,即以空间还是时间限制为优先策略决定审计文件更新,默认值为on。

• audit_space_limit:整数类型,定义允许审计日志占用的磁盘空间总量,默认值为1GB,在实际配置中需要结合环境进行总体考虑。

• audit_file_remain_time:整数类型,定义保留审计日志的最短时间要求,默认值为90,单位为天。特别的,如果取值为0,则表示无时间限制。

• audit_file_remain_threshold:整数类型,定义审计目录audit_directory下可以存储的审计文件个数。默认值为1048576。

• audit_rotation_size:整数类型,定义单个审计日志文件的最大大小,当审计日志文件大小超过此参数值时,新创建一个审计文件。

• audit_rotation_interval:整数类型,定义新创建一个审计日志文件的时间间隔。默认值为1天,单位为分钟。

通过上述的这些配置参数,系统管理员用户可以在查询任务发生后找到对应的审计日志,并进行有效归档。审计日志文件也会按照参数指定的规则进行更新、轮换等。

（二） 审计追踪机制

openGauss将审计所产生的文件独立存放在审计文件夹中,按照产生的先后顺序进行标记管理,并以特定的格式进行存储(默认为二进制格式文件)。当审计管理员需要进行审计查询时,通过执行函数pg_query_audit()即可,其具体的语句如下:

select * from pg_query_audit(timestamp valid_start_time, timestamp valid_end_time, audit_log);

其中,valid_start_time和valid_end_time定义了审计管理员将要审计的有效开始时间和有效结束时间;audit_log表示审计日志信息所在的归档路径,当不指定该参数时,默认查看链接当前实例的审计日志文件(不区分具体的审计文件)。

值得注意的是,valid_start_time和valid_end_time的有效值为从valid_start_time日期中的00:00:00开始到valid_end_time日期中的23:59:59。由于审计日志中包含了众多的信息,如时间、地点、行为分类等,审计管理在获得完整的信息后可以增加各种过滤条件来获得相对应的更明确的信息。

（三）统一审计

传统审计依据开关定义了不同的审计组合行为。事实上,这种无区分对待的审计虽然记录了所有想要审计的行为,但是对于通过审计日志发现问题则显得不那么容易,且管理员无法为特定的用户定义特定的行为,反而造成了系统处理的负担。因此需要为审计添加更精细化管理的能力。

统一审计的目的在于通过一系列有效的规则在数据库内部有选择性执行有效的审计,从而简化管理,提高数据库生成的审计数据的安全性。本节所述的技术目前处于研发阶段,对应产品尚未向客户发布。

openGauss提供了一套完整的统一审计策略机制,依据不同任务的诉求对用户行为进行定制化审计管理。更进一步,openGauss的统一审计不仅可以依据用户、依据表进行审计行为定义,同时还可以扩展至通过IP地址、App的名称来过滤和限制需要审计的内容。实际的语句如下:

CREATE AUDIT_POLICY policy_name
[
(privilege_audit_clause) | (access_audit_clause)
[filter_clause FILTER_TYPE(filter_value)]
[ENABLED|DISABLED]];

其中,privilege_audit_clause定义语句如下:

PRIVILEGES (DDL|ALL) [ ON (LABEL(resource_label_name)) [, …]* ];

该语句定义了针对 DDL类语句的审计策略,其中 LABEL表示一组资产集合,即数据库对象的集合。access_audit_clause定义语句如下:

ACCESS (DML|ALL) [ ON (LABEL(resource_label_name)) [, ...]* ];

该语句定义了针对 DML类语句的审计策略。filter_clause标记需要过滤的信息,常见的 Filtertypes(过滤类型)包括IP、APPS应用(访问的应用名)、ROLES(数据库系统用户)以及 LABEL对象。

一个有效的统一审计策略可参见如下:

CREATE AUDIT_POLICY admin_policy PRIVILEGES CREATE, ALTER, DROP FILTER ON IP(local), ROLES(dev);

该语句表示创建针对 CREATE/ALTER/DROP操作的审计策略,审计策略只对dev用户在本地(local)执行CREATE/ALTER/DROP行为时生效。

五、 openGauss数据安全技术

数据库最重要的作用是存储数据和处理分析数据。数据是整个数据库系统中最关键的资产。因此,在保护系统不受侵害的基础上最为重要的任务就是保护数据的安全。常见的数据安全技术包括数据加密、数据脱敏(Data Masking)、透明数据加密(Transparent Data Encryption,TDE)和全程加密(Always Encryption)技术。这里囊括了数据的动态流程和静态存储行为。

（一） 数据加密算法

数据加密和解密是防止数据隐私泄露最为常见也最为有效的手段之一。数据在经过加密后以密文形式存放在指定的目录下。加密的意义在于,通过一系列复杂的迭代计算,将原本的明文转换为随机的没有任何具体含义的字符串,即密文。当所使用的加密算法足够安全时,攻击者在有限的计算资源下将很难根据密文获取到明文信息。

常见的加密算法可分为对称加密算法和非对称加密算法。其中最为著名的非对称加密算法为 RSA 算法,其密钥长度须达到3072比特(b)才可以保证其安全性,即强安全。常见的对称加密算法为 AES算法,如 AES128和 AES256。相比于非对称加密算法,对称加密算法运算速度快,密文长度增长少,安全性容易证明,所需要的密钥长度短,但也存在密钥分发困难和不可用于数字签名等缺点。除了上述介绍的加密算法外,还有很多其他强安全算法,在此不一一介绍。下面重点介绍openGauss中所支持的数据加密能力。

首先openGauss在内核定义了数据加密和解密的函数,并对外提供了数据加密和解密的接口,函数接口为:

gs_encrypt_aes128(text, initial_value)；

其中,text为需要加密的明文数据;initial_value为生成密钥时需要的初始化向量。该函数可以被灵活地应用在 SQL语句的各个地方。例如,通过使用INSERT 语句插入数据或者查询数据时均可以绑定该函数对数据进行加密处理,具体如下:

SELECT * FROM gs_encrypt_aes128(tbl.col, ‘1234’);

通过该查询,用户可以直接返回表tbl中的col列的密文信息。

与加密函数相对应的是解密函数,其接口格式定义为:

gs_decrypt_aes128(cypertext, initial_value);

其中,cypertext为加密之后的密文;initial_value需要为与加密时所采用的相同的值才可以,否则使用该函数也无法得到正确明文。

除了基本的数据加密和解密接口外,openGauss还在多个特性功能里提供了数据加密和解密功能。其中第一个提供加密和解密功能的特性是数据导入导出;第二个提供加密和解密功能的特性是数据库备份恢复。

（二）数据脱敏技术

在很多应用场景下,用户需要通过拥有表中某一列的访问权限来执行任务,但是又不能获取所做事务之外的其他权限。以快递人员为例,快递人员在递送包裹的时候需要知道收件人的联系方式和姓氏,但是无须知道对应的收件人的全称。在快递收件人信息部分,如果同时定义了收件人的姓名和电话,则暴露了收件人的隐私信息,“有心之人”可以通过此信息进行虚假信息构造或利用该隐私信息进行财产欺诈。因此在很多情况下,所定义的敏感信息是不建议对外展现的。

数据脱敏是解决此类问题的最有效方法之一,通过对敏感数据信息的部分信息或全量信息进行特殊处理可以有效掩盖敏感数据信息的真实部分,从而达到保护数据隐私信息的目的。数据脱敏按照脱敏呈现的时机可以分为数据动态脱敏和数据静态脱敏,其中前者在数据运行时对数据进行特殊处理,后者在数据存储的时候进行特殊处理以防止攻击者通过提取数据文件来直接获取敏感信息。本小节重点介绍数据动态脱敏技术。

数据动态脱敏的安全意义在于:

• 用户在实际操作的时候无须用真实数据,只需要使用一个变化后的数据,可有效规避数据信息的直接暴露。
• 在不同的国家或地区的法律法规中,如 GDPR(通用数据保护条例),约定不同的用户在管理数据的时候具有不同的访问对象权限。
• 对于表中的同一列数据信息,不同的用户应具有不同的用途。

数据动态脱敏功能在数据库内核实际上表现为数据处理函数。通过函数处理使得数据库中的数据在返回给实际查询用户时数据值发生变更,如用户所有的年龄信息值在返回给客户端时均显示为“0”;又或是字符串数据中的部分字节位变更为其他字符,如信用卡卡号“1234 5678 0910 1112”在返回给客户端时显示为“XXXX XXXX XXXX 1112”。

在openGauss系统中,数据动态脱敏策略定义如下:

CREATE MASKING_POLICY policy_name
(
(masking_clause)
[filter_clause]
[ENABLE|DISABLE]
);

其中的具体参数说明如下:

• masking_clause定义如下:

MASKING_FUNCTION(PARAMETERS) ON (SCOPE(FQDN)) | (LABEL(resource_label_name)) [, …]*;

定义了针对不同数据集合对象所采用的脱敏函数。这里,LABEL 为数据库安全标签。数据库安全标签实际上定义了一组数据内部的表对象或表中的部分列,用于标记相应数据脱敏策略的范围。

• filter_clause定义如下:

FILTER ON FILTER_TYPE(filter_value [, …]*) [, …]*;

定义了数据动态脱敏策略所支持的过滤条件。 一个实际的数据动态脱敏案例如下:

CREATE MASKING_POLICY my_masking_policycreditcardmasking ON LABEL (mask_credcard),maskall ON LABEL (mask_all)FILTER ON IP(local), ROLES(dev);

其中,my_masking_policy为定义的数据动态脱敏策略名字;creditcardmasking以及mask_all为定义的 masking处理函数,分别用于处理从属于 mask_credcard对象集合和 mask_all对象集合;mask_credcard和 mask_all代表不同的Label对象,这些Label对象名称将作为唯一标识记录在系统表中。FILTER 表示当前动态脱敏策略所支持的连接源,连接源指的是实际数据库管理员使用何种用户,从何IP源位置发起,使用何种 App应用来访问当前的数据库。通过使用 FILTER 可以有效定义系统的访问源信息,并规避不应该访问当前系统的行为。

openGauss在系统内部预定义了七种数据脱敏策略,具体如表1所示。

表1 数据脱敏策略 |脱敏策略 | 含义 |脱敏前数据 | 脱敏后数据| |--|--|--|--| | creditcardmasking | 针对信用卡定义类数据的脱敏策略 |4880-9898-4545-2525 | xxxx-xxxx-xxxx-2525 | |maskall | 全脱敏策略 | 4880-9898-4545-2525 |xxxxxxxxxxxxxxxxxxx | | basicemailmasking |邮件类信息基础脱敏策略：脱敏用户名 | alex@gmail.com |xxxx@gmail.com | | fullemailmasking |邮件类信息全脱敏策略 | alex@gmail.com | xxxx@xxxxx.com | | alldigitsmasking | 数字脱敏策略 | alex123alex | alex000alex | | shufflemasking | 置换脱敏策略 | hello word | ollehdlrow | |randommasking | 随机脱敏策略 | hello word | ad5f5ghdf5 |

用户在实际使用时,还可以根据自己的需求自行定义数据脱敏策略。

（三）透明加密技术

当数据在静态存储状态时,除了使用常见的静态脱敏技术进行数据隐私保护外,另一种行之有效的方法是 TDE(透明加密)。事实上,静态脱敏在实际应用过程中是存在一定限制的。用户并不能对所有的数据类型都施加静态脱敏措施。

TDE从加密策略出发,即使用户数据被导出,也可以有效解决数据信息泄露风险。数据透明加密的初衷是为了防止第三方人员绕过数据库认证机制,直接读取数据文件中的数据(数据文件中的数据虽然是二进制数据,但是仍然是明文存放)。所以对数据库的数据文件进行加密后,必须在数据库启动后,用户通过正常途径连接数据库,才可以读取解密后的数据,达到数据保护的目的。

openGauss实施透明加密策略,首先是需要确 定一个数据库加密密钥(Database Encryption Key,DEK),该DEK由系统密钥管理系统(Key Management Service,KMS)生成,数据库密钥密文(EncryptedDatabaseEncryptionKey,EDEK)以文件方式(gs_tde_keys.cipher)存储于数据库系统中。该 DEK 一次生成,终身使用,不可变更,不可轮换。在快照(即备份)恢复时,需要使用此前的 DEK。

数据库在每次启动时,通过读取本地存储的密钥信息和 EDEK,向 KMS机器上的URL地址,传入密钥版本名(version-name)、密钥名(name)、IV 值和数据库加密密钥密文值,从而获取到解密后的 DEK。此密钥会缓存在实例的内存当中,当数据库需要加密或解密数据时从内存中复制密钥明文。

openGauss支持两种格式的透明加密算法,通过 GUC参数transparent_encryption_algo进行控制,当前支持的算法包括 AES-CTR-128和SM4-CTR-128。加密模式选用CTR(CounTeR,计数器模式)的原因是 CTR 加密可以保证明文和密文长度相等。明文和密文长度相等是由数据块(Block)的大小决定的,因为内存和磁盘存储格式对块的大小是有要求 的 (默 认 为 8KB)。特 别 的,在 openGauss列 存 储 中,列 存 储 单 元(ColumnUnit,CU)的最大值是有限制的,所以其加密后的长度也不能超过最大限制值。

一个完整的数据透明加密流程如图1所示,即该特性的生命周期共分为3个阶段:安装阶段、启动阶段和使用阶段。

• 安装阶段:用户通过安装部署的配置,生成密钥记录文件和 GUC参数。

• 启动阶段:用户依据密钥记录文件和 GUC参数,获取到明文。

• 使用阶段:用户根据密钥算法标记和全局缓存明文,完成数据落盘的加密和数据读取的解密。

图1 数据透明加密流程

（四） 全程加密技术

无论是当前通用的数据脱敏方案,还是数据透明加密方案,其所解决的都是部分状态或部分流程下的数据隐私安全。数据库攻击者可通过其他不同的攻击技术手段在数据以明文存在或处于内存中时抓取数据流信息,从而达到获取隐私数据的目的。如果数据在整个生命周期中都能够处于加密的形态,且密钥掌握在用户自己手中,则数据库用户可有效地防止数据隐私的泄露。

全程加密技术就是在这种场景下诞生的。其核心是使得数据从用户手中进入到数据库系统后一直处于加密状态,用户所关心的数据分析过程也在密态状态下完成。在整个数据分析处理过程中,即使用户数据被攻击者窃取,由于密钥一直掌握在客户自己手中,攻击者也无法获得相关的信息。目前该技术处于研发阶段,对应产品尚未发布。

openGauss分三个阶段来实现完整的数据全程加密功能。

• 第一阶段:实现客户端全程加密能力。系统在客户端提供数据加解密模块和密钥管理模块,在这种设计思路下数据在客户端完成加密后进入数据库,在完成处理分析返回结果的时候在客户端完成解密功能。客户端全程加密的缺陷在于只能支持等值类查询。
• 在第二阶段:将在服务端实现基于密文场景的密文查询和密文检索能力,使得数据库具备更加强大的处理能力。
• 在第三阶段:openGauss将构建基于可信硬件的可信计算能力。在此将基于鲲鹏芯片来构建数据库的可信计算能力。在可信硬件中,完成对数据的解密和计算。数据从可 信 硬 件 进 入 到 真 实 世 界 后,将 再 加 密 成 密 文 返 回 给 客 户。一 个 完 整 的openGauss全程加密方案架构如图2所示。

图2openGauss全程加密方案架构

下面介绍openGauss客户端全程加密方案,也称为客户端列密方案 (Client ColumnEncryption,CCE)。在该方案中,首先应该由用户来指定对哪一列数据进行 加密,通过在指定的属性列后面加上关键字“encrypted”进行标记,如下述语句所示:

CREATE TABLE test_encrypt(creditcard varchar(19) encrypted);

为了有效保证加密数据的安全性并支持数据的密态查询,在内核中选用确定性AES算法。具体来说,其加密算法为:AEAD_AES_256_CBC_HMAC_SHA_256。整个方案中使用双层密钥方案,第一层根密钥用户向密钥管理中心获取,作为根密钥(master key)。第二层为数据加密密钥,也称为工作密钥。工作密钥通过根密钥加密后存放在服务器端。在加密列创建完成后,如果没有工作密钥,则系统会单独为该列创建一个工作密钥。不同的属性列可以通过创建语法指定并共享列加密密钥。

为保证整个系统的安全性,加密工作密钥的加密算法强度应高于使用工作密钥加密数据的强度。在openGauss中,一般使用 RSA-OAEP算法来加密工作密钥,而根密钥仅存放在客户端。密钥层次关系如图3所示。

图3 全程加密功能的密钥管理方案

由于采用确定性加密算法,对于相同的明文,所获取的密文也是相同的。在这种机制下,客户端全程加密可有效地支持等值查询,只需要将对应查询条件中的参数按照对应属性列的加密算法进行加密,并传给服务端即可。一个完整的客户端全程加密方案的查询流程如图4所示。在流程图的客户端部分,需要优先检查相关信息的有效性。

图4客户端加密方案查询流程图

客户端全程加密方案是非常简单易懂的,即通过确定加密机制保障结果的正确性和完整性,但对于日益复杂的查询任务来说,客户端全程加密方案是远远不够的。因为客户端全程加密仅仅能满足那些等值查询任务,如等值条件查询、分组、连接操作等。对于那些更为复杂的数据搜索,如比较查询、范围查询等,则需要更为复杂的密态查询算法或服务端可信硬件方案。

事实上,密文查询算法和检索算法在学术界一直都是热点的研究方向,如 OPE(Order Preserve Encryption,保存加密)/ORE(Order Reveal Encryption,顺序揭示加密)算法、SSE(SymmetricSearchableEncryption,顺序揭示加密)算法等。openGauss将针对排序、范围查询、模糊检索实现纯软件态的密文查询和密文检索。纯软件方案的缺陷在于:由于在密文状态下进行运算,会导致系统整体性能变慢。为了支持密态计算,需要密文在计算完成后解密的结果与明文计算所获得的结果相同。全同态加密是最行之有效的算法,可有效解决数据在密文形态下的加法和乘法计算,而不暴露相关明文信息。但是全同态加密最大的问题在于其性能过于低效,以至于没有一款商业数据库支持该能力,哪怕是部分同态加密能力,如加法同态或者乘法同态。

在第三阶段,openGauss将提供基于可信硬件的密态计算能力。其核心是数据密文形态进入服务端可信硬件中并完成所需要的密文计算。可信硬件将系统内核分为安全世界和非安全世界。数据计算完成后再以密文形态返回给非安全世界,并最终返回给客户端。目前通用的Intel芯片和 ARM 芯片均提供了相类似的功能。在Intel芯片中,该隔离区域被称为 SGX(SoftwareGuardExtensions,软件保护发展)。SGX是一个被物理隔离的区域,数据即使以明文形式存放在该物理区域内,攻击者也无法访问。在 ARM 架构中,与其类似的功能被称为 Trust Zone(受信区域),基于 Trust Zone,人们可以构建可信操作系统(Trusted OS),然后可以开发相对应的可信应用。基于可信计算环境,用户可以解密这些数据进行各类数据库查询操作。当数据离开这些环境后,数据则以密文形态存在,并返回给客户再进行解密。从而起到保护数据隐私的目的。

六 、openGauss云安全技术

传统的数据库对于企业来说,运维是一个重大的难题,因为每个企业需要拥有针对特定数据库专业知识的 DBA 人员,且数据库运维成本很高,对于小企业来说是很难持续维持的。随着云技术的成熟,越来越多的企业将应用和数据迁移上云。不同于传统的IT 业务场景,在云环境下,系统所面临的风险远远多于私有环境。因此,除基本的安全能力外,还需要额外的考虑云环境所面临的风险。

（一） IAM 认证

当用户需要把数据库部署到云上时,用户首先需要通过 Portal界面创建数据库服务。创建成功后,用户则可以下载对应的客户端来进行数据管理操作。为了提升数据库使用过 程 中 的 便 捷 性 和 安 全 性,云 服 务 一 般 会 提 供 IAM(Identityand Access Management,身份与访问管理)服务。

openGauss搬迁上云后所提供的服务称为华为数据仓库服务(Data Warehouse Service,DWS)。当与IAM 进行对接时,需要对应的服务和数据库的 C/S两端协作完成。完整的IAM 认证对接组件流程图如图5所示。

图5 IAM 认证对接组件流程图

在上述流程图中,要求云数据库服务管控侧和openGauss内核侧分别具备如表2的功能。

表2 云数据库服务管控侧和openGauss内核侧功能表 | 序号 | 云数据库服务管控侧 | openGauss内核侧 | | ------------ | ------------ | ------------ | | 1 | 与IAM对接，支持配置具有登录数据库权限的IAM角色信息 | 支持创建支持IAM认证的数据库用户，该用户没有密码，只支持IAM连接认证使用 | | 2 | 支持获取凭证API接口，以ak/sk信息为入参获取token，且返回token前需要校验token中IAM用户名信息 | 服务端新增认证类型，通过用户属性判断使用IAM认证，而非账户口令认证 | | 3 | 获取凭证API接口需支持用户自动创建及群组添加用户功能 |客户端JDBC支持使用凭证API接口获取IAM临时凭据信息，并作为密码参数，传递给服务器 | | 4 |在DB开始认证前，将集群标识码、解析token用的证书传递到数据库服务器上 | 数据库服务侧支持获取region证书对token进行解签名 | | 5 | 将集群标识码信息与token信息进行封装，返回给DB client使用 | 数据库服务根据token(含集群标识码)、policy等信息check解签名后的token是否符合数据库连接请求的要求，进行最终认证 |

事实上,openGauss支持两种方式来创建用于IAM 认证的用户。第一种方式是手动创建,使用语句如下,无须指定该用户的密码。

CREATE USER 'db_iam_user' PASSWORD DISABLE;

第二种方式为自动创建,由 DWS管控侧提供凭证来指定自动创建参数(参数为AutoCreate),如果指定的数据库用户不存在,则会自动创建,需 openGauss内核侧适配,工具支持以下参数:

• 集群标识符:包含数据库的集群名称。

• 数据库用户名:现有或新的数据库用户名称。如果数据库中不存在此用户且AutoCreate为true,则将创建支持IAM 认证的数据库新用户。如果此用户不存在且AutoCreate为false,则请求会失败。

• AutoCreate(可选):如果数据库用户名不存在,则创建新用户。

获取凭证 API接口将通过 DWSService和管控侧工具将 AutoCreate、数据库用户名信息传递到管控域,GuestAgent需要内部连接数据库查询 DWS Service传递的数据库用户名是否存在,如果存在,则直接退出;如果不存在,则判断 AutoCreate是否为true,如果AutoCreate为true,则拼接如下SQL语句发给数据库创建用于IAM 认证的用户:

CREATE ROLE user_name PASSWORD DISABLE；

（二） 安全chroot技术

数据库搬迁上云后需要解决的另外一个问题是目录安全。当攻击者知道数据库的安装目录后,可以破坏数据库的目录结构。chroot(change Root)技术通过改变程序执行时所参考的根目录位置增进系统的安全性来限制使用者能做的事。

chroot是当前云环境必须具备的一种技术,chroot的作用包括:

• 切换运行系统的根目录所在位置,可引导 Linux系统启动和系统急救;
• 增强系统的安全性,限制用户的可见性和权限;
• 建立与原始系统相隔离的系统目录结构,降低失败传播等问题。

openGauss采用基于chroot目录内容最小化方案将集群所有相关文件配置在chroot目录下的/var/chroot文件,在经过chroot之后,系统读取到的目录和文件将不再是旧系统根下的而是新根下,建立一个与原系统隔离的系统目录结构,增加了系的安全性,限制了用户的权利。默认chroot的目录路径为/var/chroot。

（三）防篡改技术

数据库从线下搬迁到云上后,除了解决基本的风险之外,还有一个最为重要的风险,就是恶意 DBA 的运维风险。DBA 用户及恶意运维人员可以登录系统,并恶意修改系统数据。在修改完数据信息后,DBA 用户可以删除对应的审计日志而不被审计管理员发现。这里实际上体现的是第三方可信源“监守自盗”的问题。

当前解决第三方可信源“监守自盗”的最有效方法是去中心化。区块链就是最好的体现,即在牺牲一点效率的情况下,可获得极大的安全性。在区块链系统中,首先没有一本中央大账本了(如第三方机构),所以无法摧毁;其次,无法作弊,除非篡改者能够控制系统内的大多数人对计算机中的账本进行修改,否则系统会参考多数人的意见来决定什么才是真实结果,而自己修改的账本完全没有意义。

区块链的本质即分布式多活数据库。区块链与数据库在很多概念上具有共同之处。下面就一些区块链中的基本概念进行对比。

• 共识算法:在分布式数据库中,最为关键的一点是需要保持数据的一致性。当前普遍采用 PAXOS或 RAFT 算法达成分布式数据库的数据一致性协商。在实施时,数据分片会同时存放在数据库的主从实例上,主实例负责数据的读写操作,从实例进行只读操作。当主实例写入数据时,其事务日志会被实时同步给其他从实例进行回放,以达到主从实例之间数据一致性的目标。 相比于区块链体系,数据库的主实例即为日志生成实例,其每次生成事务日志的功能,与区块链中每次出块时矿工的功能完全等价。但是分布式数据库每次操作时对日志实时广播到实例中,并且在事务提交时进行一致性判断。

• 智能合约:在区块链系统中,智能合约其实是一段存储在一个区块链上的代码,由区块链交易触发,并与区块链状态模式相互影响。这里所说的代码可以是任意的支持语言,如Java、Fortran、C++等。当使用SQL时,它就是写在扩展SQL中的存储过程。

除了上述关键技术点对比分析外,还可以对区块链和数据库在其他技术细节上进行如表3所示的分析。

表3 区块链和数据库技术分析 | 分析点 | 数据库|区块链| |--|--|--| | 参与者 | 单方参与 | 多方参与 | | 管理 | Centralized | Decentralized | | 最新记录 | Table Value | World State | | 历史记录| Log | Chain| | 查询 | Table Value | World State + Chain | | 数字签名 | No | Yes | | 容错机制 | CFT（Crash Fault Tolerance） | BFT（Byzantine Fault Tolerance） | | 用户自定义逻辑 |Stored Procedure/User Define Function | Smart Contract |

事实上,通过上述分析可以看到,数据库和区块链具有很多相似之处,因此可以在数据库中融入区块链的思想,将区块链天生具备的防篡改能力集成到数据库中。

openGauss数据将支持两种形态的防篡改系统:中心化部署和去中心化部署方式。中心化部署和去中心化部署方案的主要区别在于:

• 中心化部署情况下,对外提供服务的实例即为主实例。
• 不需要通过拜占庭等类似的共识算法进行共识和校验。

因此,在中心化部署下,除主实例外的剩余实例主要为日志备份实例,或提供对外的查询服务。在去中心化部署下,交易连接的任务实例即为主实例(整个系统是一个多主的关系),然后在本地交易完成后与其他实例进行背书共识和验证。当复制实例验证成功后方可提交当前事务。

由于结合了数据库的优点和区块链的优点,openGauss防篡改系统有如下优势:系统内数据不可更改、记录历史可追溯、数据加密可验证、系统高可靠、整体易用性高。

七 、openGauss智能安全机制

随着攻防理念的发展,系统中的安全特性变得越来越复杂。虽然更加系统化、精细化的安全技术可以有效地防御和解决环境中存在的各类风险,但是对 DBA 和运维人员都提出了较高的要求。这部分工作无论是由企业来做,还是由云服务提供商来完成,都是一个较大的挑战。另一方面,不同国家和地区对安全的诉求和定义也是不一样的,服务提供商在选择对应的安全策略时很容易遗忘彼此之间的差异。因此需要系统变得更加智能,变得可以自己管理这些安全机制,这称为自治安全机制或智能安全机制。

事实上,越来越多的数据库服务商正在聚焦于通过使用 AI技术来提升系统的安全性,这不仅包括通常的智能数据安全,还包括系统自治管理安全。在众多的智能安全机制中,首要的是敏感数据的发现。对于数据库而言,最重要的是保护用户数据,而数据中最为重要的是敏感数据。随着数据格式的多样化,用户实际的隐私数据隐藏在了海量的数据潮中,更为困难的一点是,不同行业、不同国家的法律法规所定义的敏感数据是不一样的。因此,不仅要实现敏感数据发现功能,还要基于 AI来实现该功能。

除了发现敏感数据外,另外一个重要的需要是利用 AI功能的特性使 AI防 SQL注入攻击。SQL注入通过动态拼接 SQL 注入传入Web服务端或者数据库服务端。其呈现的方式多种多样。与之类似的还包括 AI异常行为发现和 AI日志分析。AI系统通过对异常行为和 AI日志的分析,可以快速了解到系统在遭遇什么样的风险,以及这些风险行为的特征是什么,并会提示存在的风险,然后由系统自己根据当前存在的风险进行安全策略制定。一个完整的AI自反馈机制如图6所示。这也是openGauss未来重点的发力方向。

图6 AI自反馈机制全景图

在整个 AI自反馈机制中:

• 数据库仍然可以接收来自不同行为的连接,包括终端手机数据、数据库用户、各类应用,也可能涵盖攻击者。所有的这些访问行为均记录在数据库内核日志中。

• 除了对外的这些连接行为外,数据库迁移上云后还会有一个特殊类的连接用户,如 DBA 或集群维护用户,这些用户存在第三方信任问题。

Gauss松鼠会是汇集数据库爱好者和关注者的大本营， 大家共同学习、探索、分享数据库前沿知识和技术， 互助解决问题，共建数据库技术交流圈。