一、为什么要重视“配置与策略”安全？

攻击面多：错误配置（暴露端口、弱 TLS、默认密码）是攻链中最常见的初始入口。

影响范围广：一处全局配置（如开放 S3 桶或允许匿名访问）可能影响千万用户数据。

持续性风险：配置漂移（drift）会随着时间积累形成长期风险。

难以检测：很多配置问题不产生明显报错，只有在被滥用时才暴露。

合规要求：很多法规（PCI-DSS、ISO27001、GDPR）都把配置/策略管理纳入考核。

结论：把配置与策略当作代码来管理（Configuration as Code / Policy as Code），并把安全嵌入 CI/CD 与运行时，是最有效的防线。

二、配置安全的核心原则（高阶准则）

最小权限（Principle of Least Privilege）：账号、服务、网络都只给必要权限。

安全默认（Secure by Default）：默认关闭危险功能；开通需显式授权。

可审计、可回滚：所有配置变更可追溯、可回滚。

自动化：用 IaC / 配置管理工具实现可复现配置；使用自动扫描防止人为失误。

分层防护（Defense-in-Depth）：网络、主机、应用、数据层都应有策略。

定期验证：持续合规检查、基线比对、漏洞扫描与渗透测试。

密钥/秘密分离：禁止把凭证硬编码在配置文件或仓库中。

三、关键域与实操建议

下面把配置安全拆成若干具体域，每一项给出问题、解决策略与示例/模板。

3.1 身份与访问管理（IAM / Access Control）

问题点

过宽的角色（如 AWS IAM *:*）

长期凭证（长期密钥、service account）

未启用 MFA/2FA

未细化资源级权限

对策

使用最小权限角色，使用 RBAC/ABAC 做资源级控制。

使用短期凭证（STS、AssumeRole），避免长期密钥。

强制 MFA 对高权限用户与敏感操作。

使用审批流程（如变更工单）为高权限变更护航。

开启权限使用审计（谁何时以何角色访问了哪些资源）。

示例策略模板（密码/身份）

密码长度 ≥ 12，至少包含三类字符，最大使用周期不超过 180 天（但更推荐使用长寿命 + MFA + 阻止弱密码列表）。

管理员必须启用 MFA。

所有 API 密钥使用短期令牌或托管密钥服务（例如 AWS STS / Azure AD token）。

3.2 网络与边界策略（防火墙、Segmentation、Zero Trust）

问题点

默认允许出/入站全部流量

东西向流量不受限（内部横移风险）

没有微分段、没有服务间网络策略

对策

外围：边界防火墙只允许必要端口（例如 80/443 公网），其他端口仅 VPN /跳板访问。

内部：实现分段（VPC/subnet/NSG），将管理/数据库/应用分层。

零信任：服务间基于身份进行授权（mTLS、service identity）。

网络策略：在集群（Kubernetes）中启用 NetworkPolicy，禁止默认全通。

示例 - iptables/nftables 最小入站规则（示意）

# 仅允许 SSH (管理机) 和 HTTPS
iptables -P INPUT DROP
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.10 -j ACCEPT   # 管理员跳板IP
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT

示例 - Kubernetes NetworkPolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-except-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 80

3.3 服务与协议硬化（SSH/TLS/HTTP）

问题点

使用弱的 TLS 协议/弱套件、证书过期

SSH 开放 root 登录或弱口令

HTTP 安全头缺失（CSP、HSTS）

对策

TLS：优先 TLS1.3；禁用 SSLv3/TLS1.0/1.1；强制使用证书自动化（ACME/LetsEncrypt）与短周期证书轮换。

SSH：禁用 root 登录；使用公钥认证；关闭密码登录（PasswordAuthentication no）；限制来源 IP。

HTTP：启用 HSTS、CSP、X-Frame-Options、Referrer-Policy。

示例 - sshd_config

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
X11Forwarding no
AllowUsers adminuser

示例 - nginx TLS（简化示意）

server {
  listen 443 ssl http2;
  ssl_certificate /etc/letsencrypt/live/site/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/site/privkey.pem;
  ssl_protocols TLSv1.3 TLSv1.2;
  ssl_prefer_server_ciphers on;
  add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
}

注意：具体 cipher 列表会随时间更新，建议遵循主流厂商/CA/OWASP 的推荐并定期审查。

