Cloud DLP 簡介
在資料驅動的世界中，了解敏感資料的所在地是保護資料的第一步。Cloud Data Loss Prevention (DLP) 是一項完全託管的服務，旨在協助您在 Google Cloud 生態系統及其他環境中發現、分類與保護敏感資料。
對於 PSE 考試，您必須了解如何設定檢查工作、利用範本實現可擴展性，並解讀風險分析指標，以確保符合 GDPR、HIPAA 和 PCI DSS 等法規要求。
白話文解釋
Cloud DLP 之所以讓人覺得抽象，是因為它把偵測、分類與統計風險分析三件事打包成一個產品。下面三個比喻把每個概念對應到具體事物，讓 PSE 等級的設計抉擇變得明確。
比喻一：機場安檢 X 光機（InfoType 偵測器）
內建 InfoTypes 就像機場安檢的 X 光機 —— 它已經被預先訓練去辨識已知形狀：筆電、液體、刀具。CREDIT_CARD_NUMBER 與 US_SOCIAL_SECURITY_NUMBER 等同於機器已熟知的「金屬物件」剪影。自訂 InfoTypes（regex 與字典） 則是某個機場額外加上的補充規則，例如「禁止攜帶該國貨幣超過 X 元」 —— 是疊加在全球規則之上的窄域規則。Hotwords（熱詞） 則是站在旁邊讀行李吊牌的工作人員：即使 X 光影像模糊，吊牌寫著「MEDICAL EQUIPMENT」就能提高對內容物的信心。
比喻二：圖書館編目專案（檢查範本）
想像你要替分佈在 50 個分館的 10,000 本書編目。你不會希望每個館員自己發明分類規則。檢查範本（Inspection Template） 就是共用的編目手冊 —— 由一個團隊撰寫，每個分館（也就是每個跑在 BigQuery 資料集或 GCS 儲存桶上的 job）都引用同一本手冊。當你更新「什麼算稀有書」的規則（例如把最小可能性提高到 VERY_LIKELY），之後所有的盤點都會自動套用新規則。De-identification template（去識別化範本） 則是館員在公開目錄發布前蓋在書籍紀錄上的塗銷章。
比喻三：人口普查匿名化辦公室（風險分析）
普查資料收齊後，統計處想公開彙整結果，但不能曝露任何個人。k-anonymity 是「公開的每一列，在準識別碼上必須與至少 k-1 列長得一模一樣」 —— 確保沒有任何家戶是它的郵遞區號+年齡+所得這個分桶裡唯一的存在。l-diversity 再加一條：「同一個分桶內的敏感欄位必須有至少 l 個不同值」 —— 即使攻擊者把你壓縮到一群人，仍無法鎖定診斷結果。δ-presence 則回答「這個人到底有沒有出現在資料集裡？」 —— 當「被納入」本身就是敏感資訊時特別重要（例如愛滋門診的訪客名單）。
理解 InfoTypes
Cloud DLP 的核心是 InfoTypes。InfoType 是一種敏感資料類型，例如信用卡號碼、電子郵件地址或政府核發的身分證字號。
InfoTypes 的類型：
- 內建 InfoTypes： Google 提供超過 150 種預定義的偵測器，用於全球 PII、PHI 和財務資料（例如
CREDIT_CARD_NUMBER、US_SOCIAL_SECURITY_NUMBER）。 - 自訂 InfoTypes： 由您建立的專屬偵測器。
- 規則運算式 (Regex)： 用於員工編號或內部專案代碼等特定格式。
- 字典 (Dictionaries)： 要搜尋的特定單字或片語列表。
- 代理詞 InfoTypes (Surrogate Term InfoTypes)： 用於識別先前去識別化步驟產生的權杖 (Tokens) 或預留位置。
InfoType 是 Cloud DLP 訓練後可識別的一種敏感資料類別，它結合了模式匹配 (Pattern Matching) 與機器學習等多種偵測技術。
熱詞規則與可能性調整
原始的 regex 或內建偵測器常常產生大量誤判，因為數字與字串脫離脈絡後往往是模稜兩可的。熱詞規則 (Hotword Rules) 讓你在「設定的字串出現在比對位置的鄰近視窗內」時，把該筆 finding 的 likelihood 提高（或降低）。
熱詞規則的組成
熱詞規則存在於附掛到某個 InfoType 的 inspectionRuleSet 內，包含：
hotwordRegex—— 觸發字串，例如(?i)(employee\s*id|emp\s*#)proximity——windowBefore與windowAfter，以字元為單位（常見 30–50）likelihoodAdjustment—— 可用fixedLikelihood: VERY_LIKELY或relativeLikelihood: +2
範例：收緊 US_SOCIAL_SECURITY_NUMBER
{
"inspectionRuleSet": [{
"infoTypes": [{"name": "US_SOCIAL_SECURITY_NUMBER"}],
"rules": [{
"hotwordRule": {
"hotwordRegex": {"pattern": "(?i)(ssn|social\\s*security)"},
"proximity": {"windowBefore": 50},
"likelihoodAdjustment": {"fixedLikelihood": "VERY_LIKELY"}
}
}]
}]
}
少了熱詞，一個 9 位數的發票編號可能只觸發 POSSIBLE。加上規則後，只有「前 50 字元內出現 SSN:」的數字才會被升級為 VERY_LIKELY，其餘可以靠 likelihood 門檻過濾掉。
熱詞改變的是 likelihood，而不是 regex 本身 —— DLP 仍必須先比對到底層的 InfoType 模式。如果你的自訂 regex 從頭到尾都沒命中，再多熱詞規則也救不了。在疊熱詞之前，務必先用 dlp.content.inspect 對樣本資料驗證基礎偵測器是否正確觸發。
排除規則：抑制誤判
熱詞的鏡像對照組是排除規則 (Exclusion Rules)，它會把符合特定噪訊模式的 findings 直接移除，即使 InfoType 已經命中也一樣。在掃描測試資料、fixture 檔案或 placeholder 看起來很像真資料的環境時，排除規則是必備工具。
常見的排除模式
dictionary—— 把出現在清單裡的 finding 移除（例如[email protected]、[email protected]）。regex—— 把符合 regex 的 finding 移除（例如測試用電話555-01\d{2}）。excludeInfoTypes—— 當 finding 同時命中另一個 InfoType 時丟棄（例如PERSON_NAME與US_HEALTHCARE_NPI重疊時抑制PERSON_NAME）。matchingType——MATCHING_TYPE_FULL_MATCH、MATCHING_TYPE_PARTIAL_MATCH或MATCHING_TYPE_INVERSE_MATCH。
{
"exclusionRule": {
"dictionary": {"wordList": {"words": ["[email protected]", "[email protected]"]}},
"matchingType": "MATCHING_TYPE_FULL_MATCH"
}
}
PSE 考試常見陷阱：應試者誤以為提高最小 likelihood 等同於排除規則。並非如此。Likelihood 門檻是全域性地丟掉「所有」低信心 findings —— 包括真實 PII。排除規則則是外科手術式地移除一群已知誤判，同時保留低門檻以便抓到真正的命中。優先用排除規則；只在粗略最後手段時才動 likelihood。
BigQuery 與 Cloud Storage 的掃描工作
檢查工作（dlp.dlpJobs.create 配上 inspectJob payload）負責處理靜態資料的重活。PSE 情境裡最常出現的兩個儲存標的是 BigQuery 與 Cloud Storage。
BigQuery storage config
tableReference——{projectId, datasetId, tableId}指定標的。rowsLimit/rowsLimitPercent—— 針對巨大資料表抽樣，控制成本。sampleMethod——TOP（取前 N 列）或RANDOM_START（統計上具代表性）。identifyingFields—— DLP 會把這些欄位回傳到 finding，讓你可以追到來源列（補救流程的關鍵）。- Findings sink：把
actions.saveFindings.outputConfig.table設成另一個 BigQuery 資料表，之後就能用 SQL 直接查 findings。
Cloud Storage storage config
fileSet.url——gs://bucket/prefix/*的 glob，會自動遞迴。bytesLimitPerFile/bytesLimitPerFilePercent—— 對每個物件設掃描量上限。fileTypes—— 限制為[CSV, TEXT_FILE, IMAGE, PDF, AVRO, WORD_DOCUMENT, EXCEL_DOCUMENT, ...]。sampleMethod——TOP從檔頭開始讀；RANDOM_START跳到隨機偏移再讀。
gcloud dlp jobs create inspect \
--inspect-template-name="projects/$PROJECT/locations/global/inspectTemplates/pii-baseline" \
--bigquery-table="$PROJECT.analytics.events" \
--action-save-findings-table="$PROJECT.dlp_findings.events_pii"
PSE 考試請牢記掃描工作的三大支柱：(1) storageConfig（掃哪裡 —— BigQuery / GCS / Datastore / hybrid）、(2) inspectConfig 或 inspectTemplateName（掃什麼 —— InfoTypes、rule sets、min likelihood）、(3) actions（findings 怎麼處理 —— saveFindings 寫進 BigQuery、pubSub 發告警、publishSummaryToCscc 送到 Security Command Center、publishFindingsToCloudDataCatalog 打標）。所有 DLP 架構題都可以對應到這三個支柱之一。
用 Cloud Functions 與 Eventarc 做事件式抽樣檢查
針對事件驅動的掃描 ——「進到 landing bucket 的每個檔案都得先掃過，才能流入 curated bucket」—— 用 Cloud Functions（或 Cloud Run）搭配 DLP API。
架構模式
- Eventarc trigger 監聽
google.cloud.storage.object.v1.finalized，每當 GCS 有新物件就觸發。 - Cloud Function 下載（或串流）物件，對小於約 0.5 MB 的檔案直接以 inline bytes 呼叫
dlp.projects.content.inspect；較大檔案則改用非同步的dlp.dlpJobs.create。 - Findings 由 function 分流：乾淨檔案複製到 curated bucket；含有
LIKELY以上 finding 的檔案移到 quarantine bucket，並透過 Pub/Sub 通知資安團隊。
Python 範例片段
from google.cloud import dlp_v2
def scan_object(event, context):
client = dlp_v2.DlpServiceClient()
parent = f"projects/{PROJECT}/locations/global"
item = {"byte_item": {"type_": "TEXT_UTF8", "data": fetch_bytes(event)}}
response = client.inspect_content(
request={
"parent": parent,
"inspect_template_name": INSPECT_TEMPLATE,
"item": item,
}
)
if any(f.likelihood >= dlp_v2.Likelihood.LIKELY for f in response.result.findings):
quarantine(event)
配額與成本考量
content.inspect是依掃描的 MB 數計費；呼叫前先檢查物件大小。- 對大於 0.5 MB 同步上限的檔案，改用
inspect_gcs_file走DlpJob，讓 function 立即回傳，再從 Pub/Sub 的JOB_COMPLETED通知回收結果。 - 當資料落地有合規要求時，使用區域端點（
us-east1、europe-west1等）——parent變成projects/$P/locations/europe-west1。
檢查工作與範圍
Cloud DLP 可以使用檢查工作 (Inspection Jobs) 掃描各個位置的資料：
- Cloud Storage (GCS)： 掃描檔案（CSV、JSON、PDF、圖片）。
- BigQuery： 掃描資料表與資料行。
- Datastore： 掃描實體 (Entities)。
- 混合環境： 透過 DLP API，您可以從地端資料庫或其他雲端供應商發送酬載 (Payloads) 至服務進行掃描。
可能性分數與信心水準
DLP 不僅僅是給出「符合」或「不符合」；它會提供一個可能性 (Likelihood) 分數：
VERY_UNLIKELY(極不可能)UNLIKELY(不太可能)POSSIBLE(可能)LIKELY(很可能)VERY_LIKELY(極其可能)
在設定檢查工作時，您可以設定最小可能性門檻以減少雜訊。例如，僅報告評定為 LIKELY 或 VERY_LIKELY 的符合項。
為規模化設計檢查範本
為數百個儲存桶或資料表個別管理工作是非常低效的。檢查範本 (Inspection Templates) 允許您定義一次配置，並在多個工作中重複使用。
- 一致性： 確保整個組織應用相同的 InfoTypes 與可能性級別。
- 易於更新： 更改範本會自動影響後續所有引用該範本的工作。
- 職責分離： 安全管理員可以建立範本，而資料工程師則使用該範本觸發工作，而無需了解具體的偵測邏輯。
混合檢查與串流資料
對於不儲存在 Google Cloud 託管空間中的資料，您可以使用 DLP API 進行：
- 內容檢查 (Content Inspection)： 發送一小段文字或圖片進行即時分析。
- 混合工作 (Hybrid Jobs)： 掃描地端的大型資料集，僅將中繼資料/發現結果發送至 Google Cloud 控制台進行集中報告。
風險分析：超越單純的偵測
風險分析可協助您了解資料集的隱私風險，即使該資料集已進行部分去識別化。
- k-anonymity (k-匿名性)： 透過將某人與資料集中至少其他 k 個人進行比較，衡量其被重新識別的風險。
- l-diversity (l-多樣性)： 確保在每個「準識別碼 (Quasi-identifier)」群組中，敏感屬性至少具有 l 個不同的值，以防止「同質性攻擊」。
- δ-presence (Delta-presence)： 估計特定個人屬於該資料集的機率。
風險分析對於開放資料 (Open Data) 計畫至關重要。它能協助您判斷「經過清洗」的資料集是否真正可以安全發布。
管理工作觸發器與排程
您可以使用工作觸發器 (Job Triggers) 自動執行發現工作：
- 排程 (Schedules)： 每天或每週執行一次掃描，以捕捉新的敏感資料。
- 事件驅動 (Event-based)： 當新檔案上傳到特定 GCS 儲存桶時觸發掃描（結合 Cloud Functions 或 EventArc）。
與 Security Command Center (SCC) 整合
DLP 的發現結果可以直接發送至 Security Command Center：
- 提供安全狀態的「單一入口網站 (Single pane of glass)」。
- 實現自動化告警與修補（例如，如果 DLP 發現一個含有 PII 的公開儲存桶，SCC 可以觸發封鎖動作）。
PSE 考試情境
情境 1：減少誤判
「一名安全工程師正在掃描 BigQuery 資料表中的客戶 ID。內建偵測器標記了太多無關的數字。工程師應該如何提高準確性？」
解答： 1. 將最小可能性門檻提高至 VERY_LIKELY。 2. 使用熱詞 (Hotwords)（出現在數字附近的上下文線索，如 'ID' 或 'Account'）來增加信心分數。 3. 使用更具體的 Regex 建立自訂 InfoType。
情境 2：地端資料的合規性
「一家公司需要識別地端 SQL 資料庫中的 PII，但希望使用 Google Cloud DLP 進行分類。最佳做法是什麼？」 解答： 在混合工作 (Hybrid Job) 配置中使用 DLP API。地端代理程式掃描資料，僅將發現結果（或一小段內容）發送給 Cloud DLP 進行分類。
總結檢查表
- 定義內建與自訂 InfoTypes 之間的差異。
- 解釋可能性的五個級別。
- 描述使用檢查範本的好處。
- 在風險分析中對比 k-anonymity 與 l-diversity。
- 識別 DLP 可以原生執行檢查工作的服務。
- 列出自動觸發 DLP 工作的方法。