0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kaga-yasumitsu(加賀 泰光)inパナソニック コネクト株式会社

【AWS/GCP/Azure】AssumeRole「実装の差」から「思想の違い」をまとめてみた

Posted at

「AssumeRoleってAzureやGCPでどうやるの？」と時間を溶かしてるAWSエンジニア（主に自分）へ

안녕하신게라！パナソニック コネクト株式会社クラウドソリューション部の加賀です。

最近、マルチクラウド環境でインフラを構築・運用する機会が増えてきました。AWSをメインで使っていると「AWSのあの機能、AzureやGCPだとどう実現するんだっけ？」と脳内で変換することがよくあります。

特に、セキュアな権限管理の要であるAWS IAMロールとAssumeRole。これがもたらす「一時的な権限昇格」や「クロスアカウントアクセス」といった強力なパターンは、他のクラウドではどう実現するんでしたっけ？となりがちです。この違いを正しく理解しておくことは、セキュアなマルチクラウド環境を設計する上で極めて重要です。

この記事では、

  • AWSのIAMロールとAssumeRoleの仕組みを改めておさらいしたい方
  • AWSの知識をベースに、AzureやGCPの権限管理の概念をキャッチアップしたい方
  • 各クラウドで、どのリソースがどんな操作をしたかログで追跡したい方

に向けて、AWSのIAMロールに相当する機能をGCPとAzureそれぞれでどのように実現するのか、概念レベルで分かりやすく比較・解説します。

先にこの記事の結論をまとめると、以下の3点となります。

  • GCPはAWSと似ており、AssumeRoleに相当する権限借用（Impersonation） を用いる。
  • Azureは思想が異なり、ロールを動的に引き受けるAssumeRoleに直接相当する機能はない。
    → 代わりにPIMのJITロールの有効化やEntra B2Bのガバナンス機能で同様の目的を達成する。
  • これらの活動は、各クラウドの監査ログで「誰が、誰の権限で、何をしたか」まで追跡可能。

これらのポイントをAWSのIAMロールを基準に、一つずつ丁寧に解き明かしていきます。

※この記事は各機能の概念的な理解を目的としており、詳細な設定手順には触れません。

【AWS】IAMロールと監査ログ

まずは、今回の比較の基準となるAWSの仕組みからおさらいしましょう。

権限管理の仕組み → IAMロール

IAMロールは、特定の「役割（Role）」に権限を付与する仕組みです。IAMユーザのように個人に紐づくのではなく、EC2インスタンスやLambda関数といったAWSリソース、あるいは他のアカウントのユーザなどが「その役割を一時的に引き受ける（AssumeRole）」ことで、権限を利用します。

IAMロールを使う最大のメリットは、アクセスキーなどの長期的なクレデンシャル情報をコードや環境変数に埋め込む必要がなくなることです。

この仕組みを理解する上で重要なのが、「IAMロールの信頼ポリシー」と「IAMポリシー」という2種類のポリシーです。

  • IAMロールの信頼ポリシー
    「誰が」このロールを引き受ける（AssumeRole）ことを許可するかを定義します。
    例えば、「EC2インスタンスサービス (ec2.amazonaws.com) だけがこのロールを引き受けられる」のように、信頼する相手（プリンシパル）を指定します。
  • IAMポリシー（ロールにアタッチする権限ポリシー）
    「何を」できるかを定義します。
    例えば、「S3のmy-backupバケットに対してのみ、オブジェクトの書き込み(PutObject)を許可する」のように、具体的な操作権限を定義します。

この2段構えにより、「EC2インスタンスが、バックアップ用のロールを引き受けて、S3バケットにファイルを書き込む」といった一連のセキュアな操作が実現できます。

IAMロールの代表的なユースケース

このIAMロールの仕組みは、主に2つの強力なユースケースで活用されます。

  • 一時的な権限昇格
    普段は権限を持たないユーザやリソースが、特定の操作（デプロイ、バックアップなど）を行うときだけ、必要な権限を持つロールを一時的に引き受ける。
  • クロスアカウントアクセス
    アカウントAのリソースが、アカウントBのロールを引き受けることで、セキュアにアカウントB内のリソースを操作する。

