💡 写在前面：去年甲方公司产品交付因为等保2.0测评没过，被监管部门要求整改，项目上线推迟了整整一个月，直接经济损失达200万。作为测试负责人，我全程参与了测评过程，踩了不少坑，也积累了不少经验。今天把等保2.0测评的核心知识点、检查清单、实战案例详细整理出来，希望对大家有帮助。

一、等保2.0详解：概念、等级、法律依据

1.1 什么是等保2.0

等保2.0（信息安全技术 网络安全等级保护基本要求 GB/T 22239-2019）是中国网络安全领域的基本国策，于2019年5月10日发布，2019年12月1日正式实施，替代了之前的等保1.0标准（GB/T 22239-2008）。

📌 核心要点

等保 = 等级保护 = 对信息系统分等级实行安全保护

2.0 = 第二版标准 = 更全面、更严格、更适应新技术

法律地位：《网络安全法》第二十一条明确规定，国家实行网络安全等级保护制度。


1.2 等保2.0的五个安全保护等级

等级
适用对象
损害程度
测评频率
一级
一般信息系统
损害公民、法人和其他组织的合法权益
不做强制要求
二级
县级重要信息系统
严重损害社会秩序和公共利益
每2年至少1次
三级
地市级以上重要信息系统
特别严重损害社会秩序和公共利益，或损害国家安全
每年至少1次
四级
国家级重要信息系统
特别严重损害国家安全
每半年至少1次
五级
国家级极端重要信息系统
特别严重损害国家安全
依据特殊安全需求进行

💼 企业常见等级

• 二级：大多数中小企业的业务系统（OA、CRM、官网等）

• 三级：金融、医疗、教育、政府、电力、交通等行业的核心业务系统

• 四级：银行核心系统、电力调度系统、铁路信号系统等


1.3 等保2.0的法律依据

等保2.0不是”建议标准”，而是法律强制要求。主要法律依据：

⚠️ 不做等保的后果

1. 行政处罚：警告、罚款（最高100万）、停业整顿

2. 业务影响：系统不能上线、无法招投标、无法申请牌照

3. 刑事责任：导致重大安全事故的，可追究刑事责任

真实案例：2023年，某三甲医院因等保测评不通过，HIS系统被责令下线整改，影响数万患者就医。


二、等保2.0 vs 等保1.0：核心变化对比

等保2.0相比等保1.0，不是简单的”版本升级”，而是理念、范围、要求的全面革新。

对比维度
等保1.0（2008版）
等保2.0（2019版）
保护对象
传统信息系统（主机、网络、应用）
扩展到云计算、移动互联、物联网、工业控制系统、大数据平台
安全理念
被动防御（防外为主）
主动防御（内外兼防）+ 全生命周期保护
技术要求
5个方面：物理安全、网络安全、主机安全、应用安全、数据安全
5个层面：安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心
管理要求
5个方面：安全管理制度、安全管理机构、人员安全管理、系统建设管理、系统运维管理
5个方面（名称不变，内容细化）
控制项数量
二级：175个控制点
三级：290个控制点
二级：135个控制点
三级：190个控制点
（控制项更精简，但要求更具体）
测评方法
访谈、检查、测试
访谈、检查、测试、调研分析（增加”调研分析”）
云安全
基本不涉及
专门章节规定云计算安全扩展要求
个人信息保护
未明确提及
明确要求保护个人信息安全


🎯 等保2.0的核心变化总结

1. 对象扩展：从传统IT系统扩展到云计算、物联网、工控系统等

2. 理念升级：从”分级保护”到”分级保护+关键信息基础设施保护”

3. 要求强化：技术要求和管理要求更加细化和严格

4. 动态保护：强调全生命周期的持续保护，不是一次性测评

5. 合规处罚：与《网络安全法》等法律衔接，处罚力度大幅加强


三、等保2.0测评的完整流程（5大步骤详解）

等保2.0测评不是”一锤子买卖”，而是一个持续的过程。完整流程包括5个步骤：
步骤1：定级备案（1-2周）

