CIS 基线（CIS Benchmarks）是由 Center for Internet Security 发布的安全配置指南，经专家 共识编写而成。它覆盖各类操作系统——Amazon Linux、Ubuntu、RHEL、Windows——给出数百条具体建议： 文件权限、内核参数、口令策略、应当关闭的服务，以及审计配置。
把加固施加在 AMI 上——而不是在每一台已部署的服务器上——是最高效的：加固一次，之后每个实例 生来就是安全的。这正是 ISO 27001、SOC 2、PCI DSS 等框架所要求的「默认安全」路线。
L1 与 L2 级别：该拧多紧
CIS 按级别定义了配置档。选对档位，才不会因为用力过猛而弄坏应用。
| 配置档 | 目标 | 何时采用 |
|---|---|---|
| Level 1（L1） | 基础安全，对功能几乎没有影响 | 多数负载的起点 |
| Level 2（L2） | 面向敏感环境的纵深防御 | 受监管数据、高风险场景；可能需要调优 |
| STIG | 美国国防部的要求 | 政府或国防合同 |
CIS 加固配置档及其适用范围。
如何在镜像里自动化加固
手工加固既不可扩展，也无法审计。以下是把它纳入构建流水线最常见的三条路径：
- EC2 Image Builder 搭配 CIS 组件：AWS 提供与托管 CIS 级别的集成，在构建过程中应用并 校验基线，也可以选用 Marketplace 上的 CIS Hardened 镜像。
- Ansible 加一个加固角色：在 Packer 的 provisioner 里复用面向 Linux 的 CIS 角色；这在 各朵云之间都可移植。
- 自己写幂等脚本：适合特定场景，优点是完全掌控，缺点是要自己维护。
不可或缺的高价值控制项
如果必须排优先级，以下这些 CIS 控制项能以最低成本换来最大的风险下降：
- 禁用 SSH 的 root 直连，强制使用密钥登录，绝不用口令。
- 移除不必要的软件包与服务，缩小攻击面。
- 配置主机防火墙（firewalld 或 nftables），默认拒绝。
- 启用审计（
auditd）与集中式事件日志。 - 应用安全的内核参数（
sysctl），防范欺骗与网络攻击。 - 严格的口令策略与账户锁定。
- 关键文件的正确权限：
/etc/passwd、/etc/shadow以及启动目录。
验证加固是否真的生效
只加固不验证，是一种信仰行为。请加入一个自动化验证阶段：对照基线给镜像打分，未达阈值就让 构建失败。
- CIS-CAT、InSpec 或 OpenSCAP 扫描刚烤好的实例，生成合规报告。
- 通过阈值：比如把「L1 控制项通过率 ≥ 95 %」设为质量门禁。
- 审计证据：把报告作为构建产物保存下来；下一次 SOC 2 或 ISO 审计时它就是真金白银。
平衡点：既安全，又不弄坏应用
经典的错误是盲目套用 L2，然后发现应用启动不了。稳妥的策略是：从 L1 起步，做度量，再在预发 环境中逐项验证、有选择地提升到 L2。为每一个合理的例外写下记录；带着书面理由关掉的控制项在 审计中可以接受，悄悄关掉的则不行。
常见问题
CIS 加固会拖慢我的实例吗？
L1 配置档对性能的影响几乎为零。L2 中某些高强度审计控制项可能带来额外开销，所以要有选择地 应用并加以度量。
我必须购买 CIS Hardened 镜像，还是可以自己来？
你完全可以自己加固——用 Ansible、OpenSCAP 或 EC2 Image Builder 的组件。Marketplace 上的 CIS Hardened 镜像能省事，还自带验证，但并非必需。
做了加固就等于符合 ISO 27001 或 PCI DSS 了吗？
加固是一项重要的技术控制，但合规还涵盖流程、政策与证据。加固 AMI 让你离目标近得多，却不能 替代合规框架的其余部分。
在 imaxe.cloud，我们从按业界良好实践加固过的镜像出发，让你在安全的基线上部署。
