awoooi/docs/security/KALI-SECURITY-MESH-BLUEPRINT.md

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. 目標資料流

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	低

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