Amazon SCS-C02: 数据保护与 S3 — 学习指南
属于 AWS Security Specialty SCS-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.
S3 存储桶策略、资源 ARN 和显式拒绝
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，没有语句能够匹配，请求因此被默认拒绝。
以下策略正确地使用了两种 ARN 格式，拒绝了所有非 TLS 访问，并为一个特定角色授予了读取权限。
{
"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 的范围——例如，通过 NotPrincipal 或 Condition——而不是在它下面追加一个许可语句。
生命周期规则、对象过期和 Vault Lock
S3 生命周期规则可以自动完成存储类别转换和对象过期操作。为了满足保留要求——例如在数据注入 30 天后删除 PII——可以附加一条规则，使当前对象版本在 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 小时内完成的两步式“启动/完成”过程），它就无法被更改，即使是账户根用户也不行。这与在 S3 对象级别操作的 Object Lock 不同。
阻止公开访问和 CloudFront OAC
S3 阻止公开访问 (BPA) 是一组在账户和存储桶级别设置的开关，它会覆盖任何可能授予公共访问权限的 ACL 或策略。在账户级别启用所有四个开关，并使用 SCP（例如，当 s3:PutBucketPublicAccessBlock 操作会放宽设置时拒绝该操作）来强制执行。这种深度防御策略可以防止工程师因配置了过于宽松的 ACL 而意外地重新暴露存储桶。
对于通过 CloudFront 提供服务的面向公众的内容，正确的模式是源访问控制 (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 和跨区域复制
Object Lock 对单个对象强制执行 WORM 语义，并要求在创建存储桶时启用版本控制和 Object Lock（它不能在事后添加到现有存储桶中，除非联系 AWS）。存在两种保留模式：
监管模式 (Governance mode)： 拥有
s3:BypassGovernanceRetention权限的特权主体可以缩短或移除保留期。合规模式 (Compliance mode)： 任何用户——包括 AWS 账户根用户——都无法在对象过期前删除、覆盖或缩短其保留期。此外，拥有
s3:PutObjectLegalHold权限的用户可以独立地应用和移除合法保留 (legal hold)。
当要求对所有身份都实现绝对不可变性时，合规模式是正确的选择。要将这种保证扩展到跨区域，可将 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 的新存储桶并迁移数据。
混淆治理模式与合规模式： 治理模式不会阻止特权用户移除保留策略；只有合规模式才能阻止 root 账户进行此操作。
实践问题：用例场景
场景： 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)，其复制规则需保留对象锁定元数据，以便复制的对象在灾备区域中保持不可变。
- 创建 S3 生命周期规则，将老化对象转换到 S3 Glacier 存储类别，并为允许的保留期限设置对象过期时间；对于必须在法律上保持不可变的存档，将其放入 Amazon S3 Glacier 文件库，并应用 Glacier Vault Lock 策略来强制执行一次写入的保留策略。
- 跨账户部署 Amazon Macie 以发现和分类 PII，启用 S3 Inventory 并使用 Amazon Athena 查询结果以进行调查性查询，并触发自动修复（Lambda/Step Functions）来标记、隔离或将敏感对象移动到锁定的加密存储桶中。
理由： 这种分层方法强制实施了最低权限和加密，为合规性提供了不可变保留和跨区域持久性，并使用 Macie/Athena 进行集中发现和自动修复——这与 AWS 在数据保护和生命周期管理方面的最佳实践相一致。
Amazon Macie：自动发现、分类作业和允许列表
Amazon Macie 是一项托管的数据安全服务，它使用机器学习和模式匹配来发现存储在 Amazon S3 中的敏感数据——个人身份信息 (PII)、支付卡号 (PAN)、凭证以及自定义正则表达式定义的数据类型。Macie 以两种经常被混淆的互补模式运行。
自动敏感数据发现是一个低成本、持续运行的过程，它对账户中（或当 Macie 委派给安全账户时，在整个组织中）的每个存储桶中的对象进行抽样。它会为每个存储桶建立一个敏感度分数和清单。当您拥有数千个存储桶且尚不知道敏感数据位于何处时，这是正确的起点，因为它通过抽样而不是扫描每个对象来最大限度地降低成本和管理开销。
分类作业（敏感数据发现作业）是针对特定存储桶的一次性或计划性深度扫描。一旦自动发现将某个存储桶标记为包含敏感数据，您就可以创建一个范围限定在该存储桶的分类作业，以进行详尽的分析。因此，典型的模式是：在整个组织范围内启用自动发现，然后仅对被标记的存储桶跟进执行分类作业。
允许列表是用于抑制已知良性匹配的机制。如果一个数据湖包含合成的测试 PAN（例如，众所周知 4111 1111 1111 1111 测试卡范围），Macie 会标记每一次出现。重写或移动数据成本高昂且具有破坏性；正确的方法是定义一个 Macie 允许列表——可以是一个包含精确值的纯文本列表或一个正则表达式——并将其与您的分类作业和自动发现配置相关联。与允许列表匹配的结果将从发现结果中排除，而真正的 PAN 仍会继续触发警报。
实践问题：用例场景
场景： Meridian Financial 公司运行着一个多账户 AWS 环境，其中有数百个 S3 存储桶，用于存储交易日志、客户文档以及已移至 S3 Glacier 的长期归档。他们的安全团队有基本的加密和日志记录措施，但缺乏跨账户的集中式敏感数据发现或一致的保留策略控制。
挑战： 最近发现一个面向公众的存储桶，由于一个错误的存储桶策略和到 S3 Glacier 的生命周期转换，其中包含了带有个人身份信息 (PII) 的客户归档记录。Meridian 公司需要找到所有敏感数据，修复暴露风险，并从现在开始强制执行合规的归档保留策略。
推荐方法：
- 在整个 AWS Organization 中启用 Amazon Macie，并开启自动化的 S3 发现功能，以便 Macie 持续评估存储桶和对象的敏感数据及风险配置。
- 创建针对所有 S3 存储桶的 Macie 分类任务；为社保号码 (SSN) 和账号配置自定义敏感数据标识符，并设置允许列表以排除已知的测试数据、供应商文件和服务账户。
- 使用 S3 Inventory 枚举 S3 Glacier 中的对象，然后运行 S3 Batch Operations，临时恢复那些仅被清单标记出来供 Macie 扫描的对象，以便分类任务可以检查归档到 Glacier 的内容。
- 通过将 Macie 发现结果发送到 Amazon EventBridge 和 Security Hub 来自动化修复；触发 Lambda 函数以应用安全的 S3 存储桶策略、启用 S3 阻止公共访问、移除公共 ACL，并标记存储桶以供审查。
- 实施持久保留和预防措施：在关键存储桶上启用 S3 版本控制和 S3 对象锁定（监管/合规模式），通过存储桶策略强制使用带有 CMK 的 SSE-KMS，并部署 AWS Organizations SCP 来阻止公共 ACL，并在适用时要求加密和对象锁定。
- 为 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 阻止公共访问 (BPA) 仅阻止源自公共互联网或匿名主体的访问。如果存储桶策略或 ACL 授予了访问权限，它不会阻止来自不同 AWS 账户或不同 AWS Organization 的经过身份验证的主体访问该存储桶。因此，当要求是防止跨组织访问时，仅依赖 BPA 是不正确的——您必须将存储桶策略与 Organizations 级别的服务控制策略 (SCP) 结合使用。
两个 IAM 条件键使组织边界的强制执行变得精确：
aws:ResourceOrgID：拥有被访问资源的 Organization ID。用于身份策略/SCP 中，以拒绝主体接触您组织之外的资源。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 对单个对象版本强制执行一次写入、多次读取 (WORM) 的语义。它要求在存储桶上启用 S3 版本控制（没有版本控制的 Object Lock 是不可能的——锁保护的是特定的版本 ID，而不是键名）。
监管模式：拥有
s3:BypassGovernanceRetention权限的用户可以缩短或移除保留期。适用于内部策略的执行。合规模式：在保留期到期之前，任何主体（包括 AWS 账户根用户）都不能缩短、移除或删除该对象版本。这是满足法规不可变性要求（如 SEC 17a-4、FINRA、HIPAA 归档）的正确选择。
保留期可以按对象设置（Retain-Until 日期），也可以通过默认的存储桶级别保留配置来设置。合法保留是一种独立的、无限期的锁定，它会一直存在，直到被持有 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 用于强制执行不可变的保管库访问策略。该过程有两个调用：initiate-vault-lock 会将策略置于进行中状态并提供一个 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 运行，策略将永久不可变；中止操作仅在进行中的窗口期内有效。
相关陷阱：DNSSEC 信任链
一个常见的跨域陷阱与 Route 53 DNSSEC 有关。为子域的托管区启用 DNSSEC 签名会生成一个密钥签名密钥 (Key Signing Key, KSK) 和一个相应的 DS 记录。该 DS 记录必须发布在父区域中；如果没有它，解析器将无法验证信任链，从而将响应视为伪造或回退到不安全的解析，导致验证客户端的 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.
通过考试 →