目标：确定系统等级，到公安机关备案

主要工作：

  • 编写《系统定级报告》：说明系统功能、业务对象、服务范围、业务依赖度等
  • 组织专家评审：邀请3-5名网络安全专家对定级报告进行评审
  • 到公安机关网安部门备案：提交定级报告、专家评审意见、系统拓扑图等
  • 领取《备案证明》：公安机关审核通过后，发放备案证明

输出文档：《系统定级报告》、《备案证明》

测试工程师参与：提供系统功能说明、网络拓扑图等技术资料
步骤2：差距分析（2-4周）

目标：对照等保2.0标准，检查系统现状与要求的差距

主要工作：

  • 使用等保测评工具进行自动化扫描（漏洞扫描、配置核查、日志分析等）
  • 手工检查安全功能（身份认证、访问控制、审计日志等）
  • 访谈系统管理员、安全管理员、网络管理员等
  • 查阅安全管理制度、运维记录、培训记录等文档
  • 编写《差距分析报告》：列出所有不符合项，并评估风险等级

输出文档：《差距分析报告》、《整改建议书》

测试工程师参与：核心参与者，负责安全功能测试、漏洞扫描、渗透测试等
步骤3：整改加固（4-12周，视差距大小而定）

目标：针对差距项进行整改，使系统满足等保2.0要求

主要工作：

  • 制定《整改方案》：明确整改项、整改措施、责任人、时间计划
  • 技术整改：加固系统配置、修补漏洞、部署安全设备、完善安全功能等
  • 管理整改：完善安全管理制度、加强人员培训、规范运维流程等
  • 整改自测：对整改项进行自测，确认整改效果

输出文档：《整改方案》、《整改报告》、《自测报告》

测试工程师参与：核心参与者，负责整改验证测试、回归测试等
步骤4：等级测评（1-2周）

目标：委托有资质的测评机构进行正式测评

主要工作：

  • 选择测评机构：选择具有等保测评资质的第三方机构（全国约200家）
  • 签订测评合同：明确测评范围、测评内容、测评时间、费用等
  • 测评机构进场：测评师现场测评，包括工具扫描、手工测试、文档审查、人员访谈等
  • 整改不符合项：对测评中发现的不符合项进行整改（可能有多个轮次）
  • 出具测评报告：测评机构出具《网络安全等级保护测评报告》

输出文档：《网络安全等级保护测评报告》、《不符合项整改报告》

测试工程师参与：配合测评师工作，提供测试账号、测试环境、技术文档等
步骤5：监督检查（持续进行）

目标：公安机关定期对已备案系统进行监督检查

主要工作：

  • 每年自查：三级系统每年、二级系统每2年进行自查，并提交自查报告
  • 配合监督检查：公安机关可能不定期进行检查，需要配合提供资料
  • 重大变更重新测评：系统发生重大变更（如架构升级、新增模块、业务扩展等），需要重新测评
  • 证书到期续证：等保测评证书有效期3年，到期前需要重新测评

测试工程师参与：参与自查、配合检查、执行回归测试等

💡 时间规划建议

首次做等保测评的企业，建议预留3-6个月的时间。

• 定级备案：1-2周

• 差距分析：2-4周

• 整改加固：4-12周（主要时间消耗点）

• 等级测评：1-2周（不含整改轮次时间）

如果系统基础较好，整改量小，3个月可以完成；如果系统问题较多，可能需要6个月甚至更久。


四、等保2.0技术要求的检查清单（12大核心检查项）

等保2.0将安全要求分为安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心五个层面。

作为测试工程师，我们重点关注安全计算环境（应用系统安全）和安全管理中心（日志审计、集中管控）。以下是12大核心检查项：

🔍 检查项1：身份鉴别（必须全部通过）

