【クラウド入門 第8回】IAMとセキュリティ 前編 ― IAMのユーザー・グループ・ロールとポリシー、評価の順序、ルートユーザーとMFA、STSとAssumeRole、Identity Center、Directory Service、Organizations・SCP・RCP

「EC2 で動くアプリから S3 のファイルを読ませたいので、IAM ユーザーを作ってアクセスキーをサーバーの設定ファイルに書こうと思います。何か問題はありますか」
「Organizations の SCP で『東京以外のリージョンは使用禁止』にしたのに、管理アカウントでは大阪にリソースを作れてしまいました。設定を間違えたのでしょうか」

第7回では、VPC の DNS、オンプレとの接続、Route 53、CloudFront を見ました。ネットワークの次は「誰が何をしてよいか」です。オンプレでは LDAP や Active Directory のディレクトリと、サーバーごとのアクセス制御でこれを決めていました。AWS では IAM が同じ役目を担いますが、守る対象はサーバーへのログインではなく AWS の API 呼び出しです。さらに、鍵の管理（KMS）、証明書（ACM）、脅威の検知（GuardDuty など）も、マネージドのサービスとして用意されています。

第8回と第9回では、IAM とセキュリティを2回に分けて見ていきます。前編の第8回では、IAM のユーザー・グループ・ロールとポリシー、ポリシーの評価の順序、ルートユーザーの保護と MFA、STS と AssumeRole、IAM Identity Center と ID 連携、AWS Directory Service、Organizations と SCP・RCP を扱います。KMS による暗号化、Secrets Manager、ACM、検知と防御のサービス、Azure との対応は、後編の第9回で扱います。数値・料金は2026年9月時点のもので、料金は東京リージョンの例です。

---

IAM（Identity and Access Management）とは

IAM は AWS の認証（誰か）と認可（何をしてよいか）を一元的に扱う仕組みです。オンプレの LDAP や Active Directory が担う「ディレクトリ＋アクセス制御」に相当しますが（ディレクトリの考え方は、このブログの連載「LDAP入門」第1回の「ディレクトリとは」で、AD は連載「Active Directory入門」第1回で詳しく扱います）、対象はサーバーへのログインではなく AWS の API 呼び出しです。コンソール操作も CLI も SDK もすべて API なので、IAM で許可されていなければ何もできません。

構成要素は、人やアプリに対応する IAM ユーザー、ユーザーをまとめる グループ、一時的に権限を引き受ける ロール、そして権限の中身を JSON で書いた ポリシーの4つです。IAM はグローバルサービスでリージョンに依存せず、追加料金もかかりません。既定は「すべて拒否」で、ポリシーで明示的に許可したものだけが通ります（デフォルト拒否）。上限は1アカウントあたりユーザー 5,000、ロール 1,000（引き上げ可）、ユーザーあたりアクセスキー2つです（2026年9月時点）。

現在の AWS のベストプラクティスは「人の恒久的な IAM ユーザーを作らず、IAM Identity Center（この回の「ID 連携：IAM Identity Center と SAML」）で社内の ID から一時的な権限を得る」方向にあり、IAM ユーザーはどうしても必要な場合（一部のサードパーティ連携）に限る流れになっています。

• 対象は「AWS の API 呼び出し」。コンソールも CLI も同じ
• ユーザー／グループ／ロール／ポリシー。グローバル、無料、デフォルト拒否
• 人は Identity Center 経由、サービスにはロール。IAM ユーザーは最小限

---

IAM ユーザー・グループ・ロール

4種類の主体の違いです。

種類	認証情報	有効期限	主な用途
IAM ユーザー	パスワード（コンソール）、アクセスキー ID＋シークレット（API）	恒久（ローテーション推奨）	人（過渡的）、外部システム連携
IAM グループ	なし（ユーザーの集合）	—	部門・役割ごとにポリシーをまとめて付与。グループの入れ子は不可
IAM ロール	一時的なアクセスキー＋セッショントークン（STS が発行）	15 分〜12 時間	EC2／Lambda／ECS などのサービス、クロスアカウント、フェデレーション
ルートユーザー	メール＋パスワード	恒久	初期設定と特定操作のみ

「サービスに権限を持たせたいときは必ずロール」です。EC2 にアクセスキーを置く代わりに「インスタンスプロファイル」経由でロールを付け、アプリは IMDS（第3回）から一時認証情報を得ます。冒頭の1つ目の相談がこれです。アクセスキーを設定ファイルに書くと、恒久のキーがサーバーやバックアップ、AMI に残り、漏れたときに無効にするまで使われ続けます。ロールなら、認証情報は期限付きで自動的に入れ替わります。

Lambda の実行ロール、ECS のタスクロール、RDS からの S3 参照も同じ仕組みです。ロールには「誰がこのロールを引き受けてよいか」を書く信頼ポリシーと、「引き受けたら何ができるか」のアクセス許可ポリシーの2種類が付きます。