これにより、開発者は普段のIAM Userの権限と、特権ロールの権限を動的に切り替えながら作業ができます。この 「IDを使い分ける」という感覚が、AWSエンジニアの基本体験となっています。AWS CLIのプロファイルを切り替えたり、マネジメントコンソールで「ロールの切り替え」をしたりする、あのお馴染みの操作の裏側ではこの仕組みが動いています。

以降のセクションでは、GCPとAzureでこれらのシナリオがどのように実現されるか、という視点で比較していきます。

監査ログでの確認 → CloudTrail

AWSでは、CloudTrailを見ることでIAMロールに関連する操作の履歴を確認できます。特に、どのエンティティがロールを引き受け、どのような操作を行ったかを追跡することが重要です。

  • userIdentityオブジェクトに注目します。
  • ロール引き受け後の操作ログでは、typeがAssumedRoleとなります。
  • principalIdにAROA...:session-nameの形式で引き受けたロールのIDとセッション名が記録されます。
  • arnにはarn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/ROLE_SESSION_NAMEという形式で、「どのロールセッションが」 操作したかが明確に記録されます。

これにより、「いつ、EC2インスタンスが、どのロールを引き受けて、S3バケットにファイルを置いたか」といった一連の行動を追跡できます。

【GCP】サービスアカウントとCloud Audit Logs

次に、AWSと概念的に似ている部分が多いGCPを見ていきましょう。

権限管理の仕組み → サービスアカウント

GCPでは 「サービスアカウント」 が、AWSのIAMロールに相当する、ワークロード（VMインスタンス、Cloud Runなど、人間以外のプログラム）に紐づくアイデンティティとして機能します。
しかし、両者には少しだけ思想の違いがあり、それが実装の差となっています。
AWSのIAMロールは純粋な「役割（Role）」であり、それ自体がリソースを所有することはできません。
一方、GCPのサービスアカウントは、ユーザアカウントと同じレベルの「ID（プリンシパル）」として扱われ、プロジェクトやリソースに対してOwnerロールを付与できます。
この違いが、後述する権限借用の仕組みにも影響を与えています。

GCPでは、AWSのように「信頼」と「権限」を別々のポリシーで定義するのではなく、「誰に（プリンシパル）、何を（ロール）、どこで（リソース）」許可するかをIAMポリシーに記載し、バインディングします。

  • プリンシパル (Principal)
    「誰が」を定義します。操作の主体を指し、Googleアカウント、Googleグループ、そしてここで重要なサービスアカウントなどが該当します。
  • ロール (Role)
    「何が」出来るか、具体的な権限のセットを定義します。これはAWSの権限ポリシーに相当します。例えば、「ストレージオブジェクト閲覧者(roles/storage.objectViewer)」のように定義済みのロールや、カスタムロールを指定します。

この「プリンシパル」と「ロール」を、プロジェクトやストレージバケットといったリソースに バインドする（結びつける） ことで権限が付与されます。

AWSのAssumeRoleに相当する「権限借用（Impersonation）」

GCPでは、AWSのAssumeRoleが実現する「一時的な権限昇格」や「クロスプロジェクトアクセス」をどう実現するのでしょうか。
ここで登場するのが 「サービスアカウントの権限借用 （Impersonation）」 です。

これは、あるID（ユーザや別のサービスアカウント）が、一時的に特定のサービスアカウントになりすまして操作する仕組みです。

  • 一時的な権限昇格として
    開発者が普段は読み取り専用の権限しか持たないが、デプロイ時にはデプロイ用のサービスアカウントの権限を借用して書き込み操作を行う、といったユースケースで利用できます。
  • クロスプロジェクトアクセスとして
    AWSのクロスアカウントロール利用と非常によく似たセキュアな運用を可能にします。

