第 1 章　セキュアなアーキテクチャの設計（30%）

AWS リソースへのセキュアなアクセス

この章で学ぶこと

  • 複数アカウントにまたがるアクセス制御と管理
  • AWS のフェデレーションと ID のサービス（IAM、IAM Identity Center）
  • AWS のグローバルインフラストラクチャ
  • AWS のセキュリティのベストプラクティス（最小権限など）
  • 責任共有モデル

この章に出てくる用語

プリンシパル
リクエストを出した主体。 IAM ユーザー、IAM ロールを引き受けたセッション、AWS のサービス自身（EC2 や Lambda がロールを使っている状態）、別アカウントのプリンシパルなどが入る。「人」とは限らず、プログラムやサービスもプリンシパルになるのがポイント。
ARN（Amazon Resource Name）
AWS のリソース 1 つ 1 つに付く、世界で一意な名前。 arn:aws:s3:::my-bucket/report.pdf のように、サービス・リージョン・アカウント ID・リソース名を「:」で区切って並べる。ポリシーで対象を指定するときは、この ARN を書く。S3 だけは ARN にリージョンとアカウント ID が入らない（バケット名が世界で一意だから）。
権限の境界（Permissions boundary）
その ID が持てる権限の上限を決める枠。 ポリシーを付ける操作ではなく、「どれだけ付けても、この枠より外へは出られない」という上限を定める。開発者に IAM ユーザーを作る権限を渡したいが、作られたユーザーが管理者になってしまうのは困る、という場面で使う。
AWS STS（Security Token Service）
期限付きの資格情報を発行するサービス。 ロールを引き受けると、STS がアクセスキー・シークレットキー・セッショントークンの 3 点セットを返す。既定の有効期間は 1 時間で、ロールの設定で最大 12 時間まで延ばせる。期限が切れたら取り直すので、漏れても被害が時間で止まるのが長期キーとの違い。
AWS Organizations
複数の AWS アカウントをまとめて管理する仕組み。 管理アカウント（旧マスターアカウント）の下に組織単位（OU）を作り、そこにメンバーアカウントをぶら下げる。請求が 1 本にまとまる（一括請求）、ボリューム割引がアカウントをまたいで効く、という金銭面の利点もある。
SCP（サービスコントロールポリシー）
OU やアカウントに対して、使ってよいサービスの上限を決める枠。 注意すべきは、SCP は権限を与えないということ。あくまで「ここから先は使わせない」という天井で、実際に操作できるようにするには別途 IAM ポリシーが要る。
AWS RAM（Resource Access Manager）
自分のリソースを、別のアカウントに「共有」する仕組み。 サブネット・Transit Gateway・Route 53 の解決ルール・ライセンスなどを、相手にコピーさせずに使わせられる。ロールを引き受けさせるのとは別の話で、あちらは「操作させる」、こちらは「使わせる」。複数アカウントで 1 つの VPC を共有する構成（共有 VPC）で出てくる。
AWS Control Tower
複数アカウントの環境を、推奨構成でまとめて立ち上げる仕組み。 Organizations・SCP・CloudTrail・Config・IAM Identity Center などをばらばらに設定する代わりに、ガードレール付きの初期構成を一気に作る。新しいアカウントを決まった形で払い出す（Account Factory）用途で問われる。

IAM（Identity and Access Management）がやっているのは、プリンシパル（誰が）・アクション（何を）・リソース（どれに）の 3 つを突き合わせて、許可か拒否かを返すことだけだ。料金はかからない。

図 1-1　IAM が答えている 1 つの質問
図 1-1　IAM が答えている 1 つの質問

3 つのうちどれが欠けても通らない。そして何も書かなければ拒否される。AWS には「とりあえず全部許可」の既定は無い。新しく作った IAM ユーザーは、ポリシーを付けるまで何もできない。

許可の内容は JSON で書く。覚える欄は 4 つだけだ。

