# Kali 資訊安全網藍圖

> 日期：2026-05-06（台北時間）
> 範圍：`192.168.0.112` Kali 資安主機、所有 AWOOOI/AwoooP 資產、開發主機 `192.168.0.168` 與 `192.168.0.111`
> 姿態：先建框架、預設只觀測、後續分階段收攏

## 0. 核心決策

將 `192.168.0.112` 建置為整個架構的資安感測與驗證節點，但初期不採用高強度封鎖。

初期模式如下：

| 層級 | 初期姿態 | 後續姿態 |
|---|---|---|
| 資產發現 | 唯讀盤點與可達性確認 | 持續資產漂移偵測 |
| 掃描 | 低噪音排程掃描 | 依風險與批准執行深度掃描 |
| 發現項 | 寫入證據、評分、路由 | SLA、責任歸屬、政策閘門 |
| 修復 | 僅提出建議 | dry-run、批准後受控執行 |
| 封鎖 | 除確認的機密外，不讓 CI/CD 強制失敗 | 逐步推進 P0/P1 閘門 |

這遵守 MASTER 自主化飛輪規則：不建立靜態黑白名單決策引擎，不硬編修復動作，不在缺少 dry-run 與批准證據時執行破壞性操作。

## 1. 目前盤點結論

### 已經存在

| 面向 | 目前證據 | 缺口 |
|---|---|---|
| Kali 主機 | `192.168.0.112:8080` 已出現在 `docs/reference/SERVICE-ENDPOINTS.md`、`KALI_SCANNER_URL`、NetworkPolicy egress、blackbox probe、`KaliScannerDown` 告警；2026-05-13 已確認 live `/health` healthy 並完成第一波 targeted scanner package update | 目前只監控存活，尚未形成完整掃描結果治理閉環 |
| 資產資料庫地基 | ADR-090 migration 已定義 `asset_inventory`、`asset_discovery_run`、`asset_coverage_snapshot`、`asset_compliance_snapshot` | 目前 scanner 以 K8s 為主；Docker、Gitea repos、網站、主機套件、Kali findings 還不完整 |
| AIOps KPI | `/api/v1/aiops/kpi` 會彙整資產、覆蓋率、規則品質、容量與自動化流量 | 資安姿態尚未成為 KPI 的一級區塊 |
| 合規掃描 | 已寫入 7 個 compliance 維度，SSL 與 Secret 年齡有部分檢查 | `cve_scan`、`audit_log_enabled`、`access_reviewed`、`encryption_at_rest` 多數仍是 `unknown` |
| 資安 Agent | 已有 `SecurityAgent`、`vuln-verifier`、`security_interceptor`、AwoooP security ADR | 尚未接成以 Kali 為核心的資安網 |
| 監控 | 已有 Prometheus/Alertmanager、SignOz、Sentry、blackbox、node exporter、Docker textfile exporter | 資安 finding 尚未正規化為 Prometheus metrics 與 incident taxonomy |
| 網路護欄 | `k8s/awoooi-prod/02-network-policy.yaml` 已 default-deny，並明確允許到 112/110/188/120/121/111 的必要 egress | 168 不是架構資產；111 主要被視為 Ollama fallback，尚未成為完整資安資產 |

### 明顯缺口

| 缺口 | 影響 | 第一個修正方向 |
|---|---|---|
| `192.168.0.168` 沒進 inventory | 開發工作站對資安覆蓋不可見 | 加入資安資產登錄，初期只觀測 |
| `192.168.0.111` 主要被當成 Ollama fallback | Local AI/dev host 可能有模型、SSH、套件風險，但尚未以主機姿態納管 | 加入 host posture、service、model、package、access-review 檢查 |
| Kali findings 沒有標準 schema | 結果會變成一次性報告，不能成為 AI 飛輪證據 | 正規化為 `asset_compliance_snapshot` 與 security event envelope |
| 程式碼資安與 runtime 資安分離 | repo 漏洞、secrets、containers、live services 無法關聯 | 將 SAST、secret、SBOM、container scan 結果接到 `asset_inventory` |
| 缺少階段性 enforcement 表 | 初期容易過度收緊 | 使用 observe -> warn -> approve -> block 的推進閘門 |

## 2. 資安資產地圖