---

IAM ポリシーの構造（JSON）

例として、特定のバケットの読み取りだけを許可し、S3 の削除は明示的に拒否するポリシーです。

{
  "Version": "2012-10-17",
  "Statement": [
    { "Sid": "ReadLogs",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::app-logs", "arn:aws:s3:::app-logs/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "true" } } },
    { "Sid": "DenyDelete",
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "*" }
  ]
}

• 基本の要素は Effect（Allow/Deny）、Action（サービス:操作。ワイルドカード可）、Resource（ARN）、Condition（送信元 IP、MFA の有無、タグ、時間帯など）。Principal はリソースベースポリシー（S3 バケットポリシー、ロールの信頼ポリシー）でだけ使う
• Version は常に 2012-10-17（省略すると古い文法になり、変数が使えない）
• 「最小権限」のため Action: "*" や Resource: "*" を避ける。まず AWS 管理ポリシー（ReadOnlyAccess など）で始め、IAM Access Analyzer の「未使用のアクセス」やポリシー生成機能で絞り込む
• 検証は IAM Policy Simulator か、aws iam simulate-principal-policy で行う

---

ポリシーの種類と評価の順序

ポリシーには付ける場所と役割の違う種類があり、決まった順序で評価されます。

• アイデンティティベース：ユーザー／グループ／ロールに付ける（AWS 管理・カスタマー管理・インライン）
• リソースベース：S3 バケットポリシー、KMS キーポリシー、Lambda のリソースポリシー、ロールの信頼ポリシー。別アカウントからのアクセス許可はこれで書く
• アクセス許可の境界（Permissions Boundary）：そのユーザー／ロールが持てる権限の上限。委任先に「自分より強い権限を作らせない」ために使う
• SCP／RCP（この回の「AWS Organizations と SCP」）：アカウント全体の上限（例：「東京以外のリージョンは使用禁止」「CloudTrail を無効化させない」）
• セッションポリシー：AssumeRole のときに渡して、さらに絞る
• 評価順序：①明示的な Deny があれば即拒否 → ②RCP → SCP で許可されているか → ③リソースベースで許可 → ④アイデンティティベースで許可 → ⑤境界の範囲内か → ⑥セッションポリシーの範囲内か → どこにも Allow が無ければ暗黙の拒否
• 同一アカウント内はアイデンティティかリソースのどちらかに Allow があれば通る。クロスアカウントは両方に Allow が必要。ただしロールの信頼ポリシーと KMS のキーポリシーは、同じアカウントでもそのポリシー側での許可が必要

---

ルートユーザーの保護と MFA

ルートユーザーはアカウントのすべてを操作できるため、最初に守りを固めます。

• ルートユーザーの必須対策：MFA の設定（2024年5月に管理アカウント、6月に単独のアカウント、2025年6月にメンバーアカウントを含む全アカウントで必須化）、アクセスキーを作らない（既にあれば削除）、メールアドレスは個人ではなく配布リスト、パスワードは物理的に管理
• MFA の方式：仮想 MFA（Authenticator アプリの TOTP）、FIDO2 セキュリティキー／パスキー（パスキーは2024年から対応。フィッシング耐性が最も高い）、ハードウェア TOTP トークン。1ユーザーに最大8デバイス
• 「MFA していないと拒否」のポリシーの例："Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}} で Deny
• ルートユーザーの一元管理（2024年11月〜）：Organizations の管理アカウントから、メンバーアカウントのルートの認証情報を削除し、必要なときだけ短時間の特権セッションを発行できる。メンバーアカウントのルートのパスワードを個別に管理しなくてよくなった
• IAM 認証情報レポート（aws iam generate-credential-report）で、全ユーザーの MFA の有無・キーの最終使用日を CSV で棚卸しできる。90日以上使っていないキーは無効化する
• RADIUS やフェデレーションで使われる MFA の考え方が、そのまま当てはまる（このブログの連載「フェデレーション入門」第11回の「MFA の方式と強さ」、連載「RADIUS入門」第17回の「VPN の認証と MFA の制約」）

$ aws iam generate-credential-report      # レポートの作成を依頼する
$ aws iam get-credential-report --query Content --output text | base64 -d > report.csv

---

STS（Security Token Service）と AssumeRole

STS は一時的な認証情報（アクセスキー ID・シークレット・セッショントークンの3点セット）を発行するサービスで、IAM ロールの仕組みを支えています。sts:AssumeRole を呼ぶと、信頼ポリシーで許可された主体だけが、そのロールの権限を有効期限付きで得ます。有効期限はロールの設定で1〜12時間（既定1時間）、ロールからさらに別のロールを引き受ける「ロールチェーン」は1時間が上限です（ロールの表の「15 分〜12 時間」は、引き受けるときに指定できる長さの範囲です）。

