等级保护测评策略建议整改措施

 

主机安全

 服务器windows

身份鉴别

b)操做系统和数据库系统管理用户身份标识应具备不易被冒用的特色，口令应有复杂度要求并按期更换；

整改方法：

修改配置策略：  
一、查看控制面板—管理工具—本地安全策略—帐户策略—密码策略；  
二、查看控制面板—管理工具—计算机管理—系统工具—本地用户和组—用户—右键—属性—是否勾选“密码永不过时”。  
建议修改值：  
（一）策略修改  
一、密码必须符合复杂性要求；   已启用  
二、密码长度最小值；    12个字符  
三、密码最长使用期限；   42天  
四、密码最短使用期限；  2天  
五、强制密码历史；   5个记住密码  
六、密码永不过时属性。  未勾选“密码永不过时” 
（二）使用状况  
口令长度至少12位以上，由数字、特殊字符、字母（区分大小写）组成，每三个月按期进行修改

f)应采用两种或两种以上的组合的鉴别技术对管理用户进行身份鉴别。

•     整改方法：

•     验证检查：  
一、采用令牌、USB-KEY或智能卡等身份认证技术手段对用户进行身份鉴别  
建议整改：  
部署双因素产品或者堡垒机

访问控制

a)应启用访问控制功能，依据安全策略控制用户对资源的访问；

•     整改方法：

•     验证检查：  
是否能提供用户权限对照表，设置的用户权限是否与权限表一致。  
建议整改：  
完善用户权限表（纸质版或电子版）

•     c)应实现操做系统和数据库系统特权用户的权限分离；

•     整改方法：

•     验证检查：  
一、询问操做系统管理员与数据库管理员是否为同一人；  
二、检查操做系统管理员与数据库管理员是否使用不一样的帐户登陆。  
建议整改：  
一、操做系统管理员与数据库管理员不为同一人； 
二、操做系统管理员与数据库管理员使用不一样的帐户登陆。

•     f)应对重要信息资源设置敏感标记；

•     整改方法：

•     验证检查：  
一、询问主机管理员是否认义了主机中的重要信息资源；  
二、询问主机管理员，是否为主机内的重要信息设置敏感标记。  
建议整改：  
暂无

•     g)应依据安全策略严格控制用户对有敏感标记重要信息资源的操做。

•     整改方法：

•     验证检查：  
一、询问主机管理员是否认义了敏感标记资源的访问策略；  
二、查看有敏感标记的重要信息资源是否依据访问策略设置了严格的访问权限。  
建议整改：  
暂无

安全审计

•     a)审计范围应覆盖到服务器上的每一个操做系统用户和数据库用户；

•     b)审计内容应包括重要用户行为、系统资源的异常使用和重要系统命令的使用等系统内重要的安全相关事件；

•     d)应可以根据记录数据进行分析，并生成审计报表；

•     F)应保护审计记录，避免受到未预期的删除、修改或覆盖等。

•     总体考虑

•     整改方法：

•     验证检查：  
一、查看控制面板—管理工具—本地安全策略—本地策略—审核策略；  
二、询问并查看是否有第三方审计工具或系统。 
建议整改：  
（一）策略修改  
   一、审核策略更改；   成功  
   二、审核登陆事件；   成功，失败  
   三、审核对象访问；   成功，失败  
   四、审核过程跟踪；   成功，失败  
   五、审核目录服务访问；没有定义  
   六、审核特权使用；   成功，失败  
   七、审核系统事件；   成功  
   八、审核帐户登陆事件；   成功，失败  
   九、审核帐户管理。   成功，失败  
（二）windows自身日志查看  
右键【个人电脑】/【此电脑】→【管理】→【事件查看器】→右键单击任一事件查看器→Windows日志，查看应用程序、安全、Setup、系统日志的时间是否知足存储6个月；同时点击应用程序、安全、Setup、系统日志右键【属性】，审计日志的存储大小设置知足需求，但不得低于64M（默认是20M），达到最大日志量后应选择日志满时将其存档，不覆盖事件（默认是按须要覆盖日志（旧事件优先））  
（三）设备部署  
一、物理机房：部署日志审计系统  
二、上云服务器（如阿里云）：日志服务

入侵防范

•     a)应可以检测到对重要服务器进行入侵的行为，可以记录入侵的源IP、攻击的类型、攻击的目的、攻击的时间

•     b)应可以对重要程序的完整性进行检测，并在检测到完整性受到破坏后具备恢复的措施；

•     c)操做系统应遵循最小安装的原则，仅安装须要的组件和应用程序，并经过设置升级服务器等方式保持系统补丁及时获得更新。

•     总体考虑

•     整改方法：

