bucket 的四道安全防線

一個 S3 bucket 在 IaC 裡至少要描述四個獨立資源，各自對應一道防線。Terraform 把它們拆成獨立資源是設計選擇 — 每道防線可以單獨 review、單獨調整、單獨追蹤變更歷史。

 1resource "aws_s3_bucket" "assets" {
 2  bucket = "acme-${var.env}-assets"
 3
 4  tags = { service = "cdn-origin", env = var.env }
 5}
 6
 7resource "aws_s3_bucket_versioning" "assets" {
 8  bucket = aws_s3_bucket.assets.id
 9  versioning_configuration { status = "Enabled" }
10}
11
12resource "aws_s3_bucket_server_side_encryption_configuration" "assets" {
13  bucket = aws_s3_bucket.assets.id
14  rule {
15    apply_server_side_encryption_by_default {
16      sse_algorithm = "aws:kms"
17    }
18  }
19}
20
21resource "aws_s3_bucket_public_access_block" "assets" {
22  bucket                  = aws_s3_bucket.assets.id
23  block_public_acls       = true
24  block_public_policy     = true
25  ignore_public_acls      = true
26  restrict_public_buckets = true
27}

versioning

versioning 讓物件的每次覆寫都保留前一版。誤覆寫時可以從版本歷史回退到前一個正確版本，誤刪時物件只是被標記為 delete marker、前一版仍然存在。這道防線對承載正式資料的 bucket 是必要的 — 沒有 versioning 的 bucket，一次誤操作就是資料永久遺失。

versioning 開啟後會累積歷史版本的儲存量。搭配生命週期規則設定 noncurrent_version_expiration 可以控制保留多少天的舊版本，避免儲存成本無限成長。這個天數是「保留能力」跟「儲存成本」的取捨 — 保留 30 天通常足以涵蓋發現問題到回退的時間差，受合規要求的資料則依規定延長。

server-side encryption

server_side_encryption 確保物件在 S3 落地時加密。aws:kms 使用 KMS 管理的金鑰，加密操作對應用程式透明 — 寫入時自動加密、讀取時自動解密，不需要改應用程式碼。選 aws:kms 而非 AES256（SSE-S3）的判斷依據是存取控制粒度：KMS 金鑰可以獨立設定 key policy，讓「誰能解密」這件事跟「誰能讀 bucket」分開管理，適合跨帳號或跨團隊的場景。

使用 KMS 加密的 bucket 在跨帳號存取時，目標帳號除了要有 bucket 的讀取權限，還需要 KMS key 的 kms:Decrypt 權限 — 少了這一步會拿到 AccessDenied，錯誤訊息通常指向 S3 權限而非 KMS，排查時容易走錯方向。

public access block

public_access_block 的四個布林全設 true，等於從 bucket 層級封死對外公開的可能。即使有人之後誤加了一條公開的 bucket policy 或 ACL，這個 block 也會擋住。它是一道兜底機制 — 擋的是設定錯誤，不是正常操作。

靜態掃描工具（checkov / tfsec）會標記缺少 public access block 的 bucket。這正是模組七：infra 走 PR 流程裡自動化護欄的典型攔截對象 — 漏設的 bucket 會在 PR 階段被擋下，而非部署到線上才發現。

定期用 CLI 掃一遍帳號內所有 bucket 的公開狀態，命中的每個 bucket 都要能回答「這個公開是故意的、理由是什麼」：

1aws s3api list-buckets --query 'Buckets[].Name' --output text | tr '\t' '\n' | \
2  while read b; do
3    status=$(aws s3api get-public-access-block --bucket "$b" 2>/dev/null | \
4      jq -r '.PublicAccessBlockConfiguration | to_entries[] | select(.value==false) | .key')
5    [ -n "$status" ] && echo "$b: $status"
6  done

生命週期規則

儲存成本隨物件數量與保留時間線性成長。生命週期規則讓 IaC 描述「某類物件多久後搬到更便宜的儲存層、再多久後刪掉」，把成本控制變成可版本控制的設定。

 1resource "aws_s3_bucket_lifecycle_configuration" "assets" {
 2  bucket = aws_s3_bucket.assets.id
 3
 4  rule {
 5    id     = "archive-old-logs"
 6    status = "Enabled"
 7    filter { prefix = "logs/" }
 8
 9    transition {
10      days          = 30
11      storage_class = "GLACIER_IR"
12    }
13    expiration { days = 365 }
14  }
15
16  rule {
17    id     = "cleanup-old-versions"
18    status = "Enabled"
19    filter {}
20
21    noncurrent_version_expiration {
22      noncurrent_days = 30
23    }
24  }
25}

