AWS IAM徹底解説：GCP IAM・Azure AD/Entra IDとの比較で学ぶ「権限設計・ゼロトラスト」実践ガイド

はじめに（要点サマリー）

本記事では、AWS Identity and Access Management（IAM） を中心に、GCP IAM（Cloud IAM）、Azure AD / Microsoft Entra ID + Azure RBAC を比較しながら、クラウド時代の「ユーザー・権限・認証」の考え方 を整理していきます。
先に結論を一言でまとめると、
- AWS：IAMユーザー／ロール／ポリシー／SCP を組み合わせた「JSONベースの権限エンジン」
- GCP：principal・role・resource の3つで考える「ロールベース権限（Cloud IAM）＋Org Policy」
- Azure：Entra ID(旧Azure AD)によるID管理と、Azure RBAC / Azure Policy での「IDとリソースを厳密に結びつける世界」
  というイメージで捉えると理解しやすいです。
設計の肝は、
1. 「人間」と「システム」をきちんと分けて扱うこと
2. IAMロールを中心に据えて「一時的な権限だけ渡す」こと
3. 最小権限（Least Privilege）を維持するための運用ルールを決めること
4. マルチアカウント／マルチクラウドを前提に、上位レベルのガードレールを引いておくこと
5. ゼロトラストに向けて「ネットワークではなくIDで守る」発想に切り替えること
  の5点です。
想定読者は、情報システム部門のクラウド移行担当、SaaS/業務アプリの開発者、SRE・インフラエンジニア、セキュリティ/ガバナンス担当、スタートアップの技術リーダーのみなさま。
読み終わるころには、AWS IAMを中心に、GCP IAM・Azure AD/Entra IDでも通用する**「権限設計の共通思考パターン」** が身についている状態を目指します。

1. IAMとは何をするサービスなのか：役割と「責任分界」

まず、IAMという名前をふんわりと日本語にすると、「誰が」「何に」「どこまで」触っていいかを決めるサービス です。

誰が（Who）：人間・アプリ・マイクロサービス・バッチ・他クラウド・パートナー…
何に（What）：S3バケット・EC2インスタンス・RDS・Lambda・VPC・CloudWatch などAWS上のあらゆるリソース
どこまで（How）：s3:GetObject だけ、ec2:Describe* だけ、rds:* は禁止… といったアクション単位

IAMは、これらをJSONポリシー（許可/拒否ルール）で表し、リクエストごとに評価して「OK/NG」を判断するエンジンです。

1.1 コンポーネントのざっくり対応表

AWS IAM
- アイデンティティ：IAMユーザー／IAMロール／IAMグループ
- ポリシー：AWS管理ポリシー／カスタマー管理／インラインポリシー／SCP／Permission Boundary
GCP IAM（Cloud IAM）
- principal（user/service account）＋role（プリンシパルに付ける）＋resource
Azure（Entra ID + Azure RBAC）
- ID：ユーザー／サービスプリンシパル／マネージドID
- 権限：ロール（Built-in / Custom）をスコープ（サブスクリプション／リソースグループ／リソース）に対して付与

どれも最終的には、「Principal（主体）＋Role／Policy（権限セット）＋Resource（対象）」 を組み合わせる点は同じなんです。

2. 人・システム・外部を分けて考える：アイデンティティの基本分類

IAM設計の最初の一歩は、「誰がAWSを触るのか」 を整理することです。

2.1 人間のアイデンティティ

管理者（プラットフォームチーム・セキュリティチーム）
開発者（アプリ開発・データエンジニアなど）
オペレーター（監視・運用チーム）
経営・監査担当（読み取り専用の可視化権限だけ欲しい人）

AWSでは、本来**「IAMユーザーに直接ログインさせる」よりも「外部IdP＋IAMロール」**が推奨です。

例：Entra ID / Okta / Google Workspace などで人を管理 → SSO で AWS に入る → IAMロールにスイッチロール

これはGCPやAzureでも同じで、

GCP：Cloud Identity / Workspace のアカウントでコンソールにログイン、Cloud IAMでプロジェクト権限を付与
Azure：Entra ID（旧Azure AD）のユーザーがポータルにログインし、Azure RBACでサブスクリプション/リソースグループ権限をもらう

という流れになります。

2.2 システムのアイデンティティ

人間以外にも、「権限を持つ存在」はたくさんいます。

アプリケーション（EC2上のAPIサーバ、ECS/EKSコンテナ、Lambda関数）
バッチ処理・ETLジョブ
他クラウドやオンプレからAWSにアクセスしてくるクライアント
SaaSからAWSにアクセスする連携

AWSでは、これらは基本的にIAMロールで表現します。