•     验证检查：  
一、询问是否安装了主机入侵检测系统，并进行适当的配置；  
二、查看是否对入侵检测系统的特征库进行按期升级；  
三、查看是否在检测到严重入侵事件时提供报警。 
四、询问是否对关键程序的完整性进行校验； 
五、管理工具—服务—查看可使用的服务  
六、监听端口，命令行输入“netstat -an”  
七、“控制面板”—“管理工具”—“计算机管理”—“共享文件夹”  
建议整改：  
（一）策略修改  
一、仅开启须要的服务端口（135 137 139 445等端口建议不开启，若业务须要，应作好系统相应补丁）  
二、关闭不须要的组件和应用程序，仅启用必须的功能  
三、关闭默认共享文件  
（二）设备和服务部署  
一、物理机房：部署IDS、IPS  
二、上云服务器（如阿里云）：部署安骑士或态势感知、web应用防火墙、抗DDoS

恶意代码防范

•     a)应安装防恶意代码软件，并及时更新防恶意代码软件版本和恶意代码库；

•     b)主机防恶意代码产品应具备与网络防恶意代码产品不一样的恶意代码库；

•     c)应支持防恶意代码软件的统一管理。

•     总体考虑

•     整改方法：

•     验证检查：  
一、查看是否安装了防恶意代码软件； 
二、查看恶意代码库是否为最新；  
三、主机防病毒软件是否与网络版防病毒软件相同 
四、安装的防病毒软件是否支持统一管理 
建议整改：  
（一）设备和服务部署  
一、物理机房：防病毒网关、包含防病毒模块的多功能安全网关和网络版防病毒系统，任选一种部署  
二、上云服务器（如阿里云）：态势感知或安骑士

资源控制

•     b)应根据安全策略设置登陆终端的操做超时锁定；

•     整改方法：

•     验证检查：  
一、桌面右键—个性化—屏幕保护程序；  
二、在运行中输入gpedit.msc打开“组策略”，在计算机配置—管理模块—Windows组件—远程桌面服务—远程桌面会话主机—会话时间限制中，查看是否设置“活动但空闲的远程桌面服务会话时间的限制”。  
建议整改：  
（一）策略修改  
一、启用屏保并勾选“在恢复时显示登陆屏幕”  
二、设置“活动但空闲的远程桌面服务会话时间的限制”（推荐值设置15分左右）1.1.2. linux

身份鉴别

•     b)操做系统和数据库系统管理用户身份标识应具备不易被冒用的特色，口令应有复杂度要求并按期更换；

•     centos/Fedora/RHEL

•     整改方法：

•     验证检查：  
一、查看/etc/login.defs，访谈询问当前所设置的密码长度及更换周期；  
二、查看/etc/pam.d/system-auth，确认密码复杂度要求。  
       密码最长有效期PASS_MAX_DAYS；  
       密码最短存留期PASS_MIN_DAYS；  
       密码长度最小值PASS_MIN_LENS；  
       密码有效期警告PASS_WARN_AEG；  
       密码须包含大写字母个数ucredit；  
       密码须包含小写字母个数lcredit；  
       密码须包含的数字字符个数dcredit； 
       密码须包含的特殊符号个数ocredit。 
建议整改：  
（一）策略修改  
一、/etc/login.defs文件中进行以下变量配置：  
PASS_MAX_DAYS：90；  
PASS_MIN_DAYS：2；  
PASS_MIN_LENS：8；  
PASS_WARN_AEG：7；  
二、/etc/pam.d/system-auth文件中添加下面信息：  
password requisite pam_cracklib.so minlen=8 ucredit=-1 lcredit=-1 dcredit=-1ocredit=-1；  
三、当前所设置的密码长度应很多于8位，具备必定的复杂度并能按期更换。

•     Ubuntu/Debian

•     整改方法：

•     验证检查：  
一、查看/etc/login.defs，访谈询问当前所设置的密码长度及更换周期；  
二、查看/etc/pam.d/common-password，确认密码复杂度要求。  
       密码最长有效期PASS_MAX_DAYS；  
       密码最短存留期PASS_MIN_DAYS；  
       密码长度最小值PASS_MIN_LENS；  
       密码有效期警告PASS_WARN_AEG；  
       密码须包含大写字母个数ucredit；  
       密码须包含小写字母个数lcredit；  
       密码须包含的数字字符个数dcredit； 
       密码须包含的特殊符号个数ocredit。 
建议整改：  
（一）策略修改  
一、/etc/login.defs文件中进行以下变量配置：  
PASS_MAX_DAYS：90；  
PASS_MIN_DAYS：2；  
PASS_MIN_LENS：8；  
PASS_WARN_AEG：7；  
二、/etc/pam.d/system-auth文件中添加下面信息：  
password requisite pam_cracklib.so minlen=8 ucredit=-1 lcredit=-1 dcredit=-1ocredit=-1；  
三、当前所设置的密码长度应很多于8位，具备必定的复杂度并能按期更换。

