---
phase: 2
name: scope-lock-and-reflow
purpose: Phase 2 范围锁定仪式 + 盘点回流机制 + 影子证书溯源 + 资产分类
parent: ../SKILL.md
updated: 2026-04-23
---

# 🔒 Phase 2 · Scope Lock + 回流机制

> Phase 1 的资产清单是"**发现结果**"，不是"**本次要做什么**"。两者之间必须有一道**范围锁定仪式（Scope Lock Ceremony）**。
> 此外，Phase 3-6 任一阶段发现新资产，必须能**回流**到 Phase 2 清单并触发重评估，而非静默忽略。

---

## 1. Scope Lock Ceremony（范围锁定仪式）

### 1.1 为什么需要仪式感

Phase 1 闭包发现可能产出几十条资产条目，但**不是每条都要本次变更**。常见三类：

| 归类 | 举例 | 处理 |
|---|---|---|
| **in-scope** | 本次变更主目标 | 进入 Phase 3-6 |
| **out-of-scope** | 不在本次范围（如过期还远的关联证书） | 仍在清单可见，但不处理 |
| **defer** | 想处理但本次条件不满足（如凭证丢失） | 生成"未知资产追踪表"跟进 |

**没有显式仪式**的后果：Phase 3-6 会反复纠结"这个要不要做"，客户焦躁。

### 1.2 仪式执行

Agent 在 Phase 1 交付资产清单后，**不直接进 Phase 3**，而是发一张 **Scope Lock 表** 给客户逐行勾选：

```markdown
## Scope Lock 表（请逐行勾选）

### 主证书闭包内
| 资产 | 默认建议 | 客户决定 |
|------|---------|---------|
| Cert-A (主证书) | ✅ in-scope | [ ] in-scope  [ ] defer  [ ] out-of-scope |
| *.billing.example.com (关联证书 60 天后过期) | ✅ in-scope（合并换） | [ ] in-scope  [ ] defer  [ ] out-of-scope |
| Cert-Z (6 个月后才过期) | ⚠️ defer（本次不急） | [ ] in-scope  [ ] defer  [ ] out-of-scope |

### 影子证书（见 §3 溯源流程）
| Cert-X (LE acme.sh 自签，admin.example.com) | ❓ 待溯源 | [ ] in-scope  [ ] defer  [ ] out-of-scope |

### 未知资产
| 收购遗留 zone foo.com 的部署点 | ⏳ 追踪中 | [ ] in-scope（等解锁）  [ ] defer  [ ] out-of-scope |

☑️ 客户确认后锁定范围，进入 Phase 3
```

### 1.3 Scope Lock 后的更改规则

- **仪式完成后**：范围锁定，Phase 3-6 只处理 in-scope 条目
- **Phase 3-6 发现新资产**：走**回流机制**（§2），**不得**擅自改范围
- **客户主动要求扩范围**：回到 Scope Lock 重锁一次，记录版本号（v1.0 → v1.1）

---

## 2. 盘点回流机制

### 2.1 为什么需要回流

Phase 1 的闭包虽然努力，但**客户记忆会在 Phase 3-6 被触发**冒出被遗忘的资产。F1 案例里老王在 Phase 3 才想起旧 Java JKS 还装着证书——这是**高频真实现象**。

骨架必须允许"**Phase 3/4/5/6 任一阶段发现新资产 → 回流到 Phase 2 → 重锁 Scope → 再进入对应 Phase**"。

### 2.2 回流流程

```
  [当前 Phase] → 发现新资产
       ↓
  Agent 暂停当前 Phase
       ↓
  回到 Scope Lock，生成《范围变更请求》(Scope Change Request)
       ↓
  客户决策：in-scope / defer / out-of-scope
       ↓
  更新资产清单版本（v1.0 → v1.1）
       ↓
  如果 in-scope：
    - 对新资产做 Phase 1 迷你循环（闭包 / DNS 探针）
    - 把新资产挂到当前 Phase 的处理计划里
    - 按需触发 Phase 3 风险重评估
  如果 defer/out-of-scope：
    - 仅记录，不处理
       ↓
  恢复当前 Phase 执行
```

### 2.3 范围变更请求（SCR）格式

```markdown
## Scope Change Request #N
- **发现时机**：Phase X / 某具体步骤
- **新资产**：[具体描述 + 证据]
- **默认建议**：in-scope / defer / out-of-scope
- **理由**：...
- **影响的已有计划**：[列出哪些 Phase 3-6 产物需要回写]
- **客户决策**：[ ] 接受建议  [ ] 其他：_____
```

---

## 3. 影子证书溯源工作流

### 3.1 触发条件

Phase 1 / Phase 2 CT 日志查询时发现 **"非种子证书闭包内" 的证书**（例：同一 zone 签过另一张 CA 的证书、不在 Agent 已知清单里的证书）。

### 3.2 溯源步骤

```
Step 1  按 CA 查签发账号
  - 通过证书 Subject 和签发 CA 联系该 CA 的账号主体
  - 查出"是谁签的"

Step 2  内部通告确认
  - Agent 生成一张"影子证书归属确认单"
  - 客户在公司内部（邮件 / 企微 / Slack）发一遍，问"这张证书是谁在管？"
  - 限期 48h 内认领

Step 3  三路分流
  - 认领 → 合法影子（业务团队自建，纳入 Scope Lock defer）
  - 逾期未认领 → 上报安全组（可能是盗签 / 供应链风险 / 离职员工遗留）
  - 可疑 → 按安全组流程走吊销评估

Step 4  记录溯源结果到资产清单
```

