SAA / ドメイン1 セキュアなアーキテクチャの設計

重要な内容

AWS IAM (Identity and Access Management)

は、AWS アカウント内で「誰が、どのリソースに、何をしてよいか」を制御するためのサービスです。 ユーザー、グループ、ロール、ポリシーを使って、AWS リソースへの認証と認可を管理します。

SAA では、IAM を単独サービスとして暗記するよりも、、、、、、 Endpoint などと組み合わせた権限設計を判断できることが重要です。 特に、長期を避けて IAM ロールとを使う設計、、アクセス、明示的な拒否の優先順位がよく問われます。

Point
  • IAM = Identity and Access Management の略です。
  • Identity は「身元」や「ID」、Access は「利用」、Management は「管理」という意味です。
  • つまり IAM は「誰が何にアクセスできるかを管理するサービス」と覚えます。
  • 和訳

概要

は、AWS の権限管理の中心になるサービスです。 人間が にサインインする場合も、 や が や にアクセスする場合も、最終的には「その主体に許可があるか」を評価します。

IAM では、操作する主体をプリンシパルと呼びます。 代表的なプリンシパルには、IAM ユーザー、IAM ロール、AWS サービス、ユーザーがあります。 プリンシパルに対して、 形式のポリシーで許可または拒否を定義します。

概要の図 Allow Deny プリンシパルユーザー・ロール・サービス AWS API リクエスト IAM の認可評価 ポリシー 許可される? AWS リソースへアクセス 拒否

SAA の学習では、IAM ユーザーを作る手順よりも、「長期認証情報を置かずにアクセスさせるには何を使うか」「で安全に委任するには何を設定するか」「どのポリシーが最終的な権限を制限するか」を判断します。

見るポイント代表的な判断
人間のアクセスか、アプリケーションのアクセスか人間は やフェデレーション、AWS サービスは IAM ロールを優先します。
長期認証情報が必要か原則としてを埋め込まず、を使います。
どこまで許可するかで、必要な Action、Resource、Condition に絞ります。
複数アカウントをまたぐかと権限ポリシーを持つ IAM ロールで委任します。
明示的な拒否があるか明示的な Deny は Allow より優先されます。

主要技術

①IAM アイデンティティとルートユーザー

の基本要素は、ユーザー、グループ、ロールです。 IAM ユーザーは特定の人やアプリケーションに対応する長期的なアイデンティティです。 IAM グループは複数ユーザーに同じ権限を付与するためのまとまりです。 IAM ロールは、必要なときに引き受けてを得るためのアイデンティティです。

要素主な用途SAA での判断ポイント
アカウント作成時の完全権限主体日常利用しません。 を有効化し、最小限の作業だけに使います。
IAM ユーザー例外的な長期認証情報、緊急アクセスロールやで代替できない場合に限定します。
IAM グループユーザーへの権限一括付与グループにポリシーを付け、個別ユーザーへの直接付与を減らします。
IAM ロールAWS サービス、、フェデレーションSAA では最も重要です。一時的な認証情報を使います。
組織内ユーザーの複数アカウントへの人間のアクセス管理で検討します。

ルートユーザーは AWS アカウント全体に対する強い権限を持ちます。 通常の運用、アプリケーション実行、日常的な管理作業では使いません。 ルートユーザーには MFA を設定し、は作成しない設計が基本です。 現在はルートユーザーの MFA が既定で強制され、作成時やサインイン時に登録を求められます。

を使う場合は、メンバーアカウントのルートアクセスを一元管理できます。 この機能を有効にすると、メンバーアカウントのルートユーザーのパスワード、アクセスキー、署名証明書を削除し、MFA を無効化できます (組織で新しく作るアカウントは、最初からルートの認証情報を持ちません)。 ルートユーザーでしかできない作業のうち、全プリンシパルを拒否してしまった ポリシーや キューポリシーの削除などは、管理アカウントまたは IAM の委任管理者が特権タスクとして短時間のルートセッションで実行できます。 長期のルート認証情報を各アカウントに残さずに済むため、多数のアカウントでルートのパスワードと MFA デバイスを保管する運用が不要になります。