•     c)应启用登陆失败处理功能，可采起结束会话、限制非法登陆次数和自动退出等措施；

•     整改方法：

•     验证检查：  
一、find /lib* -iname "pam_tally2.so"或find /lib* -iname "pam_tally.so"是否有改动态库 
二、是否有如下参数：auth required pam_tally2.so  onerr=fail deny=X  unlock_time=Xeven_deny_root root_unlock_time=X（限制从终端登陆）  
三、/etc/pam.d/sshd文件中是否有以上相同参数（限制ssh登陆） 
建议整改：  
一、centos：/etc/pam.d/system-auth或Ubuntu：/etc/pam.d/common-password文件中添加：auth required pam_tally2.so onerr=fail  deny=3  unlock_time=40 even_deny_rootroot_unlock_time=30  
注意添加的位置，要写在第一行，即#%PAM-1.0的下面。  
以上策略表示：普通账户和 root 的账户登陆连续 3 次失败，就统一锁定 40 秒， 40 秒后能够解锁。  
若是不想限制 root 账户，能够把  even_deny_root root_unlock_time这两个参数去掉， root_unlock_time 表示 root 账户的 锁定时间，onerr=fail 表示连续失败，deny=3,表示 超过3 次登陆失败即锁定。 
二、/etc/pam.d/sshd文件中添加相同参数  
（备注：以上参数根据实际状况进行设置，至少配置/etc/pam.d/sshd文件限制ssh登陆）

•     f)应采用两种或两种以上组合的鉴别技术对管理用户进行身份鉴别。

•     整改方法：

•     验证检查：  
操做系统登陆是否采用口令+令牌、USB KEY等方式进行身份鉴别。  
建议整改：  
（一）设备或服务部署  
一、物理机房：采用双因子认证设备 
二、上云服务器（如阿里云）：云堡垒机

访问控制

•     a)应启用访问控制功能，依据安全策略控制用户对资源的访问；

•     整改方法：

•     验证检查：  
是否能提供用户权限对照表，设置的用户权限是否与权限表一致。  
建议整改：  
完善用户权限表（纸质版或电子版）

•     d)应严格限制默认账户的访问权限，重命名系统默认账户，修改这些账户的默认口令；

•     整改方法：

•     验证检查：  
一、重命名系统默认账户（root）；  
二、修改默认账户的口令。  
建议整改：  
一、根据业务需求状况对root进行重命名，其口令必须进行修改

•     f)应对重要信息资源设置敏感标记；

•     整改方法：

•     验证检查：  
一、询问主机管理员是否认义了主机中的重要信息资源；  
二、询问主机管理员，是否为主机内的重要信息设置敏感标记。  
建议整改：  
暂无

•     g)应依据安全策略严格控制用户对有敏感标记重要信息资源的操做。

•     整改方法：

•     验证检查：  
一、询问主机管理员是否认义了敏感标记资源的访问策略；  
二、查看有敏感标记的重要信息资源是否依据访问策略设置了严格的访问权限。  
建议整改：  
暂无

备注：linux系统分为Ubuntu、OpenSUSE、Fedora、Debian、RHEL、CentOS等，每一个系统又分为不一样的版本，所以在修改策略时须要在相同环境的测试机上进行验证后，在正式环境中进行修改

 

安全审计

•     a)审计范围应覆盖到服务器上的每一个操做系统用户和数据库用户；

•     b)审计内容应包括重要用户行为、系统资源的异常使用和重要系统命令的使用等系统内重要的安全相关事件；

•     c)审计记录应包括事件的日期、时间、类型、主体标识、客体标识和结果等；

•     d)应可以根据记录数据进行分析，并生成审计报表；

•     e)应保护审计进程，避免受到未预期的中断；

•     f)应保护审计记录，避免受到未预期的删除、修改或覆盖等。

•     总体分析

•     整改方法：

•     验证检查：  
一、输入service syslog/rsyslog status 、service auditd status查看进程是否存在。  
二、（centos：cat /etc/syslog.conf或cat /etc/rsyslog.conf文件中应包含相似于如下值：*.info;mail.none;news.none;authpriv.none;cron.none/var/log/messages；）（Ubuntu：cat/etc/rsyslog.d/50-default.conf 文件中应包含相似于如下值：*.info;mail.none;news.none;authpriv.none;cron.none/var/log/messages；） 
三、是否对审计日志按期查看、分析，生成审计分析报表  
四、是否安全额外的审计进程保护  
五、查看syslog.conf、audit.conf文件中日志信息所在文件的访问权限，如：  
 ls -l /var/log/messages；  
 (centos：ls -l/var/log/secure)；（Ubuntu：ls -l/var/log/auth.log） 
 ls -l /var/log/audit/audit.log；   
