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 redaction API 設計（預設 redaction rule + 自訂 pattern）
• Transport 安全（HTTPS / basic auth / 同區網也要加密的理由）
• Collector access control 實作（認證 / 授權 / access log）
• 去識別化策略（IP 截斷 / user agent 簡化 / stack trace 路徑清理 / session UUID）
• GDPR 最小化原則的工程落地
• 「監控資料洩漏」的 threat model
• Client-side SDK 認證的根本限制（credential 必然暴露、多層緩解策略）

跨分類引用

• → backend 07 資安：server-side 的 secret management 跟本模組的 redaction 互補
• ← ux-design 模組三 輸入機制：IME 個人化學習 = secret 洩漏
• ← testing 模組二 客戶端可觀測性：log 內容可能含 secret，需要 redaction
• → monitoring 模組八：去識別化是商業利用的入場條件
• 待建連結 → compliance/（隱私法規教學分類）

本文是 PostgreSQL overview 的 implementation-layer deep article。同時是 #128 self-aware limitation 第 1 點「6 維仍可能漏類（identity / consistency / residency 三軸候選）」的 residency 軸驗證、跟 migration playbook methodology「何時不該套」段 對「政策合規驅動」是否在 methodology scope 的反思。

政策驅動的 migration 屬本 methodology 嗎

Migration playbook methodology 「何時不該套」段曾把「compliance-driven migration」歸為排除情境、後來改寫為「不在排除範圍 — 法規驅動只是 driver、資料層仍走 type A-E 之一」。本文是該改寫的 正面實證 — GDPR EU residency 強制需求驅動 single-region → multi-region rollout、本文是 政策驅動但仍走 audit + type 對映流程 的 case study。

但 reviewer D 在第三輪 audit 提出：residency 不只是 driver、本身是 cross-cutting constraint、反向約束 topology + operational + schema；該不該升 獨立 audit 軸？本文是該議題的 dogfood。

三層約束：driver / topology / contract

GDPR 對 PostgreSQL multi-region rollout 的影響在三個層次：

1. Driver layer：EU 客戶資料必須 物理上儲存在 EU（GDPR Article 44-49）— 觸發 multi-region migration 的根本理由
2. Topology layer：跨 region replication 不能 自由跨 region 複製 EU 客戶資料、必須按 GDPR scope 分區；topology 設計受合規約束
3. Contract layer：審計能 demonstrate 「EU 資料在 EU」、操作日誌 + replication evidence 必須可追溯；application + ops contract 多出合規 obligation

跑 6 維 diff dimension audit 對「single us-east → us-east + eu-west」：

6 維 audit 抓不到「Residency contract = High」這軸。用既有 6 維歸類、會走 Type F multi-axis（topology + operational + application change 多 High）+ 政策合規補強段；但這個歸類 漏掉合規對 topology / operational / application 的反向約束：

• Topology layer：6 維只 audit 「topology 是否變動」、漏 audit 「topology 範圍是否受合規約束」
• Operational layer：6 維只 audit 「operational 是否重設計」、漏 audit 「audit log / encryption / access control 是否符合合規要求」
• Application layer：6 維只 audit 「application code 是否改」、漏 audit 「資料 routing 是否符合 residency rule」

Residency 不只是 driver、是 cross-cutting constraint、會反向約束其他 3-4 維、且帶獨立工作量（合規 evidence collection / DPIA / audit prep）。

Residency axis 是否獨立：3 個論據

Yes、residency 是獨立軸：

1. 可獨立發生：原本 multi-region setup、新增「PCI 強制信用卡資料只能 us-east」、是 純 residency 變更、其他 6 維皆 Low（topology 不重設計、operational 不重設計、application 加 routing rule 即可）；但 residency 約束 routing + log 範圍
2. 驅動工作量分佈：本文 multi-region GDPR rollout 工作量分佈：
   • Topology setup（logical replication / region setup）：~25%
   • Operational redesign（HA / backup / monitoring）：~20%
   • Application routing change（region detection / data filter）：~15%
   • Residency compliance（DPIA / audit log / access control / encryption / evidence）：~40%
3. Cross-cutting nature：residency 不只影響「資料放哪」、影響：
   • Backup 可不可以 cross-region store（多數 GDPR 不允許）
   • Audit log 是否包含 EU PII（需 EU 端 log + 跨 region log filter）
   • Encryption key 是否可 cross-region share（多數情境不允許）
   • Application access logs 是否含 EU IP / user ID

