深色模式
零信任初探：理念与落地路径
摘要：零信任不是一款产品，而是一套"永不信任、始终验证"的设计原则。本文讲清它的核心假设与三大支柱，并给出运维侧可以分阶段推进的落地路径。
适用环境
bash
cat /etc/os-release
command -v kubectl && kubectl version --short 2>/dev/null
systemctl is-active sshd
ss -lntup | head -20
command -v nft && nft list ruleset | grep -c "policy drop"1
2
3
4
5
2
3
4
5
操作步骤
1. 先理解核心假设的转变
传统模型：内网 = 可信，外网 = 不可信。一旦进入内网（VPN、办公网），基本畅通无阻。
零信任模型：网络位置不提供任何信任。每一次访问都要验证身份、设备状态、上下文，并且是持续验证而非一次验证。
实践含义：内网服务同样要鉴权、加密、最小权限、审计。
2. 三大支柱
| 支柱 | 含义 | 运维侧对应措施 |
|---|---|---|
| 强身份验证 | 身份可信且持续校验 | 双因子、短时效令牌、设备证书 |
| 最小权限访问 | 只给访问特定资源所需权限 | RBAC、按资源授权、Just-In-Time 权限 |
| 持续验证与可见性 | 每次请求都评估风险 | 日志、行为分析、策略引擎、自动响应 |
3. 落地第一阶段：身份与凭据（最容易起步）
bash
# 消灭共享账号与长期静态口令
awk -F: '$3>=1000 {print $1}' /etc/passwd
# 所有 SSH 走密钥 + 双因子，禁止口令
sshd -T | grep -E '^(permitrootlogin|passwordauthentication)'
# 静态密钥集中托管并短时效
vault status 2>/dev/null | head -31
2
3
4
5
6
2
3
4
5
6
目标：不存在长期有效的静态凭据，所有访问都可归因到具体的人或服务。
4. 落地第二阶段：微隔离（缩小爆炸半径）
bash
# 主机层：按来源精确放行（而非网段大开）
nft list ruleset | grep -E "dport|saddr"
# K8s 层：默认拒绝 + 逐条放行
kubectl get netpol -A1
2
3
4
2
3
4
目标：任何单点被拿下，横向可达面被限制在最小范围。
5. 落地第三阶段：替代传统 VPN 的访问控制
传统 VPN 一旦接入等于进入内网。替代思路：
- 应用级代理（identity-aware proxy）：每次访问单独鉴权，按应用授权而非按网络授权。
- 服务间 mTLS：服务身份用证书，双向校验。
- Just-In-Time 访问：需要运维时申请临时权限，到期自动回收。
bash
# 服务间 mTLS 落地（Istio 示例）
kubectl -n prod get peerauthentication 2>/dev/null
istioctl x describe pod <pod> -n prod 2>/dev/null | grep -i mtls1
2
3
2
3
bash
# 临时权限到期自动回收示例
cat >/usr/local/bin/jit-revoke.sh <<'EOF'
#!/bin/bash
# 扫描 /etc/sudoers.d/ 中带过期标记的授权并撤销
grep -l "# expires:" /etc/sudoers.d/* 2>/dev/null | while read -r f; do
exp=$(grep -oP '# expires: \K[0-9-]+' "$f")
[ "$(date +%F)" ">" "$exp" ] && { rm -f "$f"; visudo -c >/dev/null; echo "已回收: $f"; }
done
EOF
chmod +x /usr/local/bin/jit-revoke.sh1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
6. 落地第四阶段：持续验证与自动化响应
bash
# 行为基线 + 异常检测（Falco）
systemctl is-active falco
journalctl -u falco --since "1 hour ago" | grep -c CRITICAL
# 策略引擎（OPA/Kyverno）在准入时拦截不合规请求
kubectl get clusterpolicies 2>/dev/null | head -51
2
3
4
5
2
3
4
5
7. 运维侧改造清单（可直接对照执行）
| 现状 | 零信任改造 |
|---|---|
| 办公网/VPN 内可直接访问管理后台 | 管理后台单独鉴权 + 仅允许应用级代理访问 |
| 服务间调用无鉴权 | 全量 mTLS + 服务身份证书 |
| 长期 SSH 密钥 | 短期证书（SSH CA）+ 集中签发与吊销 |
| 网段级防火墙放行 | 按身份/标签的细粒度策略 |
| 静态数据库口令 | 动态凭据 + 短 TTL |
SSH 证书登录示例（替代长期 authorized_keys）：
bash
# 生成 CA
ssh-keygen -t ed25519 -f /etc/ssh/ca -C "ssh-ca"
ssh-keygen -s /etc/ssh/ca -I opsuser -n opsuser -V +8h /home/opsuser/.ssh/id_ed25519.pub
# 服务端信任 CA
echo "TrustedUserCAKeys /etc/ssh/ca.pub" >> /etc/ssh/sshd_config.d/97-ca.conf
sshd -t && systemctl reload sshd1
2
3
4
5
6
2
3
4
5
6
8. 常见误区
- 零信任 ≠ 买一套产品就完事，它是架构原则。
- 零信任 ≠ 取消内网防护，微隔离反而更重要。
- 零信任 ≠ 一次性项目，是分阶段的持续演进。
验证
bash
# 身份：无口令登录、无共享账号
sshd -T | grep -E 'passwordauthentication|permitrootlogin'
# 隔离：默认拒绝生效
nft list ruleset | grep -c "policy drop"; kubectl get netpol -A | wc -l
# 加密：服务间 TLS
kubectl -n prod get peerauthentication -o yaml 2>/dev/null | grep -i mode
# 凭据：短期证书有效
ssh-keygen -L -f /home/opsuser/.ssh/id_ed25519-cert.pub 2>/dev/null | grep -A2 "Valid:"1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
判定标准：所有访问可归因；无长期静态凭据；默认拒绝已生效；服务间加密且双向校验。
常见坑
以为买了 SDP/零信任网关就等于落地零信任
产品只是载体。没有身份治理、微隔离和持续验证，网关会退化成另一个 VPN。
只做身份不做微隔离
身份被突破后依然可以横向移动。两者必须并行。
一次性大爆炸式改造
零信任迁移周期长、影响面大。按"身份 → 隔离 → 代理 → 持续验证"分阶段推进。
改造过程中忘记保留应急通道
收紧访问时务必保留带外控制台与应急账号（物理/流程上受控），否则会出现无人能运维的局面。
忽视用户体验导致被绕过
过于繁琐的验证会让团队找后门绕过。要在安全与效率间取平衡，用 SSO、短期证书等降低摩擦。