AssumeRole には派生形があり、SAML アサーションを渡す AssumeRoleWithSAML（この回の「ID 連携：IAM Identity Center と SAML」）、OIDC トークンを渡す AssumeRoleWithWebIdentity（GitHub Actions や EKS の Pod からの利用、Cognito）があります。

実務で最も多いのはクロスアカウントアクセスで、監査用アカウントのロールを本番アカウントの管理者が引き受ける、という形で「アカウントをまたいでも認証情報を渡さない」設計ができます。CLI では ~/.aws/config に role_arn と source_profile を書けば、自動で AssumeRole します。

# ~/.aws/config の例（アカウント ID は例）
[profile audit]
role_arn = arn:aws:iam::111122223333:role/AuditRole
source_profile = default

$ aws sts get-caller-identity --profile audit
{
    "UserId": "AROAEXAMPLEID:botocore-session-1759500000",
    "Account": "111122223333",
    "Arn": "arn:aws:sts::111122223333:assumed-role/AuditRole/botocore-session-1759500000"
}

恒久のキーを配らず、有効期限付きのトークンを都度発行するという点は、Kerberos のチケットの考え方と同じで、漏洩しても被害を時間的に限定できます（このブログの連載「Kerberos入門」第1回の「チケットの世界」と、第4回の「有効期限と更新」で詳しく扱います）。aws sts get-caller-identity で「今誰として動いているか」を必ず確かめる癖をつけましょう。

• 一時認証情報（3点セット）を発行。有効期限1〜12時間
• AssumeRole／WithSAML／WithWebIdentity。クロスアカウントの基本
• 恒久キーを配らない設計＝Kerberos のチケットと同じ発想

---

ID 連携：IAM Identity Center と SAML

人の認証は、社内の ID 基盤とつないで一元化します。

• IAM Identity Center（旧 AWS SSO）：Organizations 配下の複数アカウントへのシングルサインオンを提供。ユーザーは1つのポータルから、アカウント×「アクセス許可セット」（ポリシーのテンプレート）を選んで一時認証情報を得る。CLI も aws sso login で対応
• ID ソース：Identity Center の内蔵ディレクトリ／Microsoft Entra ID・Okta などの外部 IdP（SAML 2.0＋SCIM でユーザー同期）／AWS Managed Microsoft AD・AD Connector（この回の「AWS Directory Service：AD をどう扱うか」）
• IAM の SAML フェデレーション（Identity Center を使わない従来型）：IdP を IAM に登録し、SAML アサーションのロール属性で AssumeRoleWithSAML。SAML の SP-Initiated／IdP-Initiated の流れそのもの（連載「フェデレーション入門」第5回の「SP 起点と IdP 起点」）
• OIDC フェデレーション：GitHub Actions・GitLab CI から、アクセスキーを置かずにデプロイの権限を得る現在の標準（AssumeRoleWithWebIdentity）
• Amazon Cognito：エンドユーザー（アプリの利用者）向けの認証基盤。社員向けの Identity Center とは対象が違う
• 現在の推奨：人の認証は社内 IdP（Entra ID など）→ Identity Center → 各アカウントのロールという流れ。IAM ユーザーを人に配らない

LDAP 連携からフェデレーション（SAML・OIDC）への移り変わりは、このブログの連載「LDAP入門」第10回の「LDAP からフェデレーションへ」で詳しく扱います。

---

AWS Directory Service：AD をどう扱うか

オンプレの Active Directory を AWS でどう扱うかには、4つの選択肢があります。

選択肢	内容	向くケース
AWS Managed Microsoft AD	AWS が運用する本物の Windows Server AD（2 DC、マルチ AZ）。フォレスト信頼でオンプレ AD と接続可。Standard／Enterprise	クラウド側にも DC を置きたい、FSx for Windows・RDS SQL Server・WorkSpaces の認証
AD Connector	オンプレ AD へのプロキシ。DC は作らない。VPN/DX で到達できることが前提	認証をオンプレ AD に残したまま AWS サービスと連携
Simple AD	Samba 4 ベースの互換ディレクトリ。小規模向け	軽量な LDAP 認証。Windows の機能は限定的
EC2 に自前で DC	通常の AD 構築	完全な制御が必要、既存の運用手順を変えたくない

AD の「サイトとサービス」や SRV レコードの仕組みは、AWS でもそのまま使えます（AD と DNS の関係は、このブログの連載「DNS入門」第10回の「AD統合DNS」で詳しく扱っています。サイトと SRV による DC の探し方は連載「Active Directory入門」第4回・第6回）。VPC の DHCP オプションセット（第7回）で DNS を DC に向けるか、Route 53 Resolver の転送ルールで AD のドメインだけを DC へ転送します。Managed AD では Domain Admins・Enterprise Admins の権限は使えません（AWS が管理しています。スキーマの拡張は、LDIF ファイルをコンソールから取り込む形でできます）。EC2 のシームレスなドメイン参加では、SSM 経由で起動時に自動で参加させます。