No、residency 可塞 operational + driver：

• 反論：residency 是 operational 子議題、加 audit + replication scope 規則就好
• 拒絕：residency 反向約束 topology / application / operational、且帶獨立合規工作量（DPIA / cross-border transfer agreement / data subject rights）；不是單純 operational 子議題

實證：本文 migration 工作量 40% 在 compliance、確認 residency 是 獨立工作量主軸。

結構：Type F multi-axis + residency compliance 獨立段

本文結構是 Type F 為主（topology high + operational high）+ residency compliance 獨立段（不在 6 維任一個）：

11. 政策驅動的 migration 屬本 methodology 嗎（meta-reflection 開頭）
22. 三層約束：driver / topology / contract
33. Residency axis 是否獨立的論據
44. 結構 differentiator（Type F multi-axis + residency compliance 段）
55. EU residency 對 topology / operational / application 的反向約束
66. Migration 流程（含 DPIA 跟 evidence collection 階段）
77. Production 故障演練
88. Capacity / cost（含合規 audit cost）
99. 整合 / 下一步

9 章節、240-270 行。比標準 Type F 多 1 段（residency compliance）+ 1 段（meta-reflection）。

EU residency 對其他維度的反向約束

 1Residency rule → Topology constraint:
 2- EU customer data 不能 replicate to us-east
 3- Backup of EU table 不能 store in non-EU region
 4- Logical replication subscriber 在 us-east 必須 filter out EU data
 5
 6Residency rule → Operational constraint:
 7- Cross-region monitoring 不能 export EU PII to global SaaS (Datadog)
 8- Audit log 含 EU user_id 必須 store 在 EU
 9- Encryption key (KMS) 不能 share 跨 region（EU 端用 EU KMS）
10- DBA / SRE access EU data 必須 from EU jurisdiction + 記 audit trail
11
12Residency rule → Application constraint:
13- Application 必須 detect user region + route 對應 DB endpoint
14- Cross-region join / aggregate 對 EU user 必須走 EU 端 query
15- Data export feature 必須 reject 跨 region export request

每條反向約束都是 新工作量、不在 6 維 audit 內。

Migration 流程（含 DPIA + evidence collection）

10 step、跨 5 個月：

Step 1 + 9 + 10 是 residency-specific、不在既有 6 維內。

Production 故障演練

Case 1：Replication filter 漏 table、EU 資料 leak 到 us-east

徵兆：6 個月後 internal audit 發現 us-east 端 customers table 含 EU 客戶資料；replication filter 設定漏改、新加的 eu_customer_extensions table 被自動 replicate 到 us-east。

根因：PostgreSQL logical replication publication 預設 FOR ALL TABLES、新加的 table 自動納入；應該明示 FOR TABLE list... 並 GDPR review。

修法：

1. Publication 改 explicit table list：CREATE PUBLICATION xxx FOR TABLE users, orders, ...、不用 FOR ALL TABLES
2. Schema change review 加 GDPR check：每個 DDL PR 必須答「新 table 是否含 EU PII、是否該 filter」
3. Replication monitor：定期跑 SELECT * FROM pg_publication_tables 對照 expected list、漂移立刻 alert
4. Evidence collection：filter 配置 + audit log 留檔、出事 DPO 知道何時 leak

Case 2：Backup 跨 region store、合規違規

徵兆：跑 1 年後 GDPR audit 抓到 EU table 的 backup 存在 us-west S3 bucket；違反 Article 44-49 限制。

根因：pgBackRest 預設用 global S3 bucket（在 us-east-1）；EU PostgreSQL cluster backup 跑去 us-east、跨境傳輸無 transfer mechanism。

修法：

1. Per-region backup config：EU cluster 用 EU S3 bucket（eu-west-1）、寫進 pgBackRest config
2. Backup test：每月跑一次 backup restore drill、validate backup 是 from EU region
3. Bucket policy 強 enforce：EU bucket 加 aws:RequestedRegion=eu-west-1 強制 region match
4. Audit log archive 同理：log shipping 也必須 region-respect

Case 3：Monitor SaaS 收集 EU PII、合規 alert

徵兆：Datadog APM 收集了 EU customer 端 request 含 user_email 在 trace、被 DPO catch、required to delete 過去 90 天的 Datadog data。

根因：APM trace 預設收集 application context、含 PII；Datadog 是 us-east SaaS、PII 跨境到 Datadog us-east、違規。

