認證：來源是誰

認證驗證送出資料的 client 是否合法。未認證的 request 應該被拒絕，避免任意來源向 collector 寫入資料。

API Key 認證

每個合法的 SDK client 有一個 API key。Collector 檢查 request header 中的 API key 是否在合法清單中。

 1func authMiddleware(next http.Handler) http.Handler {
 2    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 3        key := r.Header.Get("X-API-Key")
 4        if !isValidKey(key) {
 5            http.Error(w, "unauthorized", http.StatusUnauthorized)
 6            return
 7        }
 8        next.ServeHTTP(w, r)
 9    })
10}

自用工具場景下，一個 API key 對應一個 client 通常就足夠。多個 client（例如同一個 app 的 iOS 和 Android 版本）可以用同一個 key，或每個平台一個 key 以便在 access log 中區分來源。

mTLS（Mutual TLS）

Client 和 server 互相驗證對方的憑證。安全性比 API key 高 — 攻擊者即使取得 API key，沒有 client 憑證也無法連線。

mTLS 的設定成本較高（每個 client 需要產生和管理憑證），適合對安全性要求較高的環境。自用工具通常不需要 mTLS。

授權：允許做什麼

授權控制已認證的 client 可以執行哪些操作。Collector 的操作通常分為兩類：寫入事件和查詢事件。

角色分離

最簡單的授權模型是兩個角色：

• Writer：只能寫入事件（POST /events）。SDK client 使用這個角色。
• Reader：只能查詢事件（GET /events、GET /query）。開發者的 CLI 工具使用這個角色。

角色分離的價值在於限制洩漏的影響範圍。如果 SDK 的 API key 被洩漏，攻擊者只能寫入（產生垃圾事件），不能讀取（看到歷史事件中的敏感資訊）。

寫入限制

即使認證通過、角色正確，collector 也可以對寫入加上限制：

• Rate limit：每個 API key 每分鐘最多 N 個 request。防止 client 端 bug 導致事件風暴。
• Payload size limit：每個事件最大 M KB。防止異常大的 event data 消耗儲存。
• Schema validation：事件必須符合定義的 JSON schema。格式不正確的事件拒絕存入。

Access Log：誰做了什麼

Access log 記錄每個到達 collector 的 request — 來源 IP、API key（或 key 的 hash）、操作類型、時間戳、response status。

Access log 的用途：

安全審計：發現異常行為 — 未知 IP 的大量寫入、非工作時間的讀取、連續的認證失敗。

問題排查：SDK 說事件送出成功但 collector 沒有收到 — access log 可以確認 request 是否到達、response 是什麼。

用量統計：每個 client 送了多少事件、佔多少儲存。

Access log 本身也是監控資料，但和業務事件分開儲存。Access log 存在 collector 本機的 log 檔中，用系統的 logrotate 管理輪替。

12026-06-19T10:30:00Z POST /events key=sk_mon_ab...cd ip=192.168.1.50 status=200 size=1234
22026-06-19T10:30:01Z POST /events key=INVALID ip=10.0.0.99 status=401 size=0
32026-06-19T10:31:00Z GET /query key=sk_read_ef...gh ip=192.168.1.1 status=200 size=8901

下一步路由

• SDK 端的 redaction → SDK Redaction API 設計
• Transport 層的加密 → Transport 安全
• 資料儲存後的去識別化 → 去識別化策略
• Client-side credential 暴露的根本限制 → Client-side SDK 認證

威脅模型的轉變

連網環境的安全投資集中在邊界防禦：防火牆規則、DDoS 防護、入侵偵測、漏洞修補的速度。斷網環境的邊界是物理的——網路線沒有接上去，防火牆規則不是問題。威脅從「外面的人怎麼進來」變成「裡面的人怎麼把東西帶出去、或把有害的東西帶進來」。

斷網環境的安全投資因此集中在三個面向：控制誰能碰什麼（存取控制）、記錄誰碰了什麼（稽核日誌）、審查什麼東西跨越邊界（傳輸審查）。

實體安全是 infra 的責任