なお、Simple AD は2026年7月30日から新しい顧客の受け付けを止めています（既存の顧客は引き続き作成できます。AWS は Managed Microsoft AD か AD Connector を勧めています）。クラウドのディレクトリが LDAP を話すかどうかは、このブログの連載「LDAP入門」第10回の「クラウドの LDAP」で詳しく扱います。

---

AWS Organizations と SCP

Organizations は、複数の AWS アカウントを1つの組織として束ねるサービスです。「管理アカウント」の下に「組織単位（OU）」を階層化し、その中に「メンバーアカウント」を置きます。

機能は大きく3つあります。

1. 一括請求：全アカウントの請求を管理アカウントにまとめ、RI／Savings Plans・S3 のボリューム割引を組織全体で共有します
2. サービスコントロールポリシー（SCP）：OU やアカウントに「できることの上限」を付けます。例は「ap-northeast-1 以外のリージョンでのリソース作成を拒否」「CloudTrail・GuardDuty の無効化を拒否」「ルートユーザーの操作を拒否」です
3. サービス連携：CloudTrail の組織トレイル、Config、GuardDuty、Security Hub、AWS Backup、Identity Center の委任管理です

SCP は権限を与えるものではなく「許可の上限」であり、管理アカウント自身には効きません。冒頭の2つ目の相談がこれで、設定の誤りではなく仕様です。管理アカウントは請求と組織の管理だけに使い、業務のリソースはメンバーアカウントに置きます。

2024年には SCP の対になる RCP（リソースコントロールポリシー）が追加され、「組織外の主体から S3 や KMS へアクセスさせない」というデータ境界を組織全体に強制できるようになりました。OU の設計は「Security／Infrastructure／Workloads（Prod／Dev）／Sandbox」のような AWS 推奨の構成を起点にすると、Control Tower（第12回）との相性がよいです。

• 管理アカウント → OU → メンバーアカウントの階層。一括請求と割引の共有
• SCP＝許可の上限（拒否リスト）。RCP＝リソース側のデータ境界
• OU は Security／Infrastructure／Workloads／Sandbox が起点

---

考えてみよう

1. 手元の AWS アカウントで、アクセスキーを持つ IAM ユーザーはいくつありますか。認証情報レポートで、MFA の有無とキーの最終使用日を確かめ、ロールや Identity Center に置き換えられるものを挙げてください
2. 「本番アカウントの CloudTrail を誰にも止めさせない」には、IAM ポリシー・アクセス許可の境界・SCP のどれを使うのがよいでしょう。管理アカウントにはどう備えますか
3. 監査用アカウントの担当者に、本番アカウントのログ用の S3 バケットを読ませたいとします。本番アカウントに IAM ユーザーを作らずに済ませるには、どちらのアカウントに何を用意し、どのポリシーに Allow を書く必要がありますか

ヒント：1は「IAM ユーザー・グループ・ロール」と「ルートユーザーの保護と MFA」、2は「ポリシーの種類と評価の順序」と「AWS Organizations と SCP」、3は「STS（Security Token Service）と AssumeRole」と、「ポリシーの種類と評価の順序」のクロスアカウントの条件を見直してください。

---

まとめ

• IAM は AWS の API 呼び出しの認証・認可。デフォルト拒否で、明示的な Deny が最優先
• サービスにはロール、人には Identity Center 経由の一時的な権限。恒久のアクセスキーを配らない
• ポリシーはアイデンティティベース・リソースベース・境界・SCP／RCP・セッションポリシーの組み合わせで評価され、クロスアカウントは両側に Allow が必要
• ルートユーザーは MFA を付けてアクセスキーを作らず、日常には使わない
• STS の一時認証情報は Kerberos のチケットと同じ発想で、クロスアカウントの基本
• オンプレの AD は Managed Microsoft AD・AD Connector・Simple AD・EC2 の DC から選ぶ
• Organizations の SCP は許可の上限で、管理アカウントには効かない。RCP はリソース側のデータ境界

次回は、KMS による暗号化、Secrets Manager と Parameter Store、ACM、検知と境界防御のサービス、Azure との対応を扱います。

---

連載「クラウド入門」全14回

1. クラウドとは（定義・歴史・責任分界）
2. AWSの全体像
3. コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）
4. コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）
5. ストレージ
6. ネットワーキング 前編（VPC・サブネット・SG・NACL）
7. ネットワーキング 後編（DNS・接続・Route 53・CloudFront）
8. IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）（この記事）
9. IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）
10. データベース
11. 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
12. 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）
13. Well-Architectedフレームワーク
14. これまでのテーマとAWSの対応・まとめ