随着数字化技术的飞速发展,数字、连接、信号、人工智能充斥着人们工作、生活的各个领域。这些数字化信息被快速转换成数据并存放在各式各样的数据库系统中,而且通过进一步的数据管理与分析产生商业价值。这些有价值的数据或被存放在企业相对封闭的私有网络内,或被存放在相对开放的公有云环境下,又或是集成在智能系统中。人们在享受由数字化发展所带来的便捷生活的同时,也可能面临着无处不在的隐私泄露、信息篡改、数据丢失等安全风险。
openGauss作为新一代自治安全数据库,为有效保障用户隐私数据、防止信息泄露,构建了由内而外的数据库安全保护措施。本篇将介绍和分析openGauss所采用的安全技术以及在不同应用场景下所采取的不同的安全实施策略。
一、openGauss安全机制概览作为独立的组件,传统数据库系统构建于特定的操作系统平台上,以对外提供数据服务或通过对接可视化管理界面对外提供数据管理服务,整个系统部署在一个封闭的网络环境中。系统中的数据存放于物理存储介质上,存储介质可以为机械磁盘,也可以为SSD(固态硬盘)。硬件的稳定性和可靠性作为重要的一个环节,保障了数据整体的存储安全。
图1openGauss安全机制体系openGauss安全机制充分考虑了数据库可能的接入方,包括DBA、用户、应用程序以及通过攻击途径连接数据库的攻击者等。
openGauss提供了用户访问所需的客户端工具GaussSQL(缩写为gsql),同时支持JDBC/ODBC等通用客户端工具。整个openGauss系统通过认证模块来限制用户对数据库的访问,通过口令认证、证书认证等机制来保障认证过程中的安全,同时可以通过黑白名单限制访问IP。
用户对对象的访问操作本质上是对数据的管理,包括增加、删除、修改、查询等各类操作。数据在存储、传输、处理、显示等阶段都会面临信息泄露的风险。openGauss提供了数据加密、数据脱敏以及加密数据导入导出等机制保障数据的隐私安全。
localDATABASEUSERMETHOD[OPTIONS]
hostDATABASEUSERADDRESSMETHOD[OPTIONS]
hostsslDATABASEUSERADDRESSMETHOD[OPTIONS]
hostnosslDATABASEUSERADDRESSMETHOD[OPTIONS一个HBA文件中可以包含多条记录,一条记录不能跨行存在,每条记录内部是由若干空格、/和制表符分隔的字段组成。在实际认证过程中,身份认证模块需要依据HBA文件中记录的内容对每个连接请求进行检查,因此记录的顺序是非常关键的。
每一条记录中各个字段的具体含义如下所述:
gs_gucset-Zcoordinator-Nall-Iall-h“hostdatabase1jack122.10.10.30/32sha256”这条命令将在所有的CN侧对应的HBA文件中添加对应规则。
（二）服务端认证方法openGauss安全认证方法在HBA文件中由数据库运维人员配置,支持trust认证、口令认证和cert认证。
2.口令认证openGauss目前主要支持sha256加密口令认证。由于整个身份认证过程中,不需要还原明文口令,因此采用PBKDF2单向加密算法。其中Hash函数使用sha256算法,盐值salt则通过安全随机数生成。算法中涉及的迭代次数可由用户自己视不同的场景决定,需考虑安全和性能间的一个平衡。
为了保留对历史版本的兼容性,在某些兼容性场景下,openGauss还支持MD5算法对口令进行加密,但默认不推荐。
3.cert认证openGauss支持使用SSL安全连接通道(在安全认证通道详细介绍)。cert认证表示使用SSL客户端进行认证,不需要提供用户密码。在该认证模式下,客户端和服务端数据经过加密处理。在连接通道建立后,服务端会发送主密钥信息给客户端以响应客户端的握手信息,这个主密钥将是服务端识别客户端的重要依据。值得注意的是,该认证方式只支持hostssl类型的规则。
在文中,提到openGauss所支持的METHOD字段选项包括trust、reject、sha256、cert及gss。除去上述介绍的三种认证方法外,reject选项表示对于当前认证规则无条件拒绝,一般用于“过滤”某些特定的主机。gss表示使用基于gssapi的kerberos认证,该认证方法依赖kerberosserver组件,一般用于支持openGauss集群内部通信认证和外部客户端连接认证,外部客户端仅支持gsql(openGauss提供的在命令行下运行的数据库连接工具。)或JDBC连接时使用。
（三）安全认证通道openGauss支持SSL标准协议(TLS1.2)。SSL协议是安全性更高的协议标准,它们加入了数字签名和数字证书来实现客户端和服务器的双向身份验证,保证了通信双方更加安全的数据传输。
1.配置客户端参数客户端参数配置依据实际场景分为单向认证配置和双向认证配置,整个配置信息存储在客户端工具所在的环境配置文件中(如.bashrc文件)。单向认证需要配置如下参数:
exportPGSSLMODE=“verify-ca”
exportPGSSLROOTCERT="/home/ommdbadmin/cacert.pem"双向认证需配置如下参数：
exportPGSSLCERT="/home/ommdbadmin/client.crt"
exportPGSSLKEY="/home/ommdbadmin/client.key"
exportPGSSLROOTCERT="/home/ommdbadmin/cacert.pem"2.修改客户端密钥的权限客户端根证书、密钥、证书以及密钥密码加密文件的权限,需保证为600。如果权限不满足要求,则客户端无法以SSL连接到集群。配置如下:
chmod600cacert.pem
chmod600client.key
chmod600client.crt
chmod600client.key.cipher
chmod600client.key.ran在实际应用中,应结合场景进行配置。从安全性考虑,建议使用双向认证方式,此时客户端的PGSSLMODE变量建议设置为verify-ca。但如果本身数据库处在一个安全的环境下,且业务场景属于高并发、低时延业务则可使用单向认证模式。
（四）RFC5802认证协议在实际应用过程中,仅仅选定认证方法是不够的,还需要有一套完整的认证机制。这个机制要很好地解决客户端和服务端认证交互过程中的通信风险,还要解决客户端接收到加密口令后的验证问题。
客户端知道用户名username和密码password,客户端发送username给服务端,服务端检索相应的认证信息,例如salt、StoredKey、ServerKey和迭代次数iteration-count(注意,服务端可能对于所有的用户都是用相同的迭代次数)。然后,服务端发送盐值salt和迭代次数给客户端。客户端需要进行一些计算,给服务端发送ClientProof认证信息,服务端通过ClientProof对客户端进行认证,并发送ServerSignature给客户端。客户端通过ServerSignature对服务端进行认证。具体密钥计算公式如下:SaltedPassword:=Hi(password,salt,i)其中，Hi()本质上是PBKDF2。
ClientKey:=HMAC(SaltedPassword,“ClientKey”)
StoredKey:=Hash(ClientKey)
AuthMessage:=client-first-message-bare+“,”+
server-first-message+“,”+
client-final-message-without-proof
图3密钥衍生过程在这里,服务端存的是StoredKey和ServerKey。
图4服务端、客户端认证标准流程客户端发送username和随机生成的挑战值C-Nonce给服务端。服务端返回盐值salt、迭代次数以及随机生成的挑战值Nonce给客户端。Nonce是将从客户端收到的C-Nonce和随机生成字符串组合形成的新挑战值。客户端发送认证响应。响应信息包含客户端认证信息ClientProof和挑战值Nonce。ClientProof证明客户端拥有ClientKey,但是不通过网络的方式发送。在收到信息后,首先需要校验传来的挑战值Nonce,校验通过后,计算ClientProof。客户端利用盐值salt和迭代次数,从password计算得到SaltedPassword,然后通过密钥计算公式计算得到ClientKey、StoredKey和ServerKey。计算AuthMessage、ClientSignature。通过将客户端首次发送的信息,服务端首次发送的信息以及客户端的响应信息(不包含认证信息)连接起来得到AuthMessage。代码如下:AuthMessage:=client-first-message-bare+“,”+server-first-message+“,”+client-final-message-without-proof
ClientSignature:=HMAC(StoredKey,AuthMessage客户端通过将ClientKey和ClientSignature进行异或得到ClientProof：
ClientProof:=ClientKeyXORClientSignature将计算得到的ClientProof和第2步接收的随机字符串Nonce发送给服务端进行认证。
服务端认证Nonce和ClientProof,并且发送自己的认证信息ServerSignature。首先需要校验Nonce,校验通过后,计算ServerSignature。使用其保存的StoredKey和AuthMessage通过HMAC(HashMessageAuthenticationCode,哈希消息认证码)算法进行计算,然后与客户端传来的ClientProof进行异或,恢复ClientKey,再对ClientKey进行哈希计算,得到的结果与服务端保存的StoredKey进行比较。如果相等,则服务端对客户端的认证通过。ClientSignature:=HMAC(StoredKey,AuthMessage)
基于角色管理模型,用户可具备对对象的访问操作权限,并基于此完成数据管理。而这些用户所具备的权限是会经常发生变化的,为了有效地防止诸如权限提升、利用权限漏洞进行恶意操作等行为,必须进行权限的合理管控,即对象权限管理。更重要的是,需要在对象被访问操作时对当前用户的合法权限进行有效性检查,即对象权限检查。
（一）角色管理模型在openGauss内核中，用户和角色是基本相同的两个对象，通过CREATEROLE和CREATEUSER分别来创建角色和用户，两者语法基本相同。以CREATEROLE的语法为例进行说明，其语法为（通过“\hCREATEROLE”可以在系统中查询）：
CREATEROLErole_name[[WITH]option[…]][ENCRYPTED|UNENCRYPTED]{PASSWORD|IDENTIFIEDBY}{‘password’|DISABLE};其中设置子句option的选项可以是：
{SYSADMIN|NOSYSADMIN}
|{AUDITADMIN|NOAUDITADMIN}|{CREATEDB|NOCREATEDB}
|{USEFT|NOUSEFT}|{CREATEROLE|NOCREATEROLE}
|{INHERIT|NOINHERIT}|{LOGIN|NOLOGIN}
|{REPLICATION|NOREPLICATION}|{INDEPENDENT|NOINDEPENDENT}
|{VCADMIN|NOVCADMIN}|CONNECTIONLIMITconnlimit
|VALIDBEGIN‘timestamp’|VALIDUNTIL‘timestamp’
|RESOURCEPOOL‘respool’|USERGROUP‘groupuser’
|PERMSPACE‘spacelimit’|NODEGROUPlogic_cluster_name
|INROLErole_name[,…]|INGROUProle_name[,…]
|ROLErole_name[,…]|ADMINrole_name[,…]
|USERrole_name[,…]|SYSIDuid
|DEFAULTTABLESPACEtablespace_name|PROFILEDEFAULT
|PROFILEprofile_name|PGUSER
该命令仅可由具备CREATEROLE或者超级管理员权限的用户执行。对语法中涉及的关键参数做如下说明:
(1)ENCRYPTED|UNENCRYPTED用于控制密码是否以密文形态存放在系统表中。目前该参数无实际作用,因为密码强制以密文形式存储。
(2)SYSADMIN|NOSYSADMIN决定一个新创建的角色是否为“系统管理员”,默认为NOSYSADMIN。
与该参数具有相类似概念的还包括AUDITADMIN|NOAUDITADMIN、CREATEDB|NOCREATEDB、CREATEROLE|NOCREATEROLE,分别表示新创建的角色是否具有审计管理员权限,是否具有创建数据库权限,以及是否具有创建新角色的权限。
(3)USEFT|NOUSEFT决定一个新角色是否能操作外表,包括新建外表、删除外表、修改外表和读写外表,默认为NOUSEFT。
(4)INDEPENDENT|NOINDEPENDENT定义私有、独立的角色。具有INDEPENDENT属性的角色,管理员对其进行的控制、访问的权限被分离,具体规则如下:
(6)PERMSPACE设置用户使用空间的大小。
管理员通过GRANT语法将角色赋给相应的用户可使该用户拥有角色的权限。而在实际场景中,一个用户可以从属于不同的角色,从而拥有不同角色的权限。同样角色之间的权限也可以进行相互传递。用户在继承来自于不同角色的权限时,应尽量避免权限冲突的场景,如某一用户同时具有角色A不能访问表T的权限和角色B访问表T的权限。
为了更清晰地描述权限管理模型,需要说明openGauss系统中的权限分为两种类型:系统权限和对象权限。系统权限描述了用户使用数据库的权限(如访问数据库、创建数据库、创建用户等)。对象权限,顾名思义,描述了用户操作数据库对象的权限(如增加、删除、修改、查表对象、执行函数、使用表空间等)。
角色所有的权限都记录在系统表pg_authid里面,通过对应的字段进行描述。如pg_authid表中对应的createrole字段用于标记当前角色是否拥有创建角色的权利。
角色的这些系统属性实际上定义了用户使用数据库权限的大小。例如,所有具有CREATEROLE权限的角色都可以创建新的角色或用户。
在整个数据库系统的安装部署时会创建一个初始化用户。该初始化用户拥有最高权限,也称为系统的超级用户,这也是pg_authid表中唯一一个superuser字段为true(真)的角色。
超级用户可以按照实际的业务诉求创建普通用户,也可以通过其所创建的管理员创建新的普通用户,再进行权限的管理。超级用户可以随时进行权限的赋予和撤回,也可以直接参与到实际的数据管理业务中。在单用户场景的作业管理模式中,使用超级用户使权限和数据管理变得非常的高效。
（二）三权分立模型如上文所述,openGauss安装完成后会得到一个具有最高权限的超级用户。数据库超级用户的高权限意味着该用户可以做任何系统管理操作和数据管理操作,甚至可以修改数据库对象,包括接下来将要介绍的审计日志信息。对于企业管理来说,手握超级用户权限的管理人员可以在无人知晓的情况下改变数据行为,这带来的后果是不可想象的。
为了很好地解决权限高度集中的问题,在openGauss系统中引入三权分立角色模型,如图5所示。三权分立角色模型最关键的三个角色为安全管理员、系统管理员和审计管理员。其中,安全管理员用于创建数据管理用户;系统管理员对创建的用户进行赋权;审计管理员则审计安全管理员、系统管理员、普通用户实际的操作行为。
事实上,产品使用过程中的安全是技术本身与组织管理双重保障的结果,在系统实现三权分立模型后,需要有三个对应的产品自然人分别握有对应的账户信息,以达到真正权限分离的目的。
四、openGauss审计与追踪openGauss在部署完成后,实际上会有多个用户参与数据管理。除了管理员用户外,更多的是创建的普通用户直接进行数据管理。用户的多样性会导致数据库存在一些不可预期的风险。如何快速发现和追溯到这些异常的行为,则需要依赖审计记录机制和审计追踪机制。
（一）审计记录机制审计记录的关键在于:
定义何种数据库操作行为需要进行日志记录。记录的事件以何种形式展现和存储。只有有效地记录了所关心的行为信息,才能依据这些行为进行问题审计和追溯,实现对系统的一个有效监督。
正如在“三权分立模型”中描述的,进行权限分离后,就出现了审计管理员(当然也可以使用普通角色管理模型中的系统管理员来担当)。审计管理员最重要的作用在于对管理员以及普通用户所有关心的行为进行记录和审计追溯。审计首先要定义审计哪些数据库行为,其次需要定义审计内容记录在什么文件中以及何种目录下,最后需要定义清楚应提供何种接口供审计管理员进行审计查询。
不同于总体开关,每一个对应的子审计项都支持动态加载,在数据库运行期间修改审计开关的值,不需要重启数据库即可支持。审计的子项目包括如下部分:
audit_database_process:数据库启动、停止、恢复和切换审计。
audit_user_locked:用户锁定和解锁审计。
audit_user_violation:用户访问越权审计。
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_space_limit:整数类型,定义允许审计日志占用的磁盘空间总量,默认值为1GB,在实际配置中需要结合环境进行总体考虑。
audit_file_remain_threshold:整数类型,定义审计目录audit_directory下可以存储的审计文件个数。默认值为1048576。
audit_rotation_size:整数类型,定义单个审计日志文件的最大大小,当审计日志文件大小超过此参数值时,新创建一个审计文件。
通过上述的这些配置参数,系统管理员用户可以在查询任务发生后找到对应的审计日志,并进行有效归档。审计日志文件也会按照参数指定的规则进行更新、轮换等。
（二）审计追踪机制openGauss将审计所产生的文件独立存放在审计文件夹中,按照产生的先后顺序进行标记管理,并以特定的格式进行存储(默认为二进制格式文件)。当审计管理员需要进行审计查询时,通过执行函数pg_query_audit()即可,其具体的语句如下:
（三）统一审计传统审计依据开关定义了不同的审计组合行为。事实上,这种无区分对待的审计虽然记录了所有想要审计的行为,但是对于通过审计日志发现问题则显得不那么容易,且管理员无法为特定的用户定义特定的行为,反而造成了系统处理的负担。因此需要为审计添加更精细化管理的能力。
统一审计的目的在于通过一系列有效的规则在数据库内部有选择性执行有效的审计,从而简化管理,提高数据库生成的审计数据的安全性。本节所述的技术目前处于研发阶段,对应产品尚未向客户发布。
openGauss提供了一套完整的统一审计策略机制,依据不同任务的诉求对用户行为进行定制化审计管理。更进一步,openGauss的统一审计不仅可以依据用户、依据表进行审计行为定义,同时还可以扩展至通过IP地址、App的名称来过滤和限制需要审计的内容。实际的语句如下:
CREATEAUDIT_POLICYpolicy_name[(privilege_audit_clause)|(access_audit_clause)[filter_clauseFILTER_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对象。
一个有效的统一审计策略可参见如下:
CREATEAUDIT_POLICYadmin_policyPRIVILEGESCREATE,ALTER,DROPFILTERONIP(local),ROLES(dev);该语句表示创建针对CREATE/ALTER/DROP操作的审计策略,审计策略只对dev用户在本地(local)执行CREATE/ALTER/DROP行为时生效。
五、openGauss数据安全技术数据库最重要的作用是存储数据和处理分析数据。数据是整个数据库系统中最关键的资产。因此,在保护系统不受侵害的基础上最为重要的任务就是保护数据的安全。常见的数据安全技术包括数据加密、数据脱敏(DataMasking)、透明数据加密(TransparentDataEncryption,TDE)和全程加密(AlwaysEncryption)技术。这里囊括了数据的动态流程和静态存储行为。
（一）数据加密算法数据加密和解密是防止数据隐私泄露最为常见也最为有效的手段之一。数据在经过加密后以密文形式存放在指定的目录下。加密的意义在于,通过一系列复杂的迭代计算,将原本的明文转换为随机的没有任何具体含义的字符串,即密文。当所使用的加密算法足够安全时,攻击者在有限的计算资源下将很难根据密文获取到明文信息。
常见的加密算法可分为对称加密算法和非对称加密算法。其中最为著名的非对称加密算法为RSA算法,其密钥长度须达到3072比特(b)才可以保证其安全性,即强安全。常见的对称加密算法为AES算法,如AES128和AES256。相比于非对称加密算法,对称加密算法运算速度快,密文长度增长少,安全性容易证明,所需要的密钥长度短,但也存在密钥分发困难和不可用于数字签名等缺点。除了上述介绍的加密算法外,还有很多其他强安全算法,在此不一一介绍。下面重点介绍openGauss中所支持的数据加密能力。
首先openGauss在内核定义了数据加密和解密的函数,并对外提供了数据加密和解密的接口,函数接口为:
gs_encrypt_aes128(text,initial_value)；其中,text为需要加密的明文数据;initial_value为生成密钥时需要的初始化向量。该函数可以被灵活地应用在SQL语句的各个地方。例如,通过使用INSERT语句插入数据或者查询数据时均可以绑定该函数对数据进行加密处理,具体如下:
SELECT*FROMgs_encrypt_aes128(tbl.col,‘1234’);通过该查询,用户可以直接返回表tbl中的col列的密文信息。
与加密函数相对应的是解密函数,其接口格式定义为:
gs_decrypt_aes128(cypertext,initial_value);其中,cypertext为加密之后的密文;initial_value需要为与加密时所采用的相同的值才可以,否则使用该函数也无法得到正确明文。
除了基本的数据加密和解密接口外,openGauss还在多个特性功能里提供了数据加密和解密功能。其中第一个提供加密和解密功能的特性是数据导入导出;第二个提供加密和解密功能的特性是数据库备份恢复。
数据脱敏是解决此类问题的最有效方法之一,通过对敏感数据信息的部分信息或全量信息进行特殊处理可以有效掩盖敏感数据信息的真实部分,从而达到保护数据隐私信息的目的。数据脱敏按照脱敏呈现的时机可以分为数据动态脱敏和数据静态脱敏,其中前者在数据运行时对数据进行特殊处理,后者在数据存储的时候进行特殊处理以防止攻击者通过提取数据文件来直接获取敏感信息。本小节重点介绍数据动态脱敏技术。
数据动态脱敏的安全意义在于:
用户在实际操作的时候无须用真实数据,只需要使用一个变化后的数据,可有效规避数据信息的直接暴露。在不同的国家或地区的法律法规中,如GDPR(通用数据保护条例),约定不同的用户在管理数据的时候具有不同的访问对象权限。对于表中的同一列数据信息,不同的用户应具有不同的用途。数据动态脱敏功能在数据库内核实际上表现为数据处理函数。通过函数处理使得数据库中的数据在返回给实际查询用户时数据值发生变更,如用户所有的年龄信息值在返回给客户端时均显示为“0”;又或是字符串数据中的部分字节位变更为其他字符,如信用卡卡号“1234567809101112”在返回给客户端时显示为“XXXXXXXXXXXX1112”。
在openGauss系统中,数据动态脱敏策略定义如下:
CREATEMASKING_POLICYpolicy_name((masking_clause)[filter_clause][ENABLE|DISABLE]);其中的具体参数说明如下:
masking_clause定义如下:MASKING_FUNCTION(PARAMETERS)ON(SCOPE(FQDN))|(LABEL(resource_label_name))[,…]*;定义了针对不同数据集合对象所采用的脱敏函数。这里,LABEL为数据库安全标签。数据库安全标签实际上定义了一组数据内部的表对象或表中的部分列,用于标记相应数据脱敏策略的范围。
filter_clause定义如下:FILTERONFILTER_TYPE(filter_value[,…])[,…];定义了数据动态脱敏策略所支持的过滤条件。一个实际的数据动态脱敏案例如下:
CREATEMASKING_POLICYmy_masking_policycreditcardmaskingONLABEL(mask_credcard),maskallONLABEL(mask_all)FILTERONIP(local),ROLES(dev);其中,my_masking_policy为定义的数据动态脱敏策略名字;creditcardmasking以及mask_all为定义的masking处理函数,分别用于处理从属于mask_credcard对象集合和mask_all对象集合;mask_credcard和mask_all代表不同的Label对象,这些Label对象名称将作为唯一标识记录在系统表中。FILTER表示当前动态脱敏策略所支持的连接源,连接源指的是实际数据库管理员使用何种用户,从何IP源位置发起,使用何种App应用来访问当前的数据库。通过使用FILTER可以有效定义系统的访问源信息,并规避不应该访问当前系统的行为。
（三）透明加密技术当数据在静态存储状态时,除了使用常见的静态脱敏技术进行数据隐私保护外,另一种行之有效的方法是TDE(透明加密)。事实上,静态脱敏在实际应用过程中是存在一定限制的。用户并不能对所有的数据类型都施加静态脱敏措施。
TDE从加密策略出发,即使用户数据被导出,也可以有效解决数据信息泄露风险。数据透明加密的初衷是为了防止第三方人员绕过数据库认证机制,直接读取数据文件中的数据(数据文件中的数据虽然是二进制数据,但是仍然是明文存放)。所以对数据库的数据文件进行加密后,必须在数据库启动后,用户通过正常途径连接数据库,才可以读取解密后的数据,达到数据保护的目的。
openGauss实施透明加密策略,首先是需要确定一个数据库加密密钥(DatabaseEncryptionKey,DEK),该DEK由系统密钥管理系统(KeyManagementService,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参数,获取到明文。
（四）全程加密技术无论是当前通用的数据脱敏方案,还是数据透明加密方案,其所解决的都是部分状态或部分流程下的数据隐私安全。数据库攻击者可通过其他不同的攻击技术手段在数据以明文存在或处于内存中时抓取数据流信息,从而达到获取隐私数据的目的。如果数据在整个生命周期中都能够处于加密的形态,且密钥掌握在用户自己手中,则数据库用户可有效地防止数据隐私的泄露。
openGauss分三个阶段来实现完整的数据全程加密功能。
CREATETABLEtest_encrypt(creditcardvarchar(19)encrypted);为了有效保证加密数据的安全性并支持数据的密态查询,在内核中选用确定性AES算法。具体来说,其加密算法为:AEAD_AES_256_CBC_HMAC_SHA_256。整个方案中使用双层密钥方案,第一层根密钥用户向密钥管理中心获取,作为根密钥(masterkey)。第二层为数据加密密钥,也称为工作密钥。工作密钥通过根密钥加密后存放在服务器端。在加密列创建完成后,如果没有工作密钥,则系统会单独为该列创建一个工作密钥。不同的属性列可以通过创建语法指定并共享列加密密钥。
CREATEUSER‘db_iam_user’PASSWORDDISABLE;第二种方式为自动创建,由DWS管控侧提供凭证来指定自动创建参数(参数为AutoCreate),如果指定的数据库用户不存在,则会自动创建,需openGauss内核侧适配,工具支持以下参数:
集群标识符:包含数据库的集群名称。数据库用户名:现有或新的数据库用户名称。如果数据库中不存在此用户且AutoCreate为true,则将创建支持IAM认证的数据库新用户。如果此用户不存在且AutoCreate为false,则请求会失败。AutoCreate(可选):如果数据库用户名不存在,则创建新用户。获取凭证API接口将通过DWSService和管控侧工具将AutoCreate、数据库用户名信息传递到管控域,GuestAgent需要内部连接数据库查询DWSService传递的数据库用户名是否存在,如果存在,则直接退出;如果不存在,则判断AutoCreate是否为true,如果AutoCreate为true,则拼接如下SQL语句发给数据库创建用于IAM认证的用户:
CREATEROLEuser_namePASSWORDDISABLE；（二）安全chroot技术数据库搬迁上云后需要解决的另外一个问题是目录安全。当攻击者知道数据库的安装目录后,可以破坏数据库的目录结构。chroot(changeRoot)技术通过改变程序执行时所参考的根目录位置增进系统的安全性来限制使用者能做的事。
chroot是当前云环境必须具备的一种技术,chroot的作用包括:
当前解决第三方可信源“监守自盗”的最有效方法是去中心化。区块链就是最好的体现,即在牺牲一点效率的情况下,可获得极大的安全性。在区块链系统中,首先没有一本中央大账本了(如第三方机构),所以无法摧毁;其次,无法作弊,除非篡改者能够控制系统内的大多数人对计算机中的账本进行修改,否则系统会参考多数人的意见来决定什么才是真实结果,而自己修改的账本完全没有意义。
区块链的本质即分布式多活数据库。区块链与数据库在很多概念上具有共同之处。下面就一些区块链中的基本概念进行对比。
共识算法:在分布式数据库中,最为关键的一点是需要保持数据的一致性。当前普遍采用PAXOS或RAFT算法达成分布式数据库的数据一致性协商。在实施时,数据分片会同时存放在数据库的主从实例上,主实例负责数据的读写操作,从实例进行只读操作。当主实例写入数据时,其事务日志会被实时同步给其他从实例进行回放,以达到主从实例之间数据一致性的目标。相比于区块链体系,数据库的主实例即为日志生成实例,其每次生成事务日志的功能,与区块链中每次出块时矿工的功能完全等价。但是分布式数据库每次操作时对日志实时广播到实例中,并且在事务提交时进行一致性判断。
智能合约:在区块链系统中,智能合约其实是一段存储在一个区块链上的代码,由区块链交易触发,并与区块链状态模式相互影响。这里所说的代码可以是任意的支持语言,如Java、Fortran、C++等。当使用SQL时,它就是写在扩展SQL中的存储过程。
openGauss数据将支持两种形态的防篡改系统:中心化部署和去中心化部署方式。中心化部署和去中心化部署方案的主要区别在于:
中心化部署情况下,对外提供服务的实例即为主实例。不需要通过拜占庭等类似的共识算法进行共识和校验。因此,在中心化部署下,除主实例外的剩余实例主要为日志备份实例,或提供对外的查询服务。在去中心化部署下,交易连接的任务实例即为主实例(整个系统是一个多主的关系),然后在本地交易完成后与其他实例进行背书共识和验证。当复制实例验证成功后方可提交当前事务。
由于结合了数据库的优点和区块链的优点,openGauss防篡改系统有如下优势:系统内数据不可更改、记录历史可追溯、数据加密可验证、系统高可靠、整体易用性高。
七、openGauss智能安全机制随着攻防理念的发展,系统中的安全特性变得越来越复杂。虽然更加系统化、精细化的安全技术可以有效地防御和解决环境中存在的各类风险,但是对DBA和运维人员都提出了较高的要求。这部分工作无论是由企业来做,还是由云服务提供商来完成,都是一个较大的挑战。另一方面,不同国家和地区对安全的诉求和定义也是不一样的,服务提供商在选择对应的安全策略时很容易遗忘彼此之间的差异。因此需要系统变得更加智能,变得可以自己管理这些安全机制,这称为自治安全机制或智能安全机制。
事实上,越来越多的数据库服务商正在聚焦于通过使用AI技术来提升系统的安全性,这不仅包括通常的智能数据安全,还包括系统自治管理安全。在众多的智能安全机制中,首要的是敏感数据的发现。对于数据库而言,最重要的是保护用户数据,而数据中最为重要的是敏感数据。随着数据格式的多样化,用户实际的隐私数据隐藏在了海量的数据潮中,更为困难的一点是,不同行业、不同国家的法律法规所定义的敏感数据是不一样的。因此,不仅要实现敏感数据发现功能,还要基于AI来实现该功能。
数据库仍然可以接收来自不同行为的连接,包括终端手机数据、数据库用户、各类应用,也可能涵盖攻击者。所有的这些访问行为均记录在数据库内核日志中。除了对外的这些连接行为外,数据库迁移上云后还会有一个特殊类的连接用户,如DBA或集群维护用户,这些用户存在第三方信任问题。在数据库内部,服务端会记录大量数据库内部发生的动作,并产生行为日志和审计日志。通过日志分析归类,结合人工智能模块,系统可以获取所有这些行为的特征,并提取异常行为。依据异常行为系统就可以自行决定采取何种防范策略,并加以实施应用。在整个系统中,还需要注意存储的安全,包括本地盘和云环境对象存储服务的安全。这也是整个智能系统的重要一环。八、小结数据库安全技术本质上是围绕数据库中最重要的资产——数据所展开的。当人们在设计数据库安全技术特征时,通常需要知道在什么样的场景下面临着什么样的风险,这些风险是通过什么攻击手段达成的,达成的成本有多高。只有弄清楚这些问题,数据库设计人员才能更好地结合自己的应用场景来规划安全特性。
openGauss构建了一套较为完整的数据库安全防御体系。这套安全防御体系从访问源出发,到网络、服务器,再到数据存储,涵盖了数据的整个生命周期。我们定义了不同的机制来保证系统访问安全、用户管理安全、对象访问安全及对象存储安全,还在openGauss系统中定义了数据防篡改系统,用于解决云环境下第三方可信问题。这些构成了openGauss的安全能力。