EC2には「インスタンスプロファイル（IAMロール）」
ECS/EKSタスクには「タスクロール」
Lambdaには「実行ロール」

という形で**「どのプログラムがどのロールを使うか」**を紐付けます。

GCPではサービスアカウント、Azureではサービスプリンシパル／マネージドIDが近いイメージです。

2.3 外部から来るアイデンティティ（フェデレーション）

自社IdPのユーザー
他社（パートナー）のユーザー
社外SaaS のID

これらは、SAML / OIDC / Web Identity Federation / IAM Identity Center（旧AWS SSO） などを使って一時的な権限を持つロールに変換します。
「外部ID → 一時クレデンシャル＋IAMロール」 という形にしてしまうことで、長期的な秘密鍵をAWS側に置かない設計ができます。

3. ポリシーの読み方・書き方：JSONに慣れる

IAMポリシーは、ざっくり言うと**「IF ○○なら、△△を許可／拒否する」**をJSONで書いたものです。

3.1 一番シンプルな例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::my-bucket/*"]
    }
  ]
}

Effect: Allow か Deny
Action: 許可/拒否したいAPIアクション（s3:* のようなワイルドカードも可）
Resource: 対象リソース（ARN）

評価ルールの感覚はこんな感じです。

すべてのリクエストはデフォルトDeny
どこかのポリシーでAllowされると許可候補
さらにどこかでDenyされていれば最終的にDeny優先

GCP IAMも

principal が
role （roles/storage.objectViewer のようなプリセット）を
resource にスコープで付与する

という構造で、評価モデルはほぼ同じです。Azure RBACも許可ベース＋上位スコープのDeny/Policyという形でよく似ています。

3.2 アイデンティティベース・リソースベース・SCP・Permission Boundary

AWSでは、用途によってポリシーが4種あります。

アイデンティティベースポリシー
- IAMユーザー／ロール／グループにアタッチするポリシー
- 日常的にもっとも触る部分です。
リソースベースポリシー
- S3バケットポリシー、SQSキューポリシー、KMSキーのキーポリシーなど、リソース側に直接付けるAllow/Deny
- クロスアカウントアクセスや、プライベートサービス公開に使われます。
SCP（Service Control Policy）
- AWS Organizations の仕組みで、アカウントやOU単位の「上限」 を決めるポリシー
- 「このOU配下では iam:* は一切禁止」など、ガードレールとして機能します。
- GCPでいうOrg Policy、AzureでいうAzure Policy＋Management GroupのDenyに近いイメージです。
Permission Boundary
- 特定のユーザーやロールに「これ以上の権限は絶対に与えない」という上限を設定

これらを組み合わせると、

日常の権限付与：アイデンティティベースポリシー
共有リソースの公開範囲：リソースポリシー
組織全体のルール：SCP
特定ユーザーの「上限」：Permission Boundary

という“多層防御”ができるようになります。

4. 具体的な設計パターン：ロール中心・最小権限・一時クレデンシャル

では、現場でよく使う“型”をいくつかご紹介しますね。

4.1 管理者・開発者・閲覧者ロール

複数アカウントをまたぐ場合でも、共通のロール名と権限セットを用意しておくと運用がとても楽になります。

OrganizationAdminRole
- アカウント全体の設定や、SCPの管理ができる強力ロール
- 実際にはごく少人数のみに付与
PlatformAdminRole
- VPC / IAM / CloudWatch / Security系サービスの管理
AppDeveloperRole
- 自プロジェクトのEC2/ECS/EKS/Lambda/S3などを操作できるが、IAMや組織設定は触れない
ReadOnlyRole
- すべてのAWSリソースを読み取りだけできるロール（監査・調査用）

GCPでも、roles/owner roles/editor roles/viewer に依存せず、カスタムロール で似た粒度を作るのが望ましいです。
Azureでも、Owner Contributor Reader に頼りすぎず、役割ごとのCustom Role を定義するのが定石です。

4.2 人間はIDプロバイダ→ロール、システムはロール→サービス

人間：
- Entra ID / Okta 等で認証 → AWS IAM Identity Center（AWS SSO）でロールにマッピング → コンソール/CLI からスイッチロール
システム：
- EC2/ECS/EKS/Lambdaにアタッチしたロールを通じてクレデンシャルを取得（AssumeRole / AssumeRoleWithWebIdentityなど）

長期のAccess Keyを個人に配る／サーバーに埋め込むのは極力避けて、「すべて一時クレデンシャルに寄せる」 のがゼロトラスト時代の基本です。

4.3 サンプル：読み取り専用ロールポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeAndList",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "rds:Describe*",
        "s3:ListAllMyBuckets",
        "s3:ListBucket",
        "cloudwatch:Describe*",
        "cloudwatch:Get*",
        "cloudwatch:List*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "S3ReadOnly",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-org-logs-*/*"
    }
  ]
}