检查内容：
测试方法：
# 测试1：密码复杂度验证 test_password_complexity() { # 测试弱密码，预期：系统拒绝 weak_passwords=(“123456” “password” “admin” “qwerty” “111111”) for pwd in “${weak_passwords[@]}”; do response=$(curl -X POST http://test.com/api/login \ -d “username=testuser&password=$pwd”) if [[ $response == *”success”* ]]; then echo “❌ 失败：弱密码 ‘$pwd’ 被接受” else echo “✅ 通过：弱密码 ‘$pwd’ 被拒绝” fi done # 测试强密码，预期：系统接受 strong_password=”Test@Pass123″ response=$(curl -X POST http://test.com/api/login \ -d “username=testuser&password=$strong_password”) if [[ $response == *”success”* ]]; then echo “✅ 通过：强密码被接受” else echo “❌ 失败：强密码被拒绝” fi } # 测试2：会话超时验证 test_session_timeout() { # 登录获取session session=$(login_and_get_session) # 等待16分钟（超过15分钟超时时间） sleep 960 # 尝试访问需要登录的页面，预期：重定向到登录页 response=$(curl -H “Cookie: session=$session” http://test.com/api/user/profile) if [[ $response == *”login”* ]]; then echo “✅ 通过：会话超时生效” else echo “❌ 失败：会话超时未生效” fi } # 测试3：鉴别信息加密验证（传输） test_password_transmission() { # 使用Burp Suite或Wireshark抓包，检查密码是否明文传输 # 预期：密码应该加密（如HTTPS、密码哈希等） # 也可以使用curl的–trace选项查看请求详情 curl –trace trace.log -X POST http://test.com/api/login \ -d “username=testuser&password=Test@Pass123” # 检查trace.log，确认密码未明文传输 if grep -q “Test@Pass123” trace.log; then echo “❌ 失败：密码明文传输” else echo “✅ 通过：密码未明文传输” fi }
常见问题：
整改方案：
// 整改1：密码复杂度校验（Java示例） public class PasswordValidator { public static boolean validate(String password) { // 长度至少8位 if (password.length() < 8) return false; // 包含大小写字母、数字、特殊字符中的至少3种 int types = 0; if (password.matches(“.*[a-z].*”)) types++; if (password.matches(“.*[A-Z].*”)) types++; if (password.matches(“.*\\d.*”)) types++; if (password.matches(“.*[!@#$%^&*()_+\\-=\\[\\]{};’:\”\\\\|,.<>/?].*”)) types++; return types >= 3; } } // 整改2：密码加密存储（使用BCrypt） public class PasswordService { public static String encrypt(String password) { return BCrypt.hashpw(password, BCrypt.gensalt(12)); } public static boolean verify(String password, String hashed) { return BCrypt.checkpw(password, hashed); } } // 整改3：会话超时配置（Spring Boot示例） // application.properties server.servlet.session.timeout=15m // 整改4：账户锁定（记录失败次数，达到阈值锁定） @Entity public class User { private int failedLoginAttempts; private Date lockoutTime; public boolean isLocked() { if (lockoutTime == null) return false; return new Date().before(lockoutTime); } public void recordFailedAttempt() { failedLoginAttempts++; if (failedLoginAttempts >= 5) { // 锁定30分钟 lockoutTime = new Date(System.currentTimeMillis() + 30 * 60 * 1000); } } }

🔍 检查项2：访问控制（必须全部通过）

