三種「不出境」

這個詞在不同人口中意思不同，而認知落差會在專案後期爆炸。三種定義：

定義一：物理邊界。 資料不離開機構自有的機房。

定義二：主權邊界。 資料不離開本國領土，但可以在境內的雲端資料中心。

定義三：控制邊界。 資料可以在雲端、甚至境外，但必須在機構可控制、可稽核、可撤銷的範圍內。

這三個定義必須在架構定案前確認。 我看過專案做到一半才發現法遵要的是定義一，而架構是照定義三設計的——那等於重做。

定義三的技術實現

如果採用控制邊界的定義，Google Cloud 的組合是：

VPC Service Controls：建立資料邊界。

gcloud access-context-manager perimeters create legal_pii_perimeter \
  --title="Legal PII Perimeter" \
  --resources=projects/PROJECT_NUMBER \
  --restricted-services=\
storage.googleapis.com,\
dlp.googleapis.com,\
cloudkms.googleapis.com,\
documentai.googleapis.com,\
aiplatform.googleapis.com \
  --policy=POLICY_ID

效果是：即使有人拿到了憑證，也無法把資料從邊界內複製到邊界外的專案。這防的是憑證外洩後的資料外流，是一道非常有價值的防線。

組織政策：限制資源位置。

constraint: constraints/gcp.resourceLocations
listPolicy:
  allowedValues:
    - in:asia-east1-locations
    - in:asia-northeast1-locations

這會讓任何試圖在允許區域外建立資源的操作直接失敗。

CMEK：金鑰控制權。

所有儲存資源使用客戶管理的金鑰。這帶來一個重要性質：銷毀金鑰即銷毀資料的可讀性，即使資料本身還在雲端服務商的儲存體裡。

這是「控制邊界」這個概念的核心——你可能不擁有硬體，但你擁有讓資料無法被讀取的能力。

Access Transparency 與 Access Approval：對服務商存取的控制。

前者記錄雲端服務商員工對你的資料的存取，後者要求這類存取需要你明確核准。

在金融業的委外監督要求下，這兩項的價值很高——它讓「我們對委外機構有監督能力」這句話有具體支撐。

這個架構裡實際的邊界圖

┌─────────────────────── 行內機房 ──────────────────────┐
│                                                        │
│  文件管理系統 ──→ 格式解析 ──→ 偵測（規則+語意）        │
│                                      ↓                 │
│                              去識別化引擎               │
│                                   ↓    ↘               │
│                            去識別化文字   Token Vault   │
│                                   ↓                    │
└───────────────────────────────────┼────────────────────┘
                                    ↓
┌────────────── VPC Service Controls 邊界 ───────────────┐
│                                    ↓                   │
│                            Model Armor                 │
│                                    ↓                   │
│                          Vertex AI / LLM               │
│                                    ↓                   │
│                            Model Armor                 │
└───────────────────────────────────┼────────────────────┘
                                    ↓
┌─────────────────────── 行內機房 ──────────────────────┐
│                          還原服務（授權後）             │
│                                    ↓                   │
│                              使用者                     │
└────────────────────────────────────────────────────────┘

三個重點：

一、Vault 完全在行內。 這是不能妥協的一點。

二、跨越邊界的只有去識別化文字。 沒有原文、沒有原始檔案、沒有 Vault 資料。

三、還原在行內。 明文只在行內產生。

OCR 那條線怎麼畫

D15 留下的問題：OCR 如果用雲端，原始圖檔會出行。

在上面這張圖裡，OCR 屬於「格式解析」，被放在行內。這是我建議的預設。

如果因為辨識品質必須用雲端 Document AI，那圖要改成：

┌────────── 行內 ──────────┐
│  文件管理系統             │
│       ↓                   │
│  格式判斷 ── 原生 → 行內抽取
│       ↓ 掃描件            │
└───────┼───────────────────┘
        ↓ 【原始圖檔出行】
┌────── VPC-SC 邊界 ───────┐
│  Document AI              │
└───────┼───────────────────┘
        ↓ 文字
┌────── 行內 ──────────────┐
│  偵測 → 去識別化 → ...    │
└───────────────────────────┘

把這條線畫出來、標註「原始圖檔出行」，讓治理層看到並做決定。不要把它藏在「格式解析」這個方塊裡。

D15 的建議仍然成立：證件影本一律地端，不論邊界怎麼定義。

混合部署的實際考量

如果採用 D13 的分級路由（高敏感走地端、一般走雲端），會有幾個實務問題：

一、兩套管線的一致性。 地端和雲端的偵測規則必須同步，否則同一份文件走不同路徑會得到不同結果。建議把規則定義成單一來源（一份 YAML），兩邊都從它產生設定。

二、Token 空間要統一。 如果同一個案件的文件分別走了兩條路徑，Token 必須一致（D16）。所以 Token 產生邏輯必須是共用的，而且 HMAC 金鑰要同一把。

三、分類器本身的風險。 決定文件走哪條路的分類器，如果判斷錯誤，高敏感文件就走上雲端路徑了。

這個分類器應該 fail-closed：判斷不確定時，一律走地端。 代價是地端負載增加，這是應該接受的代價。

def route_document(doc):
    score = sensitivity_classifier(doc)
    if score is None or score > THRESHOLD:
        return "on_premise"      # 不確定或高敏感 → 地端
    if has_sensitive_doc_type(doc):
        return "on_premise"      # 證件影本等 → 一律地端
    return "cloud"

四、地端的能力上限。 地端 LLM 的能力通常不如雲端旗艦模型。所以要誠實地告訴使用者：「高敏感文件的分析品質會較低，這是為了保護資料所做的取捨。」

不要假裝兩條路徑品質一樣，那會讓使用者想辦法把文件塞進雲端路徑。

邊界之外的殘餘風險

即使做完以上所有事，仍然有殘餘風險：

• 去識別化資料本身的結構洩漏（D17）
• 雲端服務商的內部存取（用 Access Approval 控制但無法完全消除）
• 模型服務的留存期
• 你的偵測漏掉的部分（永遠存在）

這些應該被寫進風險評估文件並且被接受，而不是假裝不存在。 一份誠實列出殘餘風險的架構文件，比一份聲稱零風險的文件更能通過稽核。

明天收尾。

關於作者

我是 Fngi，專注在 AI 資安、LLM 紅隊與 AI 治理框架落地。
IG：@aid3fend

有想討論的架構細節或不同意見，留言或私訊都歡迎。