ルートの守り方内容向いている場面
MFA の登録とアクセスキーの不作成単独のアカウントでも必ず行う基本対策です。すべてのアカウント
ルートアクセスの一元管理メンバーアカウントのルート認証情報を削除し、特権タスクは管理アカウントから実行します。Organizations で多数のアカウントを持つ場合
でルートユーザーの操作を拒否メンバーアカウントのルートユーザーにも SCP は効きます。認証情報は残るため、上記と組み合わせます。
Point
  • MFA = Multi-Factor Authentication（多要素認証） の略です。
  • パスワードだけでなく、認証アプリや物理キーなど別の要素も使って本人確認します。
  • Federation は「連携」や「連合」という意味です。
    • 既存の社内 ID や外部 ID プロバイダーで認証し、AWS 側では一時的なアクセス権を得る考え方です。
  • 和訳

⚠️ 頻出: 、、 などの AWS 上のワークロードにアクセスキーを埋め込む設計は避けます。サービスに IAM ロールを関連付け、一時的な認証情報を使わせます。

②IAM ポリシーの基本構造

ポリシーは、権限を定義する ドキュメントです。 どの操作を、どのリソースに対して、どの条件で許可または拒否するかを表します。

要素意味試験での見方
EffectAllow または Deny明示的な Deny は Allow より優先されます。
Action許可・拒否する 操作s3:GetObject や ec2:StartInstances のように指定します。
Resource対象リソースARN で絞ります。サービスによって指定粒度が異なります。
Principal誰に許可するかやで使います。
Condition条件、、タグ、暗号化、 Endpoint などで制限できます。

ポリシーには、とリソースベースポリシーがあります。 アイデンティティベースポリシーはユーザー、グループ、ロールに付けます。 リソースベースポリシーは ポリシーや IAM ロールの信頼ポリシーのように、リソース側に付けます。

ポリシー種別付ける場所主な用途
アイデンティティベースポリシーユーザー、グループ、ロールその主体が実行できる操作を定義します。
リソースベースポリシーS3 バケット、 キュー、 キーなどそのリソースへアクセスできる主体を定義します。
信頼ポリシーIAM ロール誰がそのロールを引き受けられるかを定義します。
Permissions Boundaryユーザー、ロールアイデンティティベースポリシーで許可できる最大範囲を制限します。
の やアカウントメンバーアカウントで利用可能な最大権限を制限します。
セッションポリシーAssumeRole などのセッション一時セッションの権限をさらに狭めます。
VPC Endpoint PolicyVPC Endpoint経由でアクセスできる主体やリソースを制限します。
②IAM ポリシーの基本構造の図 はい いいえ はい いいえ AWS API リクエスト アイデンティティベースポリシー リソースベースポリシー Permissions Boundary SCP セッションポリシー VPC Endpoint Policy 権限評価 明示的 Deny がある? 拒否 有効な Allow がある? 許可 暗黙的に拒否

Permissions Boundary、SCP、セッションポリシーは、原則として権限を付与するものではなく、最大権限を制限するものです。 たとえば SCP で s3:* が許可されていても、IAM ポリシーで S3 操作が許可されていなければ実行できません。

⚠️ 頻出: 「SCP で許可したのに操作できない」という考え方は誤りです。SCP は権限を与えず、上限を決める制御です。

③IAM ロールと一時的な認証情報

ロールは、特定の人に固定されないアイデンティティです。 ロールを引き受けると、 によってが発行されます。 この一時的な認証情報には有効期限があり、長期を配布したりアプリケーションに埋め込んだりする必要を減らせます。

ロールの用途例判断ポイント
AWS サービスロール から へアクセス、 から へアクセスワークロードにアクセスキーを置かず、ロールを関連付けます。
ロールAccount A のユーザーが Account B のリソースを管理と AssumeRole 権限の両方が必要です。
用ロール社内 、SAML、OIDC から AWS へアクセス既存 ID を使い、一時的な AWS 権限を与えます。
サービスリンクロールAWS サービスがユーザーの代わりに操作サービスに紐づいたロールで、権限編集に制約があります。
タスクロールとタスク実行ロールのアプリが DynamoDB を操作する / ECS エージェントが からイメージを取得しログを送るアプリが呼ぶ AWS の権限はタスクロール、イメージ取得・ログ送信・起動時のシークレット取得はタスク実行ロールに付けます。
OIDC フェデレーションGitHub Actions などの CI から AWS へデプロイIAM に OIDC ID プロバイダーを登録し、信頼ポリシーの条件でリポジトリやブランチを絞ります。アクセスキーを CI に保存しません。
IAM Roles Anywhereのサーバーから S3 へアクセス自社の CA をトラストアンカーとして登録し、X.509 証明書を持つ AWS 外のワークロードに一時的な認証情報を発行します。

