一、 身份鉴别

a）应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换

这里的身份标识和鉴别，说的就是用户名和口令了，具体表现出来就是你进入某个应用系统的管理后台，需要输入用户名以及口令，一般来说应用都是符合这个要求的。

身份标识具有唯一性，就是检查是否有同名账户，可以在征得管理员同意后，试着新建一个已存在账户的同名账户，看是否能创建成功。这里还有一个隐藏的要求是，查看有没有空口令账户，一般都是没有的。

身份鉴别信息具有复杂度要求，需要询问管理员，系统是否有登录密码的复杂度限制功能。

定期更换的要求，询问管理员，是否有限制密码周期的功能，上一次修改密码是什么时候。

高风险

1）根据中关村信息安全测评联盟发布的高风险判定指引文件，如果没有口令复杂度限制功能，属于高风险。

2）存在弱口令同样也是高风险。

b）应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施

登录失败处理，如果存在这个功能，一般就是连续登录失败几次后永久锁定或者锁定一段时间。存在相关的配置页面，就看看配置页面是怎么设置的；功能写在代码中的，最好还是测试一下，要经过管理员同意后再测试，以免影响业务，一般测试后会出现诸如“多次密码输入错误，账户被锁定，请在xx分钟后重新尝试登录”这样的警告。

超时自动退出，一般设置为10-15分钟，监控类系统可不设置。这个功能的，有配置页面的不多，一般都是在代码中或者配置文件（比如ASP.NET的web.config）中实现，不是很好找到明确的证据，最好还是实际试验下。等待一段时间后，刷新下，看看是否已经注销。

高风险

如果没有登录失败处理功能，将视为高风险。

c）当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听

此测评项要求，在远程管理登录应用系统的时候，身份鉴别信息禁止明文传输。首先查看这个网站是否使用了https协议，如果使用了，然后看一看使用http前缀是否能正常访问，有些网站没有做好配置，导致http和https都可以访问，要给http禁掉。

如果没有使用https，但是使用了客户端/前端加密，服务端解密这样的方式来防止明文传输，可酌情给予部分符合。

前端加密，一般都是使用md5算法计算出口令的hash值，然后再进行传输。如果前端传输口令hash值，而后端数据库存储的也仅仅只有口令的hash值，鉴别的方法就是对比前端传入的hash值是否与数据库中存储的hash值一致。在这种情况下，虽然前端传输的并非口令明文，但是实际上还是泄露了鉴别信息。这个时候，鉴别信息指的就不是口令，而是口令的hash值，此时，明文传输hash值就是明文传输鉴别信息。如果别人截取到口令的hash值，虽然不能够轻易获得原口令，但是可以使用该hahs值和用户名通过应用系统的鉴别。

也就是说，不能只在服务端，存储解密后的值，去对比前端加密后的值，服务端一定要有加解密的步骤，比如加盐。

当用户访问登录界面时，后端生成一个随机盐值（随机字符串），同时前端也得到这个字符串salt。此时，前端可以使用以下算法计算出一个hash值：MD5(MD5(password)+MD5(salt))。当然，这个算法你可以自己决定，根据实际情况进行嵌套使用，使用其他的hash算法都是可以的。

然后当这个hash值传输至后端后，数据库中存储的是MD5(password)，后端也有那个随机盐值salt，也可以使用同样的算法算出一个hash值，进行对比，即可得到结果。这样的话，别人截取到了这个hash值也没啥用，基本没有办法从hahs值逆向算出原文。这样就基本实现了鉴别信息防窃听的要求。

高风险

身份鉴别信息明文传输为高风险。

d）应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现

双因子认证，其中必须有一项是密码技术。用户名+密码属于是口令方式的认证，密码技术一般使用ukey实现身份认证。

管理员和内部用户强制使用，外部用户推荐使用。

高风险

对于三级及以上的系统，没有双因子认证是高风险。可根据补偿因素酌情判定风险等级。

二、 访问控制

a）应对登录的用户分配账户和权限

分配账户，顾名思义，给每一个人分配一个账户。

权限分配，看系统是否有权限分配的功能，不同的用户角色要有不同的权限。

b）应重命名或删除默认账户，修改默认账户的默认口令

一些出名的应用系统，其默认账户密码都在网上流传，应重命名或删除应用系统默认的账户，并且修改账户的默认口令。

高风险

默认口令未修改，应判定为高风险。

c）应及时删除或停用多余的、过期的账户，避免共享账户的存在

