二级等保应用检查项.docx

二级等保应用检查项.docx

《二级等保应用检查项.docx》由会员分享，可在线阅读，更多相关《二级等保应用检查项.docx（7页珍藏版）》请在冰豆网上搜索。

二级等保应用检查项

二级等保应用安全现场检查项整理

说明

文档基于《财政信息化项目管理系统》现场检查内容进行整理，不能代表其他系统的现场检查。

检查过程

检查组一人到现场基于《二级等保检查项》模板对建设方进行提问，提问内容基本不会偏离模板内容。

注意：

对于容易展现的检查项，检查组可能会要求建设方进行现场操作演示，因此对于一些容易重现的问题应尽量不要以欺瞒的方式回答。

举例说明：

“用户密码是否以加密方式存储”，可以通过查询数据直观的体现出来，属于容易重现的检查项；而“系统传输过程中是否对数据进行加密”，验证这个问题则需要通过开发环境进行体现，属于不易重现的检查项，对于此类检查项，检查组人员一般不会要求通过系统进行重现。

身份鉴别

应提供专用的登录控制模块对登录用户进行身份标识和鉴别；

检查系统是否有登录环节。

（一般系统都会有登录环节，不需关心）

应提供用户身份标识唯一和鉴别信息复杂度检查功能，保证应用系统中不存在重复用户身份标识，身份鉴别信息不易被冒用；

检查登录时信息是否能够唯一标示一个用户。

（一般系统都有此限制，不需关心）

检查密码的复杂度。

（二级等保要求密码长度为8位，并以数字+字母组合）

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

检查是否有多次登录失败的处理机制。

（一般都是通过增加登录失败计数器机制实现登录失败处理（每次登录失败后计数器+1，当计数器达到一定数值时进行失败处理，当用户登录成功后计数器清零），目前主流的处理方式有两种：

一是锁定用户，需要管理员进行解锁后才可再次使用；二是限制登录时间，比如10分钟后才可再次尝试登录）

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

检查是否可以绕过登录模块进入系统（直接在URL中录入某功能的页面URL）。

（一般情况下业务系统都会以登录人的信息来取得相应的业务功能和业务数据，因此大多数情况下不登录是无法正常使用系统功能的。

当然，有一个统一的检查逻辑是最好的，常见的处理手段为检查session中是否有用户登录信息，如无则跳转到错误处理逻辑）

访问控制

应提供访问控制功能，依据安全策略控制用户对文件、数据库表等客体的访问；

检查是否有可越权访问情形；（本次检查时检查人员仅提问了登录后用户能不能访问不该其使用的功能，我们回复每个用户都有功能权限，在登录后会根据功能权限仅展示用户有权限使用的功能。

）

个人理解：

该项应该是检查用户是否能够在系统中通过非常规手段获取到用户受权以外的信息。

访问控制的覆盖范围应包括与资源访问相关的主体、客体及它们之间的操作；

检查系统能否根据访问控制规则正确实施对资源的控制；（未提问，个人理解为系统功能、数据权限是否能够正常工作）

检查访问控制主体、客体；（未提问，个人理解，控制主体应为具体操作者，本系统中控制主体为用户；客体为主体能够操控的内容，本系统中客体对应系统功能、业务数据）

检查访问控制功能是否能够覆盖范围包括与资源访问相关的主体、客体及它们之间的操作；（个人理解，与之前的检查项相同，是对系统权限的严谨性进行检查，比如能否通过URL的方式直接访问无权限的功能）

应由授权主体配置访问控制策略，并严格限制默认帐户的访问权限；

检查实际授权与权限策略是否一致，无法进行越权操作；（个人理解，同样是对权限模板的正确性进行检查）

检查系统是否存在权限不受限制的超级管理员，系统不应该存在不受限的超管；（个人理解，该超级管理员与我们所理解的管理员不太一样，该超级管理员应指的是不受功能、数据权限约束的账号；而目前大多系统中管理员都是受到功能、数据权限约束，除了配给的功能和数据权限较大之外，其本质与一般用户并无差别）

应授予不同帐户为完成各自承担任务所需的最小权限，并在它们之间形成相互制约的关系。

检查系统管理模式是否符合三员管理；（三员管理指将系统管理员的日常管理功能进行拆分；其中：

系统管理员主要负责系统的日常运维工作，配给功能包含在系统运行情况监控、用户管理、系统备份恢复等功能；安全管理员：

主要负责系统的日常安全管理工作，配给功能包含在资源分配、权限管理等功能；审计员：

主要负责根据日志对管理员的操作行为进行审订跟踪、分配和监督检查，配给功能包含在日志查询、分析等功能。

）

安全审计

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

