等保2。0数据库测评MariDB数据库

　　一、MariDB介绍
　　MariaDB数据库管理系统是MySQL的一个分支， 是同一MySQL版本的二进制替代品， 主要由开源社区在维护，采用GPL授权许可 MariaDB的目的是完全兼容MySQL。
　　本次安装环境为Windows10专业版操作系统，数据库版本为10.8.3，单机部署过程比较简单就不在此进行讲解。本文针对MariDB等保测评进行实际操作，不妥之处还恳请留言指正，共同学习。
　　二、等保测评
　　身份鉴别   a) 应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换；1）执行命令：＂mysql＂检查数据库是否对用户进行身份鉴别:
　　如果直接进入数据库则未对用户进行身份鉴别，判不符合；
　　如果无法登录则表明对用户进行了身份鉴别，则需要根据口令策略再进行判定。
　　2）在数据库＂my.ini＂配置文件修改口令策略参数。
　　3)执行命令：＂show variables like ＂validate%＂;＂查看口令策略是否合理：
　　备注：如果数据库未安装密码策略插件请执行命令：＂INSTALL SONAME ＂simple_password_check＂;＂进行安装并配置相关策略。
　　4）执行命令：＂CREATE USER ＂test1＂@＂localhost＂ IDENTIFIED BY ‘123456’;若不存在空口令、弱口令的现象：
　　b) 应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施；
　　show variables like ＂%timeout%＂;
　　c) 当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听；
　　1)是否采用加密等安全方式对系统进行远程管理是否用户都是localhost，全为localhost则为本地管理，可判定为不适用。
　　2）远程管理根据实际管理情况进行判定（如了解数据库管理工具采用什么措施防止鉴别信息在传输过程中被窃听） ，若存在远程管理，执行命令：＂show variables like ＂%have_ssl%＂;＂查看是否启用ssl协议，并验证协议是否生效：
　　d) 应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。
　　访谈管理员并进行验证，是否采用双因子身份鉴别技术，鉴别技术是什么 。实际实现双因素认证比较困难，一般情况判定为不符合。
　　访问控制a) 应对登录的用户分配账户和权限；
　　1)执行命令：＂select user,host FROM mysql.user;＂查看用户，并结果结合访谈管理员是否存在网络管理员，安全管理员，系统管理员、审计管理员等多个账户，为各个管理用户分配对应的权限：
　　2）执行命令：＂select * from mysql.user where user=＂XXX＂;或＂select * from mysql.db;＂检查用户权限：
　　b) 应重命名或删除默认账户，修改默认账户的默认口令
　　检查root账户是否重命名，检查其他账户的是否属于默认账户（数据库一盘情况不存在默认口令）。  c) 应及时删除或停用多余的、过期的账户，避免共享账户的存在
　　1）询问管理员数据库中的账户使用情况，是否存在无人使用的账户，如果存在建议删除。
　　2)检查网络管理员，安全管理员、系统管理员不同用户是否采用不同账户登录数据库。 d) 应授予管理用户所需的最小权限，实现管理用户的权限分离1）执行命令：＂select * from mysql.user where user=＂XXX＂;或＂select * from mysql.db;＂检查用户权限：
　　e) 应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则
　　1）访谈和查看管理员是否制定了访问控制策略
　　2）查看管理员权限；（此测评点如果数据库已经启用身份鉴别，且具备权限分离可判定为符合）
　　f) 访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级
　　结合a）、b）、c）、d）、e）项，并访谈管理员并核查访问控制粒度主体是否为用户级，客体是否为数据库表级。
　　（此测评点多数测评机构默认判定为符合） g)应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问
　　通过访谈管理员是否对重要主体和客体设置安全标记。mongoDB自身应该不具备这个功能，可能需要依赖操作系统或者第三方来实现。该项一般默认都不符合。
　　安全审计a) 应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计
　　1）执行命令：： show global variables  like ＂%audit%＂;＂检查审计是否开启，如果未开启建议执行命令： ＂set global server_audit_logging=on;＂开启审计。
　　备注：如果数据库未安装审计插件，需执行命令：
　　第一步：＂install plugin server_audit so name ＂server_audit .dll＂;＂，（windows后缀为dll，linux后缀为so）第二步：＂flush privileges;＂。
　　2）可检查mongod.log的日志文件记录是否正常：
　　3）访谈管理员是否通过第三方工具（数据库审计系统）收集审计数据进行分析。 b) 审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息
　　1）检查mongod.log的日志文件:
　　2)核查是否部署第三方工具（数据库审计系统）增强MySQL日志功能。记录第三方审计工具的审计内容，查看是否包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息。 c) 应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等
　　应保证各个管理员尽可以访问与自身相关的日志文件，如关键日志仅允许特权账户访问
　　1)访谈管理员对审计记录如何保护，对审计记录是否定期备份，备份策略。
　　是否采取了备份、转存等手段对审计记录进行保护，避免未预期的删除、修 改或覆盖，数据库本地日志保存时间超过6个月。采用第三方数据库审计产品，审计记录保存时间超过6个月。
　　2)是否严格限制用户访问审计记录的权限，可以通过普通用户登录然后是否能够访问修改删除日志。 d) 应对审计进程进行保护，防止未经授权的中断
　　MariDB可以根据权限建立各类型的账户，可以防止审计进程未经授权的中断，如果数据库已建立审计账户且各个数据库管理员权限已分离，可判定为符合。
　　入侵防范a) 应遵循最小安装的原则，仅安装需要的组件和应用程序
　　数据库系统此测评项可判定为不适用。  b) 应关闭不需要的系统服务、默认共享和高危端口
　　数据库系统此测评项不适用。  c) 应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制
　　查看用户登录的IP地址;是否给所有用户加上IP限制，拒绝所有未知主机进行连接，当user表中的Host值不为localhost时,应指定特定IP地址，不应为%；或将user表中的Host值为空，而在host表中指定用户账户允许登录访问的主机IP，使在非信任的客户端（其他地址）以数据库账户登录时被拒绝访问。
　　执行命令＂show grants for root@localhost;＂查看用户登录的IP地址；是否给所有用户加上IP限制，拒绝所有未知主机进行连接。
　　d) 应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求
　　数据库系统此测评项不适用。 e) 应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞
　　1） 访谈管理员是否定期或不定期进行漏洞扫描或渗透测试，周期按照天/月/季度/半年/年等方式（建议漏洞扫描周期最长半年一次）。
　　2）通过本次漏洞扫描是否发现与数据库相关的高危漏洞，若存在，是否及时进行漏洞修补，执行命令：＂show variables where variable_name like ＂%version%＂;＂检查数据库版本。
　　f) 应能够检测到对重要节点进行入侵的行为，并在发生严重入侵事件时提供报警
　　数据库系统此测评项不适用。
　　恶意代码防范应采用免受恶意代码攻击的技术措施或主动免疫可信验证机制及时识别入侵和病毒行为，并将其有效阻断
　　数据库系统此测评项不适用。  可信验证可基于可信根对计算设备的系统引导程序、 系统程序、重要配置参数和应用程序等进行可信验证，并在应用程序的关键执行环节进行动态可信验证，在检测到其可信性受到破坏后进行报警，并将验证结果形成审计记录送至安全管理中心
　　通过访谈管理员，是否采取了可信技术，可信技术主要是基于可信芯片、可信根，目前实现此技术的可能性不大，一般判定为不符合。
　　数据完整性
　　a)应采用密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等；
　　传输过程中的完整性一般是通过通信协议来实现的，常见的包括TLS、SSH等协议，对数据库而言，查看是否启用了安全协议进行数据通信，同时询问管理员，确认是否还有其他保证数据传输过程中的完整性措施。
　　（本地管理判定为不适用，远程管理根据实际情况判定）
　　b)应采用密码技术保证重要数据在存储过程中的完整性，包括但不限于鉴别数据、重要业务数据和重要个人信息等。
　　对数据库配置文件进行一个完整性检测，需要配置文件初始可信状态时的哈希值，然后再根据目前的文件生成一个哈希值，对比前后的一致性，确认数据是否被篡改过，根据了解一般数据库自身不带这种机制，询问管理人员是否使用了第三方软件对数据库重要数据进行了完整性校验。
　　实际操作中可核查数据库表中的业务数据、审计数据有无存在哈希字段，据了解数据在前端一般通过json或xml格式进行传输，相关数据库表字段中具有完整性校验字段。目前一般做不到，判定为不符合。
　　数据保密性
　　a)应采用密码技术保证重要数据在传输过程中的保密性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等；
　　若password是以明文密码传送给数据库，建议不在生产环境中使用。若数据库未开启SSL时，我通过Wireshare对数据库认证过程的数据包进行抓取，可能发现传输的密码字段信息。
　　总结，最直接验证的办法就是抓包验证重要的加密数据（鉴别数据、需要加密的业务数据、个人信息等）是否明文传输。
　　b)应采用密码技术保证重要数据在存储过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等。
　　检查数据库表中的重要数据是否明文存储，根据经验除鉴别数据外，业务数据、审计数据实际很少加密存储，所以一般不符合或者部分符合。如果使用数据库加密功能，就可以符合符合，数据库加密主要分库内加密和库外加密，库内加密主要是调用的数据库本身的加密功能，库外加密主要通过第三方厂家的数据库加密功能。
　　此处主要针对鉴别信息（其他像业务数据、审计数据和配置数据一般情况未加密）传输相关的参数大致有下类三个：
　　SCRAM-SHA-256属于挑战-响应架构， 可防止密码在不可信连接上嗅探，并支持以密码散列的形式将密码存储在服务器上， 这种形式被认为是安全的。
　　MD5使用自定义安全性较低的质询-响应机制。 它可以防止密码嗅探，并避免以纯文本形式将密码存储在服务器上， 但如果攻击者设法从服务器窃取密码哈希，则不提供保护。（MD5哈希算法现在不再被认为是安全的算法）
　　据了解，MariDB数据库自身提供了加密机制， 在数据库内核实现了存储的加密。这种加密方式能防止磁盘丢失和文件被复制导致的敏感数据泄漏。但是，对于控制了数据库系统的攻击者来说却是开放的， 并没有防护能力。而且其密钥管理通常不会对数据库用户开放，安全性得不到保证。
　　数据备份恢复
　　a)应提供重要数据的本地数据备份与恢复功能；
　　1）访问管理员配置数据、审计数据、业务数据的备份策略，检查备份策略的备份情况与管理员所说是否一致，是否具有恢复测试记录。
　　2）可以通过数据库管理工具进行备份，如navicat等工具，工具具备MariDB自带的逻辑备份。它的备份原理是通过协议连接到MariDB数据库，将需要备份的数据查询出来。将查询出的数据转换成对应的insert 语句，当我们需要还原这些数据时，只要执行这些 insert 语句，即可将对应的数据还原。
　　b)应提供异地实时备份功能，利用通信网络将重要数据实时备份至备份场地；
　　部署异地备份机房，并符合备份策略通过网络定期进行异地备份。
　　c)应提供重要数据处理系统的热冗余，保证系统的高可用性；
　　集群部署、双机热备均可判定为符合。
　　剩余信息保护
　　a)应保证鉴别信息所在的存储空间被释放或重新分配前得到完全清除；
　　一般情况下数据库系统内核层默认无法实现剩余信息保护功能，需要第三方工具才能实现。
　　b)应保证存有敏感数据的存储空间被释放或重新分配前得到完全清除。
　　一般情况下数据库系统内核层默认无法实现剩余信息保护功能，需要第三方工具才能实现。
　　个人信息保护
　　a)应仅采集和保存业务必需的用户个人信息；
　　检查数据库中是否存储个人信息，若有，检查个人信息保护机制和个人信息保护管理制度
　　b)应禁止未授权访问和非法使用用户个人信息。
　　检查个人信息保护机制和个人信息保护管理制度，验证非授权人员是否可以访问个人信息存储的相关组件内容。
　　总结
　　在等保测评检查中会发现MariDB数据库大部分配置都可以实现，但是在实际测评过程中很多单位不愿意配置等保中要求的策略，一方面是管理员认为不方便自己运维管理，另一方面可能是数据库在实时生产环境中，管理员担心更改相关安全配置后影响系统的正常运行，所以我们在测评中要做好安全和生产、安全和管理的平衡。