修法：

1. APM scrub PII：application 端在 trace 前 scrub user_email / user_id 替換成 hash
2. EU-specific monitor stack：EU PostgreSQL + APM 用 Grafana on EU EKS、不送 Datadog
3. 跨 region SaaS use 必須 audit：所有外部 SaaS（Datadog / Sentry / NewRelic）必須 GDPR-friendly 配置
4. Privacy by design：log / trace 預設 scrub PII、不是 opt-in

Case 4：Cross-region query 跑 EU + US 資料、residency 違規

徵兆：BI dashboard 跑跨 region aggregation query（EU sales + US sales）、PostgreSQL FDW 從 us-east cluster query EU cluster、EU 端 server log 顯示「PII export to us-east」。

根因：開發者用 PostgreSQL Foreign Data Wrapper（FDW）方便跑跨 region query、不知道這在 GDPR 視為跨境 PII export。

修法：

1. Architecture: aggregate at edge：BI 跑 per-region aggregate、再在 BI layer compose（無 PII）；不直接跨 region join
2. FDW 限制：disable FDW from us-east → EU cluster、enforce one-way data flow
3. DBA access policy：DBA 不能直接 query EU cluster 從 us-east jumpbox
4. Query audit：production query log 跑 PII detection（regex / NER）、發現跨境 export 立即 alert

Case 5：DR drill 跨 region failover、暴露 residency assumption 失敗

徵兆：DR drill「EU 完全不可用、切到 us-east」執行後、發現 us-east 端 沒 EU 資料 — 因為一直 strict residency filter；business 端 EU 客戶 24 小時無法服務。

根因：strict GDPR residency 跟 strict DR availability 衝突 — 要 跨 region DR 就要 跨 region 持有資料、要 strict residency 就 DR 範圍受限。

修法：

1. DR strategy revision：EU 端 multi-AZ within EU、不靠跨 region；EU region 全不可用情境接受 longer RTO
2. Compliance + DR negotiation：跟 DPO / 法務談 DR 跨境 short-window 是否可接受、簽 cross-border transfer agreement
3. Backup recovery 在 EU 內：EU 端 backup 跨 AZ store、不跨 region；EU AZ 災難用 EU 另一個 AZ 重建
4. 明示 RTO trade-off：EU customer SLA 寫「regional DR 內 RTO 1 小時、global DR 24-48 小時」、residency 跟 DR 是 互斥取捨

Capacity / cost

判讀：GDPR multi-region 成本 1.5-2.5x、但合規是 必要 spend、用 cost optimization 的框架看會誤判；多數歐洲業務 7+ 年回本（避免 4% revenue fine）。

整合 / 下一步

跟 PostgreSQL → Aurora 對位

Aurora Global Database 可簡化跨 region setup、但 residency filter 仍需 application 端；不是「Aurora 就解決 GDPR」。

跟 Multi-DC MongoDB 對位

兩篇都是 multi-region rollout、但本文加合規維度；MongoDB 篇純 capacity + DR driver、本文加 residency constraint、結構不同。

跟 #128 self-aware limitation 第 1 點對位

本文驗證 residency axis 候選：

• Yes 軸獨立：reverse-constrain topology + operational + application、且帶獨立 compliance 工作量（DPIA / evidence collection / DPO sign-off）
• 作為 driver 不夠：methodology 把 residency 歸為 driver 太窄、忽略 cross-cutting constraint 性質

未來 audit 可能擴 7 維（加 residency / compliance contract）；累積 PCI / HIPAA / SOX 等不同合規 case 後再評估。

下一步議題

• Identity + Consistency + Residency 三軸候選統合：本批 3 篇分別驗證、未來累積 evidence 後考慮獨立 #129 卡 / 擴 audit 到 7-8 維
• Schrems II + new EU data transfer rules：跨大西洋資料傳輸法規變動快、playbook 半衰期短
• Data localization in China / Russia / India：類似 GDPR 但細節不同、未來 case 累積後評估

相關連結

• 上游 vendor 頁：PostgreSQL
• 平行 multi-region case：MongoDB Shard + Multi-DC
• 平行 axis 候選驗證：Vault → AWS Secrets Manager（identity 候選）/ DynamoDB Consistency Model（consistency 候選）
• Methodology：Migration playbook methodology / #128 self-aware limitation 第 1 點（residency axis 候選驗證、本文是該驗證的 dogfood）