Amazon SCS-C02: アイデンティティとアクセス管理 — 学習ガイド

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

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

ID、プリンシパル、ポリシー評価

IAMは、アイデンティティ（ユーザー、グループ、ロール）とプリンシパル（リクエストを行う認証されたエンティティ）を区別します。ユーザーは静的な認証情報を持つ長期的なエンティティです。一方、ロールは自身の認証情報を持たず、引き受けられる（assumeされる）ことで短期的なSTSトークンを生成します。グループはユーザーにポリシーをアタッチするためのコンテナです。グループがプリンシパルになることはなく、引き受けることもできません。

すべてのAPIコールは、決定論的な評価チェーンを通過します。まず、どこかに明示的なDenyがあればそれが優先され、次に組織レベルのSCPが許可し、次にアクセス許可の境界が許可し、次にセッションポリシー（もしあれば）が許可し、最後に少なくとも1つのアイデンティティベースまたはリソースベースのポリシーにAllowが含まれている必要があります。いずれかのAllowの層が欠けている場合、暗黙的なDenyとなります。これが階層化が重要である理由です。アイデンティティポリシーでs3:*を許可していても、SCPがs3:DeleteBucketを拒否したり、アクセス許可の境界がS3を完全に除外していたりすると、その許可は意味をなしません。

リソースベースのポリシー（S3バケットポリシー、KMSキーポリシー、SNSトピックポリシー、Lambda関数ポリシー）は、呼び出し元にアイデンティティポリシーがなくても、同一アカウント内であればプリンシパルに直接アクセスを許可できます。クロスアカウントアクセスの場合は、ソースアカウントのアイデンティティポリシーとターゲットアカウントのリソースポリシーの両方でアクションを許可する必要があります。

ロール、信頼ポリシー、AssumeRole

ロールには2つのポリシードキュメントがあります。信頼ポリシー（誰がそのロールを引き受けられるか）と、1つ以上のアクセス許可ポリシー（引き受けた後に何ができるか）です。信頼ポリシーは、sts:AssumeRoleアクションを使用する、ロール自体にアタッチされたリソースベースのポリシーです。信頼ポリシーが一致しない場合、呼び出し元のアイデンティティポリシーにsts:AssumeRoleが含まれていても、AssumeRoleはAccessDeniedで失敗します。

クロスアカウントでの委任の場合、信頼ポリシーは信頼するアカウント、またはそのアカウント内の特定のロール/ユーザーARNを指定し、さらにサードパーティからのアクセスにとって非常に重要なExternalIdを強制します。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-shared-secret-9271" }
    }
  }]
}

ExternalIdは混乱した使節（confused deputy）問題を防ぎます。これがないと、多くの顧客アカウントにまたがってロールを引き受けるサードパーティのSaaSプロバイダーが、誤った顧客のロールに対して操作を行うよう仕向けられる可能性があります。conditionでsts:ExternalIdを省略したり、sts:AssumeRoleの際に誤った値を渡したりすると、ロールの引き受け時にAccessDeniedが発生します。これは、監視ツールやCSPMツールなどのベンダーをオンボーディングする際によくある設定ミスです。

AWSサービス（Lambda、EC2、ECSタスクなど）の場合、信頼ポリシーはサービスプリンシパル（例: "Service": "lambda.amazonaws.com"）を指定します。S3へのアクセスが必要なLambda関数は、バケットに対するs3:GetObjectおよびs3:PutObjectを許可するアクセス許可ポリシーを持つ実行ロールを引き受けるべきです。同様に、S3バケットポリシーで、関数のロールARNをプリンシパルとして指定することもできます。単一アカウント内であれば、どちらのメカニズムも単独で機能します。

アクセス許可の境界 (Permissions Boundaries)

アクセス許可の境界は、ユーザーまたはロールにアタッチされる高度なコントロールであり、アイデンティティベースのポリシーが何を許可しているかに関わらず、そのアイデンティティが持ちうる最大のアクセス許可を制限します。有効なアクセス許可は、アイデンティティポリシーと境界の**共通部分（intersection）**になります。グループポリシーがec2:*を許可していても、境界がec2:Describe*のみを許可している場合、ユーザーはdescribe操作しかできません。