このようなポリシーをロールにアタッチしておけば、監査・調査専用アカウントにスイッチして安全に情報を閲覧できます。

5. マルチアカウント・マルチクラウド時代のIAM

5.1 マルチアカウント（AWS Organizations）

AWSでは、

Organizations で複数アカウントを束ね、
OU（組織単位） にSCPを適用し、
各アカウント内でIAMロールを標準化する

というデザインが主流です。

パターンとしては：

security OU：ログ集約アカウント、セキュリティツールを集約したアカウントなど
shared-services OU：共通基盤（VPCハブ、IAM Identity Centerなど）
workloads OU：本番／検証／開発アカウントをぶら下げる

GCPならOrganization → Folder → Project、AzureならTenant(Entra IDテナント) → Management Group → Subscription → Resource Group が同じ役目です。

5.2 マルチクラウドにおけるID戦略

「人」のIDは、できれば1つのIdP（Entra IDなど）に寄せる
各クラウドでは、「外部IdPユーザー → ロール/ロール割り当て」に変換するだけにする
ログイン・多要素認証・パスワードポリシーはIdP側のポリシーで共通管理

こうすることで、

異動・退職・ロール変更の際、IdP側の操作だけで全クラウドのアクセスを止められる
セキュリティ・監査・IDライフサイクルを一箇所で管理できる

というメリットが生まれます。

6. ゼロトラストとIAM：ネットワークではなく「誰か」で守る

VPCやファイアウォールだけで守る発想から、最近は**「ゼロトラスト」＝IDを中心にした防御**が主流になってきています。

ポイントを簡単にまとめると：

ネットワーク上で「内側/外側」をあまり信用しない
すべてのアクセスに対して「誰が」「何に」「どの条件で」アクセスしているかを毎回検証
最小権限・一時クレデンシャル・多要素認証（MFA）を徹底
監査ログを集約し、異常振る舞いを素早く検知

AWS IAMは、

IAMロール＋STSトークン（短命トークン）
IAM Identity CenterとIdP連携
ポリシーでの細かい条件指定（aws:MultiFactorAuthPresent などの条件キー）

を活用することで、「MFAを使っているユーザーだけ特定操作を許可」 といったルールを組み立てられます。
GCP IAMやAzure RBACでも、条件付きアクセス（Conditional Access） などの機能と組み合わせることで、同じような世界を構築できます。

7. 運用で差がつく「IAMルール」とチェックリスト

7.1 ルール例（社内標準にしやすいもの）

原則：人にAccess Keyを持たせない
例外でAccess Keyを使う場合は、発行とローテーションのルールを明文化
管理者権限ロールは必ずMFA必須＋セッション時間短め
“AdministratorAccess”管理ポリシーを直接使う回数を最小限に（どうしても必要な特殊ロールだけ）
プロジェクトごとに「運用ロール」「開発ロール」「閲覧ロール」を3つ定義
IAMポリシーは、可能な限りサービス単位のカスタムポリシーに分割（S3用／EC2用など）

7.2 設計チェックリスト（最初の1週間で固める項目）

IDソース：人のIDはどこで管理するか（Entra ID／Google Workspace／社内AD…）
アカウント構造：AWS Organizations／GCP Org／Azure Management Groupの構成
ロール・ポリシー名の命名規則：{org}-{env}-{role-purpose} など
標準ロールセット：管理者／開発者／閲覧者／監査／自動化…
長期クレデンシャルの扱い：Access Key／サービスアカウントキー／クライアントシークレットのルール
MFAとパスワードポリシー：どこで・誰に必須とするか
SCP・Org Policy・Azure Policy：組織単位のガードレール
監査ログ：CloudTrail／Cloud Logging／Azure Activity Log の保管と可視化
権限レビューのサイクル：四半期に一度、ロールやユーザーを棚卸し
Runbook：権限エラー時の対応・緊急時の一時的権限付与の手順

8. ケーススタディ：3つの現場シナリオ

8.1 スタートアップの小規模チーム

背景：
- 少人数でAWS中心、GCPやAzureも一部使い始めた状況
アクション：
- Entra IDやGoogle WorkspaceをIdPにして、AWSにはIAM Identity Center経由でログイン
- AWS側には「Admin／Dev／ReadOnly」の3ロールのみ定義
- Access KeyはCI用など一部に限定し、すべてSecrets Managerに保管
効果：
- メンバーの入れ替わり時、IdP側の操作だけで全クラウドのアクセス調整が可能に
- 権限設計を極力シンプルに保ちながら、ゼロトラストに近い運用ができます。