図 1-2　ポリシーの 4 つの欄
図 1-2　ポリシーの 4 つの欄
欄書くこと例
Effect許可か拒否かAllow / Deny
Action何をするか（サービス名:操作）s3:GetObject、ec2:StartInstances
Resourceどれに対してか（ARN）arn:aws:s3:::my-bucket/*
Conditionどんなときだけ許すか（任意）送信元 IP、MFA 済み、タグが一致

ポリシーには貼る場所で 2 種類ある。この区別が設問によく出る。

アイデンティティベースのポリシーリソースベースのポリシー
貼る先ユーザー・グループ・ロールリソース自身（S3 バケット、KMS キー、SQS など）
答えることこの人は何をしてよいかこのリソースは誰に触らせるか
Principal 欄書かない（貼った相手がプリンシパル）書く（誰に許すかをここで指定）
別アカウントへの許可できない（ロールを引き受けてもらう）できる（相手のアカウントを Principal に書く）

補足

リソースベースのポリシーを使えるサービスは限られている。S3・KMS・SQS・SNS・Lambda・Secrets Manager・ECR などが代表例で、EC2 や RDS には無い。「別アカウントから S3 を読ませたい」ならバケットポリシーで済むが、「別アカウントで EC2 を操作させたい」ならロールを引き受けてもらうしかない。

許可と拒否が混ざったとき、どちらが勝つか。明示的な Deny が 1 つでもあれば、他に何が書いてあっても拒否だ。この一文が IAM の設問のほぼ半分を解く。

図 1-3　評価の順序
図 1-3　評価の順序
  1. 明示的な Deny があるか ―― あれば、ここで終わり。拒否。
  2. 組織の SCP で許されているか ―― 許されていなければ拒否（次節）。
  3. 権限の境界（Permissions boundary）の内側か ―― 外なら拒否。
  4. どこかに明示的な Allow があるか ―― あれば許可。
  5. どれにも当てはまらない ―― 暗黙の拒否。

試験では

「管理者権限を持っているのに操作できない」という設問は、ほぼ 1・2・3 のどれかだ。AdministratorAccess が付いていても、SCP で禁止されていれば通らないし、権限の境界が狭ければ通らない。「IAM ポリシーを広げる」という選択肢は、この型では誤り。

第 0 章で「ロールは一時的に借りる権限の入れ物」と書いた。借りる操作が AssumeRole で、実際に資格情報を発行するのが AWS STS だ。

図 1-4　ロールを引き受ける流れ
図 1-4　ロールを引き受ける流れ

ロールにはポリシーが 2 枚付く。ここを取り違える設問が多い。

ポリシー答えること書く相手
信頼ポリシー（Trust policy）誰がこのロールを引き受けてよいかプリンシパル（アカウント・サービス・IdP）
権限ポリシー（Permissions policy）引き受けた人は何をしてよいかアクションとリソース

試験では

「ロールを引き受けられない」という設問では、信頼ポリシー側を疑う。権限ポリシーをいくら広げても、信頼ポリシーに相手が書かれていなければ引き受けられない。逆に「引き受けられるが操作できない」なら権限ポリシー側だ。

別アカウントのリソースを触らせる形はこうなる。相手のアカウントにロールを作り、その信頼ポリシーに自分のアカウントを書く。自分側のユーザーには sts:AssumeRole の許可を与える。この 2 つがそろって初めて通る。

補足

ロールを引き受けた先からさらに別のロールを引き受けること（ロールチェイニング）はできるが、その場合のセッションは最大 1 時間に制限される。12 時間に設定していても延びない。

実務ではアカウントを 1 つで使い続けない。本番と開発を分ける、部署ごとに分ける、請求をまとめる、といった理由でアカウントは増える。それをまとめるのが AWS Organizations だ。

図 1-5　Organizations の階層と SCP の効き方
図 1-5　Organizations の階層と SCP の効き方
SCPIAM ポリシー
役割上限を決める（ガードレール）権限を与える
付ける先ルート・OU・アカウントユーザー・グループ・ロール
単体で操作できるかできないできる
管理アカウントへの効き方効かない効く
ルートユーザーへの効き方メンバーアカウントのルートには効く効かない（ルートは制限できない）

試験では

SCP は管理アカウントには効かない。「組織全体で ap-northeast-1 以外を使えなくしたい」という要件で管理アカウントだけ制限が効かない、という設問が出る。対策は「管理アカウントでワークロードを動かさない」。

社員が 500 人いるとして、IAM ユーザーを 500 個作るのは誤りだ。既にある ID（Active Directory や社内の IdP）を使い、AWS 側ではロールに対応づける。これをフェデレーションと呼ぶ。

図 1-6　ID をどこから持ってくるか
図 1-6　ID をどこから持ってくるか
使うもの向いている相手何をするか
IAM Identity Center社員（複数アカウントを使う）1 回のサインインで複数アカウント・複数ロールへ。外部 IdP とも繋げる
SAML 2.0 フェデレーション社員（既存の IdP がある）IdP の認証結果を STS に渡してロールを引き受ける
AWS Directory ServiceActive Directory を使っている組織マネージドな AD、または既存 AD への接続（AD Connector）
Amazon Cognitoアプリの利用者（一般ユーザー）アプリのサインアップ／サインイン。AWS コンソールの話ではない

試験では

Cognito は「アプリを使う一般ユーザー」用、IAM Identity Center は「社員」用。この 2 つを入れ替えた選択肢が必ず出る。問題文が「モバイルアプリの利用者が」と言っていたら Cognito、「従業員が複数アカウントに」と言っていたら IAM Identity Center。

補足

IAM Identity Center は以前「AWS Single Sign-On（AWS SSO）」という名前だった。試験ガイドにも両方の名前が併記されている。選択肢にどちらで出ても同じものと分かるようにしておく。

最後に、設問で「誤り」として並ぶ定番と、「どう確認するか」を問われたときの道具をまとめる。

やりがちな形なぜ誤りか正しい形
ルートユーザーで日常作業する権限を削れず、漏れたら終わりMFA を付けてしまい、IAM ユーザー／ロールを使う
EC2 にアクセスキーを置く漏れる・期限が無いインスタンスプロファイル（ロール）
ユーザーに直接ポリシーを付けて回る増えると管理できないグループに付けて、ユーザーをグループに入れる
とりあえず * で許可する最小権限に反する必要なアクションとリソースだけ書く
アカウントを共有する誰がやったか分からない人ごとに ID を分ける（CloudTrail で追える）
道具分かること
IAM Access Analyzer外部に公開されているリソースを洗い出す（意図しない公開の検出）
認証情報レポート（Credential Report）全ユーザーのキーの古さ・MFA の有無を一覧で出す
IAM ポリシーシミュレーターこのポリシーでその操作が通るかを、実行せずに試す
AWS CloudTrail誰がいつ何の API を呼んだか。監査の基本
AWS Configリソースの設定が決めた形から外れていないか

試験では

CloudTrail は「誰が何をしたか」、CloudWatch は「どれだけ使われたか」、Config は「設定が決めた形か」。3 つとも監視に見えるので入れ替えた選択肢が出る。「操作の記録をたどりたい」なら CloudTrail で確定。

シナリオ演習

組織では全アカウントで ap-northeast-1 以外のリージョンを使えないようにしたい。ところが管理アカウントだけ制限が効かない。どうするか。

補足

答え：管理アカウントではワークロードを動かさない（SCP は管理アカウントに効かないため）。

SCP は管理アカウントに適用されない、という仕様をそのまま突いた設問。「管理アカウントにも SCP を適用する」という選択肢は存在しない操作なので落ちる。

シナリオ演習

監査法人の担当者に、本番アカウントの読み取り専用アクセスを 2 週間だけ渡したい。相手は別の AWS アカウントを持っている。最も適切な方法は。

補足

答え：本番アカウントに読み取り専用のロールを作り、信頼ポリシーに相手のアカウントを書いて引き受けてもらう。

IAM ユーザーを作って渡す案は、長期の認証情報が増えるので落ちる。リソースベースのポリシーは S3 などには書けるが、アカウント全体の読み取りには向かない。

この章のまとめ

  1. IAM が突き合わせている 3 つ
  2. 何も書かれていないときの既定
  3. 明示的な Deny と明示的な Allow、強いのは
  4. ポリシーの 4 つの欄
  5. リソースベースのポリシーにあって、アイデンティティベースに無い欄
  6. EC2 や RDS にリソースベースのポリシーはあるか

前の章

← 第0章　AWS の地図

次の章

第2章　セキュアなワークロードとアプリケーション →

この章の根拠

AWS Certified Solutions Architect - Associate (SAA-C03) 試験ガイド

最終確認 2026-10-04 ／ 対応バージョン DEA 2026-05-04 改訂版