访谈并询问是否对审计日志进行保护 
建议整改：  
（一）策略修改  
一、保障rsyslog和auditd进程开启  
二、/etc/rsyslog.conf或/etc/rsyslog.d/50-default.conf文件中日志配置以下：  
# 记录全部日志类型的info级别以及大于info级别的信息到/var/log/messages，可是mail邮件信息，authpriv验证方面的信息和cron时间任务相关的信息除外  
*.info;mail.none;authpriv.none;cron.none                /var/log/messages    
# The authpriv file has restricted access. 
# authpriv验证相关的全部信息存放在/var/log/secure  
authpriv.*                                             /var/log/secure    
# Log all the mail messages in one place. 
# 邮件的全部信息存放在/var/log/maillog; 这里有一个-符号, 表示是使用异步的方式记录, 由于日志通常会比较大  
mail.*                                                 -/var/log/maillog    
# Log cron stuff  
# 计划任务有关的信息存放在/var/log/cron  
cron.*                                                 /var/log/cron    
（备注：以上配置须要先在测试环境中验证是否正确后，在正式环境中进行修改）  
三、ls -l /var/log/messages：640； ls -l /var/log/secure：640；   
ls -l /var/log/audit/audit.log：640；ls -l /var/log/auth.log 640；（备注：保持系统默认就行，惟一须要知足的就是普通用户对这些文件只能有读的权限）  
四、查看 /var/log/messages、/var/log/secure、/var/log/audit/audit.log、/var/log/auth.log日志文件的内容是否被覆盖和删除，保存是否知足6个月  
（二）设备或服务部署  
一、物理机房：日志服务器或日志审计系统或堡垒机 
二、上云服务器（如阿里云）：OSS或日志服务或jumpserver 

入侵防范

•     a)应可以检测到对重要服务器进行入侵的行为，可以记录入侵的源IP、攻击的类型、攻击的目的、攻击的时间，并在发生严重入侵事件时提供报警；

•     整改方法：

•     验证检查：  
一、安装主机入侵检测系统并配置策略； 
二、按期对主机入侵检测系统的特征库进行维护升级；   
三、发生严重入侵事件时提供报警。 
四、是否常常命令查看more /var/log/secure | grep  refused (centos)  
五、more /var/log/auth.log | grep  refused (ubuntu)  
六、是否启用主机iptables防火墙规则、TCP SYN保护机制  
建议整改：  
（一）设备或服务部署  
一、物理机房：部署入侵检测和防护系统（IDS、IPS或防火墙带有入侵检测和防护）  
二、上云服务器（如阿里云）：安骑士或态势感知或其它防入侵服务

•     c)操做系统应遵循最小安装的原则，仅安装须要的组件和应用程序，并经过设置升级服务器等方式保持系统补丁及时获得更新。

•     整改方法：

•     验证检查：  
一、对系统补丁进行评估、测试后进行安装 
二、系统遵循最小安装原则  
建议整改：  
（一）策略修改  
一、如需最新补丁，须要评估、测试，或者根据业务使用稳定版本补丁  
二、关闭危险网络服务：echo、login等，关闭非必要的网络服务：talk、ntalk、sendmail等

 

恶意代码防范

•     a)应安装防恶意代码软件，并及时更新防恶意代码软件版本和恶意代码库；

•     b)主机防恶意代码产品应具备与网络防恶意代码产品不一样的恶意代码库；

•     c)应支持防恶意代码软件的统一管理。

•     总体考虑

•     整改方法：

•     验证检查：  
一、查看是否安装了防恶意代码软件； 
二、查看恶意代码库是否为最新；  
三、主机防病毒软件是否与网络版防病毒软件相同 
四、安装的防病毒软件是否支持统一管理 
建议整改：  
（一）设备和服务部署  
一、物理机房：防病毒网关、包含防病毒模块的多功能安全网关和网络版防病毒系统，任选一种部署  
二、上云服务器（如阿里云）：态势感知或安骑士或其它防病毒服务

 

资源控制

•     a)应经过设定终端接入方式、网络地址范围等条件限制终端登陆；

•     整改方法：

•     验证检查：  
一、使用SSH登陆则查看/etc/ssh/sshd_config  
二、查看/etc/hosts.allow和/etc/hosts.deny文件内是否配置可访问的IP或经过询问、查看方式确认是否经过网络设备或硬件防火墙实现此项要求；  
三、iptables -nvL 查看防火墙规则  
建议整改：  
（一）策略修改  
一、/etc/ssh/sshd_config文件中PermitRootLoginno，不容许root直接登陆  
二、/etc/hosts.allow和/etc/hosts.deny文件中配置可访问的IP或者经过防火墙或跳板机或堡垒机设置访问限制  
三、上云的服务器：安全组或VPC或云防火墙进行设置  
四、防火墙规则根据业务需求进行配置