ロールの認証情報を使ってさらに別のロールを引き受けることをロールの連鎖 (ロールチェーン) と呼びます。 ロールの連鎖で得たセッションは最長 1 時間に制限され、ロール側の最大セッション時間を 12 時間にしていても、1 時間を超える DurationSeconds を指定すると失敗します。 長時間の処理で連鎖が不要なら、最初のロール (EC2 のインスタンスプロファイルなど) に必要な権限を直接付けます。インスタンスプロファイルの認証情報は期限前に自動で更新されます。

③IAM ロールと一時的な認証情報の図 ロールを引き受けます 一時的な認証情報を取得します 有効期限付き認証情報 認証情報で API 実行 EC2 / Lambda など IAM ロール AWS STS S3 などのAWSリソース

AWS STS は一時的な認証情報を発行するサービスです。 一時的な認証情報は、数分から数時間の有効期限を持ち、期限切れ後は再利用できません。 EC2 インスタンスプロファイル、Lambda 実行ロール、ECS タスクロールなどは、この考え方で AWS リソースへ安全にアクセスします。

Point
  • STS = Security Token Service の略です。
  • Token は「一時的な証明書」のようなものです。
  • STS は「一時的な AWS 認証情報を発行するサービス」と覚えます。
  • AssumeRole は「ロールを引き受ける」という意味の API です。
  • 和訳

⚠️ 頻出: 「EC2 上のアプリケーションが S3 にアクセスするための最も安全な方法」は、EC2 に IAM ロールを関連付けることです。アクセスキーを 、ユーザーデータ、環境変数、コードに保存する設計は避けます。

④クロスアカウントアクセスと信頼ポリシー

アクセスでは、別アカウントの主体に自アカウントのリソース操作を委任します。 代表的な方法は、アクセス先アカウントに ロールを作り、アクセス元アカウントのユーザーやロールがそのロールを引き受ける構成です。

④クロスアカウントアクセスと信頼ポリシーの図 sts:AssumeRole を許可 Account A利用者・アプリケーション Account BIAM Role 信頼ポリシーAccount A を信頼 権限ポリシーAccount B のリソース操作を許可 Account B のリソース

クロスアカウントロールには、2 種類の許可が必要です。 アクセス先アカウントのロール側では、でアクセス元を信頼します。 アクセス元アカウント側では、対象ロールを sts:AssumeRole できる権限を付与します。

必要な設定どこに設定するか目的
信頼ポリシーアクセス先アカウントの IAM ロール誰がロールを引き受けられるかを指定します。
権限ポリシーアクセス先アカウントの IAM ロールロールを引き受けた後に何ができるかを指定します。
AssumeRole 許可アクセス元のユーザーまたはロール対象ロールを引き受ける操作自体を許可します。
External ID第三者委任の信頼条件混乱した代理問題を防ぐために使います。

外部ベンダーや監査サービスなど、第三者にアクセスを委任する場合は External ID が重要です。 External ID は、意図しない別顧客のロールを第三者が誤って引き受ける混乱した代理問題を防ぐための条件として使います。

ロールの信頼ポリシーには条件も書けます。 たとえば本番の管理者ロールに aws:MultiFactorAuthPresent の条件を付けると、 で認証した利用者だけがそのロールへ切り替え (スイッチロール) できます。 普段は読み取り専用の権限で作業し、変更作業のときだけ強い権限のロールへ切り替えると、誤操作と漏えい時の影響を小さくできます。

クロスアカウントアクセスには、ロールを引き受ける方法のほかに、 ポリシー、 キューポリシー、 キーポリシー、 ののように、リソースベースポリシーで相手アカウントのプリンシパルを直接許可する方法があります。

方法呼び出し側の権限向いている場面
ロールを引き受ける引き受けている間は元の権限を手放し、ロールの権限だけで操作します。 の操作など、リソースベースポリシーに対応しないサービスを操作する場合
リソースベースポリシーで直接許可自分の権限を持ったまま相手のリソースへアクセスします。自アカウントのリソースと相手のリソースを同時に扱う場合 (自分のバケットへ相手のバケットからコピーするなど)