境界は、権限の委任によく使用されます。開発者が自分のアプリケーション用にIAMロールを作成することを許可しつつ、作成するすべてのロールに特定の境界を付与することを要求します。開発者向けのIAMポリシーには、iam:CreateRoleとiam:PutRolePolicyに対して"iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary"のような条件が含まれます。これにより、セルフサービスを可能にしながら、権限昇格を防ぐことができます。

よくある誤解は、グループメンバーシップや追加でアタッチされたポリシーが境界やSCPを「上書き」できるというものですが、それはできません。境界とSCPは上限（ceiling）であり、下限（floor）ではありません。

条件によるMFAの強制

MFAポリシーは2つの条件キーによって制御されます。aws:MultiFactorAuthPresent（ブール値、セッションがMFAを使用して取得された場合にtrue）とaws:MultiFactorAuthAge（数値、MFAが検証されてからの秒数）です。機密性の高いAPIに対してMFAを強制し、セッションの有効期間を制限するには、次のようになります。

{
  "Effect": "Allow",
  "Action": ["rds:DeleteDBInstance", "kms:ScheduleKeyDeletion"],
  "Resource": "*",
  "Condition": {
    "Bool":            { "aws:MultiFactorAuthPresent": "true" },
    "NumericLessThan": { "aws:MultiFactorAuthAge": "7200" }
  }
}

2時間は7,200秒です。Boolの代わりにBoolIfExistsを使用するのは、キーを持たないサービスプリンシパルからの呼び出しに対して微妙に危険です。BoolIfExistsはtrueと評価され、事実上それらの呼び出し元に対するチェックをバイパスしてしまいます。したがって、人間のユーザーによる使用を強制することが目的の場合はBoolを使用することを推奨します。

長期的なアクセスキーを使用するCLIやSDKからのリクエストにはMFAコンテキストが含まれないため、ユーザーはまずsts:GetSessionToken（--serial-numberと--token-codeを付けて）またはsts:AssumeRole（--serial-number/--token-codeを付けて）を呼び出し、MFAコンテキストを含む一時的な認証情報を取得する必要があります。これらの短期的な認証情報が、MultiFactorAuthPresent条件を満たします。

aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 7200

IAM Identity Centerとフェデレーション

IAM Identity Center (旧 AWS SSO) は、AWS Organization全体で従業員のアクセスを一元管理します。許可セットはテンプレートであり、ユーザーやグループが割り当てられると、Identity Centerはターゲットアカウント内でIAMロールとして具現化します。割り当ては、プリンシパル (Identity CenterディレクトリまたはOkta/Entra IDのような外部IdPのユーザーやグループ)、許可セット、そして1つ以上のアカウントという3つの要素を紐付けます。

許可セットには、AWS管理ポリシー、カスタマー管理ポリシー (各ターゲットアカウントに存在する必要があるため名前で参照)、インラインポリシー、およびアクセス許可の境界を含めることができます。許可セットを編集すると、Identity Centerは基盤となるロールを再プロビジョニングします。これらのロールを直接編集することはありません。

IAM Identity Center外でのSAMLフェデレーションでは、AWSはIAM SAMLプロバイダーオブジェクトに登録されたIdPメタデータに対してアサーションの署名を検証します。IdPが署名証明書をローテーションした場合、更新されたメタデータXMLをアップロードする必要があります。そうしないと、STSはInvalidIdentityToken / Response Signature Invalidを返します。aws iam update-saml-provider --saml-metadata-document file://metadata.xml --saml-provider-arn ...でメタデータを更新するのが、最もオーバーヘッドの少ない修正方法です。プロバイダーを再作成したり、信頼関係を再設定したりする必要はありません。

ルートアカウント、認証情報レポート、最小権限

ルートユーザーは削除不可能な完全なアクセス権を持ち、ブレークグラスID (緊急時用のID) として扱う必要があります。ハードウェアまたは仮想MFAデバイスを有効にし、ルートアクセスキーを削除し、日常業務には使用せず、認証情報をオフラインで保管してください。OrganizationのルートまたはOUレベルでSCPを使用して、メンバーアカウントの管理者であってもGuardDutyを無効にしたり、CloudTrailを削除したり、特定のリージョンから離脱したりすることを防ぎます。SCPは決してアクセス許可を付与しません。メンバーアカウントのIAMが付与できるものをフィルタリングするだけです。

