Amazon SAA-C03: セキュリティ、IAM、KMS、ガバナンス — 学習ガイド

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

こちらの一部です： AWS SAA-C03 — 完全学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

ID基盤: ユーザー、ルート、グループ、ロール

Identity and Access Managementは、すべてのワークロードが通過するコントロールプレーンであり、その統治原則は最小権限です。つまり、必要なものだけを、必要な期間だけ許可し、静的なシークレットを保持するIDよりも、短期的な認証情報を生成するIDを優先します。

ルートユーザーはアカウントを所有し、無制限の権限を持ち、IAMポリシーやSCPによって制約することはできません。そのため、環境内で最も機密性の高い認証情報であり、非常時用として扱うべきです。新しいアカウントでは、ルートにハードウェアまたは仮想MFAデバイスを有効にし、長くユニークなパスワードを設定し、過去のルートアクセスキーを削除し、復旧が可能になるように代替の請求/運用/セキュリティ連絡先を登録します。初期設定（IAM管理者IDの作成、請求情報の設定、アカウントエイリアスの設定）の後は、AWSが明示的に要求する限られたタスク（アカウントの解約、アカウント名の変更、削除されたIAM権限の復元、MFA削除の有効化、および少数のS3/CloudFrontのルート署名操作）を除き、ルートは再び使用されません。日常業務でルートを使用するのは間違いです。なぜなら、ポリシーでスコープを制限できず、共有された場合にCloudTrailでの追跡が困難であり、一度侵害されると取り消し不可能なコントロールを奪われるからです。

人間の日常的なアクセスは、最小権限のポリシーでスコープが定められたIAM IDを介して行われます。マネージドポリシーは個々のユーザーではなくグループにアタッチします。AdministratorAccessがアタッチされたAdministratorsグループを作成し、そこに名前付きユーザーを配置することで、変更点が一つに集約され、すべてのユーザーに同じポリシーを貼り付けるというアンチパターンを回避できます。リソースは*ではなく、明示的なARNでスコープを定めます。

ロールは全く異なる目的を果たします。ロールはプリンシパル（サービス、EC2インスタンス、Lambda関数、フェデレーションユーザー、クロスアカウントの呼び出し元）によって引き受けられ、自動的にローテーションされる一時的なSTS認証情報を生成します。これらの認証情報はGitコミットで漏洩することはなく、手動でローテーションされるまで永続するのではなく数分から数時間で失効するため、ロールは人間以外のあらゆるものにとってデフォルトのIDとなります。

1つのロールに2つのポリシー: 許可と信頼

すべてのロールは2つの独立したドキュメントによって管理されており、どちらか一方を忘れることは典型的な失敗パターンです。

許可ポリシー（アイデンティティベース）は、ロールが引き受けられた後に何ができるかを宣言します。信頼ポリシー（リソースベース、ロール自体にアタッチ）は、誰がそのロールを引き受けられるかを宣言します。ロールにAmazonS3ReadOnlyAccessをアタッチしても、どのプリンシパルもそのロールに対してsts:AssumeRoleを呼び出すことが許可されていなければ何の意味もありません。逆に、許可ポリシーのない寛容な信頼ポリシーは、引き受けることはできるが何も有用なことをしないロールを生成します。

Lambdaの実行ロールは、サービスプリンシパルのパターンを示しています。呼び出し元はアカウント所有者ではなく、サービス自体です。

AssumeRolePolicyDocument:              # trust policy
  Version: "2012-10-17"
  Statement:
    - Effect: Allow
      Principal: { Service: lambda.amazonaws.com }
      Action: sts:AssumeRole
Policies:                              # permissions
  - PolicyName: ReadOrders
    PolicyDocument:
      Statement:
        - Effect: Allow
          Action: dynamodb:GetItem
          Resource: arn:aws:dynamodb:*:*:table/Orders

ワークロードID: インスタンスプロファイル、タスクロール、IRSA、Roles Anywhere

テンプレート、環境変数、またはラップトップ上に存在するすべての認証情報は、将来の侵害の元です。標準的なAWSのパターンでは、静的なアクセスキーを、ロールを通じて配信される短命で自動的にローテーションされる認証情報に置き換えます。