| 類別 | 資產 | 需要的資安覆蓋 |
|---|---|---|
| 資安感測 | `192.168.0.112` Kali Scanner API | scanner health、scan job state、工具版本、結果匯出、保存週期 |
| DevOps 金庫 | `192.168.0.110` Harbor、Gitea、runners、Sentry、Langfuse、Grafana、Prometheus、Ollama proxy | registry image scan、runner hardening、暴露 port、TLS、secrets、CI workflow risk |
| K3s 控制面 | `192.168.0.120`、`192.168.0.121`、VIP `192.168.0.125` | kube-bench 類姿態、RBAC、NetworkPolicy、Pod Security、API exposure、node health |
| AI/Web/Data | `192.168.0.188` PostgreSQL、Redis、OpenClaw、SignOz、MinIO、momo services | DB exposure、backup restore proof、Redis ACL、web/API DAST、storage access、model endpoint exposure |
| Local AI/開發 | `192.168.0.111` Ollama local fallback 與開發主機職責 | host packages、Ollama API exposure、SSH policy、model inventory、fallback readiness |
| 開發工作站 | `192.168.0.168` local development origin | dev-only CORS origin、repo secrets hygiene、local service exposure、least-privilege access |
| 公開網站 | `awoooi.wooo.work`、`aiops.wooo.work`、`mo.wooo.work`、`stock.wooo.work`、`bitan.wooo.work` 與其他 active product domains | TLS、headers、auth、公開攻擊面、endpoint inventory、uptime/security correlation |
| 程式碼/專案 | AWOOOI、AwoooP、MOMO、Tsenyang、Stock、Bitan、future tenants | SAST、dependency/SBOM、secret scan、IaC scan、container scan、contract/policy drift |
| Source Control / CI/CD | Gitea 現有 repos、GitHub primary 候選、branches、tags、workflows、webhooks、runner secrets 名稱 | 供應鏈盤點、版本完整性比對、權限審查、GitHub primary / Gitea mirror 遷移 |
| 可觀測工具 | Prometheus、Alertmanager、SignOz、Sentry、Grafana、Langfuse | admin exposure、token hygiene、alert route integrity、audit export |
| 自動化工具 | MCP Gateway、SSH provider、K8s provider、GitOps、repair bots | tool grants、approval boundaries、command safety、audit and replay |

## 3. 目標資料流

```text
Kali 112 掃描 / 驗證
  -> 資安結果 envelope
  -> AWOOOI API ingestion
  -> asset_inventory / asset_compliance_snapshot / asset_change_event
  -> Prometheus metrics + Alertmanager secops taxonomy
  -> incidents / timeline_events / automation_operation_log
  -> SecurityAgent + Critic + Reviewer triage
  -> Telegram / AwoooP Channel Event
  -> 僅建議修復
  -> 後續 dry-run + approval + 受控執行
```

第一個生產級契約應該是 `security_finding` envelope：

| 欄位 | 意義 |
|---|---|
| `finding_id` | 由 scanner、target、rule id、evidence 產生的穩定 hash |
| `scan_run_id` | Kali run id，可在可能時連到 `asset_discovery_run` |
| `asset_key` | 既有 ADR-090 asset key |
| `target` | Host、URL、repo、image、K8s object、package 或 tool |
| `category` | `exposure`、`cve`、`secret`、`misconfig`、`auth`、`tls`、`web`、`code`、`supply_chain`、`network` |
| `severity` | AI review 前的 scanner severity |
| `confidence` | AI review 前的 scanner confidence |
| `evidence_ref` | 已脫敏證據指標，不存 raw secret 或完整 exploit output |
| `recommended_mode` | `observe`、`warn`、`approve_required`、`block_candidate` |
| `human_required` | 破壞性或權限變更類 action 必須為 true |

## 4. 分階段推進

### Phase 0 - 基線與責任歸屬

目標：讓所有資產可見，但不執行 enforcement。

| 動作 | 主責 Agent | 完成證據 |
|---|---|---|
| 將 112/111/168 加進資安資產登錄 | Asset Cartographer | `asset_inventory` 有 host rows 與 tags |
| 依資產類型定義安全 scan scope | Security Orchestrator | scope file 含 `observe_only=true` |
| 保持 Kali 可達性告警為 health-only | SRE Sentinel | `KaliScannerDown` 仍是 warning，不 auto repair |
| 盤點公開網站與內部 endpoint | Web Perimeter Agent | website/api assets 有 TLS metadata |
| 盤點 Gitea 全量版本與 GitHub 對應目標 | Source Control Migration Steward | repo/branch/tag/workflow/webhook 對照表 |

閘門：不封鎖、不做破壞性掃描、不在未批准時做 credentialed scan。

### Phase 1 - 被動與低噪音掃描

目標：不干擾服務地收集 findings。

| 面向 | 初期檢查 |
|---|---|
| 主機 | port inventory、若 SSH-approved 則 OS/package inventory、SSH banner/config posture |
| 網站 | TLS expiry、headers、基本 auth/session 檢查、安全 DAST crawl |
| K8s | RBAC、Pod Security labels、NetworkPolicy coverage、exposed Services |
| 容器 | image tag inventory、SBOM、已知 CVE scan、registry metadata |
| 程式碼 | secret scan、dependency scan、IaC scan、SAST warning inventory |
| 可觀測工具 | admin exposure、unauthenticated endpoints、token/config drift |

