首页/安全/安全加固速查/等保 2.0 主机安全要求对照(三级)
主机加固基线90 条

等保 2.0 主机安全要求对照(三级)

等保 2.0 三级对主机的要求集中在身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范与可信验证;逐条映射到本包命令即可形成主机自查表。

安全加固速查安全更新于 2026-10-13

这条条目怎么用

等保 2.0(GB/T 22239-2019)三级对主机的要求集中在身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范、可信验证六块。这条不是一条命令,而是一张对照表:把测评语言翻译成可执行的核查动作,让你知道某条要求在本包里由哪个命令、哪份配置去落地。逐条走完再回答测评问题,比临场翻条款有效得多。

基本信息

加固项等保 2.0 主机条款符合性
适用平台通用(Linux 与 Windows)
风险等级高
对照标准GB/T 22239-2019 三级:安全计算环境(主机部分)
使用方式按控制点逐条对照本包条目执行并留证

主机控制点与本包落点

控制点要求要点本包落点
身份鉴别口令复杂度、登录失败处理、远程管理防窃听口令与认证策略组:pwquality、faillock、SSH 密钥
访问控制账户权限最小化、默认账户处置UID 0 核查、系统账号 nologin、sudo 与 su 收敛
安全审计覆盖每个用户、留存不少于 6 个月、防删除日志与审计组:auditd、watch 规则、留存期核查
入侵防范最小安装、关闭非必要服务与端口服务与端口收敛组、基线核查命令组
恶意代码防范防恶意代码机制及时更新完整性校验、杀毒或 EDR、补丁与漏洞管理
可信验证启动与运行态度量(依据产品能力)可信启动或专用产品,普通服务器上依赖硬件与产品支持

自查命令样例

自查命令样例
awk -F: '($3==0){print $1}' /etc/passwd   # 身份鉴别与访问控制
ss -tulnp | grep -v 127.0.0.1 | head     # 开放端口盘点
auditctl -s | head -3                    # 审计子系统状态
grep -E 'PASS_MAX_DAYS|PASS_MIN_LEN' /etc/login.defs   # 口令策略
stat -c '%a %U:%G %n' /etc/shadow /etc/passwd          # 关键文件权限

测评需要准备的证据

  • 命令输出:核查类条目保留原始输出,带主机名与执行时间
  • 配置备份:改动前后的配置文件副本,用于说明整改动作
  • 审计记录:审计日志样例,证明记录覆盖到具体用户
  • 账号清单:全部账号及其权限归属,说明默认账户已处置
  • 变更记录:加固动作对应的审批或工单编号
测评看的是证据链:命令输出、配置备份、审计记录都要留存归档。临时改配置应付测评、测完再改回去,在评审里不算整改;对自动化检出不一致的环境,这类操作反而会被比对出来。
条款有等级差异:三级要求比二级多了部分条款(如更严格的日志留存与集中审计),同一台机器按三级标准整改通常能覆盖二级,但反向不成立,写报告前先确认被测系统的等保级别。

自查表的写法

推荐把这张对照表扩展成三列表格:控制点、当前状态、证据位置。每条控制点写明「符合/不符合/不适用」,并在证据位置填写具体文件路径或命令输出编目。这样既便于自查整改,也便于测评时按图索骥,避免现场临时找证据造成漏项。

易错点

  • 把条款当成一句话结论:控制点需要落到具体命令与配置,只写「已符合」无法支撑复评
  • 日志留存口径算错:主机本地审计日志只是证据链一环,必须能证明集中留存与防删除措施
  • 忽略可信验证条款的实现门槛:普通 x86 服务器上依赖硬件能力或专用产品,几条命令糊弄不过测评
  • 整改与取证不同步:先改配置再补证据会出现时间线矛盾,正确顺序是先记录现状再改
  • 把 Linux 的落点直接套到 Windows:两边的命令与证据形式完全不同,需要分别建立对照

数据来源与参考

  • GB/T 22239-2019:信息安全技术 网络安全等级保护基本要求(三级 8.1.4)
  • 等保 2.0 测评指导书(主机安全部分)

相关工具

​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