8.2 大企業のマルチアカウント構成

背景：
- 部門ごとにAWSアカウント多数、GCPやAzureも部門ごとに使われている
アクション：
- AWS Organizationsでsecurity/shared-services/workloads OUを定義
- SCPで「rootユーザー禁止」「CloudTrailの停止禁止」「特定リージョン以外は禁止」などを設定
- Entra IDを中央IdPに、Azure／GCP／AWSすべてからSSOログイン
効果：
- 部門ごとの自由度をある程度維持しつつ、全社レベルのガードレールと監査を効かせられる
- インシデント時の「誰が何をしたか」の追跡がしやすくなります。

8.3 SaaSプロダクトのマルチテナント設計

背景：
- 複数テナントを1つのAWSアカウントに載せるSaaS
アクション：
- テナントごとにIAMロールを分けるのではなく、アプリ側でテナントIDによる権限チェックを実装
- AWS IAM側はアプリの必要最小限権限（S3の特定プレフィックス・DynamoDBテーブルなど）だけ付与
効果：
- IAMポリシーの複雑さを抑えつつ、テナントごとのアクセス制御はアプリケーションロジックで実現
- GCP／Azureに展開した際も同じアーキテクチャを持ち込めます。

9. 読者別の到達ゴール（具体的に）

9.1 情報システム部門・ITガバナンス担当の方

目指す姿：
- IdPを中心に据えた共通ID基盤を持ち、社員・外部委託・パートナーのアクセスを統一ポリシーのもとで管理できる状態。
本記事で得られるもの：
- AWS IAM・GCP IAM・Azure RBACを同じ目線で整理し、
- 「どこを全社ルールにし、どこを各プロジェクトに委ねるか」を決めるための具体的な視点。

9.2 アプリ開発者・SRE・インフラエンジニアの方

目指す姿：
- 新しいサービスを作るときに、迷わず「ロール設計」から入れるようになること。
本記事で得られるもの：
- 「人間にはIdP＋ロール、システムにはロールと一時クレデンシャル」という考え方を身につけ、
- IAMポリシーのサンプルをベースに、自分のプロジェクト用にアレンジするイメージ。

9.3 セキュリティチーム・監査担当の方

目指す姿：
- 「誰が、いつ、どこに、どんな権限を持っていたか」を説明責任を持って語れる状態。
本記事で得られるもの：
- SCP・Permission Boundary・監査ログ・権限レビューの流れをおさえることで、
- ゼロトラスト／ゼロスタンディング特権（常時管理者権限を持たない）などのモダンな運用に一歩踏み出すきっかけ。

9.4 スタートアップCTO・技術リーダーの方

目指す姿：
- 少人数のチームであっても、最初から「大人の権限設計」 をしておき、成長しても破綻しない状態。
本記事で得られるもの：
- 「最初からこれだけ決めておけば、あとで痛い目を見にくい」という、
- 現実的なミニマムルール（標準ロール・IdP・MFA・ログ・ガードレール） のイメージ。

10. 今日からできる3ステップ

「人」と「システム」のIDをリストアップする
- 管理者・開発者・運用者・バッチ・アプリ・外部SaaSなどを書き出してみましょう。
人はIdP＋ロール、システムはロールのみ、という方針を宣言する
- 可能であれば Access Key を配る運用をやめる（やめる方向に進む）と決めてしまいます。
最小限の標準ロールセットを作る
- Admin / Developer / ReadOnly の3つからで構いませんので、ポリシーをカスタムで定義し、チーム内に共有してみてください。

11. まとめ：IAMは「クラウドの土台」を支える縁の下の力持ち

AWS IAMは、サービス一覧の中だとどうしても「地味」に見えがちですが、
実は S3 / EC2 / RDS / Lambda / VPC / CloudFront / CloudWatch… どのサービスよりも先に考えるべき存在 です。

誰が（Who）
何に（What）
どこまで（How）

を丁寧に設計し、

人間のIDはIdPに集約してロールで権限を渡す
システムにはロールと一時クレデンシャルだけ渡す
SCPやPolicyで上位のガードレールを引く
ログとレビューで継続的に“権限の健康診断”をする

この流れを一度作ってしまえば、クラウドの規模が大きくなっても、マルチクラウドに広がっても、同じ考え方でスケールできる ようになります。

次のサービスの記事では、IAMと密接に関わる AWS Organizations（アカウント管理とSCP） もしくは、よりアプリ寄りに Amazon ECS/EKS などを取り上げ、GCP（GKE/Cloud Run）やAzure（AKS/App Service） との比較まで含めて解説していく予定です。
引き続き、一緒に少しずつ「壊れにくいクラウド基盤」を育てていきましょうね。