很多新手一听到”安全加固”，第一反应是”把用不上的服务都关了、把端口都封了”。这方向没错，但问题是没有标准——你凭什么判断某项配置”够安全了”？关到什么程度会误伤业务？今天改了，明天运维一键重装又回去了怎么办？
这一篇先把”安全加固”和”安全基线”这两个概念讲透，给你一套可以照着做的通用方法论。后面的 Linux、Windows、MySQL、Nginx、Apache、IIS 各章，都是在这套方法下针对具体对象的落地。
本文所有加固操作仅用于你自有或已授权的系统。对不属于你的设备做配置修改可能违法，且会影响他人业务。
什么是安全基线：一张”及格线”清单
安全基线（Security Baseline）可以理解为”一台系统/组件在投入生产前，至少要满足的最低安全要求”。它像考试及格线：不是要求你考满分，而是保证你不会因为最基础的疏忽被轻易攻破。
基线的来源通常有三类：
- 厂商/社区基准：最著名的是 CIS Benchmarks（Center for Internet Security 发布的免费加固指南），几乎覆盖所有主流操作系统、数据库、中间件。它把每条配置写成”该开还是该关、具体改哪个文件哪一行”，并标注风险等级。
- 合规标准：比如国内的等级保护基本要求（GB/T 22239）、国际标准 ISO 27001、支付行业的 PCI-DSS。它们从”过审”角度规定你必须做到哪些。
- 企业自定义：结合业务实际，在前面两类基础上裁剪。比如”对外 Web 服务器必须关掉不必要的 CGI 模块”。
基线的价值在于：把”老师傅的经验”变成可检查、可复现、可交接的清单。新人照着打勾就行，审计时也能拿出证据。
加固的四条通用原则
不管你加固的是 Linux 还是 IIS，下面四条原则几乎处处适用：
- 最小权限：只给刚够用的权限。能不用 root 就不用 root；数据库账号别用
root连应用；Web 目录不让执行权限。权限越小，被攻破后的破坏面越小。 - 最小暴露：只开放业务真正需要的端口、服务、功能。用不上的模块、用不上的协议、用不上的管理后台，一律关掉或移除。暴露面越小，被扫描命中的概率越低。
- 纵深防御：别指望一堵墙挡住所有人。系统层、网络层、应用层、数据层各设一道防线——即使 Web 被突破，还有系统权限限制、数据库权限限制兜底。
- 可恢复与可审计：加固不能把系统改到无法回滚；同时关键操作要留日志，出事能溯源。改配置前先备份原文件，这是铁律。
记住一个反直觉的点：加固不是越严越好。把
ssh端口改成只在内网、禁掉所有外联，业务可能直接挂掉。加固的终点是”安全与可用的平衡点”，不是”绝对安全”。
标准加固流程：别拿到机器就改
一个有章法的加固流程，通常分五步，建议养成习惯：
- 资产与角色确认：这台机器是 Web 服务器、数据库还是跳板机？不同角色基线不同。数据库不需要开 80 端口，Web 服务器不需要开 3306 对外。
- 现状核查（基线扫描）：先扫一遍当前配置偏离基线多少。可以用脚本批量比对，也可以用专业工具（如后面章节提到的漏扫、基线核查工具）。
- 逐项加固：按清单改配置。每改一项，确认业务还能跑。改前备份原文件（
cp nginx.conf nginx.conf.bak）。 - 验证与回归测试：加固后必须做功能验证——网站还能访问吗？数据库还能连吗？别”加固完发现业务挂了”才发现。
- 固化与持续监控：把加固脚本纳入装机模板/配置管理（Ansible、Puppet），并定期复查，防止配置漂移回旧状态。
用 CIS 基线组织你的清单：一个例子
以 Linux 为例，CIS 把加固项分成”系统设置、文件权限、账户策略、网络参数、日志审计”等大类。你可以把每一类抽成一张检查表，例如：
| 检查项 | 基线要求 | 检查方法 |
|---|---|---|
| 密码复杂度 | 长度≥12，含大小写数字 | 查 /etc/security/pwquality.conf |
| 空密码账户 | 不允许存在 | awk -F: '($2=="")' /etc/shadow |
| root 远程登录 | 禁止 SSH 直接 root 登录 | 查 PermitRootLogin no |
| 不必要的服务 | 关闭如 telnet、rsh | systemctl list-unit-files --type=service |
这张表就是后面各章的”骨架”。你不需要背下来，但要理解每一项背后防的是什么攻击。
常见误区：新手最容易踩的坑
- 误区一：关服务=更安全。盲目关掉不认识的服务，可能把
dbus、systemd-logind这类系统依赖也关了，导致机器起不来。 - 误区二：改完不测。加固后没做业务回归，结果 HTTPS 证书链、反向代理、连接池全出问题，半夜被叫起来回滚。
- 误区三：一次到位永不管。系统会打补丁、会重装、会被同事改配置。基线核查必须是周期性动作，不是一次性工程。
- 误区四：只加固主机不管应用。系统层锁死，但 Web 应用还是
admin/admin、数据库还是空密码，等于门焊死了窗开着。
进阶：把基线变成自动化
当机器多了，手工打勾不现实。进阶做法是把基线写成可执行的检查脚本或配置管理剧本：
- 用 Shell/Python 写检查脚本，输出”通过/失败”清单，失败项高亮。
- 用 Ansible playbook 把”加固动作”写成幂等操作，新机器一键应用，且重复执行不会出错。
- 接入 SIEM/配置合规平台，定期拉取各机配置做漂移检测。
这部分在第八章”基线核查清单与自动化”会展开讲具体脚本。
自测题
- 安全基线和”把系统改到最严”有什么区别？为什么不能一味求严？
- 加固流程中，为什么”验证与回归测试”这一步不能省？
- 最小权限原则在数据库加固里具体怎么体现？
- 为什么说基线核查必须是周期性的，而不是一次性工程？
实战要点与深度解析
基线落地时，最容易被忽视的是**“谁来维护基线”这个组织问题**。很多团队花大力气做了一份漂亮的 Excel 基线表，结果三个月后没人更新：新上的 Redis、新装的组件都不在表里，基线和实际资产逐渐脱节。所以基线管理第一步其实是资产梳理——你连”自己有哪些系统、跑什么组件、什么版本”都搞不清，基线就无从谈起。建议把资产清册和基线清单绑定，资产一变动，基线核查范围同步更新。
再谈一个现实矛盾：业务部门和安全的拉扯。安全想”关掉所有用不上的功能、最小权限”，业务想”别动我的环境、怕影响上线”。这个矛盾不能靠安全单方面强硬，而要靠”分级处置”化解：对确认无用且高风险的（如外网 Redis 无密码）坚决改；对可能影响业务的，先在测试环境验证、再灰度、再全量，并准备好回滚。把”可能影响业务”的担忧用”测试+回滚”来消弭，比硬碰硬更有效。
关于 CIS 基线和等保基线的关系：CIS 偏”技术配置细节”（具体改哪个文件哪一行），等保偏”能力要求”（要有身份鉴别、要有审计）。两者不冲突，反而互补：CIS 可以作为等保”技术要求”落地的具体操作手册。实践中完全可以把 CIS 的核查项映射到等保条款，一次核查同时产出”CIS 合规率”和”等保差距清单”两份产出，事半功倍。
还有一个常被问的问题：容器和云原生怎么算基线？传统基线针对”一台装好的操作系统”，但容器是无状态的、由镜像定义。所以容器时代的基线要前移：核查对象从”运行中的主机”变成”镜像和编排配置”——基础镜像是否含多余包、是否以 root 运行、Secret 是否明文、网络策略是否默认拒绝。这部分虽超出本章”主机加固”范围，但思路一脉相承：最小暴露、最小权限、可核查。
最后强调一个心态：基线不是越高越好，而是”恰到好处且可持续”。一份严到无法落地、天天产生大量 FAIL 的基线，最终会被运维无视；一份松到没意义的基线，又是形式主义。好的基线是”大部分机器能稳定 PASS、少数高风险项坚决不过”——把火力集中在真正影响安全的地方。
这一篇你该记住的
- 安全基线是”最低安全要求清单”，来源有 CIS、合规标准、企业自定义三类。
- 加固四原则：最小权限、最小暴露、纵深防御、可恢复可审计。
- 标准流程：确认角色 → 现状核查 → 逐项加固（改前备份）→ 验证 → 固化监控。
- 加固的终点是安全与可用的平衡，不是绝对安全；改完必须做业务回归测试。
- 机器多了就把基线脚本化、纳入配置管理，做周期性复查防漂移。
下一篇我们拿最常见的 Linux 服务器开刀，把上面这套方法论落到具体的 SSH、账户、内核参数和文件权限上。