この信頼関係の設定方法は、AWSのIAMロールの信頼ポリシーと対比すると理解しやすくなります。

  • AWSのAssumeRoleでは
    ロール側（権限を貸す側）のIAMロールの信頼ポリシーで、「誰が（プリンシパル）このロールを引き受けられるか」を定義します。

  • GCPの権限借用では
    GCPでは、権限を借用されるサービスアカウントに対するIAMポリシーの中で、「誰が（どのプリンシパルが）このサービスアカウントとして振る舞うことを許可されるか」を定義します。
    具体的には「権限を借用されるサービスアカウント（ターゲットSA）」に対してIAMポリシーを設定します。このポリシーの中で「サービスアカウント トークン作成者（roles/iam.serviceAccountTokenCreator）」というロールを、操作元のID（プリンシパル）に付与します。これにより、そのプリンシパルはターゲットSAの権限を持つ短期的なOAuth2.0アクセストークンを生成できるようになります。

    この他、サービスアカウントキーを管理する権限（iam.serviceAccountKeys.create）を使って永続的なサービスアカウントキーを生成する方法もありますが、これは長期的なクレデンシャルを発行することになり、漏洩リスクが高いため原則として非推奨です。監査や権限管理の観点からも、紹介した短期トークンを生成する「サービスアカウント トークン作成者」ロールの利用を強く推奨します。

AWSでは「権限を貸す側」のIAMロールの信頼ポリシーで相手を定義します。一方GCPでは、「権限を貸す側」であるサービスアカウント自身に「『権限を借りる側』のプリンシパルに、自分自身になりすますことを許可する」というIAMポリシーを設定します。
つまり、権限を委任する設定をどちら側で行うかに違いがあります。

アプローチは異なりますが、どちらも「権限を貸す側」のエンティティ（AWSではIAMロール、GCPではサービスアカウント）に設定を施すことで信頼関係を定義する点は共通です。

監査ログでの確認 → Cloud Audit Logs

GCPでは、Cloud Audit Logs でサービスアカウントの活動を確認します。

  • authenticationInfoオブジェクトに注目します。
  • principalEmailにyour-service-account@...iam.gserviceaccount.comのように、操作を実行したサービスアカウントのメールアドレスが記録されます。
  • 権限借用が行われた場合、ログにはさらに興味深い情報が記録されます。principalEmailには権限を借用されたサービスアカウント（ターゲットSA）が記録され、authenticationInfo内のserviceAccountDelegationInfoフィールドに、実際に操作を開始した元のID（操作元ID） が記録されます。

これにより、「誰が、どのサービスアカウントの権限を借用して、何をしたか」まで正確に追跡できます。

【Azure】マネージドIDとAzure Monitor Activity Log

最後にAzureです。AzureはID基盤として Microsoft Entra ID（以下 Entra ID） が中心にあり、AWS/GCPとは異なるアプローチを取るため、特に混乱しやすいポイントです。

権限管理の仕組み → マネージドIDとAzure RBAC

Azureでは 「マネージドID」 がワークロード（VM、App Serviceなど、人間以外のプログラム）のIDとなり、「Azure RBAC (ロールベースのアクセス制御)」 によって権限が付与されます。

マネージドIDの種類

まず、AzureのマネージドIDには2種類あることを理解するのが重要です。

  • システム割り当てマネージドID
    VMなどのリソースを作成する際に有効化すると、そのリソース専用のID（サービスプリンシパル）がEntra ID上に作られます。
    ライフサイクルはリソースと1対1で連動し、リソースを削除するとIDも自動で削除されるため、管理の手間が省け、特定のVMに固有の権限を与える場合に最適です。
  • ユーザ割り当てマネージドID
    独立したAzureリソースとして先にIDを作成し、それを複数のリソース（複数のVMなど）に割り当てることができます。例えば、「Webサーバ群に共通のDBアクセス権限を与える」といったシナリオで、権限設定を一度で済ませたい場合に便利です。

ロールの割り当て

Azureの権限付与は「誰に、何を、どの範囲で許可するか」というロールの割り当てによって実現されます。

  • セキュリティプリンシパル
    「誰が」を定義します。操作の主体となるIDで、ここではマネージドIDが該当します。もちろん、ユーザやグループも指定できます。
  • ロール定義
    「何を」出来るのかを定義した、実行可能な操作のコレクションです。AWSの権限ポリシーに相当します。例えば、「ストレージ BLOB データ閲覧者」や「共同作成者」といった組み込みロール、またはカスタムロールを指定します。
  • スコープ
    「どこで」その権限が有効な範囲を定義します。これがAzureの大きな特徴です。
    サブスクリプション全体、特定のリソースグループ、個々のリソース（ストレージアカウントなど）といった階層で指定できます。