检查内容：
测试方法：
# 测试1：越权访问测试（最关键） test_privilege_escalation() { # 用户A登录，获取token tokenA=$(login “userA” “passwordA”) # 用户B登录，获取token tokenB=$(login “userB” “passwordB”) # 用户A尝试访问用户B的数据，预期：403 Forbidden response=$(curl -H “Authorization: Bearer $tokenA” \ http://test.com/api/user/B/data) if [[ $response == *”403″* ]]; then echo “✅ 通过：越权访问被阻止” else echo “❌ 失败：越权访问成功” fi # 用户A尝试访问管理员功能，预期：403 Forbidden response=$(curl -H “Authorization: Bearer $tokenA” \ http://test.com/api/admin/users) if [[ $response == *”403″* ]]; then echo “✅ 通过：越权访问管理员功能被阻止” else echo “❌ 失败：普通用户可以访问管理员功能” fi } # 测试2：并发会话测试 test_concurrent_sessions() { # 用户在同一浏览器登录2次，预期：第一次登录被踢出 # 或者在代码中限制并发会话数量 # Spring Security配置示例： # http.sessionManagement() # .maximumSessions(2) # .maxSessionsPreventsLogin(true); echo “请手动测试：同一账户在3个不同浏览器登录，预期：第3次登录被拒绝” } # 测试3：权限变更审批流程测试 test_permission_approval() { # 普通用户申请提升为管理员，预期：需要管理员审批 # 1. 用户提交权限变更申请 response=$(curl -X POST -H “Authorization: Bearer $tokenA” \ -d “requested_role=admin” \ http://test.com/api/permission/request) # 2. 检查是否生成审批记录 approval=$(curl -H “Authorization: Bearer $tokenAdmin” \ http://test.com/api/approval/list) if [[ $approval == *”pending”* ]]; then echo “✅ 通过：权限变更需要审批” else echo “❌ 失败：权限变更无需审批” fi }
常见问题：
整改方案：
// 整改1：越权访问防护（使用@PreAuthorize注解） @RestController @RequestMapping(“/api/user”) public class UserController { @GetMapping(“/{userId}/data”) @PreAuthorize(“hasRole(‘USER’) and #userId == authentication.principal.userId”) public ResponseEntity getUserData(@PathVariable Long userId) { // 只允许用户访问自己的数据 return ResponseEntity.ok(userService.getData(userId)); } } // 整改2：全局权限拦截器 @Component public class PermissionInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 获取当前用户 User user = (User) request.getSession().getAttribute(“user”); // 获取请求的资源 String uri = request.getRequestURI(); // 检查权限 if (!permissionService.hasPermission(user, uri)) { response.setStatus(403); return false; } return true; } } // 整改3：敏感操作二次确认 @PostMapping(“/delete”) public ResponseEntity deleteData(@RequestBody DeleteRequest request) { // 需要用户输入密码确认 if (!passwordService.verify(user, request.getConfirmPassword())) { return ResponseEntity.status(400).body(“密码确认失败”); } // 执行删除 dataService.delete(request.getId()); return ResponseEntity.ok(“删除成功”); }

🔍 检查项3：安全审计（必须全部通过）

检查内容：
测试方法：
# 测试1：审计日志完整性测试 test_audit_log_completeness() { # 1. 用户登录 login “testuser” “password” # 2. 用户查询数据 curl -H “Authorization: Bearer $token” http://test.com/api/data # 3. 用户修改数据 curl -X PUT -H “Authorization: Bearer $token” \ -d ‘{“name”:”new name”}’ http://test.com/api/data/1 # 4. 用户退出 curl -X POST -H “Authorization: Bearer $token” \ http://test.com/api/logout # 5. 检查审计日志，预期：上述4个操作都有日志记录 logs=$(curl -H “Authorization: Bearer $adminToken” \ http://test.com/api/admin/logs?user=testuser) if [[ $logs == *”login”* ]] && [[ $logs == *”query”* ]] && \ [[ $logs == *”update”* ]] && [[ $logs == *”logout”* ]]; then echo “✅ 通过：审计日志完整” else echo “❌ 失败：审计日志不完整” fi } # 测试2：审计日志防篡改测试 test_audit_log_integrity() { # 普通用户尝试删除审计日志，预期：失败 response=$(curl -X DELETE -H “Authorization: Bearer $token” \ http://test.com/api/admin/logs/1) if [[ $response == *”403″* ]]; then echo “✅ 通过：普通用户不能删除审计日志” else echo “❌ 失败：普通用户可以删除审计日志” fi # 检查数据库，确认日志未被删除 # 或者检查日志文件，确认日志未被篡改 } # 测试3：日志存储期限测试 test_audit_log_retention() { # 查询6个月前的日志，预期：仍然存在 old_logs=$(curl -H “Authorization: Bearer $adminToken” \ “http://test.com/api/admin/logs?start_date=2024-06-01&end_date=2024-06-30”) if [[ $old_logs != *”error”* ]]; then echo “✅ 通过：6个月前的日志仍然存在” else echo “❌ 失败：日志存储期限不足6个月” fi }
常见问题：
整改方案：
// 整改1：使用AOP自动记录审计日志 @Aspect @Component public class AuditLogAspect { @Autowired private AuditLogService auditLogService; @AfterReturning(pointcut = “@annotation(org.springframework.web.bind.annotation.GetMapping)”, returning = “result”) public void logQuery(JoinPoint joinPoint, Object result) { User user = SecurityContextHolder.getContext().getAuthentication(); String method = joinPoint.getSignature().getName(); AuditLog log = new AuditLog(); log.setUser(user.getUsername()); log.setAction(“QUERY”); log.setMethod(method); log.setTimestamp(new Date()); log.setResult(“SUCCESS”); auditLogService.save(log); } @AfterReturning(pointcut = “@annotation(org.springframework.web.bind.annotation.PostMapping)”, returning = “result”) public void logCreate(JoinPoint joinPoint, Object result) { // 类似上面，记录创建操作 } } // 整改2：审计日志单独存储，普通用户无权访问 @Entity @Table(name = “audit_log”) public class AuditLog { @Id @GeneratedValue private Long id; private String username; private String action; // LOGIN, LOGOUT, CREATE, UPDATE, DELETE, etc. private String method; private String params; private String result; private String sourceIp; private Date timestamp; // 普通用户不能修改或删除 // 只有管理员可以查询 } // 整改3：使用ELK Stack集中管理日志 // logback-spring.xml localhost:5000