最小権限は、直感ではなくツールによって運用化されます。IAM 認証情報レポート (aws iam generate-credential-report の後 get-credential-report) を生成して、未使用のユーザー、古くなったアクセスキー、MFAを使用していないユーザーを見つけます。IAM Access Analyzerを使用して、アカウント間でデータを公開しているリソースポリシーを特定し、CloudTrailのアクティビティから適正サイズのポリシーを生成します。最終アクセスデータ (aws iam get-service-last-accessed-details) を使用して、ロールから未使用のサービス権限を整理します。

最後に明示的に言及する価値のある罠は、IDのAllowを追加するだけで十分だと仮定することです。KMSキーポリシーがあなたのロールを指定していない場合、SCPがアクションを拒否する場合、またはアクセス許可の境界がそれを除外している場合、呼び出しはやはり失敗します。AccessDeniedのトラブルシューティングを行う際は、常にSCP、境界、IDポリシー、リソースポリシー、セッションポリシーの全てのスタックを監査してください。

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

シナリオ: Meridian Financialは、管理、本番、開発のワークロード用に3つのアカウントを持つAWS Organizationを運用しており、機密性の高い取引データと顧客データは本番アカウントにあります。現在、レガシーな長期IAMユーザー、契約社員アカウント、Okta SAML IDプロバイダーが混在しており、アカウント間でアクセス制御に一貫性がなく、ロール設定が散在しています。

課題: 最近のインシデントで、侵害された契約社員の認証情報がMFAなしでクロスアカウントロールを引き受け、アクセス許可の境界や一元化された許可セットがなかったために過剰なアクションを実行しました。Meridianは、フェデレーション、ロールの信頼を強化し、アカウント全体でMFAと最小権限を強制する必要があります。

推奨アプローチ:

Okta SAMLと統合されたAWS IAM Identity Centerを単一のフェデレーションIDプレーンとしてデプロイし、すべてのヒューマンユーザーと契約社員を長期IAMユーザーからIdentity Centerベースのアカウントに移行し、レガシーIAMユーザーのコンソール/キーを無効化します。
IAM Identity CenterでメンバーアカウントのIAMロールにマッピングされる一元化された許可セットを作成し、すべてのロールにIAMアクセス許可の境界（IAMポリシーとして定義）を実装します。これらの境界とロールテンプレートをAWS CloudFormation StackSetsを使用してアカウント全体にデプロイします。
クロスアカウントロールの信頼ポリシーを更新し、Identity CenterのプリンシパルARNからのsts:AssumeRoleのみを許可し、MFA（例：aws:MultiFactorAuthPresent）やソースアカウントの制限を要求する条件を含めます。セッションタグにID属性を付与することを要求します。
IdP（Okta）でMFAを強制し、ロールセッションでMFA条件を要求することでAWSにその強制を反映させます。AWS Organizationsでサービスコントロールポリシー（SCP）を適用して、コンソールアクセスや新しいIAMユーザーの作成を拒否します。
継続的な監視とポリシー検証のためにAWS CloudTrail、AWS Config、IAM Access Analyzerを有効にし、検出結果をCloudWatch/GuardDutyに送信して、アラートと自動修復ワークフローを構築します。

論理的根拠: IAM Identity Centerを介したフェデレーションの一元化、許可セットと境界による最小権限の強制、信頼ポリシーでのMFAの要求、そして組織レベルのSCPと監視の適用は、影響範囲（ブラスト半径）を縮小し、権限昇格を防ぎ、監査性を提供するというAWSのベストプラクティスに沿っています。

IAMロールと信頼ポリシー: PassRoleとAssumeRole

IAMロールには2つの異なるポリシーサーフェスがあり、これらを混同することが、クロスアカウントでの認可失敗のほとんどの根本原因です。信頼ポリシー（AssumeRolePolicyDocument）は、誰が、どのような条件下でそのロールを引き受けることができるかを定義します。許可ポリシーは、ロールが引き受けられた後に何ができるかを定義します。両方のポリシーでアクションが許可されている必要があります。信頼ポリシーだけでは、S3やKMSなどへのアクセスは決して許可されません。