AWSのIAMポリシー内でリソースARNを指定するのとは異なり、Azureでは「どの階層（スコープ）で権限を割り当てるか」が権限管理の重要な要素となります。

この階層的なスコープ指定は、Azureの大きな特徴です。組織の管理単位（サブスクリプションやリソースグループ）と権限を連動させることで、トップダウンのガバナンスを適用しやすくなるよう設計されています。

AWSのAssumeRoleに相当する仕組みは？ → 設計思想の違い

Azureには、AWSのAssumeRoleやGCPの権限借用（Impersonation）のように、あるIDが別の役割（ロールやサービスアカウント）に動的になりすます、という単一の機能は存在しません。
AzureのID基盤であるEntra IDが、オンプレミスで長年使われてきたActive Directory (AD) の思想を色濃く受け継いでいる背景が設計思想の中心にあります。

ADの世界では「IDの一元管理」が基本であり、「誰がどのグループに所属し、そのグループにどの権限が与えられているか」という静的な権限管理が中心でした。
この思想に基づき、AzureではIDを動的に切り替えるのではなく、「IDはそのままで、そのIDに割り当てられたロールを一時的に有効化する」というアプローチ（後述、PIM）を取ります。全ての操作が元のIDに紐づくことを保証し、監査証跡を明確にする、という思想が根底にあります。
そのため、IDを動的に切り替えるAWS/GCPのアプローチとは異なり「どのIDに、どの権限を、どの範囲で与えるか」という実装の違いとなって現れます。

では、「一時的な権限昇格」や「クロステナントアクセス」はどう実現するのでしょうか。

  • 一時的な権限昇格として
    Azureでは「Privileged Identity Management (PIM)」という機能を使います。
    これにより、ユーザは通常は権限を持たない「資格のある（Eligible）」状態となり、必要な時に理由を申請してロールを有効化（アクティベート）することで、Just-in-Time (JIT) な権限昇格を実現します。
    ただし、現状、PIMは主にユーザやグループに対して利用される機能であり、マネージドIDのようなワークロードID（サービスプリンシパル）に対して直接「資格のある（Eligible）」状態として割り当てることはできません。この点はワークロードが自律的に権限昇格できるAWSのAssumeRoleと大きく異なるため注意が必要です。（サービスプリンシパルをEntra IDグループに追加し、そのグループをPIMで管理する方法もありますが、人の手による有効化が必要となり、自動化されたワークロードの権限昇格には適していません。）
  • クロステナントアクセスとして
    AWSのクロスアカウントアクセスに相当するシナリオは、ID連携の仕組みで実現されます。
    • Entra B2Bコラボレーション
      他の組織のユーザを自社のEntra IDにゲストとして招待し、そのゲストIDに対してRBACでロールを割り当てます。
    • Azure Lighthouse
      サービスプロバイダが、顧客のテナントのリソースを、自社のテナントから委任されて管理するための仕組みです。

このように、Azureは「ロールの信頼関係」で実現するAWS/GCPとは異なり、「IDそのものを信頼し、連携させる」という思想でクロステナントの課題を解決します。どこまでも静的なのです。

許可の加算モデル

Azureの権限は「上位から継承され、複数ある場合は加算される」というシンプルなモデルです。

  • 上位スコープから権限は継承される
    上位スコープ（例：サブスクリプション）で割り当てられた権限は、下位スコープ（例：リソースグループ）に継承されます。
  • 許可は加算される (OR評価)
    あるIDに継承も含めて複数のロールが割り当てられた場合、そのIDは割り当てられたすべてのロールに含まれる権限の和を行使できます。

この「許可の加算モデル」は、AWSエンジニアが特に戸惑うポイントかもしれません。