### 3.3 溯源表模板

```markdown
## 影子证书溯源表
| 证书 SHA | Subject | CA | 签发日 | 过期日 | 归属状态 | 处置 |
|---------|---------|-----|-------|--------|---------|------|
| abc123... | admin.example.com | Let's Encrypt | 2025-01 | 2025-04 | ✅ 业务团队 Alice 认领 | defer（本次不处理）|
| xyz789... | test.example.com | ZeroSSL | 2024-11 | 2026-02 | 🔴 逾期未认领 | 已上报安全组 |
```

---

## 4. 客户侧证书资产全景扫描选项

Phase 2 末尾应询问客户："你希望本次扫描范围是？"

| 选项 | 范围 | 额外时间 | 适用场景 |
|------|------|---------|---------|
| **A. 种子闭包窄范围**（默认） | 仅处理种子证书闭包内的资产 | 标准时间 | 明确只管这一张证书的替换 |
| **B. 全景扫描宽范围** | 额外扫 CT log 拉客户名下全部证书 | +30 min ~ 几小时 | 希望顺手理清所有证书资产 |
| **C. 同 CA 全量** | 在现 CA 账号下列出全部证书 | +10 min（如有 API 账号）| 只想看同一家 CA 的资产 |

客户选项决定 Phase 2 范围宽度。建议在 Full Path 默认 B；Standard 默认 A。

---

## 5. 资产分类维度

Phase 2 做资产分类，为 Phase 3 的风险评估提供输入：

| 分类 | 定义 | 特征 | 风险级 |
|------|------|------|-------|
| **A. 主品牌核心** | 高可见度、业务关键 | 文档齐全、负责人明确 | 🟢 低（但故障影响最大）|
| **B. 主品牌边缘** | 低流量但在册 | 可能长期无人维护 | 🟡 中 |
| **C. 收购遗留** | 合并前的独立资产 | 架构迷雾 / 负责人已离职 / 可能有法务约束 | 🔴 高 |
| **D. 影子资产** | 非官方但在活跃 | 来自业务侧自建 / 可能未审计 | 🟡 中 |
| **E. 历史废弃** | 已下线但证书未吊销 | CT 有记录但无流量 | 🟢 低（但影响资产统计）|

分类结果直接影响：
- 审批矩阵（C 类常需法务参与）
- 风险打分（C/D 类权重更高）
- 部署优先级（A 类先灰度 / 先验证）

---

## 6. 绑定点（binding）的统一定义

> **绑定点 = 可以通过 API 或控制台替换证书的最小管理单元**

| 资源类型 | 绑定点定义 | 反例（不是一个绑定点）|
|---------|-----------|-------------------|
| CDN | **1 个 CNAME 域名 = 1 个绑定点** | 不是每台 CDN 边缘机 |
| 负载均衡 | **1 个监听器（Listener）= 1 个绑定点** | 不是整个 LB 实例 |
| K8s Ingress | **1 个 Ingress 资源 = 1 个绑定点** | 不是一个 namespace |
| Nginx | **1 个 `ssl_certificate` 指令 = 1 个绑定点** | 不是一整个 Nginx 进程 |
| 裸 Java / Go 应用 | **1 个应用实例持有的 JKS/PFX 文件 = 1 个绑定点** | 不是一个主机 |
| API 网关 | **1 个自定义域名绑定 = 1 个绑定点** | 不是整个网关 |

这个定义**让盘点、审批、部署、回滚的粒度对齐**。

---

## 7. cert_role（证书角色）维度

同一批域名可能涉及多张证书，**扮演不同角色**：

| cert_role | 定义 | 举例 |
|-----------|------|------|
| **edge** | 面向终端用户的边缘证书（CDN / WAF 层）| Cloudflare Universal SSL / 阿里云 CDN 证书 |
| **origin** | CDN 回源用的源站证书（终端用户看不到）| 客户的自建 Nginx 证书 |
| **internal** | 仅内网服务间通信使用 | K8s service mesh / 内部 API |
| **mtls-server** | 双向 mTLS 的服务端证书 | API 网关对第三方的 mTLS |
| **mtls-client** | 双向 mTLS 的客户端证书 | 你作为客户端调 SaaS 时 |

**不同 cert_role 的 Phase 6 验证方式不同**：
- `edge` → 看 OCSP / CT log / 终端浏览器验证
- `origin` → 只看 CDN 回源是否 OK，不需要走公网握手
- `internal` → 只看内网访问链路
- `mtls-*` → 需双端同步更新，回滚耦合最高

> 📌 **Phase 1 盘点必须明示 cert_role**，避免默认假设"1 证书 1 部署"。

---

## 8. 相关文件

- [`01-inventory-guidance.md`](./01-inventory-guidance.md) — Phase 1 的闭包发现执行
- [`../SKILL.md`](../SKILL.md) — SAN 闭包发现根本定义
- [`03-risk-assessment-playbook.md`](./03-risk-assessment-playbook.md) — 风险评估接受资产分类输入