1. 等保三级测评的基本概念与重要性

第一次接触等保三级测评时，我和很多技术负责人一样感到无从下手。等保三级全称"信息安全等级保护第三级"，是我国对非银行金融机构、互联网企业、能源行业等重要信息系统提出的基本安全要求。简单来说，就像给系统做一次全面的"体检"，确保它具备抵御常见网络攻击的能力。

为什么企业需要重视等保测评？我经历过一个真实案例：某制造业企业的生产管理系统因为缺乏基本防护措施，遭遇勒索病毒攻击导致全线停产，直接损失超过千万。事后调查发现，如果当初按照等保三级标准部署了基础的安全防护，完全可以避免这次事故。等保不是形式主义，而是实实在在的安全底线。

对于技术团队而言，自主完成测评有三大优势：一是深度掌握系统安全状况，二是节省第三方测评费用（通常需要10-30万元），三是培养团队的安全合规能力。不过要注意，自主测评不等于降低标准，所有检查项都必须严格对标《GB/T 22239-2019》等国家标准。

2. 测评范围界定与系统分类

2.1 核心业务系统识别

在给某新能源企业做咨询时，我发现他们犯了个典型错误——试图一次性测评所有20多个系统。这不仅耗费资源，还容易导致重点不突出。我的经验是采用"四象限法"分类：

1. 高危系统：涉及用户隐私数据（如身份证、银行卡号）或直接控制物理设备的系统
2. 关键系统：支撑核心业务流程的系统（如订单交易、生产控制）
3. 边缘系统：辅助性业务系统（如内部知识库）
4. 隔离系统：完全内网运行且不处理敏感数据的系统

建议优先选择1-2个高危或关键系统作为试点。比如某电商平台，我们首先测评了支付系统和用户中心，这两个系统通过后，其他系统的测评就有了参考模板。

2.2 系统边界划分

边界划分是容易踩坑的地方。曾经有个客户将整个微服务架构作为一个系统申报，结果因为某个非核心服务不达标导致整体测评失败。正确的做法是：

• 物理边界：不同机房、不同VPC环境的系统应该分开测评
• 逻辑边界：即使部署在同一集群，业务关联度低的系统也应独立测评
• 数据边界：共享同一数据库的系统建议合并测评

实际操作中，可以绘制系统拓扑图，用不同颜色标注各组件所属的测评范围。我习惯用PlantUML画这样的示意图：

@startuml
component "用户服务" as user #LightGreen
component "订单服务" as order #LightGreen
component "支付服务" as payment #Pink
component "物流服务" as logistics #LightBlue

database "用户数据库" as user_db #LightGreen
database "业务数据库" as biz_db #Pink

user --> user_db
order --> biz_db
payment --> biz_db
logistics --> biz_db

@enduml

在这个例子中，支付服务（粉色）需要单独测评，而用户服务和订单服务可以合并为一个测评单元。

3. 自查清单与整改方案设计

3.1 技术安全自查实战

根据等保2.0标准，技术部分占70%权重。我整理了一份经过20多个项目验证的自查清单：

身份认证部分

• 检查是否有账户锁定机制（连续5次失败登录锁定15分钟）
• 测试是否允许admin/123456这样的弱密码
• 验证短信验证码是否有有效期（建议3分钟）和次数限制
• 检查JWT令牌是否设置了合理的过期时间（建议不超过4小时）

日志审计部分

• 关键操作日志必须包含：操作时间、账号、IP地址、操作类型、操作对象
• 用ELK搭建日志系统时，注意设置合理的分片策略（建议每天1个索引）
• 测试日志删除功能是否留有审计痕迹

数据安全部分

• 数据库敏感字段必须加密，推荐使用AES-256或国密SM4
• 检查备份策略是否满足RPO（恢复点目标）要求
• 测试数据传输是否强制TLS1.2+（禁用SSLv3/TLS1.0）

实际操作中，我会用自动化脚本快速检查基础项：

#!/bin/bash
# 检查SSH配置
grep -E "^PermitRootLogin no" /etc/ssh/sshd_config || echo "SSH root登录未禁用"
grep -E "^Protocol 2" /etc/ssh/sshd_config || echo "SSH未禁用协议1"

# 检查密码策略
grep -E "^PASS_MAX_DAYS 90" /etc/login.defs || echo "密码有效期设置过长"

3.2 管理制度的编写技巧

很多技术团队容易忽视管理制度建设。我曾帮一家互联网公司整理过全套文档，核心包括：

1. 安全管理制度（10-15页）：

   • 明确安全责任部门和个人
   • 规定系统上线前的安全测试流程
   • 制定第三方人员访问控制流程