儲存層的取捨

S3 提供多個儲存層，各自在存取延遲與儲存單價之間取捨：

transition 規則的日數設定要回推自業務需求：log 在除錯期間需要即時讀取（Standard），超過 30 天後幾乎只在事故回顧時才翻（Glacier Instant Retrieval 或 Standard-IA），超過一年可以淘汰或移到更深的歸檔層。把這些規則寫進 IaC，「為什麼 logs 只留一年」就是一個能在 PR 上被討論的決定，而非某人在 Console 點了不知道大家知不知道的設定。

bucket policy 與跨帳號存取

bucket policy 描述誰能對這個 bucket 做什麼操作，是 bucket 層級的存取控制。它跟 IAM policy 的差別在施力點：IAM policy 貼在身分上、定義「這個身分能做什麼」；bucket policy 貼在資源上、定義「這個 bucket 允許誰來」。兩者同時生效 — 一個請求要同時被身分端和資源端允許才會放行（除非有顯式 deny）。

跨帳號存取是 bucket policy 最常見的使用場景。一個帳號的 S3 bucket 要讓另一個帳號的 IAM role 讀取，需要兩端同時授權：bucket policy 允許那個 role 的 ARN，對方帳號的 IAM policy 也允許對這個 bucket 操作。

 1resource "aws_s3_bucket_policy" "cross_account_read" {
 2  bucket = aws_s3_bucket.assets.id
 3
 4  policy = jsonencode({
 5    Version = "2012-10-17"
 6    Statement = [{
 7      Sid       = "AllowCrossAccountRead"
 8      Effect    = "Allow"
 9      Principal = { AWS = "arn:aws:iam::111222333444:role/data-reader" }
10      Action    = ["s3:GetObject", "s3:ListBucket"]
11      Resource = [
12        aws_s3_bucket.assets.arn,
13        "${aws_s3_bucket.assets.arn}/*"
14      ]
15    }]
16  })
17}

bucket policy 的常見陷阱是 Principal: "*" — 允許任何人存取。這跟 security group 的 0.0.0.0/0 是同一類風險。除了做為 CloudFront Origin Access Control（OAC）的配合設定，幾乎沒有合理場景需要把 Principal 設成 wildcard。checkov 的 CKV_AWS_70 規則專門攔這個。

把 bucket policy 寫進 IaC 的好處是每一條授權都有 PR 紀錄 — 誰在什麼時候加了一條跨帳號存取、為什麼加、reviewer 同意了沒有。散落在 Console 的 bucket policy 沒有這些追蹤，某天發現一條不認得的授權時，只能去翻 CloudTrail 猜它是什麼時候加的。

事件通知

S3 事件通知讓 bucket 在物件被建立、刪除或還原時，自動觸發下游處理 — 寫入後自動縮圖、上傳後自動掃毒、刪除後自動通知。這些觸發關係寫進 IaC，讓「這個 bucket 會觸發什麼」成為可查詢的事實，而非散落在 Console 的隱性接線。

 1resource "aws_s3_bucket_notification" "assets" {
 2  bucket = aws_s3_bucket.assets.id
 3
 4  lambda_function {
 5    lambda_function_arn = aws_lambda_function.thumbnail.arn
 6    events              = ["s3:ObjectCreated:*"]
 7    filter_prefix       = "uploads/"
 8    filter_suffix       = ".jpg"
 9  }
10}
11
12resource "aws_lambda_permission" "allow_s3" {
13  statement_id  = "AllowS3Invoke"
14  action        = "lambda:InvokeFunction"
15  function_name = aws_lambda_function.thumbnail.function_name
16  principal     = "s3.amazonaws.com"
17  source_arn    = aws_s3_bucket.assets.arn
18}

事件通知的兩個配置常被忽略。第一是權限：S3 要觸發 Lambda，Lambda 的 resource-based policy 必須允許 S3 呼叫它（上面的 aws_lambda_permission），少了這段 apply 會成功但事件不會觸發，除錯時不容易發現。第二是 filter：不設 prefix / suffix 的通知會對 bucket 裡每一個物件操作都觸發，包括生命週期搬遷產生的物件變動 — 流量遠超預期。用 filter 把觸發範圍收斂到需要處理的路徑與檔案類型。

事件通知也可以導向 SQS 或 SNS，適合需要非同步佇列處理或 fan-out 到多個消費者的場景。選擇依據是下游的消費模式：Lambda 適合輕量即時處理（毫秒級回應），SQS 適合需要 backpressure 和重試的批次處理，SNS 適合同一事件需要同時通知多個服務。