3.4 Secrets 与证书管理

问题点

将密钥/密码硬编码在代码或提交到 VCS。

没有集中化秘密管理、密钥轮换困难。

对策

使用专用的秘密管理工具（HashiCorp Vault、AWS Secrets Manager、Azure Key Vault、GCP Secret Manager）。

禁止在代码库中提交凭证（配置 pre-commit 钩子、Secret scanning）。

强制使用短期凭证、自动轮换策略与访问审计。

生产环境禁止使用明文环境变量传递敏感密钥，使用托管注入机制。

示例（Terraform 远程状态与敏感变量处理）

远程 state 存储（S3 + DynamoDB）并加密；变量通过 Vault/Secrets Manager 注入，不在 tfvars 中写明明文密钥。

3.5 配置管理、IaC 与自动化（Infrastructure as Code）

问题点

手工变更导致漂移（drift）

IaC 模板包含不安全默认（公开 s3 、安全组宽松）

对策

所有基础设施以代码管理（Terraform/CloudFormation/ARM）。

在 CI 中加入静态扫描（tfsec、Checkov、Terrascan、cfn-lint），阻止不合规的变更进入主分支。

在部署前运行策略引擎（OPA/Gatekeeper/Conftest）做 Policy-as-Code 校验。

定期执行基线合规扫描（CIS benchmark）并自动修复或告警。

示例 - OPA/Gatekeeper 规则（伪示意）

不允许 Security Group 开放 0.0.0.0/0 的 22/3389 端口。

3.6 日志、监控与审计（Observability）

问题点

日志丢失或不可用；审计不足；告警阈值设置不合理。

对策

集中化日志（ELK/EFK、Splunk、Graylog）并对关键事件做不可篡改存储（WORM / 只追加）。

审计：启用云平台审计日志（CloudTrail、Azure Activity Log、GCP Audit Logs）。

指标与告警：Prometheus + Alertmanager，关键异常（异常登录、配置变更、密钥创建）必须触发告警并与工单系统联动。

SIEM：把日志流入 SIEM 做长期关联分析、威胁检测与取证。

3.7 补丁管理与变更控制

问题点

未及时打补丁；无法追溯谁修改了配置；上线没有回退计划。

对策

建立补丁管理周期（根据资产危害度分级：Critical / High / Medium / Low）并将关键补丁纳入紧急修复流程。

所有变更走变更管理流程：变更单、影响评估、回滚计划、变更窗口与验证。

自动化补丁工具：OS 管理（WSUS/SCUP/Ansible/Puppet/Chef）与容器镜像安全扫描（Clair、Trivy）。

3.8 运行时保护（RASP / WAF / Host Hardening）

问题点

应用运行时不受保护，入侵后的横向移动容易。

对策

Web 应用：部署 WAF（ModSecurity、Cloud WAF），阻挡常见攻击（SQLi、XSS、文件上传恶意）。

主机防护：启用防篡改工具（aide）、文件完整性监测（OSSEC、Tripwire）、并使用 SELinux/AppArmor 加固关键主机。

容器环境：启用容器安全运行时（Falco、Aqua、Sysdig）和镜像签名（Notary/rekor）。

四、策略管理（Policy）实践
4.1 Policy as Code（PaC）

将合规策略用代码/规则定义（OPA/Rego、Conftest、Gatekeeper），并在 CI/CD 强制执行。

例如定义不可创建公网可写的 S3 桶、禁止未加密 RDS 实例等。

4.2 策略治理流程

制定策略（Security Team + Product/Platform）

将策略编码并加入 CI（阻断或警告）

运行时校验（云资源变更时检查）

审计与例外管理（记录并定期审查例外）

4.3 常见政策模板（示例）

网络访问策略：生产环境所有数据库端口仅允许来自应用子网访问；管理端口仅允许跳板 IP。

密钥政策：所有长期凭证必须使用审批流程；敏感凭证寿命 ≤ 90 天。

镜像策略：生产镜像必须通过 SCA（软件成分分析）且基线扫描为 PASS。

五、测试与验证（验证配置有效性）

静态扫描（Shift-left）：tfsec / Checkov / Conftest、YAML lint、Kube-linter。

动态扫描（运行时）：攻防演练（红队）、基线合规检查、自动化复现测试。

