預設 Redaction Rule

SDK 內建的 redaction rule 覆蓋最常見的敏感欄位模式。開發者不需要設定就能獲得基本保護。

欄位名稱比對

以下欄位名稱（不分大小寫）的值自動替換為 [REDACTED]：

• password、passwd、secret、token、api_key、apiKey
• authorization、auth、credential
• ssn、social_security
• credit_card、card_number、cvv、cvc

欄位名稱比對用 substring match — user_password 包含 password 會被 redact，password_reset_token 包含 password 和 token 也會。

值格式比對

以下格式的值無論欄位名稱為何都自動替換：

• Email 地址格式（user@domain.com → u***@domain.com）
• 信用卡號碼格式（連續 13-19 位數字 → 保留末四碼）
• Bearer token 格式（Bearer xxx → Bearer [REDACTED]）

值格式比對用正則表達式。正則的效能影響在大量事件時需要注意 — 預設 rule 的正則保持簡單，避免 catastrophic backtracking。

自訂 Pattern

應用可能有自己的 secret 格式，預設 rule 覆蓋不到。SDK 提供 API 讓開發者註冊自訂 redaction pattern。

 1monitor.addRedactionRule(
 2  name: 'internal-api-key',
 3  pattern: RegExp(r'sk_live_[a-zA-Z0-9]{24}'),
 4  replacement: '[REDACTED:api-key]',
 5)
 6
 7monitor.addRedactionRule(
 8  name: 'database-url',
 9  fieldNames: ['database_url', 'db_url', 'connection_string'],
10  replacement: '[REDACTED:db-url]',
11)

自訂 pattern 的設計考量：

Pattern 在 init 時註冊。Redaction rule 在 SDK 初始化時設定，之後所有事件都通過這些 rule。不支援動態修改 — 避免「中途加 rule 導致之前的事件沒被 redact」的困惑。

Pattern 順序無關。所有 rule 獨立執行，不依賴順序。一個欄位可以匹配多個 rule，以第一個匹配的 replacement 為準。

Replacement 可以保留部分資訊。[REDACTED] 完全遮蔽，[REDACTED:api-key] 保留類型資訊，u***@domain.com 保留結構。保留類型資訊對 debug 有幫助 — 看到 [REDACTED:api-key] 至少知道這裡原本有一個 API key。

Redaction 的適用範圍

Redaction 應用在 SDK 送出事件前的最後一步 — 在序列化（JSON encode）之前。適用範圍包括：

• Event 的 data 欄位（自由欄位，開發者可能放入任何內容）
• Error 的 stack trace（檔案路徑可能包含使用者名稱或部署路徑）
• Error 的 message（例外訊息可能包含 query string 或參數值）
• Lifecycle 的 metadata（連線 URL 可能包含認證資訊）

Redaction 不應用在 SDK 的內部欄位（timestamp、event type、session ID）— 這些是 SDK 自己產生的，不包含使用者資料。

下一步路由

• 資料離開 client 後的保護 → Transport 安全
• 去識別化策略 → 去識別化策略
• IME 個人化學習的 secret 洩漏風險 → ux-design 模組三 IME 安全 checklist

同區網也要加密的理由

自用工具的 SDK 和 collector 通常在同一台機器或同一個區域網路（LAN / Tailscale tailnet）。常見的假設是「同區網不需要加密，因為只有我自己在用」。

這個假設在以下情境不成立：

共用網路：咖啡廳、共享辦公室、飯店 WiFi — 同一個 AP 下的其他裝置可以用 ARP spoofing 或 WiFi sniffing 攔截未加密的 HTTP 流量。

未來的網路拓撲變更：目前在同一台機器上的 SDK 和 collector，可能之後拆到不同的機器或不同的網路段。如果一開始就用 HTTPS，拓撲變更不需要額外的安全調整。

養成正確習慣：在自用工具上用 HTTP 是因為「反正只有我」，但相同的開發者在商業專案中可能延續這個習慣。從自用工具開始就用 HTTPS，讓加密傳輸成為預設行為。

HTTPS 設定

自簽憑證