連網環境的實體安全通常歸 facility team——機房門禁、監視器、電力冗餘。infra 團隊負責的是邏輯層的安全（IAM、security group、加密）。斷網環境裡這條分界線消失了：「誰能帶 USB 進機房」直接等於「誰能把任意程式碼注入生產環境」，這是 infra 的安全邊界，不是 facility 的。

需要 infra 團隊參與制定的實體安全政策：

可移除媒體管控：哪些人被授權攜帶 USB / 外接硬碟進入安全區域。媒體是否需要預先登記和加密。進入前是否要在掃描站過掃。政策的嚴格度依環境敏感度而定——最嚴格的環境禁止所有個人裝置、只使用登記在冊的專用搬運媒體。

機房存取控制：門禁卡 / 生物辨識的日誌要進入 infra 的稽核系統。每一次實體進出都要有記錄——誰、什麼時候、待了多久。伺服器機櫃如果有獨立的鎖，鎖的鑰匙管理也歸 infra。

Console 存取：能直接操作伺服器 console（KVM、IPMI、iLO）的人等於擁有最高權限——可以繞過所有 OS 層的認證。console 存取要限制到最小人數，每次使用要記錄。

螢幕與攝影裝置：敏感環境可能限制在安全區域內使用手機（防止拍攝螢幕上的資料）。這個政策的執行通常是 facility 負責，但政策的制定依據（什麼資料在螢幕上算敏感）是 infra 定義的。

身分與認證（沒有雲端 IAM）

連網環境用 OIDC / SSO / 雲端 IAM 管理身分。斷網環境沒有這些——需要自建身分基礎設施。

集中身分管理：FreeIPA（整合 LDAP + Kerberos + DNS + CA）或 OpenLDAP 作為統一的使用者目錄。所有內部服務（GitLab、Nexus、Harbor、Vault、Grafana）都配置 LDAP 認證，避免每個服務各自管一套使用者帳號。FreeIPA 的優勢是把 LDAP、Kerberos、DNS 和 CA 整合在一個管理介面——在資源有限的斷網環境裡減少維運面。

1# FreeIPA 安裝（CentOS/Rocky）
2sudo yum install -y ipa-server ipa-server-dns
3sudo ipa-server-install --setup-dns --no-forwarders

MFA（沒有網路的情況下）：TOTP（如 Google Authenticator）完全在本地運作、不需要網路連線。硬體 token（YubiKey）支援 FIDO2 / PIV / TOTP，在高安全環境是標準做法。智慧卡（CAC / PIV card）在政府和軍事環境最常見。

服務帳號：機器對機器的認證用 Vault 的 AppRole（role_id + secret_id 換取短期 token）或本地 SSL client certificate。不使用長期密碼或寫死的 token。

稽核日誌（沒有 CloudTrail）

連網環境用 CloudTrail / GCP Audit Log 自動記錄所有 API 操作。斷網環境要自建整條稽核鏈：收集 → 傳輸 → 儲存 → 查詢 → 告警。

OS 層級：Linux auditd 記錄 kernel 層的操作——誰執行了什麼指令、誰存取了什麼檔案、誰修改了什麼系統設定。規則用 auditctl 或 /etc/audit/rules.d/ 設定。

1# 監控所有 sudo 操作
2-a always,exit -F arch=b64 -S execve -F euid=0 -k root-commands
3# 監控 /etc/ 目錄的修改
4-w /etc/ -p wa -k etc-changes

服務層級：每個自建服務都有自己的 audit log——GitLab 的 audit events、Vault 的 audit device（可設成 file 或 syslog）、Harbor 的 activity log。這些日誌要匯聚到中央 log server。

集中收集：rsyslog 或 syslog-ng 把各主機的 audit log 轉送到一台專用的 log server。log server 的儲存用 append-only 或 write-once 媒體（防止日誌被竄改）。

日誌完整性：定期對日誌檔做 hash（sha256sum）並把 hash 存到獨立的位置。如果日誌內容被修改，hash 不匹配會被發現。在最高安全等級的環境裡，日誌會同時寫到光碟或 WORM（Write Once Read Many）儲存。

