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、明示的なDeny

S3バケットポリシーは、アイデンティティベースのポリシーと並行して評価される、リソースベースのJSONドキュメントです。その動作を決定づける2つのルールがあります。第一に、明示的な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を返します。正しい修正方法は、許容的なステートメントを後から追加するのではなく、例えばNotPrincipalやConditionを使ってDenyの範囲を狭めることです。

ライフサイクルルール、オブジェクトの有効期限、Vault Lock

S3ライフサイクルルールは、ストレージクラスの移行とオブジェクトの有効期限切れを自動化します。例えば、取り込み後30日でPIIを削除するといった保持要件を満たすには、現行バージョンのオブジェクトを30日後に失効させ、その後すぐに非現行バージョンを完全に削除するルールをアタッチします。DynamoDBに書き込まれた関連メタデータについては、DynamoDBのTTL属性を有効にして、アイテムが同じスケジュールで自己削除するようにします。これら2つのメカニズムを組み合わせることで、Lambdaやスケジューラ、独自のクリーンアップコードが不要になるため、運用上効率的です。

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

規制上の保持要件があるアーカイブデータに対しては、S3 Glacier Vault Lockがボールトレベルで個別のWORMコントロールを提供します。Vault Lockポリシーが一度コミットされると（24時間以内に実行される開始/完了の2ステッププロセス）、アカウントのルートユーザーであっても変更することはできません。これは、S3オブジェクトレベルで機能するObject Lockとは異なります。

パブリックアクセスブロックとCloudFront OAC

S3パブリックアクセスブロック (BPA) は、アカウントレベルおよびバケットレベルで設定する4つのスイッチのセットで、パブリックアクセスを許可する可能性のあるすべてのACLやポリシーを上書きします。アカウントレベルですべての4つの設定を有効にし、設定を緩和するようなs3:PutBucketPublicAccessBlockを拒否するSCPなどでこれを強制します。この多層防御により、エンジニアが誤って許容的なACLを通じてバケットを再公開してしまうことを防ぎます。

CloudFront経由で提供される公開コンテンツには、オリジンアクセスコントロール (OAC) を使用するのが正しいパターンです。OACはCloudFrontからS3へのリクエストにSigV4を使用して署名し、バケットポリシーではCloudFrontディストリビューションのサービスプリンシパルのみを許可します。OAC（または従来のOAI）なしでCloudFrontだけに依存すると、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に連絡しない限り、既存のバケットに後から追加することはできません）。2つのリテンションモードが存在します。

ガバナンスモード: s3:BypassGovernanceRetentionを持つ特権プリンシパルは、リテンション期間を短縮または削除できます。
コンプライアンスモード: AWSアカウントのルートユーザーを含むいかなるユーザーも、有効期限が切れるまでオブジェクトを削除または上書きしたり、リテンション期間を短縮したりすることはできません。さらに、s3:PutObjectLegalHoldを持つユーザーが、独立してリーガルホールドを適用・解除できます。