自用工具和內部服務用自簽憑證（self-signed certificate）就足夠。不需要購買 CA 憑證 — 自簽憑證提供加密（防竊聽）和完整性（防篡改），只是不提供身份驗證（client 無法確認 server 是不是「官方的」）。在自用場景中 server 就是自己架的，身份驗證不是問題。

1openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Go collector 使用自簽憑證：

1http.ListenAndServeTLS(":8443", "cert.pem", "key.pem", handler)

SDK 端需要信任自簽憑證。開發期可以在 HTTP client 設定 badCertificateCallback 接受自簽憑證；production 應該把自簽憑證加入系統的信任清單。

Let’s Encrypt

如果 collector 有公開的 domain name，用 Let’s Encrypt 取得免費的 CA 憑證。自動續期、不需要手動管理。適合部署在 VPS 或雲端的 collector。

Basic Auth

HTTPS 保護傳輸層（防竊聽），basic auth 保護 endpoint 層（防未授權存取）。兩者互補，缺一不可 — basic auth 在 HTTP 上傳送的是 base64 編碼的帳密，沒有 HTTPS 的加密保護等於明文傳送。

1Authorization: Basic base64(username:password)

SDK 在每個 HTTP POST request 的 header 中帶上 basic auth。Collector 端驗證帳密，不匹配則回傳 401。

Basic auth 的帳密管理：

• 帳密存在 SDK 的設定檔或環境變數中，不硬編碼在程式碼裡
• Collector 端的帳密用 bcrypt hash 儲存，不存明文
• 定期輪替帳密（自用工具半年到一年一次即可）

API Key 替代方案

如果不需要 username/password 的雙因素，單一 API key 更簡單。

1X-API-Key: sk_monitor_abc123...

API key 的管理比 basic auth 簡單（一個字串而非帳密對），但安全性略低（只有一個 factor）。自用工具場景下 API key 通常足夠。

下一步路由

• SDK 端的 redaction → SDK Redaction API 設計
• Collector 端的 access control → Collector Access Control 實作
• Server-side 的 secret management → backend 07 資安

認證：來源是誰

認證驗證送出資料的 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 認證

IP 截斷

IP 位址是最常見的個人識別欄位。完整的 IPv4 位址（192.168.1.50）可以定位到特定的網路和裝置；截斷後的 IP（192.168.1.0）保留網段資訊但無法定位到特定裝置。

截斷策略

IPv4 末八位清零：192.168.1.50 → 192.168.1.0。保留 /24 網段資訊，足以判斷「使用者在哪個網段」但無法定位到特定裝置。Google Analytics 採用這個策略。

IPv4 末十六位清零：192.168.1.50 → 192.168.0.0。更強的去識別化，但地理定位精度降低到城市級。

IPv6：截斷更多位元。IPv6 的後 80 位通常包含 MAC 位址衍生的 interface ID — 截斷到 /48 前綴保留 ISP 資訊，移除裝置識別。

實作位置

IP 截斷應在 collector 收到事件後、寫入儲存前執行。SDK 端不做 IP 截斷 — SDK 通常不知道自己的外部 IP（知道的是 NAT 後的內部 IP），外部 IP 是 collector 從 HTTP request 的 source IP 取得的。

User Agent 簡化

User agent 字串包含瀏覽器版本、OS 版本、裝置型號 — 組合起來可能形成唯一的 fingerprint。簡化 user agent 保留有用的分類資訊（「iOS 17 上的 Safari」），移除可用於 fingerprinting 的細節（「iPhone 15 Pro Max, Build/22A3354」）。

簡化規則

保留：平台（iOS / Android / Windows / macOS）、主要版本號（iOS 17、Android 14）、瀏覽器類型（Safari / Chrome / Firefox）。

移除：minor version、build number、裝置型號、CPU 架構、語言設定。

1原始：Mozilla/5.0 (iPhone; CPU iPhone OS 17_4_1 like Mac OS X)
2簡化：iOS/17 Safari

Stack Trace 路徑清理

Error 事件的 stack trace 包含檔案路徑。檔案路徑可能洩漏部署結構（/home/deploy_user/app/v2.3.1/src/...）或開發者的個人資訊（/Users/alice/projects/...）。

清理規則

移除使用者目錄前綴：/Users/alice/projects/app/src/main.dart:42 → src/main.dart:42。保留 source file 相對路徑和行號，移除使用者名稱。