•     b)应根据安全策略设置登陆终端的操做超时锁定；

•     整改方法：

•     验证检查：  
一、查看etc/profile文件中是否设置TMOUT  
建议整改：  
（一）策略修改  
一、etc/profile文件中添加TMOUT，TMOUT=600（备注：根据业务进行设定）

•     d)应限制单个用户对系统资源的最大或最小使用限度；

•     整改方法：

•     验证检查：  
一、查看 /etc/security/limits.conf 文件，访谈系统管理员针对系统资源采起的保障措施。  
fsize 用户建立的文件大小限制； 
core 生成的core文件大小的限制；  
cpu 用户进程可用cpu的限定值；  
data 进程数据段大小的限定值； 
stack 进程堆栈段大小的限定值； 
rss 进程常驻内存段的限定值； 
nofiles 进程中打开文件的最大数量。 
建议整改：  
一、根据实际需求对文件中的各个变量参数进行合理设置  
二、采用zabbix或者云监控等手段进行监控

1.2.数据库

1.2.1.    SQL数据库

• 身份鉴别

•     b)操做系统和数据库系统管理用户身份标识应具备不易被冒用的特色，口令应有复杂度要求并按期更换；

•     整改方法：

•     验证检查：  
一、打开Microsoft SQL Server Management Studio，对象资源管理器中--安全性--登陆名，  
右键各个用户--属性--常规--强制实施密码策略、强制密码过时策略；   
二、（数据库部署的操做系统中）控制面板--管理工具--本地安全设置--账户策略--密码策略：   
（1）、密码必须符合复杂性要求；   
（2）、密码长度最小值；   
（3）、密码最长使用期限；   
（4）、密码最短使用期限；   
（5）、强制密码历史；  
 三、在SQL 查询分析器中执行 Use master； Select name，Password from syslogins where password is null 或 使用数据库扫描软件，查看扫描结果中是否存在空口令/弱口令的用户。 
建议整改：  
（一）策略修改  
一、每一个用户须要勾选“强制实施密码策略”；  
二、密码必须符合复杂性要求已启用，密码长度最小值0个字符，密码最短使用期限0天，密码最长使用期限42天，0个记住密码  
三、未发现弱口令、空口令用户  

•     c)应启用登陆失败处理功能，可采起结束会话、限制非法登陆次数和自动退出等措施；

•     整改方法：

•     验证检查：  
一、打开Microsoft SQL Server Management Studio，对象资源管理器中--安全性--登陆名，  
右键各个用户--属性--常规--强制实施密码策略； 
 二、控制面板--管理工具--本地安全设置--账户策略--帐户锁定策略：   
（1）、复位账号锁定计数器；   
（2）、帐户锁定时间；  
（3）、帐户锁定阀值。  
建议整改：  
（一）策略修改  
一、每一个用户须要勾选“强制实施密码策略”；  
二、帐户锁定时间30分钟，帐户锁定阈值5次无效登陆，重置帐户锁定计数器30分

•     f)应采用两种或两种以上组合的鉴别技术对管理用户进行身份鉴别。

•     整改方法：

•     验证检查：  
一、采用令牌、USB-KEY或智能卡等身份认证技术手段对用户进行身份鉴别  
建议整改：  
部署双因素产品或者堡垒机

• 访问控制

•     d)应严格限制默认账户的访问权限，重命名系统默认账户，修改这些账户的默认口令；

•     整改方法：

•     验证检查：  
打开Microsoft SQL Server Management Studio，对象资源管理器中--安全性--登陆名，查看是否存在sa账号。  
建议整改：  
（一）策略修改  
一、对sa用户重命名

• 安全审计

•     a)审计范围应覆盖到服务器和重要客户端上的每一个操做系统用户和数据库用户；

•     b)审计内容应包括重要用户行为、系统资源的异常使用和重要系统命令的使用等系统内重要的安全相关事件；

•     c)审计记录应包括事件的日期、时间、类型、主体标识、客体标识和结果等；

•     d)应可以根据记录数据进行分析，并生成审计报表；

•     e)应保护审计进程，避免受到未预期的中断；

•     f)应保护审计记录，避免受到未预期的删除、修改或覆盖等。

•     总体分析

•     整改方法：

•     验证检查：  
打开Microsoft SQL Server Management Studio，对象资源管理器中，右键服务器--属性--安全性   
一、登陆审核；  
二、启用C2审核跟踪。  
建议整改：  
（一）策略修改  
一、勾选仅限失败的登陆， 勾选启用C2审核跟踪  
（二）设备和服务部署  
部署数据库审计系统  
1.2.2. mysql数据库

• 身份鉴别

•     b)操做系统和数据库系统管理用户身份标识应具备不易被冒用的特色，口令应有复杂度要求并按期更换；