審閱與告警：日誌收集了但沒人看等於沒有。定義哪些事件觸發主動通知（root 登入、非工作時段的操作、大量檔案存取）、哪些事件定期審閱（每週掃描異常模式）。

更新的延遲窗口

連網環境的 CVE 修補可以在小時到天的層級完成——apt update && apt upgrade。斷網環境的修補從「得知漏洞」到「修補上線」之間有結構性的延遲。

典型的延遲鏈：外部公告 CVE → 安全團隊評估影響（1-2 天）→ 在外部環境下載修補（同日）→ 掃描修補本身的安全性（1 天）→ 審批跨邊界傳輸（1-3 天）→ 在斷網測試環境驗證（1-2 天）→ 部署到生產環境（同日）。總延遲 5-10 個工作天。

這個延遲窗口是已知的、可管理的風險。管理方式：

風險接受文件：記錄哪些 CVE 在「已知但尚未修補」的窗口內，每條標註預計修補時間和暫時的補償控制。

補償控制：在修補到位之前降低漏洞的可利用性——禁用受影響的服務功能、收緊網路分段、限制受影響服務的存取權限。

分級修補：不是所有 CVE 都需要緊急處理。Critical（CVSS 9+）走加速通道（目標 3 天內修補）、High（CVSS 7-8.9）走正常通道（目標 10 天）、Medium 以下排進常規更新週期。

跨邊界傳輸的安全審查

每一個跨越隔離邊界的物件都需要審查——套件、映像、設定檔、資料匯出。搬運的操作流程在通用原則篇描述，這裡聚焦安全審查的部分。

掃描站：在邊界設置一台專用的掃描機器，所有入境的媒體先在這裡過掃——防毒掃描、檔案類型驗證、hash 比對（確認下載的套件跟官方發布的 hash 一致）。掃描站本身的病毒定義也需要定期更新（走相同的搬運流程）。

傳輸審批日誌：每次跨邊界傳輸記錄：搬運的內容清單、搬運者、審批者、搬運日期、每個檔案的 hash。這份日誌是稽核的依據——如果內部發現惡意軟體，可以回溯「它是什麼時候、由誰搬進來的」。

Data diode（單向網路裝置）：在最高安全等級的環境裡，跨邊界的網路連線用 data diode——物理上只允許資料往一個方向流動（外部→內部，或反過來）。這比軟體防火牆更難繞過，因為它是硬體限制。data diode 的限制是不支援雙向協定（如 TCP handshake），需要用 UDP-based 的傳輸工具。

主機層入侵偵測

斷網環境的網路流量監控（NIDS）效果有限——內部網路通常扁平、流量加密後難以檢查。主機層入侵偵測（HIDS）是更適合斷網環境的選擇：在每台主機上監控檔案完整性、程序行為、登入模式，而非在網路層攔截。OSSEC 和 Wazuh（OSSEC 的積極維護分支）是開源的 HIDS 方案，agent 裝在每台主機、manager 集中收集告警，不需要連外。

時程與管理層溝通

斷網環境的安全管控初始建置時程：FreeIPA 部署 + 跟所有內部服務（GitLab、Nexus、Harbor、Vault）的 LDAP 整合約需 2-3 天。auditd 規則設定 + syslog 聚合到中央 log server 約需 1 天。掃描站建置（防毒 + hash 驗證 + 傳輸日誌）約需半天。HIDS 部署（Wazuh manager + 各主機 agent）約需 1-2 天。整體安全管控從零到運作約需 5-7 個工作天。

持續維護的主要工作是病毒定義更新搬運（跟隨套件更新週期）、稽核日誌的定期審閱（每週）、以及 CVE 修補的分級處理（依 CVSS 嚴重度排程）。

跨分類引用

• → 模組二：身分與憑證地基：連網環境的 IAM 設計，跟本篇的離線身分方案互補
• → 斷網環境的通用原則：content ferry 模式的操作流程
• → 斷網環境的基礎服務：CA 和 Vault 是本篇認證和機密管理的技術基礎
• → backend 模組七：資安與資料保護：應用層的安全措施