すべてのアイデンティティに対する絶対的な不変性が要件である場合、コンプライアンスモードが正しい選択です。その保証をリージョンを越えて拡張するには、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コールは、バケットARNではなくbucket/keyに対して評価されます。/*がないと、どのステートメントも一致せず、IAMは暗黙的な拒否を返します。これは、“バケット"が許可されているように見えてもGetObjectで予期せぬ403エラーが発生する原因となります。
明示的なDenyの後にAllowを追加する: IAMの評価は順序に依存しません。一致するDenyがあれば、即座に拒否と評価されます。解決策は、許可ステートメントを追加するのではなく、(Condition、NotPrincipal、またはNotResourceを介して)拒否のスコープを狭めることです。
OACや制限的なバケットポリシーがないCloudFront: S3オリジンURLが直接アクセス可能なままになり、署名付きURL、WAFルール、地理的制限がバイパスされてしまいます。常にオリジンバケットでBPA（パブリックアクセスブロック）を有効にし、AWS:SourceArnを介してs3:GetObjectをCloudFrontサービスプリンシパルに制限してください。
既存バケットでオブジェクトロックを有効にできるという思い込み: オブジェクトロックはバケット作成時に設定する必要があります。後から適用するには、オブジェクトロックを有効にした新しいバケットを作成し、データを移行する必要があります。
ガバナンスモードとコンプライアンスモードの混同: ガバナンスモードでは、特権ユーザーが保持設定を削除するのを防げません。ルートアカウントでさえもブロックできるのはコンプライアンスモードだけです。

実践的な問題：ユースケースシナリオ

シナリオ: Meridian Financial社は、顧客の明細書、取引ログ、長期的なコンプライアンスアーカイブを、2つのAWSリージョンにまたがる複数のS3バケットに保存しています。同社の環境では、顧客ポータルにCloudFrontを使用し、クロスアカウントでのロギングや、規制上の保持要件のためにアーカイブストレージクラスへの自動ライフサイクル移行を行っています。

課題: 最近の内部レビューで、PIIを公開してしまう一貫性のないポリシーを持つバケットがいくつか発見されました。また、アーカイブされたレコードに不変の保持設定がなく、アカウントやリージョンをまたいで機密オブジェクトがどこにあるかを発見するための一元的な方法もありませんでした。

推奨アプローチ:

アカウントレベルとバケットレベルでS3パブリックアクセスブロックを有効にし、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オブジェクトロックをコンプライアンスモードで設定し、オブジェクトロックのメタデータを保持するレプリケーションルールでクロスリージョンレプリケーション (CRR) を有効にして、レプリケートされたオブジェクトがDRリージョンでも不変性を維持するようにします。
S3ライフサイクルルールを作成して、古くなったオブジェクトをS3 Glacierストレージクラスに移行させ、許容される保持期間に合わせてオブジェクトの有効期限を設定します。法的に不変である必要があるアーカイブについては、Amazon S3 Glacierボールトに配置し、Glacierボールトロックポリシーを適用して書き込み一度の保持を強制します。
複数のアカウントにAmazon MacieをデプロイしてPIIを検出し分類します。S3インベントリを有効にし、Amazon Athenaで検出結果をクエリして調査クエリを実行します。そして、自動修復（Lambda/Step Functions）をトリガーして、機密オブジェクトにタグ付け、隔離、またはロックされ暗号化されたバケットへの移動を行います。

論理的根拠: この多層的なアプローチは、最小権限と暗号化を強制し、コンプライアンスのための不変の保持とクロスリージョンでの耐久性を提供します。また、Macie/Athenaを使用して一元的な検出と自動修復を行い、データ保護とライフサイクル管理に関するAWSのベストプラクティスに沿ったものとなっています。

Amazon Macie: 自動検出、分類ジョブ、許可リスト

Amazon Macieは、機械学習とパターンマッチングを使用して、Amazon S3に保存されている機密データ（個人を特定できる情報 (PII)、ペイメントカード番号 (PAN)、認証情報、カスタムの正規表現で定義されたデータ型など）を検出するマネージド型のデータセキュリティサービスです。Macieは、しばしば混同されがちな2つの補完的なモードで動作します。

機密データの自動検出は、アカウント内のすべてのバケット（またはMacieがセキュリティアカウントに委任されている場合は組織全体）のオブジェクトをサンプリングする、低コストで継続的に実行されるプロセスです。これにより、バケットごとの機密性スコアとインベントリが構築されます。これは、何千ものバケットがあり、機密データがどこにあるかまだわからない場合の正しい出発点です。なぜなら、すべてのオブジェクトをスキャンするのではなくサンプリングすることで、コストと管理オーバーヘッドを最小限に抑えるからです。

分類ジョブ（機密データ検出ジョブ）は、特定のバケットを対象とした1回限りまたはスケジュールされた詳細なスキャンです。自動検出によってバケットに機密データが含まれているとフラグが立てられたら、そのバケットをスコープとする分類ジョブを作成して網羅的な分析を行います。したがって、標準的なパターンは、組織全体で自動検出を有効にし、その後、フラグが立てられたバケットに対してのみ分類ジョブでフォローアップすることです。

許可リストは、既知の良性の一致を抑制するためのメカニズムです。データレイクに合成テストPAN（例えば、よく知られた4111 1111 1111 1111のテストカード範囲）が含まれている場合、Macieはそのすべての出現箇所にフラグを立てます。データを書き換えたり移動させたりするのは、コストがかかり破壊的です。正しいアプローチは、Macieの許可リスト（完全一致する値の平文リストまたは正規表現）を定義し、それを分類ジョブと自動検出設定に関連付けることです。許可リストに一致するものは検出結果から除外され、本物のPANは引き続きアラートをトリガーします。

実践的な問題：ユースケースシナリオ

シナリオ: Meridian Financialは、数百ものS3バケットにトランザクションログ、顧客文書、S3 Glacierに移動された長期アーカイブを保存する、マルチアカウントのAWS環境を運用しています。セキュリティチームは基本的な暗号化とログ記録は行っていますが、アカウント全体にわたる一元的な機密データ検出や一貫した保持制御は行っていません。

課題: 最近、誤ったバケットポリシーとS3 Glacierへのライフサイクル移行の後、PII (個人を特定できる情報) を含むアーカイブされた顧客記録が公開バケットに含まれていることが発見されました。Meridianは、すべての機密データを発見し、公開状態を修復し、将来にわたってコンプライアンスに準拠したアーカイブ保持を強制する必要があります。

推奨アプローチ:

AWS Organization全体でAmazon Macieを有効化し、S3の自動検出をオンにして、Macieがバケットとオブジェクトの機密データや危険な設定を継続的に評価するようにします。
すべてのS3バケットを対象とするMacie分類ジョブを作成します。SSNや口座番号用のカスタム機密データ識別子を設定し、既知のテストデータ、ベンダーファイル、サービスアカウントを除外するための許可リストをセットアップします。
S3インベントリを使用してS3 Glacier内のオブジェクトを列挙し、S3バッチオペレーションを実行して、インベントリによって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は、すべての検出結果をaws.macieソースでAmazon EventBridgeに発行します。これにより、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) を組み合わせる必要があります。

2つのIAM条件キーにより、組織境界の強制が正確になります。

aws:ResourceOrgID: アクセスされているリソースを所有するOrganizationのID。IDポリシー/SCPで使用され、プリンシパルが自組織外のリソースにアクセスするのを拒否します。
aws:PrincipalOrgID: 呼び出し元プリンシパルのOrganizationの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/"
      }
    }
  }]
}

これを、aws:ResourceOrgIDが自組織と一致しないリソースに対するs3:DeleteObject*を拒否するSCPと組み合わせることで、バケットポリシーが誤って緩和された場合でも、組織をまたいだデータ持ち出しや削除が不可能になります。

S3オブジェクトロック：コンプライアンスモードとバージョニング

オブジェクトロックは、個々のオブジェクトバージョンに対してWORM (Write-Once-Read-Many) セマンティクスを強制します。これには、バケットでS3バージョニングが有効になっている必要があります（バージョニングなしのオブジェクトロックは不可能です。ロックはキーではなく特定のバージョン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ボールトロック：ロック完了前のポリシーエラーの修正

S3 Glacierのボールトロックは、不変のボールトアクセスポリシーを強制します。このプロセスには2つのAPIコールがあります。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は進行中のロックをコストなしでキャンセルし、修正したポリシーで再開できるようにします。代替の「修正」方法、例えばボールトを削除して再作成する（これには10TBの全アーカイブを削除して再アップロードする必要があり、取り出し料金と転送料金が発生します）ことや、ロックが完了するのを待ってから回避策を講じることは、無駄が多いか、または不可能です。一度complete-vault-lockが実行されると、ポリシーは永久に不変になります。中止（abort）は進行中の期間中にのみ有効です。

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を閲覧 →

Amazon SCS-C02: データ保護とS3 — 学習ガイド

S3バケットポリシー、リソースARN、明示的なDeny

ライフサイクルルール、オブジェクトの有効期限、Vault Lock

パブリックアクセスブロックとCloudFront OAC

S3オブジェクトロックとクロスリージョンレプリケーション

MacieとAthenaによる検出と調査

よくある落とし穴とその根本原因

実践的な問題：ユースケースシナリオ

Amazon Macie: 自動検出、分類ジョブ、許可リスト

実践的な問題：ユースケースシナリオ

Macieの検出結果とEventBridgeの統合

組織境界のためのバケットポリシー条件

S3オブジェクトロック：コンプライアンスモードとバージョニング

S3 Glacierボールトロック：ロック完了前のポリシーエラーの修正

関連する注意点：DNSSECの信頼の連鎖

Pass the whole exam — not just this question

Related guides

1つのサブスクリプション。すべての試験。