检查系统日志管理功能是否涵盖了系统重要业务；（要求日志应记录在数据库中，且除重要业务操作外，对于登录、用户的调整、授权的变更也需要记录）

应保证无法删除、修改或覆盖审计记录；

检查操作记录是否数据库存储，并且是否不能通过应用系统删除、修改和覆盖操作日志；（要求日志应记录在数据库中，且不能通过系统功能对日志进行篡改）

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

检查日志记录内容是否包括事件的日期、时间、发起者信息、类型、描述和结果。

（要求日志的内容应包含操作时间、操作人、操作事件说明、操作结果等要素）

通信完整性

应采用校验码技术保证通信过程中数据的完整性；

未检查，个人理解为应通过一定技术手段来防止数据在传输过程丢失或被篡改。

技术实现：

如使用https协议；或利用MD5码机制，在数据传输前利用传输数据生成MD5码并与数据一同传输到接收端，接收端接收到数据后再次利用数据生成MD5码，并与传输前MD5码进行比较，相同则未丢失或被篡改。

（通信不仅是指多个系统间的交互，同一系统间前台访问后台的过程也是一次通信。

）

通信保密性

在通信双方建立连接之前，应用系统应利用密码技术进行会话初始化验证；

个人理解为在与其他系统进行交互前应通过密码或其他安全手段对通信双方身份进行鉴别。

常见有以双方约定口令的方式进行验证，更安全的可以利用非对称加密手段进行校验。

本系统中因没有与其他系统交互的业务，因此在检查时仅提问了使用了哪种网络协议（http协议），以及使用系统前用户是否需要登录。

应对通信过程中的敏感信息字段进行加密；

个人理解为在通信过程（通信不仅是指多个系统间的交互，同一系统间前台访问后台的过程也是一次通信。

）中是否对敏感数据进行了加密。

由于部署网络、业务范畴、安全定级（二级）等因素的综合考虑，本系统中只有用户密码为敏感信息。

软件容错

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

检查系统是否对录入项进行了控制，比如字段类型、长度等限制；（举例说明：

比如某项数据应为数值型，那么在录入时就应控制其只可录入数值；又如数据库某字段长度为10，那么在录入时应控制其数据长度不应超过10）

检查系统是否对SQL注入攻击进行了必要的安全处理；（本系统所有SQL语句都使用预编译（PreparedStatement）的方式进行处理，最大程度上保证系统不会被SQL注入攻击影响）

在故障发生时，应用系统应能够继续提供一部分功能，确保能够实施必要的措施；

二级等保应采用双机热备的方式保障某台机器发生故障时应有备用机可以使用。

（需要甲方提供硬件支持）

资源控制

当应用系统的通信双方中的一方在一段时间内未作任何响应，另一方应能够自动结束会话；

检查系统是否有session超时处理。

（中间件都可以配置session超时时间）

应能够对应用系统的最大并发会话连接数进行限制；

检查系统是否有最大连接数限制。

（中间件都可以配置最大并发数，而JDBC配置可以限制数据库的最大连接数）

应能够对单个帐户的多重并发会话进行限制；

检查系统是否限制了单用户同时多处登录的情况。

（分为拒绝登录和强制顶替两种实现方式，两种方式都是基于在登录时将登录信息记录到application中，之后再通过信息进行判重。

但拒绝登录无法及时获取用户退出信息，因此建议使用强制顶替方式实现）

数据完整性

应能够检测到鉴别信息和重要业务数据在传输过程中完整性受到破坏；

同通信完整性

数据保密性

应采用加密或其他保护措施实现鉴别信息的存储保密性；

同通信保密性

备份和恢复

应能够对重要信息进行备份和恢复；

检查是否定期对数据库进行备份，备份周期是什么。

应提供关键网络设备、通信线路和数据处理系统的硬件冗余，保证系统的可用性；

未提问，个人理解是应有备用的硬件设备，当系统硬件出现问题时有备用件可及时更换。

（需要甲方储备）

总结

根据本项目现场检查结果，符合二级等保的系统应具备如下条件：

1.系统具体通过用户名和密码登录系统的功能，用户的密码要具备一定强度并且要加密传输、存储，连续多次登录失败后应进行必要的处理以防恶意登录。

2.系统应具备完善的权限管理机制，保证用户不能访问其没有权限的功能和数据。

3.系统重要功能的操作要有日志可查。

4.系统应对录入数据进行必要的校验，并且要做好SQL注入攻击的防范。

5.系统应限制session过期时间，线程、连接数最大值；以及防止单用户重复登录的场景。

6.在项目包含硬件的情况下应具备双机热备机制；在系统硬件非甲方统一管理的情况下应具备定期备份的机制。