リソースベースポリシーで別アカウントを許可した場合も、相手アカウント側の IAM ポリシーで同じ操作を許可しなければアクセスできません。アカウントをまたぐときは、両方のアカウントの許可が必要です。 組織内の全アカウントへ許可したいときは、アカウント ID を列挙せず、aws:PrincipalOrgID 条件で組織 ID を指定します。アカウントが増えてもポリシーを書き換えずに済みます。

⚠️ 頻出: クロスアカウントアクセスで「片側のポリシーだけ」では足りない問題が出ます。信頼ポリシー、ロールの権限ポリシー、呼び出し元の sts:AssumeRole 許可をセットで確認します。

⑤最小権限、条件、タグベース制御

設計の基本はです。 必要な操作だけを許可し、対象リソースをできるだけ絞り、必要に応じて Condition で追加条件を指定します。

制御方法例向いている要件
Action の絞り込みs3:GetObject のみ許可読み取りだけ必要な場合に使います。
Resource の絞り込み特定や特定 キーだけ許可操作対象を限定します。
Condition、送信元 、 Endpoint、タグなど状況に応じて許可・拒否を切り替えます。
タグベースアクセス制御Project=Blue のリソースだけ操作多数のリソースを属性で管理します。
IAM Access Analyzer外部公開や未使用アクセスの分析権限の見直しや過剰権限の検出に使います。

タグベースアクセス制御では、ユーザーやロールのタグと、リソースのタグを条件に使ってアクセスを制御します。 プロジェクト、環境、部門などの単位で権限を管理したいときに有効です。 ただし、タグを変更できる権限を広く与えると、実質的にアクセス権を拡大できるため注意が必要です。

タグベースアクセス制御は ABAC (属性ベースのアクセス制御) とも呼ばれます。 aws:ResourceTag/Project が ${aws:PrincipalTag/Project} と一致するときだけ許可するように書くと、プロジェクトが増えてもポリシーを追加せず、タグを付けるだけで権限が決まります。 職務ごとにポリシーを用意する RBAC (ロールベースのアクセス制御) は、プロジェクトや対象が増えるたびにポリシーの更新が必要になります。

Permissions Boundary は、開発者に IAM ロールの作成を任せるときの権限昇格の防止に使います。 iam:CreateRole を、指定した Permissions Boundary を付けることを条件 (iam:PermissionsBoundary) にして許可すると、開発者が作ったロールは境界を超える権限を持てません。