•     整改方法：

•     验证检查：  
一、使用的口令（如默认账号root）是否复杂度，而且是否认期进行更换  
建议整改：  
（一）策略修改  
一、用户口令长度8位，至少由字母、数字及字符两种以上的组合；  
二、按期更换口令。

•     c)应启用登陆失败处理功能，可采起结束会话、限制非法登陆次数和自动退出等措施；

•     整改方法：

•     验证检查：  
一、是否有登陆失败处理措施  
建议整改：  
使用了第三方技术实现了登陆失败处理功能。

•     e)应为操做系统和数据库系统的不一样用户分配不一样的用户名，确保用户名具备惟一性；

•     整改方法：

•     验证检查：  
一、否存在多个用户使用同一账号的状况。 
建议整改：  
一、不使用同一账号进行管理

•     f)应采用两种或两种以上组合的鉴别技术对管理用户进行身份鉴别。

•     整改方法：

•     验证检查：  
一、是否采用两种或两种以上组合的鉴别技术对管理用户进行身份鉴别，且其中一种是不可伪造的  
建议整改：  
一、采用令牌、USB-KEY或智能卡进行身份鉴别（部署双因子认证产品）

• 安全审计

•     a)审计范围应覆盖到服务器和重要客户端上的每一个操做系统用户和数据库用户；

•     b)审计内容应包括重要用户行为、系统资源的异常使用和重要系统命令的使用等系统内重要的安全相关事件；

•     c)审计记录应包括事件的日期、时间、类型、主体标识、客体标识和结果等；

•     d)应可以根据记录数据进行分析，并生成审计报表；

•     e)应保护审计进程，避免受到未预期的中断；

•     f)应保护审计记录，避免受到未预期的删除、修改或覆盖等。

•     总体分析

•     整改方法：

•     验证检查：  
一、是否数据库日志和审计功能是否开启 
二、是否对审计数据进行分析，并生成报表 
三、是否避免审计记录被删除、修改或覆盖，是否至少知足6个月  
四、是否认期进行数据备份，是否有数据恢复措施 
建议整改：  
（一）产品或服务部署  
数据库审计系统

•     日志或自带审计系统对性能影响巨大，产生大量文件消耗硬盘空间，事实上中大型系统都不能使用，或只能在排查问题时偶尔使用;日志系统不直观、易篡改、不完整、难管理;没法自动智能设置规则; 另外，从安全管控的标准及法规角度来看，也须要第三方独立的审计设备。

• 入侵防范

•     a)应可以检测到对重要服务器进行入侵的行为，可以记录入侵的源IP、攻击的类型、攻击的目的、攻击的时间，并在发生严重入侵事件时提供报警；

•     b)应可以对重要程序的完整性进行检测，并在检测到完整性受到破坏后具备恢复的措施；

•     c)操做系统应遵循最小安装的原则，仅安装须要的组件和应用程序，并经过设置升级服务器等方式保持系统补丁及时获得更新。

•     总体分析

•     整改方法：

•     建议整改：  
（一）产品或服务部署  
数据库防火墙

2.  应用安全

2.1.       身份鉴别

  b)应对同一用户采用两种或两种以上组合的鉴别技术实现用户身份鉴别

整改方法：

验证检查：  
一、是否采用两种或两种以上组合的鉴别技术实现用户身份鉴别  
建议整改：  
一、采用双因素认证产品  
  

d)应提供登陆失败处理功能，可采起结束会话、限制非法登陆次数和自动退出等措施；

e)应启用身份鉴别、用户身份标识惟一性检查、用户身份鉴别信息复杂度检查以及登陆失败处理功能，并根据安全策略配置相关参数。

总体分析

整改方法：

验证检查：  
一、连续屡次输入口令错误，是否有帐号锁定或者退出客户端登陆等措施  
建议整改：  
一、屡次输入错误口令，系统应该锁定帐号和退出客户端等措施

2.2.       安全审计

a)应提供覆盖到每一个用户的安全审计功能，对应用系统重要安全事件进行审计；

b)应保证没法单独中断审计进程，没法删除、修改或覆盖审计记录；

c)审计记录的内容至少应包括事件的日期、时间、发起者信息、类型、描述和结果等；

d)应提供对审计记录数据进行统计、查询、分析及生成审计报表的功能。

总体分析

整改方法：

验证检查：  
一、是否有安全审计功能模块，包括到每一个用户的安全审计功能（备注：用户应该包括内部运维用户和使用者用户）  
二、是否审计进程能中断，审计记录是否能被删除、修改和覆盖  
三、审计的记录至少包括：时间、日期、发起者信息、类型、描述和结果  
四、是否对审计记录进行查询、分析、统计和生成审计报表  
建议整改：  
一、审计包括客户及内部人员，包括应用系统的重要安全事件：帐户创建、用户权限分配、重要业务数据操做、用户身份鉴别失败等（备注：审计的内容会根据每个行业的业务方向有所不一样）  
二、审计记录至少保存6个月  
三、审计记录须要按期进行查询、分析，生成对应的审计报表