跨分類引用

• → 模組七：infra 走 PR 流程：checkov / tfsec 攔截缺少 public access block 或加密的 bucket
• → 模組八：治理好習慣：bucket 的 tagging 與成本歸因
• → 模組二：身分與憑證地基：bucket policy 與 IAM policy 的權限模型交集

服務定位

Cloud-native data policy 是 resource-bound access control — 控制邏輯掛在 BigQuery dataset / column / row 或 S3 bucket / object 上、用 Google Cloud IAM / AWS IAM 的 principal 體系做 evaluation。跟 Google DLP 比、DLP 是 content-based discovery + transformation（掃 PII、做 de-id）、本頁工具是 access boundary；典型組合是 DLP 發現 sensitive column → BigQuery policy tag 控制誰能讀 → S3 Object Lambda redact at read time。跟 Microsoft Purview 比、Purview 走 label-driven + 跨 platform（同一個 sensitivity label 跨 SharePoint / Fabric / Azure SQL）、雲端原生 policy 走 resource-bound + 限該雲；雲端原生更貼近 storage、跨雲統一靠商業 platform。跟通用 Cloud IAM 比、IAM 是 resource-level read/write 二分、本頁是 column / row / object-level 細粒度、補 IAM 解不掉的「同一張表只能看自家行」場景。

關鍵張力：資料細粒度 ↔ 跨雲 portability。BigQuery RLS 跟 S3 Access Points 的 policy 語法都是該雲專屬、換雲要重寫；換來的是 free（無額外授權）+ 平台原生效能（不過代理）。多雲 enterprise 若要統一 policy DSL、走 Immuta / Privacera / Snowflake Horizon。

本章目標

讀完本頁、讀者能判斷：

1. BigQuery 跟 S3 policy 各自能做到什麼層級的細粒度（column / row / object / cross-region）、不能做到什麼
2. Cloud-native policy 跟 Google DLP / Microsoft Purview 的責任分界、何時要組合使用
3. Multi-tenant SaaS 在共用 dataset / bucket 場景的 access boundary 設計（BigQuery RLS / S3 Access Points）
4. 何時用雲端原生 policy、何時改走 Immuta / Privacera / Snowflake 跨雲 data security platform

最短判讀路徑

判斷 cloud-native data policy 是否健康、最少看四件事：

• BigQuery 側 — RLS / column policy coverage：multi-tenant dataset 是否有 CREATE ROW ACCESS POLICY、sensitive column 是否綁 policy tag、policy tag 上的 IAM 是否走 group 而非 individual user、view-only access 是否走 Authorized View 而非 dataset grant
• S3 側 — bucket policy 結構：Block Public Access 是否 account-level 開啟、ACL 是否 disabled（Object Ownership = BucketOwnerEnforced）、共用 bucket 是否走 Access Points 分租戶、跨帳號是否經 AP policy + bucket policy 雙重驗證
• Sensitive data discovery 接口：BigQuery 是否接 Google DLP inspection job、Dataplex 是否跑 data classification、S3 是否開 Macie scan、findings 是否進 EventBridge / Security Hub 而非僅 console 看
• Audit trail completeness：BigQuery audit log（dataAccess）是否進 Cloud Logging + 進 SIEM、S3 是否開 server access logging + CloudTrail data event（GetObject / PutObject）、跟 Detection Coverage 對齊

四件事任一缺失、就是 Data Residency, Deletion and Evidence Chain 邊界的待補項目。

日常操作與決策形狀

BigQuery 側

Authorized View / Authorized Routine：view 的 SQL definition 可以讀 source dataset、grantee 只要被 grant view 自身就能查、不需要 grant source dataset access。經典「給 analyst 看 aggregate 數據但不給原始 PII row」模式 — analyst 看 SELECT region, count(*) FROM customer 沒問題、但 underlying customer table 從不出現在 analyst IAM。Authorized Routine 是同邏輯延伸到 stored procedure / UDF、適合 logic 比 SELECT 複雜的轉換場景。

Column-level security（policy tag）：在 Data Catalog 建 taxonomy + policy tag、把 BigQuery column schema 綁 tag、policy tag 上設 fine-grained reader role。沒這個 role 的 user 即使有 dataset access、SELECT * 時該 column 會 raise error 或 被 omit。HIPAA / PCI-DSS 對「即使 DBA 也不能 default 看到 PHI / cardholder data」的硬要求、走 policy tag 是技術性 enforcement、不是 procedural control。