应核查是否存在多余、过期的账户；检查实际管理员用户与系统账户之间是否一一对应，是否存在共享账号的情况。一般符合。

d）应授予管理用户所需的最小权限，实现管理用户的权限分离

查看应用系统是否实行了三权分立，即系统管理员、安全管理员和审计管理员的权限分配。

如果没有三权分立，但是进行了最小权限的限制，也属于符合。

系统管理员：管理系统中的账户、文档、文件等；

安全管理员：管理系统的授权策略以及其它基本策略的设置，还有安全参数的设置。

审计管理员：对系统中审计策略的管理，比如日志的存储策略。

如果业务比较多，比如医院的系统、财务系统或者其他系统，权限本来就会分得比较细，甚至非常细。这种情况下，给个符合是没有多大问题的。

如果业务规模比较小，可能权限分配的粒度就非常粗了。比如某个应用系统就两个角色，一类是普通用户，一类是后台用户，一般都不符合最小权限的分配，可给部分符合。

e）应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则

应由授权主体配置访问控制策略，意思就是应该由管理员配置访问控制策略，普通用户不能有这种权限，基本上应用系统都符合。

访问控制策略规定主体对客体的访问规则，意思是要限制用户对资源的访问，只能访问自己权限下的模块或资源。

高风险

访问规则没配置好，有可能会导致越权访问或非授权访问，为高风险。

f）访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级

测评项的要求应该是层层递进的，测评项e要求你设置访问控制策略，f项则是要求你设置的访问控制的粒度达到“主体为用户级或进程级，客体为文件、数据库表级”。

所以在实际测评中，如果测评项e的结果是不满足，f项肯定也不满足。

对于大部分应用系统而言，其访问控制策略，是可以达到主体为用户级、客体为文件级的。

测评的时候，看策略是否明确到某个用户（而不仅仅是用户组），某个文件（不仅仅是文件夹）。

这里其实细究的话，从某个角度上来说，有一部分应用系统是不完全符合的。基本上应用系统的权限分配方式都是角色拥有权限，用户再属于某个角色，这样用户也就获得了权限。但是如果要达到访问控制的粒度为用户级，应该还要有一个功能，就是也能直接把某个具体的权限赋予给某个具体的用户。这样，粒度就确切的达到了用户级。否则，你想调整权限，实际就得调整角色的权限，角色下面有多个用户，你就相当于调整了某一类用户的权限。除非你为了实现细粒度的控制，某些角色下面只有一个用户。当然，实际测评中根据具体情况进行结果判定，没有必要这么深究。

访问控制的粒度达到表级，这里并不是让你跑去数据库中进行查看，直接在应用系统中判断就好。应用系统中一个表单页面可以大概的类比于数据库中的一个表，比如个人信息表、业务表等。所以这个就是要看权限分配的时候，是否能直接对表单页面的权限进行分配，比如允许访问什么的。表单页面的权限一般就是功能栏、菜单栏的权限分配，大部分应用系统都可以做到。甚至有些做得更细致，比如细致到某个表单的按钮的权限上。

g）应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问。

对重要主体设置安全标记，上文中讲到用户可以被分配到某一个角色下面，那么只要把这个角色设置为重要的安全角色，并在权限上对此角色加以限制，就实现了对重要主体设置安全标记。

对客体设置安全标记，我的理解是，要让系统有这么一个功能：可以对重要的资源打“标签”，标记为敏感数据，限制用户（主体）对这些被打上安全标记的资源的访问。基本就没有能实现的，一般为不符合。

三、安全审计

a）应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计

检查应用系统是否有安全审计功能(专门的安全审计模块或不同模块中的审计功能);检查安全审计功能的范围是否覆盖所有用户，审计的安全事件是否合理，如是否包括应用系统重要安全事件 (如帐户建立、用户权限分配、重要业务数据操作、用户身份鉴别失败等行为)。

对于应用系统而言，最好的审计就是存在比较完善的操作日志，什么用户什么时间干了什么，都记录的清清楚楚，那就是绝对的符合。但是很多应用系统这方面的功能并不全，可能仅存在登录日志，但这也行，至少可以判定为部分符合。

如果被测评项系统找不到什么日志功能，可以考虑去业务流程模块去看看。很多政府部门的应用系统在业务流程记录这是很详细的，某人什么时候对某业务进行了什么操作，这也能判定为部分符合。

高风险