AWSのIAMポリシーでは"Effect": "Deny"で特定の権限を明示的に拒否するのが一般的ですが、Azure RBACのロール割り当てには基本的にDeny（拒否）の割り当てがありません。
Azure PolicyのDenyアクションや、Azure Blueprints等が利用する特殊な拒否割り当て（Deny Assignments）という仕組みで大規模なガードレールとして拒否は可能ですが、ユーザが個別に設定するものではありません。AWSのようにIAMポリシー内で柔軟に拒否を設定する使い方とは思想が異なります。

監査ログでの確認 → Azure Monitor Activity Log

Azureでは、Azure Monitor の Activity Log でマネージドIDによる操作を追跡できます。

  • イベントのCallerやclaimsプロパティに注目します。
  • Callerに[マネージドID名]や、そのオブジェクトID (GUID形式) が表示されます。
  • claims内のappidにマネージドIDのアプリケーションIDが記録されている場合もあります。どのプロパティにIDが記録されるかはイベントの種類によって異なる場合があるため、実際にログを確認しながら追跡するのが確実です。

Azureでは、すべての操作主体がEntra IDのIDに紐づくため、ログのCallerを見ることで、それがユーザなのか、マネージドIDなのかを判別することができます。

まとめ、各クラウドの概念対応表

最後に、各クラウドの権限管理と監査ログの仕組みを一覧表にまとめます。

目的 AWS GCP Azure
役割・ID
(ワークロードのID)		 IAMロール サービスアカウント マネージドID
(システム/ユーザ割り当て)
権限
(何ができるか)		 IAMポリシー
(権限ポリシー)		 IAMのロール Azure RBAC
(ロール定義)
信頼・紐付け
(誰がどう使えるか)		 IAMポリシー
(信頼ポリシー)		 IAMポリシーの
バインディング
(権限借用も含む)		 ロールの割り当て
(IDとスコープを紐付け)
一時的な権限借用
(AssumeRole相当)		 sts:AssumeRole 権限借用
(Impersonation)		 (直接の相当機能なし)
PIMのロールJITで代替
Entra B2B/Lighthouseで
テナント間を静的に連携
監査ログ
(誰が何をしたか)		 CloudTrail Cloud Audit Logs Azure Monitor
(Activity Log)

呼び方や実装は違えど、「ワークロードに長期的な認証情報を埋め込まず、動的に取得した短期的な認証情報でAPIを呼び出す」というセキュアな設計思想は共通しています。しかし、その実現方法には各クラウドの設計思想が色濃く反映されています。

  • AWS
    「信頼ポリシー」と「権限ポリシー」の2段構えで、「ロール」中心の柔軟な権限委任を実現します。
  • GCP
    AWSと似た思想を持つが、サービスアカウントという「ID」を軸に、IAMの標準的な仕組みで権限借用を実現します。
  • Azure
    Entra IDによる「ID」の一元管理が基本。IDはそのままで、必要な時にロールを有効化するPIMと、ID自体を連携させるB2BやLighthouseで実現します。

マルチクラウド環境の権限設計で壁にぶつかった時「なぜこのクラウドは、こんな仕様なんだ？」と感じたら、ぜひこの記事で解説した「思想の違い」に立ち返ってみてください。
それは単なる機能の差ではなく、各クラウドが持つ哲学の差なのです。その背景を理解することが、より堅牢でセキュアなシステムを構築するための最短ルートになるはずです。

この記事が、皆さんのマルチクラウドジャーニーの一助となれば幸いです。

次回予告

今回は、EC2やLambdaのようなクラウド内部のワークロード（機械）が、AssumeRoleに相当する機能を使って権限を得る仕組みを比較しました。しかし、現代のセキュアな開発においてもう一つ欠かせないのが、GitHub ActionsやCircleCIのようなクラウド外部のワークロードとの連携です。

「CI/CDパイプラインに、もうアクセスキーは埋め込みたくない！」その背中をそっと押します。

次回の記事では、この「外部ワークロード連携」をテーマに、アクセスキーなしでクラウドを操作する仕組みを掘り下げます。
AWSのAssumeRoleWithWebIdentity（OIDC連携）、GCPのWorkload Identity連携、そしてAzureのワークロードIDのフェデレーション。これら三者三様の「実装の差」を「思想の差」から比較します。お楽しみに！

お断り
記事内容は個人の見解であり、所属組織の立場や戦略・意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?