のポリシーでは、操作ごとに対象の ARN が違う点に注意します。 s3:ListBucket はバケットの ARN (arn:aws:s3:::bucket) に対する操作で、プレフィックスを絞るときは s3:prefix 条件を使います。 s3:GetObject や s3:PutObject はオブジェクトの ARN (arn:aws:s3:::bucket/prefix/*) に対する操作です。

IAM ユーザーに MFA を使わせたい操作は、aws:MultiFactorAuthPresent 条件で MFA 認証済みのセッションのときだけ許可します。

IAM Access Analyzer は、外部アクセスの分析やポリシーの検証に使います。 SAA では、公開されている S3 バケットやで引き受け可能なロールなど、意図しない外部アクセスを見つけるサービスとして押さえます。 組織を信頼ゾーンにした分析を作ると、組織外の主体からアクセスできるリソースだけを結果として洗い出せます。

既存の権限を最小権限へ絞り込む手段もあります。

手段分かること使い方
IAM Access Analyzer のポリシー生成 に記録された実際の操作指定期間の利用実績から、必要な操作だけを並べたポリシーのひな形を作ります。
IAM Access Analyzer の未使用アクセスの分析使われていないロール、、パスワード、権限組織やアカウント全体の過剰な権限を継続的に見つけます (有料)。
最終アクセス情報サービスや操作ごとに最後に使われた日時長く使われていない権限を削ります。
⑤最小権限、条件、タグベース制御の図 必要な作業 必要な Action に限定 対象 Resource に限定 Condition で追加制限 Access Analyzer で確認 最小権限に近づける

⚠️ 頻出: 「すべての S3 バケットにフルアクセス」より、「特定バケットの特定プレフィックスに読み取りだけ許可」のほうが最小権限です。試験では、広すぎる * を避ける選択肢が正答になりやすいです。

⑥認可評価と拒否の優先順位

の権限評価では、最初は暗黙的に拒否されます。 有効な Allow がある場合に許可されますが、どこかに明示的な Deny があると拒否されます。

状態結果試験での見方
Allow がない拒否デフォルトは暗黙的拒否です。
Allow がある許可候補他の制限や Deny がないか確認します。
明示的 Deny がある拒否Allow より優先されます。
Permissions Boundary で許可されていない拒否の上限を超えられません。
で許可されていない拒否メンバーアカウントでは組織の上限を超えられません。
Endpoint Policy で許可されていない拒否経由のアクセスでは追加境界になります。

たとえば、IAM ポリシーで の読み取りが許可されていても、S3 ポリシーで特定条件に合わないアクセスを Deny していれば拒否されます。 暗号化された S3 オブジェクトでは、S3 の GetObject 権限だけでなく、KMS キーの利用権限も必要です。

⑥認可評価と拒否の優先順位の図 はい いいえ いいえ はい はい いいえ アクセス要求 明示的 Deny? 拒否 Boundary / SCP / Session / Endpoint の範囲内? 有効な Allow? 許可 暗黙的拒否

IAM はグローバルサービスですが、IAM の変更は各所へ反映されるまで時間がかかる場合があります。 そのため、IAM ユーザー、グループ、ロール、ポリシーの作成や変更を、アプリケーションの高可用な処理経路に組み込まない設計が推奨されます。

⚠️ 頻出: 「権限を付けた直後なのに一時的に失敗する」文脈では、IAM の変更反映に時間がかかる場合があります。ただし、試験ではまず明示的 Deny、SCP、Permissions Boundary、KMS 権限、リソースポリシーを確認します。

試験対策

SAA では、 の細かい 構文よりも、アーキテクチャ上の安全な権限委任を判断します。 基本方針は、長期を避け、IAM ロールとを使い、で許可することです。

、、 などの AWS ワークロードが他の AWS サービスにアクセスする問題では、IAM ロールを選びます。 アプリケーションコード、環境変数、ユーザーデータ、、 などにアクセスキーを保存する選択肢は避けます。

アクセスでは、アクセス先アカウントにロールを作成し、アクセス元から sts:AssumeRole します。 第三者に委任する場合は External ID を条件に含めると、混乱した代理問題の対策になります。

問題文のキーワード優先して考える機能理由
EC2 から S3 に安全にアクセスEC2 インスタンスプロファイル / IAM ロールアクセスキーを保存せず一時的な認証情報を使えます。
Lambda から にアクセスLambda 実行ロール関数に必要な権限だけを付与します。
別アカウントのリソースを操作クロスアカウント IAM ロールと AssumeRole で安全に委任します。
外部ベンダーに監査を依頼IAM ロール + External ID混乱した代理問題を防ぎます。
複数アカウントのユーザー管理人間のアクセスを一元管理しやすくなります。
組織単位でサービス利用を制限アカウント内の最大権限を制限します。
権限があるはずなのに拒否明示的 Deny / SCP / Boundary / リソースポリシー / Allow 以外の制限を確認します。
S3 やロールの外部公開を検出IAM Access Analyzer意図しない外部アクセスを分析します。
Endpoint 経由だけ許可VPC Endpoint Policy + 条件付きポリシーネットワーク経路を含めた制御ができます。
試験対策の図 AWS サービス・アプリ 人間・社内ユーザー 別アカウント IAM 設計問題 誰がアクセスしますか? IAM ロール IAM Identity Center / フェデレーション クロスアカウントロール 必要な権限は? 最小権限ポリシー 追加の上限制御は? SCP Permissions Boundary セッションポリシー Access Analyzer で確認

権限トラブルの問題では、評価順序を意識します。 最初に明示的 Deny がないかを見ます。 次に、SCP、Permissions Boundary、セッションポリシー、VPC Endpoint Policy、、KMS キーポリシーなど、権限を狭める要素を確認します。 最後に、必要な Allow が実際に存在するかを確認します。

コスト面では、IAM、IAM Identity Center、 は追加料金なしで利用できます。 ただし、IAM Access Analyzer の一部分析や、IAM で許可した先の AWS サービス利用には料金が発生する場合があります。 SAA では、IAM 自体の料金よりも、セキュリティ、運用負荷、権限範囲、監査性のトレードオフを重視します。

参考文献

  1. ※1出題比率: AWS 公式の試験ガイドに記載された、採点対象の設問のうちその分野が占める割合です。

検索

キーワードを入力してください