信頼ポリシーとロールを引き受けられる主体

信頼ポリシーはロールにアタッチされるドキュメントで、ロールの引き受けを許可するプリンシパルを正確に定義します。これは門番の役割を果たします。アクセス権限ポリシーで強力なアクセスを許可していても、信頼ポリシーに指定されていなければ、誰もそのロールを使用できません。試験では、信頼ポリシーの誤りが、アクセス不能や危険な過剰権限の主な原因として頻繁に登場します。

信頼ポリシーのPrincipal要素では、次の対象を指定できます。

• AWS — アカウント、ユーザー、またはロールの ARN（Amazon Resource Name）。
• Service — lambda.amazonaws.com などの AWS サービス。
• Federated — SAML プロバイダーまたは Web ID プロバイダー。

意図した範囲を超える信頼を付与しないためには、適切なプリンシパルの種類を選び、対象を具体的に指定することが重要です。

クロスアカウントでロールを引き受けるには、双方の合意が必要です。対象アカウントのロールの信頼ポリシーで呼び出し元のプリンシパルを許可し、かつそのプリンシパルの ID ベースポリシーで、ロールの ARN に対するsts:AssumeRoleを許可する必要があります。どちらか一方でも欠けていれば、リクエストは拒否されます。この双方向のハンドシェイクは、試験でよくあるひっかけです。

この信頼ポリシーでは、アカウント 111122223333 にある特定のロールが対象のロールを引き受けることを許可しています。アカウント全体ではなく正確な ARN を指定するほうが、より限定的で安全です。

プリンシパルとしてarn:aws:iam::ACCOUNT:rootを指定すると、アカウント全体を信頼することになります。そのアカウント内で sts:AssumeRole 権限も持つプリンシパルであれば、誰でもロールを引き受けられます。これは範囲が広すぎます。可能な場合は、最小権限の原則に従い、正確なユーザーまたはロールの ARN を指定して信頼範囲を狭めてください。

信頼ポリシーでは、Conditionブロックを使用して、ロールを引き受けられる主体と条件をさらに限定できます。一般的なキーには、混乱した代理人問題を防ぐsts:ExternalId、MFA を必須にするaws:MultiFactorAuthPresent、aws:SourceIpなどがあります。Condition によって、特定の検証可能な状況でのみロールの引き受けを許可できます。

機密性の高いロールを引き受ける前に MFA を必須にするのは、強力なパターンです。信頼ポリシーの条件で、呼び出し元のセッションが MFA を使用して認証されたことを確認します。これにより、長期的な認証情報が盗まれた場合でも、第二要素がなければ権限の高いロールを引き受けられず、攻撃の難易度を大幅に高められます。

一部のロールはサービスにリンクされたロールであり、AWS によって事前定義されているため、信頼ポリシーを編集できません。これらのロールにより、AWS が必要とする正確な信頼関係に基づいて、サービスがユーザーに代わってリソースを管理できます。権限と信頼関係が厳密に管理され、サービスのライフサイクルに結び付いているため、これらを見分けることが重要です。

内部のプリンシパル（同じアカウント）を信頼するほうが、一般的には外部アカウントやサードパーティの SaaS ベンダーを信頼するよりもリスクが低くなります。外部との信頼関係では、必ず特定のプリンシパルと ExternalId などの条件を組み合わせてください。外部との信頼関係はすべて、攻撃者が悪用を狙う侵入口になり得るものとして扱ってください。

IAM Access Analyzerは、信頼ポリシーとリソースポリシーを自動的に確認し、外部アカウントやパブリックな主体が引き受けられるロールを検出します。意図しないクロスアカウントまたはパブリックな信頼関係にフラグを立てるため、信頼範囲を狭められます。Access Analyzer の検出結果をレビューすることは、過剰に広い信頼を見つけるための、推奨される試験関連の対策です。

安全に信頼関係を設計するには、可能な限り具体的なプリンシパルを指定し、必要に応じて ExternalId や MFA などの条件を追加し、アカウントルートへの信頼よりもロールを優先し、Access Analyzer でレビューしてください。信頼ポリシーは誰がを、アクセス権限ポリシーは何をを定義することを覚えておきましょう。アクセスを機能させ、最小権限を維持するには、両方の内容が一致している必要があります。

信頼ポリシーについての知識を確認しましょう。

信頼ポリシーは、ロールを引き受けられるプリンシパルを定義し、アクセス権限ポリシーの内容にかかわらず門番として機能します。クロスアカウントでロールを引き受けるには、双方向のハンドシェイク、つまり信頼ポリシーと呼び出し元の sts:AssumeRole 権限の両方が必要です。アカウントルートよりも特定のプリンシパル ARN を優先し、ExternalId や MFA などの条件を追加して、IAM Access Analyzerで監査してください。