安全基线这件事甲方安全岗几乎都做过但大部分都做成了一张没人看的 Excel。典型的样子安全部门花两周整理出一份几百行的配置清单发给运维要求自查整改运维看一眼回一句太多了哪些必须改安全部门说都是必须的然后就没有然后了。半年后审计来查发现清单躺在共享盘里没人动过。我在几个项目里踩过这个坑后来把基线从文档做成了流水线一份分级清单 一套自动核查脚本 一条例外审批通道 一个接进整改台账的出口。核查覆盖率从靠人肉抽查的 20% 左右做到全量自动跑配置类问题从季度清理变成每周出报告。这篇把整条流水线拆开写包括可以直接跑的核查脚本。一、基线为什么总是落不了地先想清楚失败的原因不然做多少版清单都一样。我总结下来是四个错位错位表现结果粒度错位一条基线写成一本书操作系统应安全配置运维无法执行刚性错位所有条目都标必须没有例外机制遇到业务冲突就整份放弃验证错位只发清单不验证靠自查自报报上来的全是已整改归属错位安全部门写、运维改、没人签字出问题互相推其中刚性错位是最致命的。安全基线本质上是默认拒绝的配置集合而业务系统几乎总有一些合理的不合规——老系统必须开 telnet、某中间件必须用弱加密算法对接旧设备、某服务必须以 root 跑。如果你不给这些情况留正规出口运维就会整体不执行因为按清单来一定会影响业务。所以第一件事不是写清单是给清单分级并给例外留通道。二、基线分级三层结构只有第一层不可协商我把所有基线条目分成三层这个结构直接决定了后面所有流程怎么跑。层级定义数量占比例外可能违反后果L1 红线违反即构成可直接利用的高危风险约 15%不允许例外立即整改24 小时内L2 标准业界通行的安全配置要求约 65%需审批有替代措施30 天内或走例外L3 建议加固项收益明确但非必需约 20%可自主决定纳入季度计划L1 的判断标准很简单这一条如果没做攻击者能不能直接进来或者直接拿走数据。比如数据库对公网开放存在空口令或默认口令账号SSH 允许 root 直接登录 密码认证未授权的远程管理端口暴露3389/22/5900Web 目录可列目录且含备份文件应用存在已知的未修复高危组件在野利用这些不给例外。如果业务确实冲突方案是改架构不是签例外。L2 才是主体也是容易扯皮的部分。L3 用来给运维送分做完显得有进展实际风险不大——这个设计对推动整体配合度很有效。三、清单本身怎么长按可验证来写一条基线写得对不对只有一个标准能不能用一条命令或者一次检查判断出符合/不符合。反例操作系统应进行安全加固关闭不必要的服务和端口。正例可直接验证编号检查项判定方法合格标准层级LNX-001SSH 禁止 root 登录sshd -T \grep permitrootlogin输出permitrootlogin noL1LNX-002SSH 禁止密码认证sshd -T \grep passwordauthentication输出noL2LNX-003口令最小长度grep -E ^minlen /etc/security/pwquality.conf≥ 10L2LNX-004口令复杂度grep -E ^(minclassdcreditucredit) /etc/security/pwquality.conf四类字符中至少三类L2LNX-005登录失败锁定grep deny /etc/security/faillock.confdeny ≤ 5L2LNX-006审计服务运行systemctl is-active auditdactiveL1LNX-007关键目录权限stat -c %a /etc/shadow000 或 640 以下L1LNX-008空口令账号awk -F: ($2){print $1} /etc/shadow无输出L1LNX-009内核参数-禁止 IP 转发sysctl net.ipv4.ip_forward0非路由设备L3LNX-010时间同步timedatectl status \grep synchronizedyesL2这个表的价值在于每一条都能被脚本直接判定不需要人去理解、判断、解释。写清单时容易犯的一个错是写应该、建议、适当这类模糊词。一旦出现这类词这条基线就等于没写——因为没人能验证也没人会执行。四、自动化核查把清单变成脚本清单定了下一步是让它自动跑。架构很简单整条流水线分四层每一层的输入输出都必须固定下来否则脚本就跑不起来采集层各主机执行核查脚本输出统一的 JSON每条带 check_id、结果、证据比对层与基线定义逐条比对生成符合 / 不符合 / 不适用三种结论汇总层按系统、按责任人聚合出 HTML 或 Excel 报告闭环层不符合项自动写入整改台账进入整改流程关键在于采集层要足够轻不装 agent、不依赖特定平台、能批量下发。这一点很重要——很多企业的基线核查做不下去就是因为要求装一套重型工具而运维不愿意在几百台机器上装东西。我用的方式是最原始的一段 bash 脚本通过已有的运维通道ansible / 堡垒机 / 批量执行推下去跑输出 JSON 回来。下面这段可以直接用覆盖上面表里的主要检查项#!/bin/bash # baseline_check.sh - Linux 基线核查输出 JSON # 用法: ./baseline_check.sh /tmp/baseline_$(hostname).json out() { printf %s\n $1; } j() { printf %s: {value: %s, level: %s},\n $1 $2 $3; } echo { echo \host\: \$(hostname)\, echo \time\: \$(date -Iseconds)\, echo \items\: { # LNX-001 SSH root 登录 v$(sshd -T 2/dev/null | awk /^permitrootlogin/{print $2}) j LNX-001 ${v:-unknown} L1 # LNX-002 SSH 密码认证 v$(sshd -T 2/dev/null | awk /^passwordauthentication/{print $2}) j LNX-002 ${v:-unknown} L2 # LNX-003 口令最小长度 v$(grep -E ^\s*minlen /etc/security/pwquality.conf 2/dev/null | awk -F {print $2} | tr -d ) j LNX-003 ${v:-unset} L2 # LNX-005 登录失败锁定 v$(grep -E ^\s*deny /etc/security/faillock.conf 2/dev/null | awk -F {print $2} | tr -d ) j LNX-005 ${v:-unset} L2 # LNX-006 审计服务 v$(systemctl is-active auditd 2/dev/null) j LNX-006 ${v:-inactive} L1 # LNX-007 /etc/shadow 权限 v$(stat -c %a /etc/shadow 2/dev/null) j LNX-007 ${v:-unknown} L1 # LNX-008 空口令账号 v$(awk -F: ($2){print $1} /etc/shadow 2/dev/null | tr \n , ) j LNX-008 ${v:-none} L1 # LNX-009 IP 转发 v$(sysctl -n net.ipv4.ip_forward 2/dev/null) j LNX-009 ${v:-unknown} L3 # LNX-010 时间同步 v$(timedatectl status 2/dev/null | awk -F: /synchronized/{gsub(/ /,,$2);print $2}) j LNX-010 ${v:-unknown} L2 # 附加监听在 0.0.0.0 的高危端口 v$(ss -lntp 2/dev/null | awk NR1 $4 ~ /0\.0\.0\.0:(3306|6379|9200|27017)/{print $4} | tr \n ,) j LNX-011 ${v:-none} L1 echo } echo }输出长得像这样正好能被下游解析{ host: app-node-01, time: 2026-03-25T09:12:3308:00, items: { LNX-001: {value: no, level: L1}, LNX-002: {value: yes, level: L2}, LNX-008: {value: none, level: L1} } }汇总端用一个短脚本把结果转成不符合项清单直接当整改台账用import json, glob RULES { # 编号 - (合格判定函数, 说明) LNX-001: (lambda v: v no, SSH 允许 root 直接登录), LNX-002: (lambda v: v no, SSH 允许密码认证), LNX-003: (lambda v: v.isdigit() and int(v) 10, 口令最小长度不足), LNX-006: (lambda v: v active, 审计服务未运行), LNX-007: (lambda v: v in (0, 000, 640), /etc/shadow 权限过宽), LNX-008: (lambda v: v none, 存在空口令账号), LNX-010: (lambda v: v yes, 未启用时间同步), } rows [] for f in glob.glob(/tmp/baseline_*.json): d json.load(open(f, encodingutf-8)) for code, item in d[items].items(): check, desc RULES.get(code, (None, None)) if not check: continue if not check(item[value]): rows.append({ host: d[host], code: code, level: item[level], actual: item[value], issue: desc, }) rows.sort(keylambda x: (x[level], x[host])) for r in rows: print(f[{r[level]}] {r[host]:20s} {r[code]} {r[issue]} (当前值: {r[actual]})) print(f\n共 {len(rows)} 项不符合)跑完直接得到一份可以贴进整改通知的清单按等级和主机排好序。Windows 侧不用写脚本系统自带两个工具就够:: 导出当前安全策略与基线 .inf 比对 secedit /export /cfg C:\tmp\current.inf :: 查看本地密码策略实际生效值 net accounts :: 导出组策略结果集看最终生效配置 gpresult /h C:\tmp\gpresult.html /f把基线做成一个.inf模板用secedit /configure /db secedit.sdb /cfg baseline.inf就能批量套用。这套东西在域环境里走组策略更省事非域机器才用 secedit。五、例外管理给改不了一条正规路这是整套机制能不能长期跑的关键。没有例外通道运维只有两个选择要么硬改可能引发故障要么不理风险悬空。有例外通道就变成第三个选择走流程、留痕、加补偿措施。例外单我设计成一张表五个必填项字段要求示例基线编号精确到条目LNX-002系统/主机明确责任范围旧版 ERP 应用节点 ×2无法整改原因必须是客观约束不能是没时间对接的旧设备仅支持密码认证补偿措施必须可验证仅允许内网 10.0.0.0/8 访问已加 ACL有效期 复核时间最长 6 个月到期自动回到待整改至 2026-09-309 月复核规则有三条L1 不允许例外只允许临时缓解 限期整改且必须业务负责人签字例外必须有补偿措施没有补偿措施的不批例外到期自动复活不允许永久例外第 3 条最容易被绕过——很多单位的例外单签完就再没人看。我的做法是把例外单和台账打通到期日到点自动回到待整改状态跟着周报一起推。六、接进整改闭环别做两套流程基线核查出来的不符合项本质上就是漏洞。所以不要单独建一套基线整改流程直接并入漏洞整改的同一张台账。字段设计上只要多两列字段说明来源漏扫/基线核查/人工发现/外部通报基线编号基线类问题填写其他为空这样带来三个好处领导看一张表就知道整体风险不用听你解释两套体系整改推动的话术、分级时限、复测流程全部复用同一个系统的漏洞和基线问题能一起排期减少反复打扰业务方关于整改推动的完整方法责任矩阵、话术库、七步 SOP我另外写过一篇这里不重复展开两篇配合看就是一条完整链路。七、怎么衡量基线做得好不好不要用核查了多少台这种过程指标用下面四个指标定义参考目标红线清零率L1 不符合项已闭环 / 总数100%任何时点都不该有存量核查覆盖率已纳入自动核查的主机 / 资产总数核心系统 100%整体 ≥ 90%平均闭环时长从核查出问题到复测通过L1 ≤ 3 天L2 ≤ 30 天例外占比有效期内的例外条目 / 总条目 8%超过说明基线定得不合理第四个指标最有诊断价值。例外占比长期高于 10%通常不是运维不配合而是基线本身脱离实际——要么定得太严照抄等保条款但没考虑业务要么没分层该是 L3 的写成 L1。这时候该改的是基线不是加压。八、二十条最常被忽略的加固点最后给一份补漏清单都是实际核查里高频出现、但容易被写的清单漏掉的数据库监听地址是0.0.0.0而不是127.0.0.1或内网地址Redis 无密码且对公网开放这个组合出了太多事故Elasticsearch 9200 端口无认证暴露Tomcat 管理后台/manager/html用默认口令Jenkins 未授权访问/script可直接执行命令Nacos / Eureka / Consul 等注册中心面板裸奔Spring Boot Actuator 的/env、/heapdump对外可访问应用日志目录全局可读含数据库连接串明文口令备份文件.bak、.sql、.zip留在 Web 目录版本管理目录.git/.svn可被下载中间件示例应用未删除/examples/、/docs/云主机安全组放通0.0.0.0/0的 22/3389对象存储桶允许匿名列举内部 API 未做鉴权仅靠网关路由隔离运维账号共用无个人实名账号数据库账号权限过大业务账号带 DBA 权限定时任务以 root 跑业务脚本日志未集中采集本地日志保留不足 6 个月证书使用自签名或已过期未做有效期监控双因素认证未覆盖 VPN、堡垒机、云控制台这 20 条不需要一次性全推。我的建议是先把第 1、2、3、5 条做成自动扫描因为它们的高危率极高、修复成本极低改个配置、加个密码投入产出比最好。九、落地顺序建议如果你现在从零开始别一上来就写完整清单。按这个顺序走第一周只定 L1 红线不超过 20 条全部选能被一条命令验证的第二周写核查脚本先在 3~5 台非核心机器上跑通修掉脚本误报第三周全量跑一次出一份《当前基线现状报告》给领导——这一份报告是后面所有推动的凭据第四周把不符合项按系统分组走整改流程先清 L1第二个月补 L2 清单接进例会和周报形成固定节奏第三个月上例外审批把改不了的正规化不要跳过第 3 步。没有一份现状报告你就没有推动的抓手所有要求都会被当成安全部门又来找事。十、写在最后安全基线是甲方安全里最不性感、但收益最确定的一块。它不像应急响应那样有故事性也不像攻防演练那样有戏剧性但它决定了你的安全水位下限——真实世界里绝大多数被拿下的系统不是被高级 0day 打穿的而是因为一个没改的弱口令、一个没关的端口、一个没权限控制的接口。把基线做成流水线等于把靠人盯变成靠机制跑。这件事做完你才有余力去做那些更需要判断力的活。基线跑起来之后往下接的两步一是把不符合项变成整改任务方法在漏洞整改推动实操二是把基线条目对应到测评条款写法在等保2.0定级备案与差距分析。主机被打穿了的情况处置顺序看应急响应复盘。有具体场景想聊的比如你们环境里某类设备怎么核查评论区留我看到会回。
安全基线这件事甲方安全岗几乎都做过但大部分都做成了一张没人看的 Excel。典型的样子安全部门花两周整理出一份几百行的配置清单发给运维要求自查整改运维看一眼回一句太多了哪些必须改安全部门说都是必须的然后就没有然后了。半年后审计来查发现清单躺在共享盘里没人动过。我在几个项目里踩过这个坑后来把基线从文档做成了流水线一份分级清单 一套自动核查脚本 一条例外审批通道 一个接进整改台账的出口。核查覆盖率从靠人肉抽查的 20% 左右做到全量自动跑配置类问题从季度清理变成每周出报告。这篇把整条流水线拆开写包括可以直接跑的核查脚本。一、基线为什么总是落不了地先想清楚失败的原因不然做多少版清单都一样。我总结下来是四个错位错位表现结果粒度错位一条基线写成一本书操作系统应安全配置运维无法执行刚性错位所有条目都标必须没有例外机制遇到业务冲突就整份放弃验证错位只发清单不验证靠自查自报报上来的全是已整改归属错位安全部门写、运维改、没人签字出问题互相推其中刚性错位是最致命的。安全基线本质上是默认拒绝的配置集合而业务系统几乎总有一些合理的不合规——老系统必须开 telnet、某中间件必须用弱加密算法对接旧设备、某服务必须以 root 跑。如果你不给这些情况留正规出口运维就会整体不执行因为按清单来一定会影响业务。所以第一件事不是写清单是给清单分级并给例外留通道。二、基线分级三层结构只有第一层不可协商我把所有基线条目分成三层这个结构直接决定了后面所有流程怎么跑。层级定义数量占比例外可能违反后果L1 红线违反即构成可直接利用的高危风险约 15%不允许例外立即整改24 小时内L2 标准业界通行的安全配置要求约 65%需审批有替代措施30 天内或走例外L3 建议加固项收益明确但非必需约 20%可自主决定纳入季度计划L1 的判断标准很简单这一条如果没做攻击者能不能直接进来或者直接拿走数据。比如数据库对公网开放存在空口令或默认口令账号SSH 允许 root 直接登录 密码认证未授权的远程管理端口暴露3389/22/5900Web 目录可列目录且含备份文件应用存在已知的未修复高危组件在野利用这些不给例外。如果业务确实冲突方案是改架构不是签例外。L2 才是主体也是容易扯皮的部分。L3 用来给运维送分做完显得有进展实际风险不大——这个设计对推动整体配合度很有效。三、清单本身怎么长按可验证来写一条基线写得对不对只有一个标准能不能用一条命令或者一次检查判断出符合/不符合。反例操作系统应进行安全加固关闭不必要的服务和端口。正例可直接验证编号检查项判定方法合格标准层级LNX-001SSH 禁止 root 登录sshd -T \grep permitrootlogin输出permitrootlogin noL1LNX-002SSH 禁止密码认证sshd -T \grep passwordauthentication输出noL2LNX-003口令最小长度grep -E ^minlen /etc/security/pwquality.conf≥ 10L2LNX-004口令复杂度grep -E ^(minclassdcreditucredit) /etc/security/pwquality.conf四类字符中至少三类L2LNX-005登录失败锁定grep deny /etc/security/faillock.confdeny ≤ 5L2LNX-006审计服务运行systemctl is-active auditdactiveL1LNX-007关键目录权限stat -c %a /etc/shadow000 或 640 以下L1LNX-008空口令账号awk -F: ($2){print $1} /etc/shadow无输出L1LNX-009内核参数-禁止 IP 转发sysctl net.ipv4.ip_forward0非路由设备L3LNX-010时间同步timedatectl status \grep synchronizedyesL2这个表的价值在于每一条都能被脚本直接判定不需要人去理解、判断、解释。写清单时容易犯的一个错是写应该、建议、适当这类模糊词。一旦出现这类词这条基线就等于没写——因为没人能验证也没人会执行。四、自动化核查把清单变成脚本清单定了下一步是让它自动跑。架构很简单整条流水线分四层每一层的输入输出都必须固定下来否则脚本就跑不起来采集层各主机执行核查脚本输出统一的 JSON每条带 check_id、结果、证据比对层与基线定义逐条比对生成符合 / 不符合 / 不适用三种结论汇总层按系统、按责任人聚合出 HTML 或 Excel 报告闭环层不符合项自动写入整改台账进入整改流程关键在于采集层要足够轻不装 agent、不依赖特定平台、能批量下发。这一点很重要——很多企业的基线核查做不下去就是因为要求装一套重型工具而运维不愿意在几百台机器上装东西。我用的方式是最原始的一段 bash 脚本通过已有的运维通道ansible / 堡垒机 / 批量执行推下去跑输出 JSON 回来。下面这段可以直接用覆盖上面表里的主要检查项#!/bin/bash # baseline_check.sh - Linux 基线核查输出 JSON # 用法: ./baseline_check.sh /tmp/baseline_$(hostname).json out() { printf %s\n $1; } j() { printf %s: {value: %s, level: %s},\n $1 $2 $3; } echo { echo \host\: \$(hostname)\, echo \time\: \$(date -Iseconds)\, echo \items\: { # LNX-001 SSH root 登录 v$(sshd -T 2/dev/null | awk /^permitrootlogin/{print $2}) j LNX-001 ${v:-unknown} L1 # LNX-002 SSH 密码认证 v$(sshd -T 2/dev/null | awk /^passwordauthentication/{print $2}) j LNX-002 ${v:-unknown} L2 # LNX-003 口令最小长度 v$(grep -E ^\s*minlen /etc/security/pwquality.conf 2/dev/null | awk -F {print $2} | tr -d ) j LNX-003 ${v:-unset} L2 # LNX-005 登录失败锁定 v$(grep -E ^\s*deny /etc/security/faillock.conf 2/dev/null | awk -F {print $2} | tr -d ) j LNX-005 ${v:-unset} L2 # LNX-006 审计服务 v$(systemctl is-active auditd 2/dev/null) j LNX-006 ${v:-inactive} L1 # LNX-007 /etc/shadow 权限 v$(stat -c %a /etc/shadow 2/dev/null) j LNX-007 ${v:-unknown} L1 # LNX-008 空口令账号 v$(awk -F: ($2){print $1} /etc/shadow 2/dev/null | tr \n , ) j LNX-008 ${v:-none} L1 # LNX-009 IP 转发 v$(sysctl -n net.ipv4.ip_forward 2/dev/null) j LNX-009 ${v:-unknown} L3 # LNX-010 时间同步 v$(timedatectl status 2/dev/null | awk -F: /synchronized/{gsub(/ /,,$2);print $2}) j LNX-010 ${v:-unknown} L2 # 附加监听在 0.0.0.0 的高危端口 v$(ss -lntp 2/dev/null | awk NR1 $4 ~ /0\.0\.0\.0:(3306|6379|9200|27017)/{print $4} | tr \n ,) j LNX-011 ${v:-none} L1 echo } echo }输出长得像这样正好能被下游解析{ host: app-node-01, time: 2026-03-25T09:12:3308:00, items: { LNX-001: {value: no, level: L1}, LNX-002: {value: yes, level: L2}, LNX-008: {value: none, level: L1} } }汇总端用一个短脚本把结果转成不符合项清单直接当整改台账用import json, glob RULES { # 编号 - (合格判定函数, 说明) LNX-001: (lambda v: v no, SSH 允许 root 直接登录), LNX-002: (lambda v: v no, SSH 允许密码认证), LNX-003: (lambda v: v.isdigit() and int(v) 10, 口令最小长度不足), LNX-006: (lambda v: v active, 审计服务未运行), LNX-007: (lambda v: v in (0, 000, 640), /etc/shadow 权限过宽), LNX-008: (lambda v: v none, 存在空口令账号), LNX-010: (lambda v: v yes, 未启用时间同步), } rows [] for f in glob.glob(/tmp/baseline_*.json): d json.load(open(f, encodingutf-8)) for code, item in d[items].items(): check, desc RULES.get(code, (None, None)) if not check: continue if not check(item[value]): rows.append({ host: d[host], code: code, level: item[level], actual: item[value], issue: desc, }) rows.sort(keylambda x: (x[level], x[host])) for r in rows: print(f[{r[level]}] {r[host]:20s} {r[code]} {r[issue]} (当前值: {r[actual]})) print(f\n共 {len(rows)} 项不符合)跑完直接得到一份可以贴进整改通知的清单按等级和主机排好序。Windows 侧不用写脚本系统自带两个工具就够:: 导出当前安全策略与基线 .inf 比对 secedit /export /cfg C:\tmp\current.inf :: 查看本地密码策略实际生效值 net accounts :: 导出组策略结果集看最终生效配置 gpresult /h C:\tmp\gpresult.html /f把基线做成一个.inf模板用secedit /configure /db secedit.sdb /cfg baseline.inf就能批量套用。这套东西在域环境里走组策略更省事非域机器才用 secedit。五、例外管理给改不了一条正规路这是整套机制能不能长期跑的关键。没有例外通道运维只有两个选择要么硬改可能引发故障要么不理风险悬空。有例外通道就变成第三个选择走流程、留痕、加补偿措施。例外单我设计成一张表五个必填项字段要求示例基线编号精确到条目LNX-002系统/主机明确责任范围旧版 ERP 应用节点 ×2无法整改原因必须是客观约束不能是没时间对接的旧设备仅支持密码认证补偿措施必须可验证仅允许内网 10.0.0.0/8 访问已加 ACL有效期 复核时间最长 6 个月到期自动回到待整改至 2026-09-309 月复核规则有三条L1 不允许例外只允许临时缓解 限期整改且必须业务负责人签字例外必须有补偿措施没有补偿措施的不批例外到期自动复活不允许永久例外第 3 条最容易被绕过——很多单位的例外单签完就再没人看。我的做法是把例外单和台账打通到期日到点自动回到待整改状态跟着周报一起推。六、接进整改闭环别做两套流程基线核查出来的不符合项本质上就是漏洞。所以不要单独建一套基线整改流程直接并入漏洞整改的同一张台账。字段设计上只要多两列字段说明来源漏扫/基线核查/人工发现/外部通报基线编号基线类问题填写其他为空这样带来三个好处领导看一张表就知道整体风险不用听你解释两套体系整改推动的话术、分级时限、复测流程全部复用同一个系统的漏洞和基线问题能一起排期减少反复打扰业务方关于整改推动的完整方法责任矩阵、话术库、七步 SOP我另外写过一篇这里不重复展开两篇配合看就是一条完整链路。七、怎么衡量基线做得好不好不要用核查了多少台这种过程指标用下面四个指标定义参考目标红线清零率L1 不符合项已闭环 / 总数100%任何时点都不该有存量核查覆盖率已纳入自动核查的主机 / 资产总数核心系统 100%整体 ≥ 90%平均闭环时长从核查出问题到复测通过L1 ≤ 3 天L2 ≤ 30 天例外占比有效期内的例外条目 / 总条目 8%超过说明基线定得不合理第四个指标最有诊断价值。例外占比长期高于 10%通常不是运维不配合而是基线本身脱离实际——要么定得太严照抄等保条款但没考虑业务要么没分层该是 L3 的写成 L1。这时候该改的是基线不是加压。八、二十条最常被忽略的加固点最后给一份补漏清单都是实际核查里高频出现、但容易被写的清单漏掉的数据库监听地址是0.0.0.0而不是127.0.0.1或内网地址Redis 无密码且对公网开放这个组合出了太多事故Elasticsearch 9200 端口无认证暴露Tomcat 管理后台/manager/html用默认口令Jenkins 未授权访问/script可直接执行命令Nacos / Eureka / Consul 等注册中心面板裸奔Spring Boot Actuator 的/env、/heapdump对外可访问应用日志目录全局可读含数据库连接串明文口令备份文件.bak、.sql、.zip留在 Web 目录版本管理目录.git/.svn可被下载中间件示例应用未删除/examples/、/docs/云主机安全组放通0.0.0.0/0的 22/3389对象存储桶允许匿名列举内部 API 未做鉴权仅靠网关路由隔离运维账号共用无个人实名账号数据库账号权限过大业务账号带 DBA 权限定时任务以 root 跑业务脚本日志未集中采集本地日志保留不足 6 个月证书使用自签名或已过期未做有效期监控双因素认证未覆盖 VPN、堡垒机、云控制台这 20 条不需要一次性全推。我的建议是先把第 1、2、3、5 条做成自动扫描因为它们的高危率极高、修复成本极低改个配置、加个密码投入产出比最好。九、落地顺序建议如果你现在从零开始别一上来就写完整清单。按这个顺序走第一周只定 L1 红线不超过 20 条全部选能被一条命令验证的第二周写核查脚本先在 3~5 台非核心机器上跑通修掉脚本误报第三周全量跑一次出一份《当前基线现状报告》给领导——这一份报告是后面所有推动的凭据第四周把不符合项按系统分组走整改流程先清 L1第二个月补 L2 清单接进例会和周报形成固定节奏第三个月上例外审批把改不了的正规化不要跳过第 3 步。没有一份现状报告你就没有推动的抓手所有要求都会被当成安全部门又来找事。十、写在最后安全基线是甲方安全里最不性感、但收益最确定的一块。它不像应急响应那样有故事性也不像攻防演练那样有戏剧性但它决定了你的安全水位下限——真实世界里绝大多数被拿下的系统不是被高级 0day 打穿的而是因为一个没改的弱口令、一个没关的端口、一个没权限控制的接口。把基线做成流水线等于把靠人盯变成靠机制跑。这件事做完你才有余力去做那些更需要判断力的活。基线跑起来之后往下接的两步一是把不符合项变成整改任务方法在漏洞整改推动实操二是把基线条目对应到测评条款写法在等保2.0定级备案与差距分析。主机被打穿了的情况处置顺序看应急响应复盘。有具体场景想聊的比如你们环境里某类设备怎么核查评论区留我看到会回。