移除部署路徑前綴：/opt/deploy/releases/20260619/app/lib/... → lib/...。保留程式碼結構，移除部署細節。

統一 path separator：Windows 路徑（C:\Users\...）和 Unix 路徑（/home/...）統一處理。

清理規則用正則表達式匹配常見的路徑前綴模式，替換為空字串。自訂的部署路徑格式需要在 collector 設定中額外註冊。

Session UUID

Session ID 用於關聯同一次使用中的多個事件。UUID v4（隨機產生）作為 session ID，沒有可預測性、沒有順序性、無法回推使用者身份。

Session ID 的生命週期

SDK 在初始化時產生一個 UUID v4 作為 session ID，所有事件附帶這個 ID。App 重新啟動時產生新的 session ID — 前後兩次使用的事件無法關聯。

這個設計讓分析粒度限制在「一次使用」而非「一個使用者」。如果需要跨 session 關聯（例如計算 DAU），需要另一個 persistent ID — 但 persistent ID 本身就是可識別資訊，需要使用者同意。

避免使用可識別的 ID

裝置 ID（IDFA / GAID）、安裝 ID、使用者帳號 — 這些可以關聯到特定個人，不適合作為監控系統的 session ID。使用 UUID v4 確保 session ID 的唯一性來自隨機性而非身份。

去識別化是資料保護的一環，另一環是在資料離開 client 之前就處理 — SDK Redaction API 設計從 SDK 端攔截敏感欄位。法規層面的具體要求見 GDPR 最小化原則的工程落地。去識別化完成後的資料才能用於行為分析 — 這是商業利用的入場條件。

資料最小化：只收集需要的欄位

資料最小化的工程落地是「每個收集的欄位都要能回答：這個欄位用來做什麼決策？」。如果一個欄位只是「可能有用」但沒有明確的消費場景，就不應該收集。

正面表列 vs 負面排除

正面表列（allowlist）是列出「收集哪些欄位」— 只收集清單上的欄位，其他全部不收。

負面排除（denylist）是列出「不收集哪些欄位」— 預設收集所有欄位，排除清單上的。

GDPR 的精神更接近正面表列 — 每個收集行為需要有正當理由（lawful basis）。工程上的實作方式是：事件 schema 定義哪些欄位是允許的，不在 schema 中的欄位在 collector 端丟棄。

SDK 端的最小化

SDK 端的最小化更主動 — 在事件產生時就只包含必要的欄位，而非送到 collector 再過濾。

設計 SDK 的 event API 時，不提供「送任意 key-value」的 free-form API，而是提供結構化的 API：

1// free-form（難以控制收集了什麼）
2monitor.event('login', data: {'email': email, 'ip': ip, 'device': device, ...})
3
4// 結構化（schema 控制收集範圍）
5monitor.event('login', loginMethod: 'biometric', success: true)

結構化 API 的參數在 SDK 設計時就決定了收集範圍，code review 時可以檢查「為什麼這個 event 需要這個參數」。

目的限制：收集的資料只用於聲明的目的

目的限制要求資料只用於收集時聲明的目的。監控系統收集事件的目的通常是 debug 和效能監控 — 如果之後要用同一份資料做行為分析或廣告投放，需要額外的法律基礎（通常是使用者同意）。

工程落地

目的限制在工程上的實作是「不同目的的資料分開儲存、分開授權」。

Debug 用的 error 事件和行為分析用的 event 事件存在不同的儲存位置（不同的 JSONL 檔案或不同的資料庫 table）。Debug 用途的 access 不需要使用者同意（legitimate interest）；行為分析用途的 access 需要使用者同意。

分開儲存讓「使用者撤回行為分析同意」的工程操作變簡單 — 刪除行為分析的儲存，不影響 debug 儲存。

儲存限制：不保留超過必要期間的資料

儲存限制要求資料只保留達成目的所需的最短期間。監控資料的合理保留期間依用途不同：

自動清理

Collector 的儲存清理應該自動化 — 手動清理依賴人記得執行，最終會被遺忘。

JSONL 儲存用「一天一檔」的命名（events-2026-06-19.jsonl），清理腳本每天刪除超過保留期限的檔案。Cron job 或 systemd timer 定期執行。