EC2の場合、その配信メカニズムはインスタンスプロファイルです。これはIAMロールをインスタンスにバインドする薄いコンテナで、Instance Metadata Service (IMDSv2)がSDKに一時的な認証情報を提供できるようにします。デフォルトの認証情報プロバイダーチェーンは設定なしでこれらを見つけるため、boto3.client('s3')はそのまま機能し、アプリケーションコードが認証情報を目にすることはありません。SSRFベースの認証情報漏洩を防ぐために、IMDSv2 (HttpTokens: required)を強制すべきです。認証情報は約6時間ごとにローテーションされ、失効は簡単なロールの編集で行えます。

AppRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Effect: Allow
          Principal: { Service: ec2.amazonaws.com }
          Action: sts:AssumeRole
    Policies:
      - PolicyName: S3DocAccess
        PolicyDocument:
          Statement:
            - Effect: Allow
              Action: [s3:GetObject, s3:PutObject]
              Resource: arn:aws:s3:::docs-bucket/*
AppInstanceProfile:
  Type: AWS::IAM::InstanceProfile
  Properties:
    Roles: [!Ref AppRole]

ECSにおける類似の仕組みはタスクロール、Lambdaでは実行ロール、EKSポッドではIRSA (IAM Roles for Service Accounts)またはEKS Pod Identityです。いずれの場合も、AWS自体がロールに対して認証情報を仲介し、ワークロードが長期間有効なシークレットを目にすることはありません。

AMI、ユーザーデータスクリプト、または.envファイルにアクセスキーを埋め込むことは、3つの具体的な理由で間違いです。キーは自動的にローテーションされず、ソースVPCエンドポイントのようなセッションコンテキストにスコープを限定できず、インスタンスが侵害されたりAMIが誤って共有されたりした場合に認証情報が恒久的に漏洩します。

AWSの外部（オンプレミスサーバー、他のクラウド、CIランナー）にあるワークロードが、埋め込みキーなしで一時的なAWS認証情報を必要とする場合、IAM Roles AnywhereはプライベートCA（AWS Private CAまたは独自のもの）からのX.509証明書をトラストアンカーとして使用します。ワークロードはクライアント証明書を提示し、短期的なSTS認証情報を受け取ります。

aws_signing_helper credential-process \
  --certificate /etc/pki/client.pem \
  --private-key /etc/pki/client.key \
  --trust-anchor-arn arn:aws:rolesanywhere:...:trust-anchor/... \
  --profile-arn arn:aws:rolesanywhere:...:profile/... \
  --role-arn arn:aws:iam::111122223333:role/OnPremWorkload

これは、インスタンスロールやSecrets ManagerがAWS内部で解決するのと同じアンチパターンを解消します。

大規模なヒューマンアクセス: Identity Center、SAML、Directory Service

アカウントごとにIAMユーザーをプロビジョニングするのは、どんな規模であれ管理不能です。AWS IAM Identity Center（AWS SSOの後継）は、従業員アクセスのための推奨されるフロントドアです。これは、Organization内のすべてのアカウントにフェデレーションし、許可セット（IdPグループにマッピングされたテンプレート化されたIAMロール）を介して一時的なロールベースのセッションを発行する単一のディレクトリです。ユーザーはIdentity Centerポータルで一度認証し、その後、割り当てられた任意のアカウントに許可セットを引き受けます。

Identity Centerは、SAML 2.0およびSCIMを介して外部IdP（Okta、Entra ID/Azure AD、Google Workspace、ADFS）と統合し、自動化された入社/異動/退職のフローを実現します。また、オンプレミスのActive DirectoryとはAWS Directory Service AD Connector（プロキシ）またはAWS Managed Microsoft AD（AWS内の完全なレプリカ）を通じて統合します。未認証またはサードパーティ認証のユーザーからAWSを呼び出す必要があるモバイルアプリやWebアプリの場合、Amazon Cognitoが外部IDを一時的なSTS認証情報と交換し、ここでも埋め込まれた長期間有効なキーを回避します。

クロスアカウントアクセス

クロスアカウントアクセスは、共有ユーザーではなくロールで表現され、両アカウントでの合意が必要です。ターゲットアカウント（B）は、信頼ポリシーでアカウントA（またはその中の特定のプリンシパル）を指定したロールを作成し、アカウントAの呼び出し元も、そのロールのARNを対象としたsts:AssumeRole権限を持っている必要があります。どちらか一方だけでは不十分です。これにより、短期的な認証情報が生成され、両方のアカウントに明確なCloudTrailの監査証跡が残ります。

サードパーティ（SaaSベンダーなど）が引き受け元のプリンシパルである場合は、混乱した代理人問題を回避するためにExternalId条件を追加し、MFAを要求することを検討してください。

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "a1b2c3-unique-token" },
    "Bool": { "aws:MultiFactorAuthPresent": "true" }
  }
}

サービス間のクロスアカウント呼び出しでは、リソースポリシーがその役割を果たします。アカウントAのSNSトピックがアカウントBのLambdaを呼び出せるようにするには、次のようにします。

aws lambda add-permission \
  --function-name ProcessNotification \
  --statement-id AllowSNSInvoke \
  --action lambda:InvokeFunction \
  --principal sns.amazonaws.com \
  --source-arn arn:aws:sns:us-east-1:111111111111:my-topic

--principal sns.amazonaws.comはサービスプリンシパル（SNS自体がLambdaを呼び出す）であり、--source-arnは信頼の範囲を特定のトピックに限定し、混乱した代理人問題を防止します。

OrganizationsをまたいだS3共有において、バケットポリシーにすべてのアカウントARNを列挙するというナイーブなアプローチは、スケールせず、新しいアカウントが追加されるたびに破綻します。正しいパターンはaws:PrincipalOrgIDを使用することです。

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/*",
  "Condition": {
    "StringEquals": { "aws:PrincipalOrgID": "o-abcd1234ef" }
  }
}

その組織内のどのアカウントのどのプリンシパルも許可され、それ以外の誰もが拒否されます。条件なしのPrincipal: "*"はパブリックバケットになることに注意してください。スコープを制約しているのは条件キーです。アイデンティティ側の設定も依然として重要です。メンバーアカウントのユーザーは、（アカウントのルートユーザーでない限り）自身のIAMポリシーによってs3:GetObjectが付与されている必要もあります。なぜなら、クロスアカウントアクセスでは呼び出しを許可するために両サイドでの許可が必要だからです。

特にS3では、2023年以降、デフォルトのオブジェクト所有者設定であるバケット所有者強制によりACLが完全に無効化され、バケットポリシーがバケットの唯一の認可メカニズムになりました。過去に他のアカウントによってオブジェクトがアップロードされていた場合、過去のオブジェクトACLやbucket-owner-full-controlの標準ACLがまだ影響している可能性があります。

Organizationsとサービスコントロールポリシー

AWS Organizationsは、アカウントをOU（組織単位）のツリー構造に集約し、そのルートに管理アカウントを置きます。**サービスコントロールポリシー（SCP）**は、ルート、OU、または個々のアカウントにアタッチされるガードレールです。SCPはアカウント内のすべてのIAMユーザーとロール（アカウントのルートユーザーを含む）に適用されますが、管理アカウント自体には適用されません。これが、管理アカウントでワークロードを実行すべきではない理由です。

重要なメンタルモデルは、SCPは決してアクセス許可を付与しないということです。SCPは、アカウントで許可されるアクションの最大範囲を定義します。あるアクションが許可されるのは、アイデンティティポリシーまたはリソースポリシーによって許可され、かつ、そのアカウントのパス（ルートやOU）にあるどのSCPによってもブロックされていない場合のみです。例えば、開発者がAdministratorAccessを持っていても、SCPがap-southeast-2以外でのec2:RunInstancesを拒否している場合、us-east-1での起動は失敗します。逆に、s3:*を許可するSCP自体は何もしません。ユーザーは依然としてs3:*を許可するIAMポリシーを必要とします。SCPはIAMがすでに許可したものをフィルタリングするものであり、上限（天井）であって下限（床）ではありません。

典型的なSCPの用途には、リージョンのロックダウン、CloudTrailやGuardDutyの無効化の禁止、緊急時用のロール（break-glass role）以外によるKMSキーの削除の禁止、暗号化の強制などがあります。起動時にEBSの暗号化を強制するには、2つのメカニズムを組み合わせます。リージョンでデフォルトでのEBS暗号化を有効にし（ユーザーがスクリプトを変更しないようにするためのリージョンごとのアカウント設定）、さらに監査可能なガードレールとしてSCPを追加します。

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:volume/*",
  "Condition": { "Bool": { "ec2:Encrypted": "false" } }
}

SCPはアカウント全体に適用されるため、メンバーアカウントの侵害された管理者がバイパスすることはできません。タグポリシーは、標準化されたタグキーと大文字小文字の区別（例：costcenterではなくCostCenter）を強制し、コスト配分やABACが確実に機能するようにします。Organizationsは委任管理者もサポートしています。管理アカウントからセキュリティサービスを実行する代わりに、メンバーアカウント（「セキュリティ」や「監査」アカウントなど）をGuardDuty、Security Hub、IAM Access Analyzer、またはConfigの管理者として委任することで、職務の分離を維持します。

KMS: キー、キーポリシー、および所有権モデル

KMSは、所有権と管理によってキーマテリアルを区別します。

CMKはキーポリシーによって管理されます。これはキーにアタッチされるリソースベースのポリシーです。他のほとんどのAWSリソースとは異なり、キーポリシーがまずIAMに権限を委任しない限り、IAMポリシーだけではKMSキーへのアクセスを許可できません：

{
  "Sid": "EnableIAMPolicies",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

このステートメントがないと、どのIAMポリシーでもキーは使用可能になりません。キーポリシーと呼び出し元のIAMポリシーの両方がその操作を許可する必要があります。これが、最も頻繁に発生する暗号化のエラーです。IAMポリシーでkms:Decryptを許可することは必要条件ですが、十分条件ではありません。キーポリシーがIAMに権限を委任していないか、プリンシパルを指定していない場合、管理者であっても復号はAccessDeniedで失敗します。

ユーザーに代わってKMSを使用するサービス（EBS、S3、RDS、Lambdaなど）の場合、呼び出し元のロールには通常kms:GenerateDataKey、kms:Decrypt、そして多くの場合kms:CreateGrantが必要です。EKSのマネージドノードグループでEBSボリュームをCMKで暗号化する場合、Auto Scalingのサービスにリンクされたロールがキーポリシーにkms:CreateGrant付きで記載されている必要があります。さもないと、インスタンスの起動がサイレントに失敗します。

カスタマーマネージドCMKのローテーションは明示的に有効化する必要があります。多くの実務者は、すべてのKMSキーが自動的にローテーションされると誤解しています：

aws kms enable-key-rotation --key-id alias/my-cmk
aws kms get-key-rotation-status --key-id alias/my-cmk

ローテーション後も同じキーIDとエイリアスは維持されます。バッキングマテリアルは変更されますが、KMSは既存の暗号文を復号するために古いマテリアルを保持し、新しい書き込みには新しいマテリアルを使用するため、過去の暗号文は引き続き復号可能です。インポートされたマテリアルは自動ローテーションされません。KMSは7～30日の削除保留期間を強制します。これをCloudTrailでScheduleKeyDeletionまたはDisableKeyに一致するEventBridgeルールと組み合わせ、SNSトピックをターゲットにすることで、サーバーレスでポーリング不要のアラートパターンを構築できます：

{
  "source": ["aws.kms"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": { "eventName": ["ScheduleKeyDeletion", "DisableKey"] }
}

外部キーストアは、規制当局がキーマテリアルを顧客が管理するHSM内に物理的に配置することを要求する場合に、このモデルを拡張します。KMSは暗号化操作を、オンプレミスのHSMと通信するXKSプロキシに転送します。HSMがオフラインの場合、復号は失敗し、可用性は顧客の責任となります。

マルチリージョンキー（MRK）は、リージョン間で同じキーIDとマテリアルを共有するため、us-east-1で生成された暗号文をeu-west-1で直接復号できます。これは、DynamoDBグローバルテーブル、SSE-KMSを使用したS3クロスリージョンレプリケーション、およびスタンバイリージョンが暗号化されたバックアップを読み取る必要があるDRにとって正しいパターンです。標準の単一リージョンキーでは、レプリケーション時に復号してから再暗号化する必要があります。

アカウント間の暗号化リソース共有

暗号化されたAMIとEBSスナップショットの共有は、アカウント間の失敗モードとして最も一般的なものの1つです。なぜなら、4つの協調したアクションが必要だからです。(1) カスタマーマネージドCMKを使用する（AWSマネージドキーは共有不可）、(2) 宛先アカウントをプリンシパルとしてキーポリシーにkms:Decrypt、kms:DescribeKey、kms:CreateGrant、kms:ReEncrypt*とともに追加する、(3) AMIまたはスナップショットの起動/共有権限を変更してそのアカウントを含める、(4) 宛先アカウントのIAMプリンシパルもこれらのKMSアクションを持っていることを確認する。ステップ2を省略しても共有操作は成功したように見えますが、受信側のアカウントは復号できません。AMIの共有だけで十分だと考えるのは、典型的な落とし穴です。

S3サーバー側の暗号化モード

要件が年次自動ローテーション、CloudTrailでの監査可能性、そして キーコストの最小化を指定している場合、答えはAWSマネージドのaws/s3キーを使用したSSE-KMSです。これは無料で年次ローテーションされ、すべてのGenerateDataKey/Decrypt呼び出しがログに記録されます。SSE-S3はより安価ですが、キー使用の追跡記録は残りません。カスタマーマネージドCMKは月額$1が追加され、ローテーションを有効にした場合にのみローテーションされます。

SSE-S3とSSE-KMSを混同することは、PHI（保護医療情報）などを扱う際の典型的な落とし穴です。SSE-S3はデータを暗号化しますが、キーポリシーもCloudTrailでの可視性もなく、コンプライアンスチームがキーを管理する方法も提供しません。そのため、「管理」「制御」「監査」「アクセス権の取り消し」といった要件を満たしません。逆に、要件が「最小限の管理で保管時に暗号化する」ことだけである場合にSSE-KMSを選択するのは、過剰設計です。

SSE-KMSを有効にすること自体は、不正な読み取りを防ぐわけではありません。バケットポリシーがs3:GetObjectを許可し、キーポリシーが同じプリンシパルにkms:Decryptを許可している場合、オブジェクトは読み取り可能です。保管時の暗号化は、物理メディアの漏洩から防御し、キーポリシーを介して2つ目の認可チェックを追加するものです。適切にスコープが設定されたバケットポリシー、IAMポリシー、VPCエンドポイントポリシー、およびaws:PrincipalOrgID条件の代わりにはなりません。

S3での暗号化とTLSの強制

バケットを「デフォルトで暗号化」するだけでは不十分です。クライアントは暗号化ヘッダーを省略したり、上書きしたりできるからです。2つのガードレールを重ねる必要があります。デフォルトのバケット暗号化（クライアントがヘッダーを省略した場合に補完する）と、必要なヘッダーなしのPutObjectを拒否する拒否ベースのバケットポリシー、さらに非TLSアクセスを拒否するステートメントです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnEncryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::phi-bucket/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    },
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::phi-bucket", "arn:aws:s3:::phi-bucket/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

aws:SecureTransport条件はHTTPSを強制し、「転送中の暗号化」を満たします。コンプライアンスチームが所有するCMKを使用したSSE-KMSと組み合わせることで、これがPHI（保護医療情報）を保存するための標準的なパターンとなります。

転送中の暗号化と保管時の暗号化

保管時の暗号化（KMSで暗号化されたEBS、RDSストレージ、S3オブジェクト）と転送中の暗号化（通信経路上でのTLS）は、ディスクの盗難とネットワークの盗聴という異なる脅威に対処する独立したコントロールです。RDSインスタンスでKMSを有効にすると、基盤となるストレージは保護されますが、クライアントとデータベース間のセッションには何の効果もありません。このセッションはデフォルトでは暗号化されていない場合があります。RDS MySQLの場合、転送中の保護には、RDS CAバンドルをダウンロードし、パラメータグループでrequire_secure_transport=ONを設定し、クライアントを--ssl-ca=rds-combined-ca-bundle.pemで接続する必要があります。「保管時の暗号化が有効になっている」だけで十分だと見なすことは、監査でよくある不合格事項です。

Secrets ManagerとParameter Store

設定ファイル、環境変数、またはCloudFormationパラメータ内の静的なデータベースパスワードは、認証情報漏洩の主要な経路です。AWS Secrets Managerは、シークレットをKMSで暗号化して保存し、IAMで制御されたGetSecretValueを通じて公開し、そして重要なことに、Lambdaローテーション関数を介して自動的にローテーションします。RDS、Aurora、Redshift、DocumentDBについては、AWSがマネージド型のローテーションLambdaを提供しています。これはデータベースに接続し、新しいパスワードを生成し、シークレットとDBユーザーの両方をアトミックに更新し、シングルユーザーまたはマルチユーザー戦略をサポートします。他のシステムについては、createSecret、setSecret、testSecret、finishSecretという4段階のライフサイクルを実装するLambdaを作成します。

import boto3, json
secret = json.loads(
    boto3.client('secretsmanager')
         .get_secret_value(SecretId='prod/aurora/app')['SecretString'])
conn = pymysql.connect(host=secret['host'],
                       user=secret['username'],
                       password=secret['password'])

アプリケーションは（AWS SDKのキャッシュライブラリを使用して）値を短時間キャッシュし、認証失敗時に再接続します。ローテーションは透過的に行われ、パスワードを変更するためにデプロイは不要です。

SSM Parameter Store SecureStringは、ローテーションが不要でコストが最優先される場合の代替手段です。

SecureStringパラメータを取得するには、キーに対するssm:GetParameterとkms:Decryptの両方が必要です。KMSのアクセス許可を忘れることは、最も一般的な設定ミスの1つです。IAMポリシーは正しく見えても、APIコールは復号時に失敗します。

EC2、ECS、EKS、Lambdaでは、コードはIAMロールを引き受け、GetSecretValueまたはGetParameterを呼び出すべきです。ディスク上に長期的な認証情報を置くべきではありません。IAMユーザーのアクセスキーをアプリケーションコードに直接埋め込むことは、たとえ暗号化されていても、最小権限の原則に違反し、ローテーションを複雑にします。

監査とフォレンジックツール

CloudTrailは、すべてのAWS APIコール（誰が、何を、いつ、どこから）を記録します。管理アカウントから有効化された組織の証跡は、全アカウントのイベントを単一のS3バケットに集約します。理想的には、S3オブジェクトロックとMFA削除が設定された、ロックダウンされたセキュリティアカウントに保存します。これにより、不変のフォレンジック（証拠保全）タイムラインが提供されます。どのプリンシパルがボリュームを削除したか、どのロールがセキュリティグループを変更したか、どのアクセスキーがUTC 03:17にec2:RunInstancesを呼び出したか、といった情報です。これを、CloudWatch Logsとアラーム（ルートログイン、IAMポリシーの変更など）、および特定時点のリソース状態とコンフォーマンスパックのためのAWS Configで補完します。cloudtrail:StopLoggingとcloudtrail:DeleteTrailを拒否するSCPで、改ざんを防止します。

S3バケットのMFA削除は、ルートユーザーがオブジェクトのバージョンを完全に削除したり、バージョニングを無効にしたりする際に、MFAトークンの提示を強制します。これはCLIを介してルートユーザーのみが有効にでき、ランサムウェアや内部関係者による削除に対する強力な保護を提供します。

Amazon Macieは、マネージドMLを使用してS3内のPII（個人識別情報）、PHI、認証情報、財務データを発見し、重要度でランク付けされた検出結果を生成します。これは発見ツールであり、暗号化ツールではありません。

脅威検出: GuardDuty, Security Hub, Detective

Amazon GuardDutyは、VPCフローログ、DNSログ、CloudTrailの管理イベントとデータイベントを継続的に分析します。また、EKS監査ログ、S3データイベント、EBSマルウェアスキャン、Lambdaネットワークアクティビティ、およびRDSログインイベントのための専用の保護プランがあります。GuardDutyのRDS Protectionは、AuroraおよびRDSに対する異常な認証試行やブルートフォース攻撃を表面化させます。これは、L4レベルでは接続が正当であるため、セキュリティグループでは捕捉できない振る舞いです。検出結果は、EventBridge、Security Hub、Detectiveのダッシュボードに送られます。

セキュリティグループはL3–L4でのみ動作します。ポート443で0.0.0.0/0を許可するグループは、SQLインジェクションのペイロードを転送する際にその役割を果たしています。それを阻止するためにこそWAFが存在するのです。多層防御とは、セキュリティグループ、WAF、Shield、GuardDutyを組み合わせることを意味し、それぞれが他のツールでは見えないレイヤーをカバーします。

DDoS: Shield StandardとAdvanced

AWS Shield Standardは自動かつ無料で、一般的なL3/L4攻撃（SYNフラッド、リフレクション）からすべてのアカウントを防御します。可視性はなく、カスタムの緩和策もなく、人による介入パスもないまま、サイレントに実行されます。

AWS Shield Advanced（組織ごとに月額3,000ドル、加えてデータ転送料金）は、シナリオでプロアクティブなエンゲージメント、専門の対応、DDoSに起因するスケーリングに対するコスト保護、またはほぼリアルタイムの攻撃可視性が言及されている場合に必要です。CloudFront、Global Accelerator、ALB、CLB、Route 53、Elastic IPをカバーし、IAMロールを介して事前承認された**Shield Response Team (SRT)**への24時間365日のアクセスを提供します。SRTは、アクティブな攻撃中にお客様に代わってWAFルールを作成します。ALBとRoute 53の背後にある設計で、マネージドな検出と人的な対応の両方が必要な場合、Shield Standardだけでは不十分です。これが頻出のひっかけ問題です。Advancedはまた、攻撃によってトリガーされたスケーリングに対するコスト保護も提供します。「最小限の実装労力」と記載があり、アーキテクチャにすでにGlobal AcceleratorやALBが含まれている場合、答えは通常、カスタムのLambda@Edgeを構築したりCDNを移行したりすることではなく、Shield Advancedを有効にしてAWSマネージドルールグループをアタッチすることです。

アプリケーションレイヤーの保護: AWS WAF

AWS WAFは、CloudFront、Application Load Balancer、API Gateway、AppSync、App Runner、Cognitoユーザープールにアタッチします。Network Load Balancerを直接保護することはできません（前面にCloudFrontを配置します）。L7トラフィックを検査し、SQLインジェクション、XSS、サイズ制約、地理的ブロッキング、IPレピュテーション、レートリミットのためのルールを適用します。AWSマネージドルールは、正規表現を記述することなく、AWSManagedRulesCommonRuleSetやAWSManagedRulesSQLiRuleSetのようなキュレートされたグループを提供します。

レートベースのルールは、HTTPフラッドやクレデンシャルスタッフィングに対する主要な防御策です。送信元IP（または転送されたヘッダー）ごとに5分間のウィンドウあたりのリクエスト数をカウントし、違反者を自動的にブロックします。

Rules:
  - Name: RateLimitPerIP
    Priority: 1
    Statement:
      RateBasedStatement:
        Limit: 2000        # per 5-min window per IP
        AggregateKeyType: IP
    Action: { Block: {} }
    VisibilityConfig:
      CloudWatchMetricsEnabled: true
      MetricName: RateLimitPerIP
      SampledRequestsEnabled: true

WAFはDDoSサービスではありません。それはShieldの役割です。WAFは、リソースポリシー（非TLSを拒否するS3バケットポリシー、到達可能なバケットを制限するVPCエンドポイントポリシー）やネットワーク制御（セキュリティグループ、NACL）を補完します。いずれか単一のレイヤーでの設定ミスがデータを公開してはなりません。

ネットワークの分離: セキュリティグループ、NACL、Network Firewall

VPC内では、防御は階層化されています。

• セキュリティグループはステートフルで、ENIに適用され、許可のみで、すべてのルールをまとめて評価します。戻りのトラフィックは自動的に許可されるため、エフェメラルポートを明示的に開ける必要はありません。
• ネットワークACLはステートレスで、サブネットに適用され、許可と拒否の両方をサポートし、番号順に評価します。ステートレスであるため、インバウンドの443を許可した場合、レスポンスのためにアウトバウンドのエフェメラルポート1024–65535も許可する必要があります。これを忘れると、すべての返信が微妙な形でドロップされます。セキュリティグループにはこの問題はありません。
• AWS Network Firewallは、ディープパケットインスペクション、Suricata互換のIPSルール、ドメインベースの出力フィルタリングを提供し、サブネットとIGW/TGWの間に配置されて一元的な検査を行います。

セキュリティグループだけで十分だと仮定することは、サブネットレベルの脅威や影響範囲の制御を無視しています。NACLだけで十分だと仮定することは、そのステートレス性と粗さを無視しています。

ひっかけ問題カタログ

信頼ポリシーの忘れ。 ロールのアクセス許可ポリシーは能力を付与しますが、引き受け可能性を付与するのは信頼ポリシーだけです。クロスアカウントやサービス間アクセスが機能するためには両方が開いている必要があり、アイデンティティポリシーがどれだけ寛容であっても、呼び出し元はsts:AssumeRoleでAccessDeniedを受け取ります。

キーポリシーと一致しないIAMポリシー。 IAMでのkms:Decryptは必要ですが、十分ではありません。キーポリシーは、プリンシパルを指名するか、Principal: {"AWS": "arn:aws:iam::ACCOUNT:root"}でIAMに委任する必要があります。AMIの共有だけが行われ、キーポリシーが更新されていない場合、暗号化されたAMI/スナップショットの共有は失敗します。

SCPを許可として扱う。 SCPは上限を設定するだけで、許可はしません。Allow s3:*のSCPは、一致するアイデンティティポリシーがなければ何もしません。逆に、寛容なアイデンティティポリシーは、アカウントのパスにあるSCPのDenyによって制限されます。

KMSの自動ローテーションを前提とする。 カスタマー管理のCMKは有効にするまでローテーションしません。インポートされたキーマテリアルは決して自動ローテーションしません。

コンプライアンス管理下のデータにSSE-S3を選択する。 SSE-S3にはキーポリシーがなく、CloudTrailでの可視性もなく、失効パスもありません。キーの「管理」「制御」「監査」「失効」に言及する要件はすべて満たせません。

保管時の暗号化で十分だと考える。 保管時と転送中は独立しています。KMSを使用するRDSでも、require_secure_transport=ONとクライアントCAの検証が必要です。

バケットポリシーでアカウントを個別に指定する。 スケーリングせず、組織の変更で壊れます。aws:PrincipalOrgIDを使用してください。

アクセスキーをどこにでもハードコードする。 ユーザーデータ、.envファイル、CloudFormationパラメータ、Git内など、どこであっても常に間違いです。インスタンスプロファイル、タスクロール、実行ロール、IRSA/Pod Identity、またはRoles Anywhereを使用してください。

日常業務やポリシーのアタッチにルートユーザーを使用する。 ルートユーザーはIAMやSCPで制約できません。ルートにポリシーを追加することは無意味です。そうする答えは、一見して間違いです。

クロスアカウントアクセスにIAMユーザーを使用する。 IAMユーザーはクロスアカウントで引き受けることはできません。ターゲットアカウントにロールを作成し、ソースアカウントのプリンシパルにそれを引き受けさせてください。

WAFの背後にNLBを配置する。 WAFはNLBにアタッチできません。L7フィルタリングが必要な場合は、NLBの前面にCloudFrontを配置してください。

NACLでエフェメラルポートのアウトバウンドが欠落している。 ステートレスなNACLは、明示的な戻りパスのルールが必要です。アウトバウンドの1024–65535が欠落していると、インバウンドの443レスポンスがすべてサイレントに失敗します。

マネージドなエンゲージメントにShield Standardを使用する。 Standardは受動的でSRTへのアクセスがありません。「プロアクティブなマネージドエンゲージメント」や「コスト保護」を満たすのはAdvancedだけです。

← アプリケーション統合、メッセージング、ストリーミング · すべてのドメイン · 管理、運用、可観測性、コスト →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →