【初心者向け】クラウドのIAMを紹介-「誰が」「何を」「どうできる？」-（AWS, Google Cloud, Azure）
対象読者
- クラウドを使い始めたが、IAMの概念が掴みきれていない方
- 特定のクラウドIAMは分かるが、他のクラウドとの違いや思想を知りたい方
- 最小権限の原則や組織的なガバナンスをどう実現すべきか悩んでいる方
TL;DR
- IAMは**「誰が (プリンシパル)」「何に (リソース)」「何をできるか (権限)」**を管理する仕組み。この基本は3クラウド共通です。
- ユーザーIDの基盤が根本的に違う。AWSは独立、GCはGoogleアカウント、AzureはMicrosoft Entra IDが中心。
- 権限の作り方も思想が違う。AWSは柔軟なカスタムポリシー、GCは豊富な事前定義ロール、Azureはスコープでの制御が特徴。
- 組織管理はAWSはガードレール(SCP)、GC/Azureはトップダウンの継承モデル。一時的な権限昇格も各社で仕組みが異なる。
第1章: IAMの共通概念 - クラウドセキュリティの心臓部
クラウドを利用する上で、避けては通れない最重要サービスが「IAM (Identity and Access Management)」です。IAMは、クラウド上のあらゆるリソースへのアクセスを制御するセキュリティの根幹を担います。
1-1. IAMの役割は「認証」と「認可」
IAMが担う役割は、大きく分けて2つです。
-
認証 (Authentication): 「あなたは誰ですか？」
IDとパスワード、多要素認証などを用いて、アクセスしようとしているのが本当に本人かを確認するプロセスです。 -
認可 (Authorization): 「あなたは何ができますか？」
認証されたユーザーに対し、どのリソースへの、どの操作を許可するかを定義するプロセスです。
この「認証」と「認可」を通じて、**「誰が (プリンシパル)」「どのリソースに」「どんな操作 (権限) を許可するか」**を管理するのがIAMの本質であり、この考え方は3つのクラウドプラットフォームで共通しています。
IAM を使用すると、AWS リソースへのアクセスを安全に管理できます。IAM を使用して、誰を認証 (サインイン) し、誰にリソースの使用を認可 (アクセス許可) するかを制御します。
1-2. IAMを構成する基本要素
IAMを理解するために、まずは3つの基本要素を押さえましょう。
- プリンシパル (Principal): 操作を行う主体。「誰が」にあたる部分。人間のユーザーだけでなく、アプリケーションやサーバー（ワークロード）も含まれます。
- 権限 (Permission/Action): 「何をできるか」という操作の定義。「VMを起動する」「ストレージバケットからファイルを読み込む」など。
- リソース (Resource): 操作の対象。「何に」にあたる部分。VM、データベースなど。
- ポリシー/ロール (Policy/Role): プリンシパルと権限、リソースを結びつけるルールや役割の定義。
これらの関係性を図にすると以下のようになります。
第2章: 基本要素の比較 - 似ているようで全く違う各社の思想
基本概念は同じでも、その実装方法は各クラウドで大きく異なります。特に「プリンシパル（誰が）」と「権限の与え方」には、各社の出自や思想が色濃く反映されています。
2-1. 「誰が」の定義 - ID基盤の違い
これが最も根本的な違いです。
-
AWS: 独立したIAMユーザー
AWSでは、クラウド環境ごとに独立したIAMユーザーを作成するのが基本です。AWS Identity and Access Management (IAM) ユーザーは、AWS アカウント内に作成するアイデンティティです。
-
Google Cloud: Googleアカウントが中心
Google Cloudでは、個人のGmailや企業用のGoogle Workspaceで使われるGoogleアカウントがユーザーの基本となります。Cloud Identityというサービスで、Google Workspaceを契約していなくても企業ドメインのGoogleアカウントを管理できます。プリンシパルは、Google アカウント（エンドユーザー用）、サービス アカウント（アプリと仮想マシン用）、...のいずれかになります。
-
Azure: Microsoft Entra IDが世界の中心
Azureは、Microsoft 365などでも利用されるID基盤 Microsoft Entra ID (旧Azure AD) と不可分です。Entra IDに登録されたユーザーが、Azureリソースへのアクセス主体となります。Azure RBAC は、Azure Resource Manager 上に構築された承認システムであり、Azure リソースに対する詳細なアクセス管理を提供します。
2-2. 権限の与え方 - ロールとポリシーの関係性
「何をできるか」を定義する方法も、アプローチが異なります。
-
AWS: ポリシーをアタッチ（貼り付け）する
AWSでは、JSON形式で権限を記述したIAMポリシーを作成し、それをユーザー、グループ、ロールに**アタッチ（貼り付け）**します。非常に柔軟で詳細な権限設定が可能で、カスタムポリシーを自作する文化が根付いています。 -
Google Cloud: 権限セットとしてのロール
GCでは、ロール自体が権限の集合体として定義されています。「編集者」「閲覧者」といった数百種類の事前定義ロールが用意されており、基本的にはこれらを選択してプリンシパルに割り当てます。Googleによるメンテナンスのメリットが大きく、カスタムロールは最終手段と位置づけられています。 -
Azure: スコープを意識したロールの割り当て
AzureもGCと似ており、組み込みロールを割り当てるのが基本です。しかし最大の特徴はスコープという概念です。「Aさんは、サブスクリプションXの中では『共同作成者』だが、リソースグループYの中では『閲覧者』だ」というように、場所に応じて役割を変えることができます。
第3章: 組織と階層での管理 - エンタープライズガバナンスの実現
個々の権限設定だけでなく、企業全体としてクラウドをどう統制するかも重要です。そのための「階層構造」と「組織レベルのルール」にも大きな違いがあります。
3-1. 階層構造の違い
-
AWS: 独立したアカウントをOrganizationsで束ねる
基本単位は独立したAWSアカウントです。これらをAWS Organizationsというサービスで束ね、OU（組織単位）でグルーピングします。アカウントの独立性が高く、請求やリソースの分離が明確です。 -
Google Cloud: 組織 > フォルダ > プロジェクトのトップダウン
組織を最上位とし、その下にフォルダ、プロジェクトと続く階層構造が前提です。リソースは必ずプロジェクトに所属し、上位で設定したIAMポリシーは下位に継承されます。 -
Azure: 管理グループで柔軟な階層を構成
管理グループを用いて、課金単位であるサブスクリプションを柔軟にグルーピングできます。GCと同様、上位スコープで割り当てたロールは下位に継承されます。
3-2. 組織レベルの権限制御
-
AWS: SCPによるガードレール
サービスコントロールポリシー (SCP) を使って、組織やOUに対し「許可される操作の最大範囲」を定めます。これは権限を与えるものではなく、上限を設けるガードレールです。アカウント内のIAMユーザーが管理者でも、SCPで禁止されていればその操作はできません。SCP は、組織内のすべての AWS アカウント で使用できるアクセス許可を集中管理する方法を提供します。
-
Google Cloud: ポリシーの継承と組織のポリシー
IAMポリシーの継承により、トップダウンで一貫した権限管理が可能です。加えて、組織のポリシーサービスを使い、「リソースを作成できるリージョンを制限する」といったルール（制約）を強制できます。 -
Azure: Azure Policyによるルール強制
IAMロール（RBAC）による権限管理に加え、Azure Policyが強力です。「暗号化が有効でないストレージは作成できない」といったコンプライアンスルールを定義し、組織全体に強制することができます。RBACとPolicyの二段構えでガバナンスを実現します。
第4章: 応用編 - 一時的な権限昇格とSSO
実際の運用では、常時強い権限を持つのではなく、必要な時だけ権限を得る仕組みや、既存のIDで安全にログインするSSOが不可欠です。
4-1. 一時的な権限の利用
-
AWS: スイッチロール (Assume Role)
ユーザーやEC2インスタンスなどが、IAMロールを引き受ける (Assume) ことで、一時的にそのロールの権限を獲得します。コンソール上で役割を切り替える体験はAWSの大きな特徴です。 -
Google Cloud: サービスアカウントの権限借用 (Impersonation)
ユーザーが特定のサービスアカウントになりすますことで、そのサービスアカウントの権限を一時的に利用します。「役割の帽子をかぶる」AWSに対し、こちらは「別人の仮面をかぶる」イメージです。 -
Azure: PIMによるJust-In-Time (JIT) アクセス
Privileged Identity Management (PIM) を使い、特権ロールを「アクティブ化」する申請・承認プロセスを導入します。理由を入力し、多要素認証を経て、期間限定で（例: 8時間だけ）ロールが有効になります。監査を重視した厳格な仕組みです。Azure AD Privileged Identity Management (PIM) は、組織内の重要なリソースへのアクセスを管理、制御、監視できるサービスです。
Microsoft Learn - Azure AD Privileged Identity Management とは
4-2. SSOとID連携のベストプラクティス
- AWS: IAM Identity Center (旧AWS SSO) をハブとし、Microsoft Entra IDやOktaなどの外部IDプロバイダ (IdP) と連携するのがベストプラクティス。パスワードを持つIAMユーザーの作成は非推奨です。
- Google Cloud: Cloud Identity または Google Workspace のアカウントをID基盤の中心に据えます。外部IdPとは Workforce Identity連携 で接続します。
- Azure: Microsoft Entra ID がIdPの中心であり、Azureへのログインも、他のSaaSへのSSOもEntra IDを基点に行うのが自然な形です。
第5章: モダンなIAMの必須要素
IAMは設定して終わりではありません。ゼロトラスト時代に求められる、より動的でセキュアな管理手法を見ていきましょう。
5-1. 機械のID管理 (ワークロードアイデンティティ)
VMやコンテナが他のサービスを呼び出す際、アクセスキーなどをコードに埋め込むのは非常に危険です。各クラウドには、これを避けるための「キーレス認証」の仕組みがあります。
- AWS: IAM Roles for EC2/ECS/Lambda
- Google Cloud: サービスアカウント
- Azure: マネージドID
これらを使うことで、ワークロードは一時的な認証情報を自動で取得し、安全に他のサービスを呼び出せます。これは3クラウド共通の最重要プラクティスです。
5-2. アクセス場所の制御 (コンテキストアウェアアクセス)
「誰が」だけでなく、「どこから」「どんなデバイスで」といった条件（コンテキスト）でアクセスを制御します。
-
AWS: IAMポリシーの
Condition句でIPアドレスなどを指定。 - Google Cloud: VPC Service Controlsでネットワーク境界を作成。
- Azure: 条件付きアクセスでユーザー、場所、デバイス状態を組み合わせた柔軟なルールを定義。
5-3. 権限の監査と最適化
付与した権限が過剰でないか、継続的に見直すことが重要です。
- AWS: IAM Access Analyzerが未使用の権限を検出し、ポリシーの最適化案を提示。
- Google Cloud: IAM Recommenderが機械学習で過剰な権限を分析し、具体的な削除案を推奨。
- Azure: PIMのアクセスレビューで特権ロールの要否を定期的に棚卸しするプロセスを自動化。
第6章: まとめ - 各クラウドの思想
最後に、各クラウドのIAMの考え方をまとめます。
-
AWS: 柔軟性と詳細なコントロールが可能。 豊富な機能と実績があり、ユーザーがJSONポリシーを記述して「最小権限」を自ら作り上げていく文化。ベストプラクティスが確立されている安心感があります。
-
Google Cloud: シンプルさとGoogle基盤への集約。 Googleアカウントを中心としたID管理と、豊富な事前定義ロールにより、シンプルで間違いの少ない権限管理を目指します。IAM Recommenderなど、MLを活用した自動最適化も特徴です。
-
Azure: エンタープライズの既存環境との親和性と多層防御。 Microsoft Entra IDを中核に、RBAC（役割）とAzure Policy（ルール）を組み合わせることで、柔軟かつ強力なガバナンスを実現します。PIMなど、監査やコンプライアンスを意識した機能が豊富です。
基本的に共通する概念はあるものの、それぞれの事業者の強みや考え方の違いから微妙に異なる部分はあるので、特定のクラウドに特化して使う場合は、その点をきちんと押さえたうえで使う必要があります。
広く、浅くでまとめましたので、足りない面も多いとは思いますが、ここを第１歩として皆さんの理解の助けとなれば幸いです。