Row-level security (RLS)：CREATE ROW ACCESS POLICY tenant_filter ON dataset.table GRANT TO ('group:analysts@org.com') FILTER USING (tenant_id = SESSION_USER())。每個 query 自動 append filter、user 看到的 row 由 policy expression 決定。Multi-tenant SaaS（共用 dataset、每行帶 tenant_id）必用 — 否則 query 必須在 application layer 帶 WHERE、漏一處就是跨 tenant data leak。對應 Snowflake 2024 Credential Abuse 的對照啟示。

Dynamic Data Masking：column 上設 masking rule（hash / nullify / partial mask / regex replace）、不同 IAM 角色看不同 mask 程度 — email_address 在 admin 看到原值、在 analyst 看到 ***@example.com、在 external partner 看到 NULL。補 RLS 不足之處：RLS 過濾 哪些 row 看得到、Masking 過濾 看到的 row 內容怎麼呈現；兩者組合解大多數 multi-tenant + multi-role 場景。

Dataplex Data Classification + DLP 整合：Dataplex 走 lake-wide 治理（dataset metadata + lineage + quality）、自動觸發 Google DLP inspection、發現 sensitive column 自動建議 / 套用 policy tag。是 GCP 內部把 discovery → access control 自動化的標準路徑。

S3 側

Block Public Access account-level：2018 推出、2023 起新建 bucket 預設開啟。account-level setting 強制 override 所有 bucket policy / ACL — 即使有 bucket policy 寫 "Principal": "*"、Block Public Access 開啟時也禁止對外暴露。Production AWS 帳號必須 account-level 開、bucket-level 額外加固。是 LastPass 2022 Backup Chain 類事故的 last-line defense。

Bucket policy / IAM policy / ACL（legacy）：三層 evaluation — bucket policy（resource-based、寫在 bucket 上）、IAM policy（identity-based、寫在 principal 上）、ACL（legacy object-level、新建 bucket 應禁用）。AWS 2023 起推 Object Ownership = BucketOwnerEnforced、強制 ACL disabled、所有 access 經 bucket policy + IAM 決定。舊 bucket 應走 ACL → bucket policy migration。

S3 Access Points：每個 bucket 可開多個 Access Point、各有獨立 name + policy + VPC restriction。Multi-tenant 場景（一個 bucket 服務多個 tenant）走「每個 tenant 一個 AP + AP policy 限定 prefix + 限定 VPC」、取代過去「shared bucket + prefix-based IAM」的脆弱模式。對應 Mailchimp 2023 Support Tool Abuse 的對照啟示 — 共用入口需 per-tenant policy boundary、不是 application-layer filtering。

Multi-Region Access Points (MRAP)：跨 region replicated bucket 的單一 global endpoint、自動 route 到最近 region。資料駐留要求高的場景（GDPR / 中國資料法）反而要慎用、因為 read 來源不可預測；對 latency-sensitive 全球分發是 first-class 解法。

Object Lambda Access Points：在 GetObject response path 插 Lambda、做 read-time transformation（redact PII / format conversion / image resize / decrypt + re-encrypt）。同一份 raw object、不同 caller 透過不同 Object Lambda AP 看到不同版本 — 等同 BigQuery Dynamic Data Masking 在 S3 的對應物。但 Lambda 有 cold start + 6MB response limit、不是所有場景都合適。

Macie sensitive data discovery：S3 專屬、scan bucket 找 PII / credential / payment data、findings 進 EventBridge + AWS Security Hub。跟 Google DLP 同層但限 S3、不能掃 RDS / DynamoDB。findings 應自動 route 到 SIEM、不是只在 Macie console 等人看。對應 Progress WS_FTP 2023 File Service Breach 的對照 — 對外檔案服務必有 audit + 異常量 baseline + Macie sensitive content scan。

S3 Object Ownership / ACL disabled：2023+ 預設 ACL disabled、所有新 bucket 應 keep this default、舊 bucket 走 audit + migration（先掃 ACL grant、確認沒人靠 ACL 拿 access、再切換）。混用 ACL + bucket policy 的 bucket 是 access control 漂移最常見的源頭。

核心取捨表

選雲端原生 policy 的核心訴求：單一雲 + 預算敏感 + 不想引入新 vendor。多雲 enterprise + 統一治理需求高、走 Immuta / Privacera 才能避免兩套 policy 漂移。

進階主題

BigQuery Authorized View vs RLS 取捨：Authorized View 適合 shape-based filtering（grantee 只能看 aggregate / 特定 column subset）、RLS 適合 value-based filtering（grantee 只能看 tenant_id = self 的行）。實務常常組合 — view 限 column、view 上再加 RLS 限 row。view 的問題是維護成本（schema 改要同步改 view）、RLS 的問題是 policy expression 寫錯整批 user 看不到資料、staging tenant 跑過再 promote。