プリンシパルがsts:AssumeRoleを呼び出すと、STSは呼び出し元のアイデンティティとセッションコンテキスト（ソースIP、MFA状態、セッションタグ、外部ID）に対して、ターゲットロールの信頼ポリシーを評価します。呼び出し元のプリンシパルは、そのロールのARNに対するsts:AssumeRoleをAllow（許可）するアイデンティティベースのポリシーも持っている必要があります。この二重の要件により、アカウント境界を越えた安全なロールの引き受けが可能になります。

MFAと外部IDを要求する、典型的なクロスアカウントの信頼ポリシーは次のようになります。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" },
      "StringEquals": { "sts:ExternalId": "unique-partner-id-8842" }
    }
  }]
}

aws:MultiFactorAuthPresentキーは、引き受け可能なロールの信頼ポリシーでのみ意味を持ちます。なぜなら、MFAコンテキストはSTSの呼び出し時に確立され、その後のサービス呼び出しでは確立されないからです。S3バケットポリシーやロールの許可ポリシーにMFA条件を追加するのはよくある間違いです。元の人間がMFAで認証した場合でも、引き受けられたロールのセッションは通常aws:MultiFactorAuthPresent=trueを保持しないため、これらの条件はすべてのアクションを暗黙的に拒否します。MFAはロール引き受け時に強制してください。長期間有効なセッションに対して再認証を強制するには、aws:MultiFactorAuthAgeを使用します。

PassRoleは、試験シナリオでつまずきやすい第二の関門です。CloudFormation、EC2、Lambda、CodeBuildなどのサービスに、あるロールとして実行するように指示する場合、呼び出し元のアイデンティティはiam:PassRoleを持っている必要があります。

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

シナリオ: Meridian Financial社は、本番、開発、CI/CDツール用に個別のアカウントを持つマルチアカウントのAWS Organizationを運営しています。クロスアカウントでのデプロイや、インフラ変更を実行するためにロールを引き受けるサードパーティのCIエージェントのために、一元管理されたIAMロールを使用しています。アイデンティティの境界はロールの信頼ポリシーによって強制されており、一部のチームは、インスタンスやタスクにロールをアタッチするためにiam:PassRoleを付与された、長期間有効なインスタンスプロファイルやLambda関数を使用しています。

課題: 最近の監査で、過度に広範なiam:PassRole権限により、CI/CDプリンシパルがEC2インスタンスプロファイルにAdministratorロールを渡すことが可能になっていたことが判明しました。そして、攻撃者はAssumeRoleの信頼関係を悪用し、アカウントをまたいで過剰な権限を取得しました。

推奨アプローチ:

AWS CloudTrailとAmazon EventBridgeを使用して最近のiam:PassRoleおよびsts:AssumeRole API呼び出しを特定し、CloudTrail LakeまたはAthenaでクエリを実行して、どのプリンシパルがいつどのロールARNを渡したかをリストアップします。
複数のアカウントにまたがってIAM Access Analyzerを実行し、リソースベースの信頼ポリシーの公開状況を発見し、Organizationの外部や外部プリンシパルから引き受け可能なロールをリストアップします。
広範なiam:PassRoleポリシーを、Resourceで特定のロールARNを指定する最小権限のIAMポリシーに置き換えます。さらに、aws:PassedToServiceやaws:PrincipalOrgIDなどの条件キーを追加して、誰が、何がそのロールを受け取れるかを制限します。
ロールの信頼ポリシーを強化して条件を必須にします。aws:PrincipalOrgIDの使用、サードパーティ向けのsts:ExternalId、aws:SourceIdentityの要求、最大セッション期間の強制などを行い、未知のプリンシパルによる広範なAssumeRoleを防ぎます。
iam:PassRoleとAssumeRoleの異常を検出するためにAmazon EventBridgeルールを設定し、Amazon SNSにアラートを送信します。そして、過度に広範なポリシーを取り消したり修正したりするための自動化されたLambdaプレイブックを作成し、継続的なコンプライアンスのために検出結果をAWS Security HubとAWS Configに記録します。