下一步路由

• 去識別化技術 → 去識別化策略
• 監控資料洩漏的威脅分析 → 監控資料洩漏的 threat model
• Collector 的儲存設計 → 模組四 Collector 設計

威脅場景一：傳輸竊聽

攻擊方式

攻擊者在 SDK 和 collector 之間的網路路徑上攔截未加密的 HTTP 流量。同網段的 ARP spoofing、WiFi sniffing、或中間人（MITM）proxy。

暴露的資料

事件的完整 JSON payload — 包括 redaction 後殘留的資訊（使用者行為、系統狀態、error message）。API key 或 basic auth credential 如果在 HTTP header 中明文傳送，也會被攔截。

防護

使用 HTTPS 加密傳輸（Transport 安全）。所有 SDK 到 collector 的通訊走 TLS — 自簽憑證在自用場景足夠，公開部署用 Let’s Encrypt。

威脅場景二：儲存入侵

攻擊方式

攻擊者取得 collector server 的存取權限（SSH 入侵、容器逃逸、雲端 IAM 權限提升），直接讀取儲存的事件檔案。

暴露的資料

所有歷史事件 — 包含 redaction 處理後的事件。如果 redaction 不完整（遺漏了某些敏感欄位），歷史事件中可能包含 secret。

防護

最小化儲存：只保留必要期限的資料，過期自動刪除（GDPR 最小化原則）。攻擊者能取得的資料量與保留期間成正比。

檔案系統加密：LUKS（Linux）或 FileVault（macOS）對整個磁碟加密。Server 關機後磁碟資料無法被讀取。

access log 監控：記錄所有對事件儲存的存取操作（Collector Access Control）。異常存取（非工作時間、非預期的 IP）觸發告警。

威脅場景三：Endpoint 濫用

攻擊方式

攻擊者取得 SDK 的 API key（從 client 端的程式碼或設定檔中提取），大量寫入垃圾事件或惡意 payload。

影響

資料汙染：合法事件和垃圾事件混在一起，分析結果不可靠。

資源耗盡：大量寫入消耗 collector 的儲存和處理能力。

注入攻擊：如果 collector 的查詢介面沒有做好輸入驗證，惡意 payload 中的特殊字元可能觸發 injection。

防護

Rate limit：每個 API key 的寫入速率限制。正常的 SDK 行為有可預測的寫入頻率（每分鐘 N 個事件），超出正常範圍的寫入被拒絕。

Schema validation：collector 只接受符合定義 schema 的事件。格式異常的 payload 在寫入前被丟棄。

API key 輪替：如果 API key 被洩漏，輪替 key 讓舊 key 失效。SDK 端更新新 key 後恢復正常。

威脅場景四：內部越權存取

攻擊方式

有 collector 讀取權限的人（開發者、維運人員）存取超出自己職責範圍的事件資料。例如開發者查看行為分析資料（只應該看 debug 資料），或前端開發者查看 server-side 的 error 事件。

防護

角色分離：不同用途的資料用不同的存取權限（Collector Access Control）。Debug 資料和行為分析資料分開授權。

去識別化：即使有存取權限，看到的也是去識別化後的資料（去識別化策略）。IP 截斷、user agent 簡化、stack trace 路徑清理 — 降低資料的個人可識別性。

access log 審計：所有讀取操作記錄在 access log 中，定期 review。

下一步路由

• SDK 端的 redaction → SDK Redaction API 設計
• Transport 層保護 → Transport 安全
• Collector 端保護 → Collector Access Control 實作
• 去識別化技術 → 去識別化策略
• Client-side SDK 認證的多層緩解策略 → Client-side SDK 認證

這個限制來自 architecture，和 implementation 無關。混淆 JS、ProGuard 混淆 APK、編譯 Python 成 .pyc，都只增加提取成本，不改變「credential 在 client 端」的事實。

Collector Access Control 討論了 API key 和 mTLS 的認證機制，Transport 安全 討論了傳輸層加密。兩者的前提是 credential 被妥善保管。本章處理的是那個前提不成立時 — credential 已被提取或必然可被提取 — 的緩解策略。

商業方案的處理方式