五、实战案例1：医疗SaaS平台的等保2.0三级测评

📋 案例背景

企业：某医疗科技公司

系统：医疗SaaS平台（包含HIS、EMR、LIS等模块）

用户量：50万+患者，500+医生

等保等级：三级（因为涉及患者隐私数据，必须过三级）

测评时间：2024年3月-2024年6月（3个月）

🎯 测评目标

系统需要正式上线运营，必须取得等保2.0三级证书。如果测评不通过，系统不能上线，影响公司业务。

📝 测评过程

第1周：定级备案

工作：

  • 编写《系统定级报告》：说明系统功能（HIS、EMR、LIS）、业务对象（患者、医生、医院）、服务范围（全国）、业务依赖度（高）等
  • 组织专家评审：邀请3名网络安全专家+1名医疗信息化专家对定级报告进行评审
  • 到市公安局网安支队备案：提交定级报告、专家评审意见、系统拓扑图、安全管理制度等
  • 领取《备案证明》：5个工作日后领取

输出：《系统定级报告》、《备案证明》

测试工程师参与：提供系统功能说明、网络拓扑图、数据流程图等
第2-3周：差距分析

工作：

  • 使用绿盟RSAS漏洞扫描系统对Web服务器、数据库服务器、应用服务器进行全面扫描
  • 使用Burp Suite进行手工渗透测试，重点测试越权访问、SQL注入、XSS等漏洞
  • 检查安全功能：身份认证、访问控制、审计日志、数据加密等
  • 访谈系统管理员、安全管理员、数据库管理员、网络管理员等
  • 查阅安全管理制度、运维记录、培训记录、应急预案等文档
  • 编写《差距分析报告》：列出所有不符合项，并评估风险等级

发现的主要问题：