配置漂移检测：使用配置管理对比当前配置与期望状态（Ansible, Chef, Puppet）。

安全回归测试：把业务关键场景写成安全用例纳入 CI（如优惠券滥用、并发下单）。

合规审计：周期性执行 CIS 基线、PCI/ISO 合规检查。

六、典型示例片段（可直接复制的安全配置/策略样例）
A. SSH（sshd_config）

# /etc/ssh/sshd_config
Port 22
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy_admin
ClientAliveInterval 300
ClientAliveCountMax 2
# 限制强制使用较新的 KEX/Ciphers 在高安全性环境中

B. Nginx 强制 HSTS / 安全头（简化）

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "no-referrer-when-downgrade" always;

C. Kubernetes Pod Security（示意）

禁止 root 用户运行容器：

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false

D. IaC 检查（Conftest/Rego）示意

Rego 规则：阻止 S3 public

package s3

deny[msg] {
  input.resource_type == "aws_s3_bucket"
  input.acl == "public-read"
  msg = sprintf("%v: S3 bucket is public", [input.name])
}

七、常见工具（分类、用途与建议）

IaC/Policy Scanners：tfsec, Checkov, Terrascan, Conftest (OPA)

Secrets Detection：git-secrets, truffleHog, detect-secrets

Container/Image Scanning：Trivy, Clair, Anchore

Runtime / Host：Falco, OSSEC, Wazuh, auditd

WAF / App Protection：ModSecurity, Cloud WAF (AWS WAF, Azure WAF)

Secrets Management：HashiCorp Vault, AWS Secrets Manager, Azure Key Vault

SIEM / Observability：ELK/EFK, Splunk, Datadog，Prometheus+Alertmanager

Automated Remediation：AWS Config + Lambda 自动修复、GitOps 与政策阻断（Gatekeeper）

八、配置与策略安全的实施路线图（30/60/90 天）

0-30 天（底座搭建）

建立配置代码化（IaC）和版本控制标准。

在 CI 中加入基本静态扫描（tfsec/checkov）。

禁止在 repo 中存储明文密钥（pre-commit + secret scanning）。

30-60 天（防护建设）

开始 Policy-as-Code（OPA/Gatekeeper）并在 PR 阶段校验。

中央化日志/审计、启用云审计日志。

建立密钥轮换与短期凭证流程。

60-90 天（强化与运维）

启用运行时检测（Falco/OSSEC），并与告警/工单联动。

进行一次全公司规模的配置审计与修复（CIS/benchmark）。

组织红队/蓝队演练，验证检测与响应链路。

九、配置安全常见误区（与真相）

误区：“有 WAF 就安全了” → 真相：WAF 是补充，不是替代。

误区：“只要合规就安全” → 真相：合规是最低线，安全需要持续性运营。

误区：“自动化会带来风险” → 真相：缺乏审核的自动化有风险，但合规的自动化能显著降低人为错误。

十、配置与策略安全清单（操作型、便于上线检查）

身份/访问

• 禁用 root 直登，启用公钥 + MFA。

• 所有高权限操作必须审批并审计。

• 移除未使用 / 过期账号与 IAM 权限。

网络

• 公网入口仅开放必须端口。

• 内部服务启用分段与网络策略。

• 管理端口仅允许跳板 IP 访问。

密钥 / Secrets

• 密钥不在 VCS；启用 Secret Manager。

• 自动轮换关键凭证。

• 对关键密钥启用审计 / 告警。

配置管理

• 所有基础设施以 IaC 管理并经过静态扫描。

• 开发 / 测试 / 生产的配置隔离并有不同 secrets。

• 定期执行配置漂移检测。

运行时

• 集中日志 + SIEM 告警。

• 启用主机 / 容器的文件完整性监测。

• WAF + 入侵检测规则覆盖关键接口。

运维流程

• 变更流程包含回滚、验证步骤。

• 补丁管理策略与 SLAs（critical patch ≤ 7d）。

• 安全事件响应流程与演练计划。

十一、结语：把“配置安全”变成产品力

配置与策略安全不仅是安全团队的事，而是产品/平台/运维/开发的共同责任。把安全规则代码化、审计化、自动化，让安全变成开发与运维的“内建特性”，才能把配置风险降到最低并支撑业务快速演进。