閘門：findings 只進 `observe` 或 `warn`；只有確認的 hardcoded secret 可立即升為 P0。

### Phase 2 - 資安分類與告警

目標：把重複性 findings 轉成有用告警，而不是製造噪音。

新增告警分類：

| 分類 | 範例 | 初期路由 |
|---|---|---|
| `secops_exposure` | 非預期 open port、公開 admin UI | Telegram security summary |
| `secops_cve` | critical vulnerable image/package | incident + owner |
| `secops_secret` | committed token、暴露 env、弱 secret handling | P0 human review |
| `secops_web` | TLS/header/auth weakness | warning ticket |
| `secops_k8s` | privileged pod、弱 RBAC、缺 NetworkPolicy | SRE + Security review |
| `secops_supply_chain` | unsigned image、unpinned dependency、runner risk | DevOps review |

閘門：alert rule 先 warning-only；除既有 hard rules 外，不自動封鎖。

### Phase 3 - 建議與批准模式

目標：AI 提出修復，人類批准高風險變更。

| 動作 | 模式 |
|---|---|
| 建立 issue / Telegram card / AwoooP work item | automatic |
| 針對 headers、dependency bumps、NetworkPolicy additions 草擬 PR | automatic draft |
| rotate secret | approval required |
| 關閉 public port | approval required |
| 修改 RBAC / firewall / CORS | approval required |
| 執行更深層 active scan | approval required |

閘門：每個建議都必須有 evidence、blast radius、rollback 與 owner。

### Phase 4 - 逐步 enforcement

目標：將低噪音且已驗證的控制項提升為 gate。

推進順序：

| Gate | 推進條件 |
|---|---|
| Secret scan gate | 14 天低 false positives，且 confirmed sanitizer |
| Container critical CVE gate | owner mapping 與 override workflow 已存在 |
| IaC dangerous pattern gate | dry-run 可抓問題且不阻擋有效部署 |
| Public exposure gate | inventory 完整且 approved exceptions 已存在 |
| K8s security gate | Pod Security/NetworkPolicy evidence 穩定 |

除非 false-positive rate、owner routing、override、rollback path 都可量測，否則不得提升為 blocking gate。

## 5. 12 Agent 作業模型

| # | Agent | 責任 | 第一個 ownership |
|---|---|---|---|
| 1 | Security Commander | 資安網優先順序與 phase gates | 本藍圖、promotion criteria |
| 2 | Asset Cartographer | 主機、服務、repos、網站、網路、工具 | 112/111/168 的 ADR-090 asset keys |
| 3 | Kali Orchestrator | 掃描 scope、排程、工具 output normalization | `KALI_SCANNER_URL`、security finding envelope |
| 4 | Network Mapper | Port/service/topology drift | 110/112/120/121/188/111/168 + public domains |
| 5 | Web Perimeter Agent | DAST-safe website 與 API posture | public sites、AWOOOI web/API |
| 6 | Code Guardian | SAST、secrets、dependency、SBOM | repo 與 package scan evidence |
| 6A | Source Control Migration Steward | Gitea 全量版本盤點、GitHub primary 遷移、安全權限 | Gitea/GitHub repos、branches、tags、workflows、webhooks |
| 7 | Container Supply Agent | Harbor images、SBOM、image CVEs | registry 與 runtime image mapping |
| 8 | K8s Guard | RBAC、Pod Security、NetworkPolicy、API exposure | `k8s/awoooi-prod`、`k8s/pod-security` |
| 9 | Dev Host Steward | 168 與 111 developer host posture | observe-only host inventory |
| 10 | Observability Sentinel | Prometheus/SignOz/Sentry/Grafana security signals | metrics、alert rules、dashboards |
| 11 | Policy Gatekeeper | AwoooP policy、approval、exception handling | suggest/approve/block promotion |
| 12 | Evidence Archivist | 脫敏證據、audit、KM、timeline | `automation_operation_log`、KM、LOGBOOK |

這是責任分工，不代表一定要同時啟動 12 個 coding session；只有在寫入範圍互不衝突時才並行。

## 6. 需要建置的整合點

| 整合 | 目前 anchor | 需要工作 |
|---|---|---|
| Kali API health | `KALI_SCANNER_URL`、`KaliScannerDown`、`docs/security/KALI-INTEGRATION-STATUS.md` | 新增 scan run/result endpoint 或 adapter |
| 資產盤點 | `asset_scanner_job.py` | 從 K8s 擴展到 hosts、Docker、Gitea/GitHub、websites、dev hosts |
| 合規 | `compliance_scanner_job.py` | 補上 `cve_scan`、`audit_log_enabled`、`access_reviewed`、`encryption_at_rest` |
| KPI | `AiopsKpiService` | 新增 `security_posture` 區塊 |
| 告警 | `alert_rules.yaml`、`alerts-unified.yml` | result schema 穩定後新增 secops taxonomy |
| AwoooP | ADR-106/107 contracts | enforcement 前先 mirror findings 到 Channel/Runtime events |
| 前端 | `/security-compliance` | 顯示 API 產生的真實 security posture，不用靜態 widgets |
| 知識 | KM/RAG + playbooks | 資安修復 outcomes 成為可檢索 evidence |