没有审计功能并且未采取其他审计措施即为高风险。

b）审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息

应核查审计记录信息是否包括事件的日期和时间、主体标识、客体标识、事件类型、事件是否成功及其他与审计相关的信息。

有什么字段就写什么字段，至少应该包括日期、用户、事件、具体操作这四个字段，要不然就是部分符合。

c）应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等

对审计记录进行保护，看应用系统有没有删除记录的功能，一般是没有的，非要删除就得跑去数据库或服务器上删除，这种情况是符合的。如果存在删除功能，比如日志删除的按钮，就要看是这个按钮的权限是如何分配的，是否仅分配给管理员账户。

定期备份，如果记录存储在数据库中，看数据库是否定期备份；如果记录存储在文件中，则看文件是否定期备份。留存时间要大于6个月，查看最早的记录距离现在是否超过6个月。

高风险

审计记录能被恶意删除，高风险；日志留存时间少于6个月，高风险（除非应用系统的上线时间少于6个月）。

d）应对审计进程进行保护，防止未经授权的中断

对应用系统进行测试。如果审计模块是一个单独的进程，则尝试非授权中断审计进程，查看是否成功；如果审计模块是一个独立的功能，则尝试非授权关闭审计功能，查看是否成功。

大部分情况是审计进程与应用进程为同一个，无法被独立中断。审计进程随应用启动而启动，应用系统界面无关闭审计按钮，审计功能无法单独关闭。如果有设置关闭功能的话，要看看这个关闭功能是否只有管理员有权限。

四、入侵防范

a）应遵循最小安装的原则，仅安装需要的组件和应用程序

根据GB/T 28448-2019《信息安全技术网络安全等级保护测评要求》测评对象范围描述，应用系统无该项要求。此控制项测评对象针对服务器，不包含业务应用系统，此项不适用。

b）应关闭不需要的系统服务、默认共享和高危端口

根据GB/T 28448-2019《信息安全技术网络安全等级保护测评要求》测评对象范围描述，应用系统无该项要求。此控制项测评对象针对服务器，不包含业务应用系统，此项不适用。

c）应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制

根据GB/T 28448-2019《信息安全技术网络安全等级保护测评要求》测评对象范围描述，应用系统无该项要求。此控制项测评对象针对服务器，不包含业务应用系统，此项不适用。

d）应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求

数据有效性检验，就是对用户输入的数据进行过滤，是否符合应用系统所要求的数据格式、类型。人机接口和通信接口，指的就是输入框。

1、检查系统是否在数据输入界面对无效或非法数据进行检验，如注册用户时是否可以以-- or1=1--等做为用户名，传送给服务器的参数(如查询关键字、url中的参数等)中包含特殊字符( or1'='1,and 1=1--，and 1=0--or 1=0--)时是否可以正常处理；

2、除特殊字符校验外，还应添加对数据有效性的校验，如尝试输入长度不符合要求，只允许输入数字的地方输入字母等查看系统反应，比如要求输入金额、数字的地方，输入字母等非法数据是否可以提交。或者输入负数。

3、检查系统返回的错误信息中是否含有sql语句、sql错误信息以及web服务器的绝对路径等;

测试的时候一定要经过系统管理员的同意。

高风险

基本上应用系统都有数据有效性检验功能，但是如果检验不严谨导致系统出现了高危漏洞并且未采取防护手段，就得判定为高风险了。

e）应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞

应能发现可能存在的已知漏洞，询问管理员是否定期对应用系统进行漏洞扫描或者渗透测试（对于c/s架构以渗透为主），或购买了这样的安全服务。然后，如果对方说有，就让其提交相关的扫描报告、渗透报告。

高风险

这个就需要看测评过程中，渗透部的同事对应用系统进行漏洞扫描、渗透测试的时候，有没有发现高危漏洞。如果有就高风险，说明管理员做定期漏扫的时候没扫出来，有安全风险。

f）应能够检测到对重要节点进行入侵的行为，并在发生严重入侵事件时提供报警

根据GB/T 28448-2019《信息安全技术网络安全等级保护测评要求》测评对象范围描述，应用系统无该项要求。此控制项测评对象针对服务器，不包含业务应用系统，此项不适用。

五、可信验证

a）可基于可信根对计算设备的系统引导程序、系统程序、重要配置参数和应用程序等进行可信验证，并在应用程序的关键执行环节进行动态可信验证，在检测到其可信性受到破坏后进行报警，并将验证结果形成审计记录送至安全管理中心。