所有主流的 client-side telemetry 方案都面對同樣的限制。它們的共同策略是：承認 client credential 會暴露，把防線從「保護 credential」轉移到「限制 credential 被濫用的影響」。

Google Analytics 4：Measurement ID（G-XXXXXXXXXX）直接寫在網頁的 JS snippet 中，任何人檢視網頁原始碼都能取得。GA4 的防護在 server-side — Google 用 domain 白名單過濾來源，加上自動的 bot traffic 偵測剔除機器流量。Measurement Protocol（server-to-server）需要額外的 API secret，但 client-side 的 gtag.js 不需要。

Sentry：DSN（Data Source Name）包含 project ID 和 public key，直接嵌在 SDK init 的程式碼中。Sentry 官方文件明確標示 DSN 是 public 的 — 攻擊者取得 DSN 只能送事件，不能讀取已收集的資料。防護靠 rate limit（每個 project 的 events/sec 上限）、allowed domains（只接受來自白名單 domain 的事件）、和 server-side 的 event 去重。

Firebase：整個 google-services.json / GoogleService-Info.plist 的內容 — 包含 apiKey、projectId、appId — 都視為公開資訊。Firebase 的安全模型不依賴這些 key 的保密性；它們的功能是識別（identify）而非授權（authorize）。需要保護的資源靠 Firebase Security Rules 和 App Check（device attestation）處理。

Datadog RUM：Client token 是獨立於 API key 的 credential。API key 可以讀寫所有 Datadog 資料，必須保護在 server-side；client token 只能寫入 RUM 事件，設計上可以暴露在 client 端。Datadog 建議搭配 intake proxy（collector 前面加一層自己的 server），讓 client token 不直接出現在瀏覽器中。

這些方案的共同模式：client-side credential 的角色是「識別來源」而非「授權存取」。即使被提取，攻擊者能做的事被限縮在「寫入事件」— 影響可控。

認證天花板：識別 vs 授權

Collector Access Control 的 API key 同時承擔識別和授權 — 有 key 就能寫入，沒 key 就被拒絕。在 server-side 場景下這沒有問題，因為 key 不會暴露。

Client-side 場景需要拆開這兩個功能：

識別（identification）：這個 request 來自哪個 app、哪個 SDK、哪個部署版本。識別資訊可以公開 — 它的價值是讓 collector 知道事件來自哪裡，用於 access log、per-app rate limit、和事件標記。

授權（authorization）：這個 request 有沒有權限執行寫入操作。授權依賴 credential 的保密性 — 在 client-side 場景下，credential 保密性的天花板很低。

接受這個區分後，client-side SDK 的 API key 更接近「識別 token」。它的洩漏不是安全事件（像 server-side API key 洩漏那樣），而是預期中的狀態。防護的重點從「防止 key 洩漏」轉移到「限制 key 被濫用時的影響」。

多層緩解策略

以下各層按實作成本遞增排列。前面的層在多數場景下足夠，後面的層在 endpoint 暴露在公開網路且面對主動攻擊時才需要。

第一層：寫入限制（collector 已有）

Collector Access Control 的寫入限制 — rate limit、payload size limit、schema validation — 是第一層防護。這些機制不區分「合法 SDK」和「偽造 client」，對所有寫入請求一視同仁地施加約束。

Rate limit 限制每個 API key 的事件速率。Schema validation 拒絕不符合 event.schema.json 結構的 payload。兩者合起來把偽造流量的影響限制在「每秒 N 筆符合 schema 的事件」— 這個量級的資料汙染對 error tracking 的影響有限（error 事件靠 stack trace fingerprint 去重），對 funnel 分析的影響較大（行為事件的計數會被灌水）。

第二層：Origin 驗證

Web SDK 的 HTTP request 帶有瀏覽器自動附加的 Origin header。Collector 可以檢查 Origin 是否在白名單中。

 1func originCheck(next http.Handler, allowed []string) http.Handler {
 2    allowedSet := make(map[string]bool)
 3    for _, o := range allowed {
 4        allowedSet[o] = true
 5    }
 6    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 7        origin := r.Header.Get("Origin")
 8        if origin != "" && !allowedSet[origin] {
 9            http.Error(w, "forbidden origin", http.StatusForbidden)
10            return
11        }
12        next.ServeHTTP(w, r)
13    })
14}