2. 应急预案（需具体到可执行）：

   • 数据泄露场景：包含通知客户的话术模板
   • DDoS攻击场景：标注具体切换流量清洗的IP段
   • 系统宕机场景：写明各业务模块的恢复优先级

3. 培训记录：

   • 新员工安全培训签到表
   • 年度安全意识测试试卷
   • 应急演练的截图和报告

建议使用Markdown管理这些文档，方便版本控制：

# 应急响应预案

## 1. 数据泄露处置流程
### 1.1 确认阶段
- [ ] 确认泄露范围（数据库表名、时间段）
- [ ] 截图保存证据

### 1.2 处置阶段
- [ ] 断开受影响服务器网络
- [ ] 修改所有相关账户密码

4. 测评全流程执行指南

4.1 定级备案实操要点

在浙江某项目备案时，我们因为材料不全来回跑了三趟。总结出必备材料清单：

1. 系统概况说明（2-3页）：

   • 业务功能描述
   • 用户规模和数据量
   • 网络拓扑示意图

2. 定级报告（需法定代表人签字）：

   • 定级依据（GB/T 22240-2020）
   • 受侵害客体分析
   • 侵害程度认定

3. 专家评审意见：

   • 需3名具备资质的专家签字
   • 包含系统边界确认意见

备案流程各地略有差异，但基本遵循这个时间线：

1. 线上提交材料（3个工作日内预审）
2. 纸质材料递交（需加盖公章）
3. 领取备案证明（通常10个工作日内）

4.2 正式测评应对策略

测评机构通常会采用"3+2"测试法：

技术测试三项核心：

1. 配置检查（提供服务器SSH只读账号）
2. 漏洞扫描（提前用Nessus自测修复）
3. 渗透测试（重点准备业务逻辑漏洞防御）

管理核查两个重点：

1. 制度文档完整性（准备文件清单）
2. 记录真实性（抽查3个月内的运维日志）

我曾遇到一个典型案例：测评人员尝试用订单号遍历漏洞（修改order_id=1001为1002），虽然系统有权限控制，但因为错误提示信息不同（"订单不存在"vs"无权访问"），还是被判定为信息泄露。这类业务逻辑问题占发现漏洞的60%以上。

5. 开源工具链搭建方案

5.1 安全扫描工具组合

经过多个项目对比测试，我推荐这套零成本方案：

功能	开源工具	部署方式	检查频率
代码审计	SonarQube+FindSecBugs	Docker部署	每次提交
Web扫描	OWASP ZAP	定时任务	每周
主机漏洞	OpenVAS	独立服务器	每月
配置基线	Lynis	本地执行	季度

具体到SonarQube的配置，建议修改这些关键参数：

<!-- sonar-project.properties -->
sonar.security.sources=ALL
sonar.cpd.exclusions=**/*Test.java
sonar.exclusions=**/generated/**/*

# 重点检查项
sonar.java.spotbugs.filters.path=spotbugs-security.xml

5.2 日志审计系统搭建

用ELK堆栈实现等保要求的6个月日志留存，需要注意：

1. 存储估算：

   • 单台应用服务器日志约2GB/天
   • 使用ILM策略：热数据保留7天（SSD），温数据30天（HDD），冷数据5个月（对象存储）

2. 关键配置：

# filebeat.yml
output.elasticsearch:
  hosts: ["es01:9200"]
  indices:
    - index: "applogs-%{+yyyy.MM.dd}"
      when.contains:
        fields.type: "app"

# Elasticsearch ILM策略
PUT _ilm/policy/logs_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "50GB" 
          }
        }
      },
      "delete": {
        "min_age": "180d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

6. 长期维护机制建设

通过测评只是起点，我建议建立三个常态化机制：

安全运维日历：

• 每月第一个周一：漏洞扫描日
• 每季度末：应急演练日
• 每年11月：等保复测准备月

变更管理流程：

1. 任何系统变更需填写安全影响评估表
2. 关键变更前执行diff检查：

# 对比配置文件变更
diff <(ssh prod-server "cat /etc/nginx/nginx.conf") nginx.conf.new

第三方组件监控：

• 建立组件清单（名称+版本+来源）
• 订阅CNVD/NVD安全通告
• 用Dependabot自动检查依赖漏洞

某客户按照这个机制运行两年后，在复测时发现问题数量减少了80%。最关键的是培养了开发人员的安全习惯——现在他们提交代码时都会自觉加上安全注释：

// SECURITY: 输入参数已做XSS过滤
public String getUserInput(String input) {
    return HtmlUtils.htmlEscape(input);
}