此控制项测评对象针对服务器，不包含业务应用系统，此项不适用。

六、数据完整性

a)应采用校验技术或密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等

完整性：是指保持信息不被破坏或修改、不丢失和信息未经授权不能改变的特性，也是最基本的安全特征。

对于B/S类型的应用系统来说，一般都是使用HTTPS协议，HTTPS协议同时实现了保密性和完整性。

而对于C/S类型的应用系统来说，如果是直接连接数据库的那种，要看数据库是否配置了SSL，在连接的时候是否使用了SSL。

以下是指导书内容：

1、可访谈系统开发人员，询问系统在通信过程中是否采用密码技术(RSA数字签名等算法，加密机、VPN通道等技术)或采用SSL (https)协议传输数据，以保证数据在通信过程中的完整性;

2、可结合案例验证，如通过获取网络通信数据包，查看通信报文是否含有用于完整性保护的验证信息。比如数据包中含有使用密码技术生成的用于完整性保护的MAC校验信息。

1和2任一符合即可判定此项符合。

高风险

对于三级及以上的系统，数据传输的过程中没有保护措施即为高风险。

b)应采用校验技术或密码技术保证重要数据在存储过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等

这里要注意和传输过程分开区别，传输过程是一个短暂的、动态的、进行过程，而这里的存储则其实应该理解为长期的保存的过程。

应用系统中，一般都会将重要的数据存储到数据库当中。应当询问管理员，是否采用了密码技术存储数据，使用了什么加密算法，比如SM4加密算法。

七、数据保密性

a）应采用密码技术保证重要数据在传输过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等

对于B/S类型的应用系统来说，一般都是使用HTTPS协议，HTTPS协议同时实现了保密性和完整性。

而对于C/S类型的应用系统来说，如果是直接连接数据库的那种，要看数据库是否配置了SSL，在连接的时候是否使用了SSL。

高风险

对于三级及以上的系统，数据明文传输是高风险项。

b）应采用密码技术保证重要数据在存储过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等

询问管理员，是否采用了密码技术存储数据，使用了什么加密算法，比如SM4加密算法。

高风险

对于三级及以上系统，没有加密存储即为高风险项。

八、剩余信息保护

a）应保证鉴别信息所在的存储空间被释放或重新分配前得到完全清除

测试用户退出登录后，按后退按钮能否访问之前的页面；

关闭浏览器或客户端后再次打开系统，看是否留存有上次登录的身份鉴别信息。若没有留存为符合。

高风险

留存身份鉴别信息且没有其他措施降低风险的，视为高风险项。

b）应保证存有敏感数据的存储空间被释放或重新分配前得到完全清除

测试应用系统，用某用户登录系统并进行操作，在该用户退出后用另一用户登录，试图操作(读取、修改或删除等)其他用户产生的文件、目录和数据库记录等资源，查看是否成功，验证系统提供的剩余信息保护功能是否正确(确保系统内文件、目录和数据库记录等资源所在的存储空间被释放或重新分配给其他用户前得到完全清除) 。

检查用户退出应用系统(正常退出和非强制关闭)后，应用系统和操作系统临时文件(IE临时文件目录、用户cookies目录、temp目录等)中是否有残留的用户敏感信息(如网上银行访问后在E临时目录里可以找到查询资金余额页面的相关敏感信息)。

高风险

对于三级及以上系统，退出登录后留存有敏感数据的，高风险。

九、个人信息保护

a）应仅采集和保存业务必需的用户个人信息

访谈业务人员了解系统收集和保存哪些个人信息，并在系统中确认相关情况；

核查有关用户个人信息保护的管理制度、用户协议书和流程，查看与系统是否保持一致。

在结果记录中，写系统收集了哪些个人信息，例如：姓名、电话等；如果该应用系统没有收集个人信息，标记为不适用项。

高风险

一般应用系统采集的都是业务必需的个人信息，很少有违规采集的。

b）应禁止未授权访问和非法使用用户个人信息

访谈业务人员了解系统如何授权访问个人信息，并在系统中确认相关情况；

核查有关用户个人信息保护的管理制度、用户协议书和流程，查看与系统是否保持一致。

一般应用系统都是通过访问控制功能限制非管理员账户无法访问用户个人信息，只有管理员可以访问这些信息；

有些单位会制定有保密协议条款，协议中有对个人信息的保密规定。

高风险

对于收集到的个人信息要严格管理。