Origin 驗證擋住的是「從瀏覽器中跨域呼叫」的場景 — 攻擊者在自己的網站用 JS 向你的 collector 發 request，瀏覽器會帶上攻擊者網站的 Origin，被 collector 拒絕。

天花板：Origin header 只有瀏覽器會自動附加。用 curl、Postman、或任何非瀏覽器 HTTP client 發 request 時，可以自行設定任意 Origin 值。Origin 驗證擋得住瀏覽器中的跨域呼叫，擋不住直接用 HTTP client 偽造的 request。

Mobile SDK（Flutter / native app）的 request 不帶 Origin header。Origin 驗證只對 Web SDK 有效。

第三層：Request signing

SDK 用 HMAC 對每個 request 簽章，collector 驗證簽章有效性。簽章的輸入包含 timestamp 和 payload hash，防止 replay attack 和 payload 竄改。

1X-Signature: a3f8c2e1b7d94f06...  (HMAC-SHA256 結果的 hex 編碼)
2X-Timestamp: 1719216000

SDK 計算方式：HMAC-SHA256(secret, timestamp + "." + SHA256(body))，結果轉 hex 字串放入 X-Signature header。

Collector 端的驗證邏輯：

 1func verifySignature(r *http.Request, secret string) bool {
 2    ts := r.Header.Get("X-Timestamp")
 3    sig := r.Header.Get("X-Signature")
 4
 5    // 拒絕超過 5 分鐘的 request timestamp（防 replay）
 6    // 5 分鐘容忍 client-server 時鐘漂移和網路延遲；行動裝置偏差大的環境可放寬到 10 分鐘
 7    // 此處的 timestamp 是 HTTP request 發出時間，和事件的 timestamp 欄位（事件產生時間）無關
 8    tsInt, err := strconv.ParseInt(ts, 10, 64)
 9    if err != nil || abs(time.Now().Unix()-tsInt) > 300 {
10        return false
11    }
12
13    body, _ := io.ReadAll(r.Body)
14    bodyHash := sha256.Sum256(body)
15    expected := hmac.New(sha256.New, []byte(secret))
16    expected.Write([]byte(ts + "." + hex.EncodeToString(bodyHash[:])))
17
18    sigBytes, err := hex.DecodeString(sig)
19    if err != nil {
20        return false
21    }
22    return hmac.Equal(sigBytes, expected.Sum(nil))
23}

Request signing 增加偽造成本 — 攻擊者需要提取 HMAC secret 並實作簽章邏輯，而非直接複製一個 API key 貼到 curl 指令。

HMAC secret 和 API key 一樣嵌在 client 端程式碼中，反編譯 APK 或閱讀 JS bundle 可以提取。Signing 增加的是攻擊者的工程投入（需要理解簽章算法並正確實作），而非理論上的安全性。對 casual attacker（看到 API key 就想試試的人）有效，對 motivated attacker（願意花時間逆向工程的人）無效。

第四層：行為分析異常偵測

Collector 端統計每個 API key（或 source.app）的事件模式，建立 baseline 後偵測偏離。

正常 SDK 的行為有可預測的特徵：

Collector 可以用 rule engine 偵測異常模式：

• 單一 API key 的事件量在 10 分鐘內超過過去 24 小時平均值的 10 倍
• 連續 N 個 request 的事件全是同一個 type
• source.sdk 欄位的值不在已知的 SDK 版本清單中

偵測到異常後的處理方式是標記而非丟棄 — 在事件中加入 _flags.suspicious = true flag，讓 dashboard 和分析查詢可以過濾。直接丟棄有誤殺正常流量的風險（例如行銷活動導致的真實流量暴增）。

攻擊者如果研究過正常 SDK 的行為模式（事件類型分布、送出間隔、payload 結構），可以模擬出相似的流量。行為分析依賴「偽造流量和正常流量有可偵測的差異」這個前提 — 對低投入的攻擊者成立，對高投入的攻擊者不一定。

第五層：Device attestation

由作業系統或平台層驗證 client 的合法性，提供 SDK 自身無法產生的證明。