软件容错

a)应提供数据有效性检验功能，保证经过人机接口输入或经过通讯接口输入的数据格式或长度符合系统设定要求；

b)应提供自动保护功能，当故障发生时自动保护当前全部状态，保证系统可以进行恢复。

总体分析

整改方法：

验证检查：  
一、检查系统是否在数据输入界面对无效或非法的数据进行校验  
二、是否对数据的格式或长度进行校验 
三、检查系统返回的错误信息中是否含有sql语句、sql错误信息以及web服务器的绝对路径等 
四、若系统有上传功能，尝试上传与服务器端语言（jsp、asp、php）同样扩展名的文件或exe等  
可执行文件后，确认在服务器端是否可直接运行 
建议整改：  
一、注册用户是否能够'—'、‘1=1’等恒等式用户名  
二、上传给服务器的参数（如查询关键字、url中的参数等）中包含特殊字符是否能正常处理  
三、不存在SQL注入、XSS跨站脚本等漏洞  
四、部署WAF或网页防篡改等第三方产品

 

资源控制

a)当应用系统的通讯双方中的一方在一段时间内未做任何响应，另外一方应可以自动结束会话；

b)应可以对系统的最大并发会话链接数进行限制；

c)应可以对单个账户的多重并发会话进行限制；

d)应可以对一个时间段内可能的并发会话链接数进行限制；

e)应可以对一个访问账户或一个请求进程占用的资源分配最大限额和最小限额；

f)应可以对系统服务水平下降到预先规定的最小值进行检测和报警；

g)应提供服务优先级设定功能，并在安装后根据安全策略设定访问账户或请求进程的优先级，根据优先级分配系统资源。

总体分析

整改方法：

验证检查：  
一、系统是否具备超时结束会话功能 
二、系统是否有最大并发会话链接数限制 
三、系统是否限制单个用户多重并发会话数 
四、系统是否设置资源限额  
建议整改：  
一、可以在合理的时间内结束超时空闲会话 
二、禁止同一个用户同时登陆系统操做（备注：根据自身业务状况而定）  
三、可以对一个访问帐户或一个请求进程占用的资源分配最大和最小限额

3.  数据库安全及备份恢复

3.1.       备份和恢复

b)应提供异地数据备份功能，利用通讯网络将关键数据定时批量传送至备用场地；

整改方法：

建议整改：  
网络和安全设备的策略配置文件进行异地备份，数据库数据进行异地备份；

4.  系统运维管理

4.1.       监控管理和安全管理中心

b)应组织相关人员按期对监测和报警记录进行分析、评审，发现可疑行为，造成分析报告，并采起必要的应对措施；

整改方法：

建议整改：  
一、对监测和告警记录有按期的分析报告和对应措施

c)应创建安全管理中心，对设备状态、恶意代码、补丁升级、安全审计等安全相关事项进行集中管理。

整改方法：

建议整改：  
一、创建安全管理中心，对设备状态、恶意代码、补丁升级、安全审计等安全相关事项进行集中管理

 

网络安全管理

d)应按期对网络系统进行漏洞扫描，对发现的网络系统安全漏洞进行及时的修补；

整改方法：

建议整改：  
一、按期的网络设备扫描，并有扫描报告和整改结果

h)应按期检查违反规定拨号上网或其余违反网络安全策略的行为。

整改方法：

建议整改：  
一、用户单位按期检查违反规定拨号上网或其余违反网络安全策略的行为

4.2.       系统安全管理

b)应按期进行漏洞扫描，对发现的系统安全漏洞及时进行修补；

整改方法：

建议整改：  
一、按期扫描系统漏洞，及时安装安全补丁，及时进行漏洞修补

c)应安装系统的最新补丁程序，在安装系统补丁前，首先在测试环境中测试经过，并对重要文件进行备份后，方可实施系统补丁程序的安装；

整改方法：

建议整改：  
一、及时作补丁修补，且安装前补丁通过测试和系统备份

g)应按期对运行日志和审计数据进行分析，以便及时发现异常行为。

整改方法：

建议整改：  
一、按期对运行日志和审计数据进行分析

4.3.       恶意代码防范管理

b)应指定专人对网络和主机进行恶意代码检测并保存检测记录；

整改方法：

建议整改：  
一、有专人对网络和主机进行恶意代码检测，并保存检测记录

d)应按期检查信息系统内各类产品的恶意代码库的升级状况并进行记录，对主机防病毒产品、防病毒网关和邮件防病毒网关上截获的危险病毒或恶意代码进行及时分析处理，并造成书面的报表和总结汇报。