# 漏洞扫描结果（使用Nessus） ## 高危漏洞（必须修复） 1. OpenSSL 1.0.2 存在Heartbleed漏洞（CVE-2014-0160） – 影响：可窃取服务器内存中的敏感数据（如私钥、密码等） – 修复：升级OpenSSL到1.1.1或更高版本 2. Apache Struts2 存在远程代码执行漏洞（CVE-2023-50164） – 影响：攻击者可远程执行任意代码 – 修复：升级Struts2到最新版本 3. MySQL 5.6 存在多个漏洞 – 影响：可导致数据库崩溃或数据泄露 – 修复：升级MySQL到5.7或8.0 ## 中危漏洞（建议修复） 1. HTTP响应头缺少X-Frame-Options（点击劫持防护） 2. Cookie未设置Secure和HttpOnly属性 3. 支持弱加密算法（如DES、MD5） ## 低危漏洞（可选修复） 1. 服务器版本信息泄露 2. 缺少CSP（Content Security Policy） # 手工测试结果（使用Burp Suite） ## 严重问题 1. 越权访问：医生A可以查看医生B的患者病历 – 测试方法：登录医生A账户，抓取查询病历的请求，将patientId从1001改为1002 – 结果：成功查看医生B的患者病历 – 风险等级：高 2. SQL注入：登录接口的username参数存在注入 – 测试方法：在username字段输入 ‘ OR ‘1’=’1 – 结果：成功绕过密码验证，登录任意账户 – 风险等级：高 3. XSS漏洞：患者姓名字段未过滤特殊字符 – 测试方法：在患者姓名中输入 – 结果：其他医生查看该患者的病历时，会执行恶意脚本 – 风险等级：中 ## 功能检查结果 1. 密码复杂度：不满足要求（允许6位纯数字密码） 2. 账户锁定：未实现（可以无限次尝试登录） 3. 会话超时：设置为1小时（超过15分钟要求） 4. 审计日志：只记录登录日志，不记录操作日志 5. 数据加密：患者隐私数据（如身份证号、病历内容）明文存储

输出：《差距分析报告》、《整改建议书》

测试工程师参与：核心参与者，负责漏洞扫描、渗透测试、功能检查等
第4-10周：整改加固

工作：

  • 制定《整改方案》：明确整改项、整改措施、责任人、时间计划
  • 技术整改：
    • 升级OpenSSL、Apache Struts2、MySQL等组件
    • 修复越权访问漏洞：在Controller层增加权限校验
    • 修复SQL注入漏洞：使用PreparedStatement替代Statement
    • 修复XSS漏洞：对用户输入进行HTML转义
    • 启用密码复杂度校验、账户锁定、会话超时等功能
    • 完善审计日志：使用AOP记录所有用户操作
    • 加密敏感数据：使用AES加密患者身份证号、病历内容等
    • 部署WAF（Web应用防火墙）：防SQL注入、XSS、CSRF等攻击
    • 部署IDS/IPS（入侵检测/防御系统）：监控异常流量
  • 管理整改：
    • 完善安全管理制度：编写《信息安全管理制度》、《账户管理制度》、《数据备份恢复制度》等
    • 加强人员培训：组织全员安全意识培训，签订保密协议
    • 规范运维流程：建立变更管理流程、事件响应流程、应急预案等
  • 整改自测：对整改项进行自测，确认整改效果

整改验证测试（重点）：

# 验证1：越权访问修复验证 def test_privilege_escalation_fixed(): # 医生A登录 tokenA = login(“doctorA”, “password”) # 医生A尝试访问医生B的患者病历，预期：403 Forbidden response = requests.get( “http://test.com/api/patient/1002/medical-record”, headers={“Authorization”: f”Bearer {tokenA}”} ) assert response.status_code == 403, “❌ 失败：越权访问仍然存在” print(“✅ 通过：越权访问已修复”) # 验证2：SQL注入修复验证 def test_sql_injection_fixed(): # 尝试SQL注入，预期：登录失败 response = requests.post( “http://test.com/api/login”, data={“username”: “‘ OR ‘1’=’1”, “password”: “anything”} ) assert response.status_code == 401, “❌ 失败：SQL注入仍然存在” print(“✅ 通过：SQL注入已修复”) # 验证3：XSS修复验证 def test_xss_fixed(): # 输入恶意脚本，预期：被转义 response = requests.post( “http://test.com/api/patient”, headers={“Authorization”: f”Bearer {token}”}, json={“name”: “”} ) # 查询该患者，预期：脚本被转义为 <script>… patient = requests.get( f”http://test.com/api/patient/{response.json()[‘id’]}”, headers={“Authorization”: f”Bearer {token}”} ) assert “