S3 Access Points + VPC-only restriction：AP policy 可加 "Condition": {"StringEquals": {"aws:SourceVpc": "vpc-xxx"}}、強制只能從特定 VPC access — 跨帳號場景（partner 帳號 access 自家 bucket）必加、避免 partner credential 外洩後可從任意網路位置存取。對應 LastPass 2022 Backup Chain 對照、backup bucket 不該跟 prod bucket 共用 IAM role + 不該允許 internet-wide access。

Object Lambda redact PII at read time：適合 raw data 已寫入、但不同 consumer 需要不同 view 的場景 — 例如客服查 user record 看到 mask 過的 SSN、合規 audit 帳號看到完整 SSN。Lambda 內部呼叫 Google DLP deid template / Comprehend PII detection / 自家 regex；要注意 cold start 對 latency 的影響、不適合 high-throughput 場景。

Macie automated discovery → SIEM：Macie findings 走 EventBridge rule → Security Hub → 推 Splunk / Elastic Security / Datadog Security — 不該只在 Macie console 看 findings。發現 unencrypted S3 bucket 有 cardholder data 必須觸發 incident response runbook、進 8 事故處理。

跨 region 跟 data residency：BigQuery dataset region + S3 bucket region 是 資料駐留 enforcement 的硬邊界、policy tooling 不能 override。GDPR / 中國資料法場景必須 region pinning + 禁止 Multi-Region replication、policy tag / RLS 無法解決資料離境問題。對應 Data Residency Deletion and Evidence Chain 章節原則。

排錯與失敗快速判讀

• BigQuery RLS 設了但 user 還是看到全部 row：policy GRANT TO 沒包該 user 的 group、或 user 有 bigquery.dataOwner role（owner override RLS）— check group membership + 降權到 dataViewer
• Column policy tag 沒生效：column 沒 attach tag、或 tag taxonomy 沒在該 project / region — check Data Catalog taxonomy location 跟 dataset region 對齊
• S3 bucket 意外 public：Block Public Access account-level 沒開 + bucket policy 寫 "Principal": "*"、或 ACL 殘留 AllUsers grant — 立即開 BPA + audit ACL（aws s3api get-bucket-acl）
• Access Point policy 跟 bucket policy 衝突：AP 允許 但 bucket policy 拒絕、最後是拒絕（explicit deny 永遠勝）— 兩層都要明確 allow、bucket policy 加 "Principal": {"AWS": "*"} + condition 限定 AP ARN
• Macie scan 跑很久 / cost 暴衝：scan 整個 bucket、含 archive prefix、沒設 sampling — 用 sensitive data discovery job with prefix filter + sampling rate、不要 default 全 bucket scan
• Authorized View grantee 看不到資料：view definition 走的 source dataset 沒 authorize 該 view、或 view 自身改了但沒重新 authorize — bq update --view_authorization 重設
• Object Lambda 慢 / timeout：Lambda cold start + 6MB response limit、大檔案不該走 Object Lambda — 改在寫入時 transform、或用 pre-signed URL 繞過 Object Lambda

何時改走其他服務

不在本頁內的主題

• BigQuery / S3 自身的完整 admin guide（pricing / region / quota）
• Encryption-at-rest 細節（KMS 整合走 AWS KMS / Google Cloud KMS 頁）
• Azure Data Lake / Azure SQL policy（屬 Azure stack、本頁不涵蓋）
• 應用層 RBAC framework（Casbin / Cerbos / OPA Rego）
• 資料庫層 RLS（PostgreSQL RLS / SQL Server Row-Level Security）— 跟雲端原生 storage policy 是不同層

案例回寫

Cloud-native data policy 在 07 案例庫沒有直接 vendor-level 事件、所有 data exfiltration case 都是 access boundary 的對照：

下一步路由

• 上游：7.7 資料駐留刪除與證據鏈、Detection Coverage and Signal Governance
• 平行：Google DLP（discovery + de-id 互補）、Microsoft Purview（label-driven 對照）
• 下游：Splunk / Elastic Security / Datadog Security（audit log + Macie findings → SIEM）
• 跨類：AWS IAM / Google Cloud IAM（principal 體系基底）、AWS KMS / Google Cloud KMS（encryption-at-rest）
• 跨模組：8 事故處理 vendor 清單（data exfiltration incident routing）、1 資料庫模組（database-layer RLS / column policy 對照）
• 官方：BigQuery column-level security、BigQuery row-level security、Amazon S3 Access Points、Amazon Macie