Amazon SCS-C02: 資料保護與 S3 — 學習指南

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

屬於 AWS Security Specialty SCS-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

S3 儲存貯體政策、資源 ARN 與明確拒絕 (Explicit Denies)

S3 儲存貯體政策是一種以資源為基礎的 JSON 文件，會與以身分為基礎的政策一起進行評估。其行為主要由兩條規則主導。首先，明確的 Deny 永遠優先：無論有多少 Allow 陳述式，只要有任何一個相符的 Deny 就會阻擋該請求。其次，Resource 元素必須精確匹配該操作的 ARN 格式。儲存貯體層級的操作 (如 s3:ListBucket) 作用於 arn:aws:s3:::my-bucket，而物件層級的操作 (如 s3:GetObject 和 s3:PutObject) 則作用於 arn:aws:s3:::my-bucket/*。一個常見的錯誤設定是在 arn:aws:s3:::my-bucket 上授予 s3:GetObject 權限，卻沒有加上 /* 後綴——因為 API 呼叫的目標是物件的 ARN，導致沒有任何陳述式匹配，請求最終被預設拒絕。

以下政策拒絕所有非 TLS 的存取，並為一個特定的角色授予讀取權限，同時正確地使用了兩種 ARN 格式。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::reports",
        "arn:aws:s3:::reports/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "AllowAnalyticsRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/Analytics" },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::reports/*"
    }
  ]
}

一個常見的陷阱是，在一個廣泛的 Deny 之後，試圖透過新增一個 Allow 來「開後門」作為例外。政策陳述式是沒有順序性的，IAM 的評估邏輯只要找到任何一個匹配的 deny，就會立即回傳 Deny。正確的修復方法是縮小 Deny 的範圍——例如，透過 NotPrincipal 或 Condition——而不是在它下面附加一個允許的陳述式。

生命週期規則、物件過期與 Vault Lock

S3 生命週期規則能自動化儲存類別的轉換與物件的過期。為了滿足保留要求——例如在擷取 PII 30 天後將其移除——可以附加一條規則，讓目前的物件版本在 30 天後過期，並在此後不久永久刪除非目前的版本。對於寫入 DynamoDB 的相關中繼資料，可以啟用 DynamoDB 的 TTL 屬性，讓項目能按照相同的時程自我刪除；結合這兩種機制在維運上非常有效率，因為不需要 Lambda、排程器或客製化的清理程式碼。

LifecycleConfiguration:
  Rules:
    - Id: ExpirePIIAfter30Days
      Status: Enabled
      Filter: { Prefix: "ingest/" }
      Expiration: { Days: 30 }
      NoncurrentVersionExpiration: { NoncurrentDays: 1 }

對於有法規保留要求的封存資料，S3 Glacier Vault Lock 在 vault 層級提供了一個獨立的 WORM 控制。一旦 Vault Lock 政策被提交 (一個需在 24 小時內完成的「啟動/完成」兩步驟流程)，它就無法被更改，即使是帳號的 root 使用者也一樣。這與在 S3 物件層級運作的 Object Lock 是不同的。

封鎖公開存取與 CloudFront OAC

S3 封鎖公開存取 (BPA) 是一組在帳號和儲存貯體層級的開關，它會覆寫任何原本可能授予公開存取的 ACL 或政策。在帳號層級啟用這全部四個開關，並透過 SCP (例如，當 s3:PutBucketPublicAccessBlock 會放寬設定時就拒絕它) 來強制執行。這種深度防禦策略可以防止工程師因一個過於寬鬆的 ACL 而意外地讓儲存貯體再次暴露於公網。

對於透過 CloudFront 提供服務的公開內容，正確的模式是使用 Origin Access Control (OAC)。OAC 使用 SigV4 來簽署從 CloudFront 到 S3 的請求；儲存貯體政策接著只允許該 CloudFront 發行版的服務主體進行存取。如果只依賴 CloudFront 而不使用 OAC (或舊版的 OAI)，會讓 S3 的 URL 可被直接存取，從而繞過了 CDN 的存取控制和 WAF。儲存貯體必須保持私有、啟用 BPA，且政策範圍應限定在該發行版的 ARN：

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::site-assets/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCXYZ"
    }
  }
}

S3 物件鎖定與跨區域複寫

Object Lock 對個別物件強制執行 WORM 語意，並要求在建立儲存貯體時就啟用版本控制和 Object Lock (它無法在事後新增到現有的儲存貯體，除非聯繫 AWS 支援)。存在兩種保留模式：

Governance 模式 (治理模式)： 擁有 s3:BypassGovernanceRetention 權限的特權主體可以縮短或移除保留期限。
Compliance 模式 (合規模式)： 任何使用者——包含 AWS 帳號的 root——都無法在物件過期前刪除、覆寫它或縮短其保留期限。此外，擁有 s3:PutObjectLegalHold 權限的使用者可以獨立地套用和移除 Legal Hold (訴訟保留)。

當需求是針對所有身分都必須達到絕對的不可變性時，Compliance 模式是正確的選擇。要將此保證擴展到跨區域，可以將 Object Lock 與 S3 Replication 搭配使用。複寫的物件會在目標儲存貯體中保留其鎖定組態 (目標儲存貯體也必須啟用 Object Lock)，因此，即使發生整個區域的事件或惡意刪除嘗試，也無法危及被保留的副本。

使用 Macie 與 Athena 進行探索與調查

Amazon Macie 使用託管和自訂的資料識別碼來掃描 S3 物件，以尋找 PII、PHI、憑證和其他敏感資料模式。它會將發現的結果報告給 Security Hub 和 EventBridge，從而實現自動化修復，例如透過基於標籤的限制性儲存貯體政策來隔離物件。在每個儲存客戶資料的區域都啟用 Macie，並透過 AWS Organizations 委派管理權限，以實現集中化的結果檢視。

Amazon Athena 提供在 S3 資料上運行的無伺服器 SQL 查詢功能，是查詢 CloudTrail 物件層級資料事件的標準工具。要調查誰存取了某個特定的 S3 物件，需為該儲存貯體啟用 CloudTrail 資料事件，將日誌傳送到一個中央的 S3 儲存貯體，然後用 Athena 進行查詢：

SELECT eventTime, userIdentity.arn, sourceIPAddress, requestParameters
FROM cloudtrail_logs
WHERE eventName IN ('GetObject','DeleteObject')
  AND requestParameters LIKE '%reports/q3-financials.pdf%'
  AND eventTime > '2024-01-01T00:00:00Z';

統整的陷阱及其根本原因

物件 ARN 遺漏 /*： 物件層級的 API 呼叫是根據 bucket/key 進行評估，而非儲存貯體的 ARN。若沒有 /*，則沒有任何陳述式會匹配，IAM 會回傳隱性拒絕 — 這會表現為即使「儲存貯體」看似被允許，GetObject 仍會出現預期外的 403 錯誤。
在明確的 Deny 之後新增 Allow： IAM 的評估順序無關；任何匹配的 Deny 都會捷徑式地直接導致拒絕。修復方法是縮小 deny 的範圍 (透過 Condition、NotPrincipal 或 NotResource)，而不是附加寬鬆的陳述式。
CloudFront 未使用 OAC 或限制性的儲存貯體政策： S3 來源 URL 仍然可以直接存取，從而繞過簽章 URL、WAF 規則和地理區域限制。務必在來源儲存貯體上啟用 BPA，並透過 AWS:SourceArn 將 s3:GetObject 限制給 CloudFront 服務主體。
假設可在現有儲存貯體上啟用 Object Lock： Object Lock 必須在建立儲存貯體時就進行設定。若要事後加裝，需要建立一個已啟用 Object Lock 的新儲存貯體，並遷移資料。
混淆控管模式與合規模式： 控管模式無法阻止特權使用者移除保留設定；只有合規模式才能阻止根帳戶進行此操作。

實務問題：使用案例情境

情境： Meridian Financial 將客戶對帳單、交易日誌和長期合規封存檔案儲存在跨越兩個 AWS 區域的多個 S3 儲存貯體中。他們的環境使用 CloudFront 來提供客戶入口網站、進行跨帳戶日誌記錄，並透過自動化生命週期轉換將資料移至封存儲存類別以符合法規保留要求。

挑戰： 最近一次內部審查發現，有數個儲存貯體的政策不一致，導致 PII 暴露、封存的記錄沒有不可變的保留設定，並且缺乏一個集中的方法來探索敏感物件在跨帳戶和區域間的位置。

建議方法：

在帳戶和儲存貯體層級啟用 S3 封鎖公開存取 (Block Public Access)，並部署 CloudFront Origin Access Control (OAC)；收緊儲存貯體政策，使用精確的資源 ARN，僅允許來自 CloudFront OAC 主體的 GetObject，並對任何非透過 OAC 的請求新增明確的拒絕。
透過在儲存貯體政策中要求 kms:Encrypt/kms:GenerateDataKey 來強制使用 AWS KMS 進行伺服器端加密，並對不包含 x-amz-server-side-encryption 和必要 kms:context 的 PutObject 請求新增明確的拒絕，以防止未加密的上傳。
對於必須保持不可變的儲存貯體，以合規模式設定 S3 Object Lock，並啟用跨區域複寫 (CRR)，其複寫規則需保留物件鎖定中繼資料，以便複寫的物件在 DR 區域中也保持不可變。
建立 S3 生命週期規則，將老舊物件轉換至 S3 Glacier 儲存類別，並為允許的保留期限設定物件過期；對於法律上必須不可變的封存檔案，則將其放入 Amazon S3 Glacier 保險庫 (vaults) 中，並套用 Glacier Vault Lock 政策以強制執行一次寫入的保留。
在所有帳戶中部署 Amazon Macie 以探索和分類 PII，啟用 S3 Inventory 並使用 Amazon Athena 查詢調查結果以進行調查性查詢，並觸發自動化修復 (Lambda/Step Functions) 來標記、隔離或將敏感物件移動到已鎖定、加密的儲存貯體中。

基本原理： 這種分層方法強制執行最低權限和加密，為合規性提供不可變的保留和跨區域耐久性，並使用 Macie/Athena 進行集中探索和自動化修復——這與 AWS 在資料保護和生命週期管理方面的最佳實務一致。

Amazon Macie：自動化探索、分類任務與允許清單

Amazon Macie 是一項受管的資料安全服務，它使用機器學習和模式比對來探索儲存在 Amazon S3 中的敏感資料——例如個人可識別資訊 (PII)、支付卡號 (PANs)、憑證以及自訂 regex 定義的資料類型。Macie 以兩種經常被混淆的互補模式運作。

自動化敏感資料探索 是一個低成本、持續運行的程序，它會對帳戶中 (或當 Macie 委派給安全帳戶時，對整個組織中) 的每個儲存貯體進行物件抽樣。它會建立每個儲存貯體的敏感度分數和清單。當您擁有數千個儲存貯體且尚不知道敏感資料位於何處時，這是正確的起點，因為它透過抽樣而非掃描每個物件來最小化成本和管理開銷。

分類任務 (敏感資料探索任務) 是針對特定儲存貯體的一次性或排程的深度掃描。一旦自動化探索將某個儲存貯體標記為包含敏感資料，您就可以建立一個範圍限定在該儲存貯體的分類任務，以進行詳盡的分析。因此，標準模式是：在整個組織範圍內啟用自動化探索，然後僅對被標記的儲存貯體執行分類任務。

允許清單是用於抑制已知良性匹配項的機制。如果資料湖中包含合成的測試用 PANs (例如眾所周知的 4111 1111 1111 1111 測試卡號範圍)，Macie 會標記每一次出現。重寫或移動資料既昂貴又具破壞性；正確的方法是定義一個 Macie 允許清單——可以是一個包含確切值的純文字清單或一個 regex——並將其與您的分類任務和自動化探索設定關聯。與允許清單匹配的項目將從調查結果中排除，而真正的 PANs 則會繼續觸發警示。

實務問題：使用情境

情境： Meridian Financial 公司在一個多帳戶的 AWS 環境中運作，擁有數百個 S3 儲存貯體，用於儲存交易日誌、客戶文件，以及已移至 S3 Glacier 的長期封存資料。他們的資安團隊有基本的加密和日誌記錄，但缺乏跨帳戶的集中式敏感資料探索或一致的保留控制機制。

挑戰： 最近發現一個公開的儲存貯體，在錯誤的儲存貯體政策和生命週期轉換至 S3 Glacier 後，包含了帶有 PII 的封存客戶記錄。Meridian 公司需要找出所有敏感資料、修復曝險，並在未來強制執行合規的封存保留政策。

建議方法：

在整個 AWS Organization 中啟用 Amazon Macie，並開啟 S3 自動探索功能，讓 Macie 持續評估儲存貯體和物件是否有敏感資料和風險配置。
建立 Macie 分類任務，目標鎖定所有 S3 儲存貯體；為 SSN 和帳號設定自訂的敏感資料識別碼，並設定允許清單 (allow lists) 以排除已知的測試資料、供應商檔案和服務帳戶。
使用 S3 Inventory 來列舉 S3 Glacier 中的物件，然後執行 S3 Batch Operations，僅暫時還原被 inventory 標記出來要給 Macie 掃描的物件，以便分類任務能檢查封存到 Glacier 的內容。
將 Macie 的發現結果傳送到 Amazon EventBridge 和 Security Hub，以自動化修復流程；觸發 Lambda 函數來套用安全的 S3 儲存貯體政策、啟用 S3 Block Public Access、移除公開的 ACL，並將儲存貯體加上標籤以供審查。
實作持久的保留和預防措施：在關鍵的儲存貯體上啟用 S3 Versioning 和 S3 Object Lock (治理/合規模式)，透過儲存貯體政策強制使用 SSE-KMS 搭配 CMK，並部署 AWS Organizations SCPs 來阻擋公開的 ACL，以及在適用情況下要求加密和 Object Lock。
為 S3 啟用 CloudTrail 資料事件，並將發現結果饋送到 SIEM 中，用於警示和定期排程 Macie 分類任務，以確保持續的涵蓋範圍。

理由： 此方法利用 Macie 進行自動化探索和目標式分類 (搭配允許清單)，僅在需要檢查時才還原 Glacier 物件，透過 EventBridge/Lambda 自動化修復，並使用 Object Lock 和 KMS 強制執行不可變的保留和加密——這與 AWS 在偵測、修復和預防性控制方面的最佳實務一致。

# Example allow list (regex form) matching common test PANs
Type: Regex
Regex: '^4111[- ]?1111[- ]?1111[- ]?1111$|^5555[- ]?5555[- ]?5555[- ]?4444$'
Name: synthetic-test-pans

若將原始的 Macie 發現結果視為絕對事實，而未設定允許或抑制清單，會產生警示疲勞，並可能將真實事件淹沒在由合成資料產生的噪音中——這就是為什麼在充滿誤報的環境中，單純「相信發現結果」是錯誤的答案。

將 Macie 發現結果與 EventBridge 整合

Macie 會將每一個發現結果發佈到 Amazon EventBridge 的 aws.macie 來源上。這讓您無需輪詢 Macie API 即可路由發現結果。一個典型的規則會將 Policy 類型的發現結果轉發到 SNS 以便呼叫待命人員，並將 SensitiveData 類型的發現結果傳送到 AWS Security Hub 進行彙總。

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

規則的目標可以是 SNS 主題、Security Hub，或是用於自訂修復的 Lambda 函數 (例如，在有問題的儲存貯體上自動套用限制性的儲存貯體政策)。

用於組織邊界的儲存貯體政策條件

S3 Block Public Access (BPA) 僅阻擋源自公用網際網路或匿名主體的存取。它不會阻止位於不同 AWS 帳戶或不同 AWS Organization 中的已驗證主體存取儲存貯體，如果儲存貯體政策或 ACL 授予了此類存取權限。因此，當需求是防止跨組織存取時，僅依賴 BPA 是不正確的——您必須將儲存貯體政策與 Organizations 層級的服務控制政策 (SCPs) 結合使用。

兩個 IAM 條件金鑰讓組織邊界的強制執行更加精確：

aws:ResourceOrgID：擁有被存取資源的 Organization ID。用於身分政策/SCPs 中，以拒絕主體接觸您組織以外的資源。
aws:PrincipalOrgID：呼叫端主體的 Org ID。用於儲存貯體政策中，以拒絕來自您組織以外的主體存取。
aws:SourceOrgPaths：來源主體的 OU 路徑，允許將範圍限定在特定的 OU (例如，只有「Production」OU 可以寫入合規儲存貯體)。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideOrg",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:DeleteObject"],
    "Resource": "arn:aws:s3:::acme-compliance/*",
    "Condition": {
      "StringNotEqualsIfExists": {
        "aws:PrincipalOrgID": "o-abcd1234",
        "aws:SourceOrgPaths": "o-abcd1234/r-root/ou-prod-xyz/"
      }
    }
  }]
}

將此與一個 SCP 配對，該 SCP 拒絕在 aws:ResourceOrgID 與您的 Org 不符的資源上執行 s3:DeleteObject* 操作，如此一來，即使儲存貯體政策被意外放寬，跨組織的資料外洩或刪除也將變得不可能。

S3 Object Lock：合規模式與版本控制

Object Lock 對個別的物件版本強制執行「寫入一次，讀取多次」(WORM) 的語意。它要求在儲存貯體上啟用 S3 Versioning (沒有版本控制的 Object Lock 是不可能的——鎖定是保護特定的版本 ID，而不是金鑰)。

治理模式 (Governance mode)：擁有 s3:BypassGovernanceRetention 權限的使用者可以縮短或移除保留期。適用於內部政策的強制執行。
合規模式 (Compliance mode)：任何主體，包括 AWS 帳戶的根使用者，都不能在保留期到期前縮短、移除或刪除該物件版本。這是滿足法規不可變性要求 (如 SEC 17a-4、FINRA、HIPAA 封存) 的正確選擇。

保留期可以針對每個物件設定 (Retain-Until 日期)，或透過儲存貯體層級的預設保留組態來設定。Legal Holds (訴訟資料保留) 是獨立的、無限期的鎖定，會一直存在，直到持有 s3:PutObjectLegalHold 權限的主體明確將其移除為止。

aws s3api put-object-retention \
  --bucket acme-audit-logs \
  --key 2024/transactions.parquet \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2031-01-01T00:00:00Z"}'

S3 Glacier Vault Lock：在鎖定完成前修正政策錯誤

S3 Glacier 上的 Vault Lock 強制執行不可變的儲存庫存取政策。此程序包含兩個 API 呼叫：initiate-vault-lock 會將政策置於 進行中 (in-progress) 狀態，並提供 24 小時的窗口期，而 complete-vault-lock 則使其永久生效。如果在 24 小時的窗口期內發現打字錯誤——例如，一個過於寬鬆的 Principal——最正確且成本最低的補救方法是：

aws glacier abort-vault-lock --account-id - --vault-name compliance-archive
aws glacier initiate-vault-lock --account-id - --vault-name compliance-archive \
  --policy file://corrected-policy.json

abort-vault-lock 會免費取消進行中的鎖定，讓您能用修正後的政策重新啟動程序。其他的「修復」方法——例如刪除並重新建立儲存庫（這需要刪除所有 10 TB 的封存檔並重新上傳，會產生擷取和傳輸費用），或是等待鎖定完成後再尋找解決辦法——都是浪費資源或不可能的。一旦執行 complete-vault-lock，政策就永久不可變更；abort 指令僅在進行中的窗口期內有效。

相關陷阱：DNSSEC 信任鏈

一個常見的跨網域陷阱與 Route 53 DNSSEC 有關。為子網域的託管區域 (hosted zone) 啟用 DNSSEC 簽署，會產生一個金鑰簽署金鑰 (Key Signing Key, KSK) 和一個對應的 DS 記錄。該 DS 記錄必須發佈在父網域 (parent zone) 中；若沒有它，解析器 (resolver) 無法驗證信任鏈，並且會將回應視為偽造，或退回到不安全的解析模式，導致驗證客戶端的 DNS 解析中斷。啟用簽署卻沒有匯出 DS 記錄並將其插入到註冊商或父網域中，是一種設定不完整的狀態，而不是一個可正常運作的 DNSSEC 部署。

← 加密、KMS 與機密管理 · 所有領域 · 網路與 VPC 安全 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

通過考試 →

瀏覽 Amazon →