整改方法：

建议整改：  
一、对系统内的恶意代码防范产品的升级状况予以按期检查和记录，并对安全日志进行按期分析并造成报告

4.4.       备份与恢复管理

e)应按期执行恢复程序，检查和测试备份介质的有效性，确保能够在恢复程序规定的时间内完成备份的恢复。

整改方法：

建议整改：  
一、按期测试备份介质的有效性，按期执行恢复程序，肯定在规定的时间内完成备份恢复

4.5.       应急预案管理

c)应对系统相关的人员进行应急预案培训，应急预案的培训应至少每一年举办一次；

整改方法：

建议整改：  
一、对系统相关人员进行应急预案的培训，培训至少每一年举办一次，并保留培训记录

d)应按期对应急预案进行演练，根据不一样的应急恢复内容，肯定演练的周期；

整改方法：

建议整改：  
一、按期对应急预案进行演练，并保留演练记录

5.  系统建设管理

5.1.       产品采购和使用

d)应预先对产品进行选型测试，肯定产品的候选范围，并按期审定和更新候选产品名单。

整改方法：

建设整改：  
有产品选型测试记录或选型报告、候选产品名单（或候选供应商名录）并按期更新

5.2.       外包软件开发

d)应要求开发单位提供软件源代码，并审查软件中可能存在的后门。

整改方法：

建议整改：  
一、在软件开发协议中，规定开发单位提供软件源代码，并进行后门审查

5.3.       测试验收

a)应委托公正的第三方测试单位对系统进行安全性测试，并出具安全性测试报告；

整改方法：

建议整改：  
一、委托公认的第三方测评单位对系统进行安全测评，并有测试报告

6.  人员安全管理

6.1.       人员考核

a)应按期对各个岗位的人员进行安全技能及安全认知的考核；

b)应对关键岗位的人员进行全面、严格的安全审查和技能考核；

c)应对考核结果进行记录并保存。

总体分析

整改方法：

建议整改：  
一、有按期安全技能和知识的考核，有考核记录 
二、有按期对关键岗位的安全考试，有考核记录

6.2.       安全意识的教育和培训

d)应对安全教育和培训的状况和结果进行记录并归档保存。

整改方法：

建议整改：  
一、对培训的记录和结果归档保存

7.  安全管理机构

7.1.       人员配备

b)应配备专职安全管理员，不可兼任；

整改方法：

建议整改：  
一、配备安全管理员，安全管理员可兼任非系统维护工做

c)关键事务岗位应配备多人共同管理。

整改方法：

建议整改：  
一、关键岗位设置多人或AB角

7.2.       受权和审批

d)应记录审批过程并保存审批文档。

整改方法：

建议整改：  
一、保存审批记录

7.3.       沟通和合做

a)应增强各种管理人员之间、组织内部机构之间以及信息安全职能部门内部的合做与沟通，按期或不按期召开协调会议，共同协做处理信息安全问题；

整改方法：

建议整改：  
一、按期召开信息安全会议，保存有会议纪要

e)应聘请信息安全专家做为常年的安全顾问，指导信息安全建设，参与安全规划和安全评审等。

整改方法：

建议整改：  
一、聘请信息安全专家

7.4.       审核和检查

a)安全管理员应负责按期进行安全检查，检查内容包括系统平常运行、系统漏洞和数据备份等状况；

整改方法：

建议整改：  
一、按期进行安全检查，有检查内容及结果记录文档

b)应由内部人员或上级单位按期进行全面安全检查，检查内容包括现有安全技术措施的有效性、安全配置与安全策略的一致性、安全管理制度的执行状况等；

整改方法：

建议整改：  
一、内部或上级单位按期全面检查，或行业主管部门委托第三方进行检查

c)应制定安全检查表格实施安全检查，汇总安全检查数据，造成安全检查报告，并对安全检查结果进行通报；

整改方法：

建议整改：  
一、保存有安全检查记录和检查报告

8.  安全管理制度

8.1.       制定和发布

c)应组织相关人员对制定的安全管理制度进行论证和审定；

整改方法：

建议整改：  
只要有证据（邮件、会议纪要、OA系统中流转记录、文件评审记录等）代表在安全管理制度发布前已进行相关的论证和审定

8.2.       评审和修订

a)信息安全领导小组应负责按期组织相关部门和相关人员对安全管理制度体系的合理性和适用性进行审定；

整改方法：

建议整改：  
一、没有至少评审一次  
二、至少有评审记录

b)应按期或不按期对安全管理制度进行检查和审定，对存在不足或须要改进的安全管理制度进行修订。

整改方法：

建议整改：  
一、每一年至少评审一次  
二、文件修改记录  三、文件评审记录