Firebase App Check：整合 DeviceCheck（iOS）、Play Integrity（Android）、reCAPTCHA Enterprise（Web），由裝置平台出具 attestation token。Collector 向 Firebase 驗證 token 的有效性。

Apple DeviceCheck / App Attest：iOS 裝置向 Apple server 請求 attestation，證明 request 來自一台真實的、未被篡改的 iOS 裝置上的合法 app。

Google Play Integrity：驗證 request 來自 Google Play 安裝的 app、在未 root 的裝置上、由合法使用者操作。

Device attestation 提供的保證比前四層都強 — 它依賴裝置硬體和平台服務（難以偽造），而非 SDK 嵌入的 secret（可提取）。

天花板：

• 平台綁定 — 每個平台（iOS / Android / Web）需要各自整合不同的 attestation 服務，跨平台 SDK 的實作成本高
• Root / 越獄裝置上 attestation 可能失敗或被繞過
• Web 端的 reCAPTCHA 驗證依賴 Google 服務，有隱私和可用性的考量
• 自架 collector 需要額外整合 Firebase Admin SDK 或各平台的驗證 API

Device attestation 適合商業產品級的 mobile app，對自架監控工具而言實作成本通常超出收益。

自架方案的規模對應

不同部署規模下，需要做到哪一層取決於 endpoint 的暴露程度和偽造流量的影響大小。

Intake proxy 架構：在公開 endpoint 和商業產品場景下，可以在 collector 前面加一層自己的 server（proxy），SDK 送事件到 proxy，proxy 用 server-side API key 轉發到 collector。Client 端的 credential 只指向 proxy，proxy 的 API key 指向 collector — credential 分層，client 端的 key 洩漏不影響 collector 的認證。

1SDK ──(client token)──→ Intake Proxy ──(server API key)──→ Collector

Proxy 的額外成本是多一個 server 和網路跳躍。自用場景下不需要；endpoint 公開時值得考慮。

偽造流量的影響分析

偽造流量進入 collector 後，對不同類型的分析影響不同。

Error tracking 影響較低：error 事件的價值在 stack trace 和 error message。偽造的 error 事件缺少真實的 stack trace — 即使格式正確，內容是編造的。Error 去重靠 fingerprint（error type + message + stack trace top frame），偽造事件產生的 fingerprint 不會和真實 error 碰撞，在 dashboard 上是獨立的 error group，容易識別和過濾。

行為分析影響較高：funnel 和 cohort 分析依賴事件計數的準確性。偽造的 page.view 和 button.click 事件直接灌水計數，導致轉換率失真。偽造事件越接近真實事件的結構（正確的 event name、合理的 timestamp），影響越大。

資源消耗是固定成本：無論事件內容是否真實，每筆事件都消耗 collector 的寫入 I/O、儲存空間、和查詢時間。Rate limit 把這個成本限制在可控範圍 — 每秒 N 筆是上限，無論來源是否合法。

事後標記策略

偵測到可疑流量後，collector 在事件中加入標記欄位而非直接丟棄。丟棄有誤殺風險 — 行銷活動的流量暴增、SDK 版本升級改變了事件模式、新平台的 SDK 上線 — 這些正常場景可能觸發異常偵測。

標記方式是在 collector 寫入時，對符合異常條件的事件附加 metadata：

1{
2  "v": 1,
3  "type": "event",
4  "name": "button.click",
5  "source": { "sdk": "js", "platform": "web", "app": "main-site" },
6  "_flags": { "suspicious": true, "reason": "rate_anomaly" }
7}

Dashboard 查詢預設排除 _flags.suspicious = true 的事件。需要調查時可以包含 — 看可疑事件的模式有助於判斷是攻擊還是誤判。

下一步路由

• Collector 端的認證和授權機制 → Collector Access Control 實作
• Transport 層的加密保護 → Transport 安全
• Endpoint 濫用的威脅分析 → 監控資料洩漏的 Threat Model
• SDK 端的寫入速率控制 → Ingestion Scaling
• 行為分析和 rule engine → Rule Engine 設計
• 偽造流量對資料完整性的影響 → 端到端資料完整性
• Error fingerprint 讓偽造 error 容易辨識 → Error Fingerprint 與去重分群