## 7. 護欄

1. 預設不做破壞性掃描。
2. 未經明確批准與維護窗口，不對 production 執行 exploit。
3. 未定義 credential source、scope、audit trail 前，不做 credentialed scanning。
4. Telegram、logs、KM 不得存 raw secret、token、cookie、key、exploit payload。
5. Phase 0-2 不自動修改 firewall、RBAC、CORS、NetworkPolicy、route 或 secret rotation。
6. 開發主機 `192.168.0.168` 與 `192.168.0.111` 初期為 `observe-only`，不是 compliance blocker。
7. Security findings 必須用 stable fingerprint 去重後才能告警。
8. 每個 finding 必須有 asset owner、severity、confidence、evidence pointer、next action。
9. Blocking gate 必須有可量測 false-positive rate 與 override workflow。
10. 長期授權由 AwoooP policy 負責；scanner 只提供 evidence。

## 7.1 2026-05-13 Live 整合狀態

`192.168.0.112` 已經完成第一波 live 盤點與低風險更新，正式記錄於 `docs/security/KALI-INTEGRATION-STATUS.md`。

已確認：

1. `kali-scanner.service` active / enabled。
2. `/health` healthy。
3. `nmap`、`nikto`、`nuclei`、`curl`、`openssl`、CA 套件已做 targeted update。
4. 已安裝 `jq`。
5. 主機時區已調整為 `Asia/Taipei`。
6. 更新後 SSH / cron / docker / scanner service 都 active，且不需 reboot。
7. `security_finding_v1` sample snapshot 已建立。
8. `kali_scan_scope_approval_v1` approval package 已建立，111/168 已納入 observe-only scope。

仍然不能做：

1. 不直接啟動 active scan。
2. 不做 credentialed scan。
3. 不讓 AwoooP 直接呼叫 Kali `/execute` endpoint。
4. 不保存 API key、SSH 密碼或任何 secret value。
5. 不做 full-upgrade、autoremove 或 reboot，除非先排維護窗口。

## 7.2 2026-06-04 只讀重驗證狀態

`192.168.0.112` 已於 2026-06-04 08:55（台北）重新完成只讀 SSH 快照，沒有啟動掃描、沒有呼叫 `/execute`、沒有執行套件更新、沒有調整設定、沒有重啟。最新證據正式記錄於 `docs/security/KALI-INTEGRATION-STATUS.md` 與 `docs/security/kali-integration-status.snapshot.json`。

已確認：

1. 既有 SSH key 可只讀連線。
2. `kali-scanner.service` 仍為 active / enabled。
3. `127.0.0.1:8080/health` 仍回 `200 healthy`。
4. `node-exporter` 與 `wg-easy` 容器仍在運作。
5. 主機時區維持 `Asia/Taipei`。
6. `failed_systemd_unit_count=1`，目前為 `networking.service`。
7. `upgradable_package_count=1994`。
8. scanner service hardening 仍是 `0 / 4`，`NoNewPrivileges`、`PrivateTmp`、`ProtectSystem`、`ProtectHome` 尚未啟用。

結論：Kali 112 已經從「文件與 5/13 盤點」推進到「6/4 再驗證的 live read-only evidence」，但仍不代表 full-upgrade、autoremove、reboot、主動掃描、憑證掃描、服務 hardening override 或 AwoooP `/execute` 已被批准。

## 8. 第一波實作建議

建議下一波程式實作：

| 步驟 | 變更 | 風險 |
|---|---|---|
| 1 | `security_finding_v1` schema / sample 已建立；下一步只需在批准後補 adapter contract / ingestion path | 低 |
| 2 | 建立 Gitea 全量版本盤點與 GitHub primary / Gitea mirror 遷移清單，先只盤點與比對，不切主控 | 低 |
| 3 | 111/168/112 已有 scan scope 草案；批准後再加進 asset discovery seed | 低 |
| 4 | 新增 Kali result ingestion endpoint，只存脫敏 findings | 中 |
| 5 | 擴充 compliance scanner，消費 Kali findings 到 `cve_scan` 與 `secops_exposure` | 中 |
| 6 | 在 `/api/v1/aiops/kpi` 新增 `security_posture` | 低 |
| 7 | 從 normalized finding counts 輸出 warning-only Prometheus metrics | 中 |
| 8 | 新增前端 `/security-compliance` 真實資料 panel | 低 |

本波不得部署自動封鎖或自動修復。