|
控制点 |
安全要求 |
要求解读 |
测评方法 |
预期结果或主要证据 |
|
身份鉴别 |
a)应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换 |
应检查MySQL数据库的口令策略配置，查看其身份鉴别信息是否具有不易被冒用的特点，例如，口令足够长，口今复杂(如规定字符应混有大,小写字母数字和特殊字符)，口令定期更新，新旧口令的替换要求 |
1)尝试登录数据库，执行mysql -u root -p查看是否提示输入口令鉴别用户身份 2)使用如下命令查询账号 select user, host FROM mysql.user 结果输出用户列表，查者是否存在相同用户名 3)执行如下语句查询是否在空口令用： select * from mysql.user where length(password)= 0 or password is null 输出结果是否为空 4)执行如下语句查看用户口今复杂度相关配置: show variables like 'validate%'; 或show VARIABLES like "%password“ |
1)用户登录数据库时，采用用户名、口令的方式进行身份鉴别 2)查询user表，不存在相同的用户名 3)不存在空口令用户; 4)配置信息: validate_password_length 8 validat_ password_mixed_case_count 1 validate_password_number_count 1 validate_password policy MEDIUM validate_password_special_char_count 1 |
|
b)应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施 |
应检查数据库系统，查看是否已配置了鉴别失败处理功能，并设置了非法登录次数的限制值，对超过限制值的登录终止其鉴别会话或临时封闭帐号。查看是否设置网络登录连接超时，并自动退出 |
1)询问管理员是否采取其他手段配置数据库登录失败处理功能。 2）执行 show variables like %max_connect_errors%";或核查my.cnf文件，应设置如下参数： max_connect_errors=100 3) show variables like ”%timeout%“,查看返回值 |
1)MySQL数据库采用第三方管理软件，且第三方管理软件设置登录失败锁定次数 2)3)数据库管理系统本地配置了参数max_connect_errors= 100, Wait_timeout = 28800，如果mysql服务器连续接收到了来自于同一个主机的请求，且这些连续的请求全部都没有成功的建立连接就被断开了，当这些连续的请求的累计值大于max_connect_errors的设定值时，mysql 服务器就会阻止这台主机后续的所有请求。Wait_ timeout: 一个连接connection空闲超过8个小时(默认值28800秒)，MySQL 就会自动断开这个连接 |
|
|
c)当进行远程管理时，应采取必要措施、防止鉴别信息在网络传输过程中被窃听 |
为了防止包括鉴别信息在内的敏感信息在网络传输过程中被窃听，应限制从远程管理数据，如果使用了远程访问，要确保只有定义的主机才可以访问服务器，一般通过 TCP wrappers 、iptables或任何其它的防火墙软件或硬件实现 |
1)是否采用加密等安全方式对系统进行远程管理 2)执行 mysql>show variables like %have_ssl%" 查看是否支持ssl的连接特性,若为disabled说明此功能没有激活,或执行s查看是否启用SSL; 3)如果采用本地管理方式，该项为不适用 |
1)远程管理采用的方式:远程管理数据库，启用了SSL连接特性。 2)用户远程管理数据库时，客户端和服务器的连接不通过或跨越不可信任的网络，采取SSH隧道加密连接选程管理通信 3)本地管理，本条N/A |
|
|
d)应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现 |
MySQL不能集成其他身份鉴别措施，应通过对操作系统层面实现双因素，强化数据库安全 |
1)MySQL不能集成其他身份鉴别措施,应通过对操作系统层面实现双因素 2）访谈系统管理员，是否采用其他技术手段实现双因素身份认证，是否采用了两种或两种以上组合的鉴别技术，如口令、数字证书Ukey. 令牌、指纹等，是否有一种鉴别方法使用密码技术 |
1)采用的登录方式有:用户名口令，MySQL数据库无法集成其他身份鉴别方式，在操作系统实现双因素，通常将服务器纳入到堡垒机管理，同时通过限制仅允许通过堡垒机坛维服务器。在堡垒机实现双因素身份认证。常见的双因素认证方式有口令、数字证书Ukey. 令牌、指纹等 2)采用的密码技术是: 在硬件UKey中使用了加密算法 |
|
|
访问控制 |
a)应对登录的用户分配账户和权限 |
访谈管理员数据库用户账户及权限分配情况，并测试网络管理员、安全管理员、系统管理员或核查用户账户和权限设置的情况，有些mysql数据库的匿名用户的口令为空，因而，任何人都可以连接到这些数据库。如果匿名帐户grants存在，那么任何人都可以访问数据库，至少可以使用默认的数据库”test“.因此，应核查是否已禁用匿名、默认账户的访问权限 |
1)执行语句select user,host FROM mysql.user 输出结果是否为网络管理员，安全管理员，系统管理员创建了不同账户: 2)执行show grants for' XXXX'@' localhost'： 查看网络管理员，安全管理员、系统管理员用户账号的权限，权限间是否分离并相互制约 |
1)审计员的角色，创建了不同的账户，并为其分配了相应的权限 2)已禁用匿名、默认账户或限制匿名、默认用户的权限 |
|
b)应重命名或删除默认账户，修改默认账户的默认口令 |
在linux中，root 用户拥有对所有数据库的完全访问权。因而，在linux的安装过程中，一定要设置root口令，要改变默认的空口令 |
1)执行select user,host FROM mysql.user 输出结果查看root用户是否被重命名或被删除 2)若root账户未被删除，是否更改其默认口令，避免空口令或弱口令. |
1)数据库管理系统默认账户已被删除 2)数据本管理系统账认账户root未被删除，但增强其口令复杂度，不要空口令、弱口令的现象 |
|
|
c)应及时删除或停用多余的、过期的账户，避免共享账户的存在 |
在默认安装mysql中，匿名户可访问test数据库.我们可以移除任何无用的数据库，以避免在不可预料的情况下访问了数据库，同时删除数据库中多余的、过期的账户，如测试账号等 |
1)在sqlplus中执行命令: select username,account_status from dba_users 2)执行下列语句: select * from mysql.user where user="" select user, host FROM mysql.user 依次核查列出的账户，是否存在无关的账户。 3)访谈网络管理员，安全管理员、系统管理员不同用户是否采用不同账户登录系统 |
1)不存在示例帐户 2)数据库管理系统用户表中不存在无关账户 3)不存在多人共享帐户的情况 |
|
|
d)应授予管理用户所需的最小权限，实现管理用户的权限分离 |
有些应用程序是通过一个特定数据库表的用户名和口令连接到WySQL的,安全人员不应当给予这个用户完全的访问权。如果攻击者获得了这个拥有完全访问权的用户，他也就拥有了所有的数据库。因此应核查用户是否行角色划分,核查访问控制策略，查看管理用户的权限是否已进行分离,并核查管理用户权限是否为其工作任务所需的最小权限 |
1)是否对用户进行角色划分且只授予账号必须的权限 如除root外,任何用户不应该有mysql库user表的存取权限，禁止将fil、.process、 super权限授予管理员以外的账户 2)查看权限表，并验证用户是否具有自身角色外的其他用户的权限 |
1）2)记录管理用户的权限分配情况：分配了网络管理员、安全员、审计员账号，root账户使用需向数据库管理员申请 |
|
|
d)应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则 |
应检查数据库系统的安全策略，查看是否明确主体(如用户)以用户和/或用户组的身份规定对客体(如文件或系统设备，目录表和存取控制表等)的访问控制，覆盖范围是否包括与信息安全直接相关的主体(如用户)和客体(如文件，数据库表等)及它们之间的操作[如读、写或执行) |
1.访谈管理员是否制定了访问控制策略 2.执行语句： mysql>selcec * from mysql.userG -检查用户权限列 mysql>selcec * from mysql.dbG --检查数据库权限列 mysql>selcec * from mysql.tables_privG 一检查用户表权限列 mysql>selcec * from mysql.columns_priviG -检查列权限列管理员 输出的权限列是是否与管理员制定的访问控制策略及规则一致 3)登录不同的用户，验证是否存在越权访问的情形 |
1制定数据库访问控制策略，由专门的安全员负责对访问控制权限的授权工作: 2)各账户权限配置，均是基于安全员的安全策略配置进行的访问控制 3)无越权访问 |
|
|
e)访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级 |
明确提出访问控制的粒度要求，重点目录的访问控制的主体可能为某个用户或某个进程，应能够控制用户或进程对文件、数据库表等客体的访问 |
1）执行下列语句： mysql>selcec * from mysql.userG -检查用户权限列 mysql>selcec * from mysql.dbG --检查数据库权限列 2)访谈管理员并核查访问控制粒度主体是否为用户级，客体是否为数据库表级 |
1) 2)由专门的安全员负责对访问控制权限的授权工作，授权主体为用户，客体为数据库表 |
|
|
f)应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问 |
MySQL不提供该项功能 |
访谈管理员，是否采用其他技术手段 |
MySQL不提供该项功能，主要依据操作系统层面实现该项功能 |
|
|
安全审计 |
a)应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计 |
如果数据库服务器并不执行任何查询，建议启用审计。在/etc/my.cnf文件的[Mysql]部分添加: 1og,=/var/1og/ my1ogfile 对于生产环境中任务繁重的MySOL数据库，启用审计会引起服务器的高昂成本，因此建议采用第三方数据库审计产品收集审计记录。应检查数据库系统，查看审计策略是否覆盖系统内重要的安全相关事件，例如，用户登录系统、自主访问控制的所有操作记录、重要用户行为(如增加/删除用户，删除库表)等。 |
1)执行下列语句: mysql>show variables like' log_%’ 查看输出的日志内容是否覆盖到所有用户，记录审计记录覆盖内容 2)核查是否采取第三方工具增强MySQL日志功能。若有，记录第三方审计工具的审计内容，查看是否包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息 |
1)数据库本地启用了日志功能，审计内容覆盖到每个用户， 能够记录用户行为和重要安全事件 2)启用审计功能策略为:配置了审计日志存储位置，或部署第三方数据库审计产品，审计内容覆盖到所有用户 |
|
b)审计记录应包括事件的日期和时间，用户、事件类型，事件是否成功及其他与审计相关的信息 |
应检查数据库系统，查看审计策略是否覆盖系统内重要的安全相关事件，例如，用户登录系统、自主访问控制的所有操作记录、重要用户行为(如增加/删除用户，删除库表)等 |
1)执行下列语句: mysql>show variables like 'log_%' 查看输出的日志内容是否覆盖到所有用户，记录审计记录覆盖内容 2)核查是否采取第三方工具增强MySQL日志功能。若有，记录第三方审计工具的审计内容，查看是否包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息 |
1）数据库本地启用了日志功能，审计内容覆盖到每个用户，能够记录重要用户行为和重要安全事件 2)采用第三方数据库审计产品，审计内容覆盖到每个用户，能够记录重要用户行为和重要安全事件 |
|
|
c)应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等 |
应保证只有root和mysql可以访问这些日志文件，其中，错误日志务必须确保只有root和MySq1可以访问hostnam'err日志文件，由于该文件存放在mysql数据历史中，文件包含如口令、地址，表名，存储过程名、代码等敏感信息，易被用于信息收集，并且有可能向攻击者提供利用数据库漏洞的信息,攻击者获取安装数据库的服务器的内部数据: MySQL日志，应确保只有root和mysq1可以访问logfileXY日志文件，此文件存放在mysq1的历史目录中。因此，应检查MySQL数据库系统是否对日志进行了权限设置，非授权人员不能对日志进行操作。另外，应防止审计日志空间不够而导致无法记录日志的情况发生，并对审计日志进行定期备份，根据《网络安全法》要求，日志应至少保存6个月以上 |
1)访谈管理员对审计话录如何保护，对审计记录是否定期备份，备份策略 2)是否严格限制用户访问审计记录的权限 |
1)采取了备份、转存等手段对审计记录进行保护，避免未预期的删除、修 改或覆盖，数据库本地日志保存时间超过6个月 2)采用第三方数据库审计产 品，审计记录保存时间超过6个月 |
|
|
d)应对审计进程进行保护，防止未经授权的中断 |
应测试通过非审计员的其他账户来中断审计进程，验证审计进程是否受到保护;对于MySQL数据库系统默认符合，但是如果采取了第三方工具，则应检查数据库系统，查看未授权用户是否能中断审计进程 |
1)询问是否严格限制管理员、审计员权限 2)用户重启实例关闭审计功能，查看是否成功 |
1)非审计员账户无法中断审计进程，审计进程受到保护 2)测试其他人员是否可以对审计进程进行开启，关闭操作，并记录 |
|
|
入侵防范 |
a)应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制 |
直接通过本地网络之外的计算机连接生产环境中的数据库是异常危险的。有时，管理员会打开主机对数据库的访问： > GRANT ALL ON *.* TO 'root'@'%' 其实是完全放开了对root的访问，因此把重要的操作限制给特定主机异常重要: >GRANT ALL ON *.* TO 'root'@'localhost' >GRANT ALL ON *.* TO 'root'@'myip.athome' >FLUSH PRIVILEGES此时，即限制仅允许指定的P(不管其是否静态)可以访问 |
查看用户登录的IP地址;是否给所有用户加上IP限制，拒绝所有未知主机进行连接 注:当user表中的Host值不为本地主机时,应指定特定IP地址，不应为%；或将user表中的Host值为空，而在host表中指定用户帐户允许登陆访问的若干主机；在非信任的客户端以数据库账户登录应被提示拒绝，用户从其他子网登录，应被拒绝 |
配置安全策略为:在防火墙上限制特定的终端(IP) 连接(访问)数据库:限定的IP地址为:XXXX |
|
b) 应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞 |
攻击者可能利用操作系统存在的安全漏洞对系统进行攻击，应对系统进行漏洞扫描，及时发现系统中存在的已知漏洞，并在经过充分测试评估后更新系统补丁，.避免遭受由系统漏洞带的风险 |
访谈MySQL补丁升级机制，查看补丁安装情况: 1)执行如下命令查看当前补于版本: show variables where variable name like "version" 2)访谈数据库是否为企业版，是否定期进行漏洞扫描，针对高风险漏洞是否评估补丁并经测试后再进行安装 |
1)数据库当前不有在高风险漏洞，补丁更新及时，记录补丁信息为: MySQL数据库补丁定期更新版本 2) 数据库为企业版，定期进行漏洞扫描，在发现数据库漏洞时，必须经测试估后进行漏洞修补 |
|
|
数据备份恢复 |
a)应提供重要数据处理系统的热冗余，保证系统的高可用性 |
任何系统都有可能发生灾难，服务器、MySQL也会崩溃，也有可能遭受入侵,数据有可能被删除。只有为最糟糕的情况做好了充分的准备，才能够在事后快速地从灾难中恢复。用户应把备份过程作为一项日常工作。数据库系统至少提供本地实时备份的功能，当数据发生错误时，能够及时恢复数据 |
询问系统管理员数据库的备份和恢复策略是什么 |
备份策略为:对数据库重要数据每天增量备份，每周全量备份: 近期恢复测试时间:每月（季度）定期进行恢复性测试演练 |
|
b)应提供异地实时备份功能，利用通信网络将重要数据实时备份至备份场地 |
应提供灾备中心，对重要的数据提供异地数据级备份，保证当本地系统发生灾难性后果不可恢复的，利用异地保存的数据对系统数据能进行恢复 |
1）询问系统管理员是否提供异地数据备份功能,是否定时批量传送至备用场地 2)如果条件允许，则查看其实现技术措施的配置情况 |
部署数据备份机房：有异地备份机房，实时（定期）将数据备份到机房 |