RAM ロールとは - Resource Access Management - Alibaba Cloud ドキュメントセンター

RAM ロール

RAM ロールは、ポリシーがアタッチされた RAM アイデンティティの一種です。RAM ユーザーとは異なり、ロールは単一の個人やアプリケーションに関連付けられておらず、信頼されたプリンシパルであれば誰でも引き受けることができます。ロールには、パスワードや AccessKey ペアなどの長期的な認証情報はありません。プリンシパルがロールを引き受けると、Security Token Service (STS) はそのセッションでのみ有効な一時的なセキュリティ認証情報を生成します。

各 RAM ロールはアカウント内のリソースであり、ポリシーや API コールでロールを参照するために使用される一意の Alibaba Cloud リソース名 (ARN) (acs:ram::<account-id>:role/<role-name>) を持ちます。ロールの ARN を確認するには、「RAM ロールの表示」をご参照ください。

RAM ロールと RAM ユーザーは、コンソールの異なるメニューで管理されます。

RAM ロール：左側のナビゲーションペインで、[ID 管理] > [ロール] をクリックします。
RAM ユーザー：左側のナビゲーションペインで、[ID 管理] > [ユーザー] をクリックします。

ARN 形式を使用して ID の種類を区別することもできます。:role/ を含む ARN は RAM ロール (たとえば、acs:ram::123456789012:role/adminrole) を識別し、:user/ を含む ARN は RAM ユーザー (たとえば、acs:ram::123456789012:user/user1) を識別します。

探しているアイデンティティがロールの一覧にない場合は、代わりにユーザーの一覧を検索してください。逆も同様です。

RAM ロールの利点

RAM ロールは、アクセスセキュリティと効率を向上させます。

一時的な権限昇格：プリンシパルに特定のタスクのための昇格された権限を付与し、長期的な高権限の認証情報を維持する必要がなくなります。
クロスアカウントでのリソースアクセス：あるアカウントのプリンシパルに別のアカウントのリソースへのアクセス権を付与し、アイデンティティを複製することなく一元管理を実現します。
サービスおよびアプリケーションへのセキュアなアクセス: Elastic Compute Service (ECS) インスタンスまたはその他のサービス上のアプリケーションは、AssumeRole を介してロールを引き受けて一時的な認証情報を取得するため、アプリケーションコードにハードコーディングされた AccessKey ペアが不要になります。

基本概念

RAM ロールを取り扱う前に、これらの概念を理解してください。

プリンシパル

プリンシパルは、ロールを引き受けることができるアイデンティティです。ロールの信頼ポリシーで、どのプリンシパルが信頼されるかが定義されます。プリンシパルは、次の 3 つのタイプに分類されます。

タイプ	説明	一般的なユースケース
Alibaba Cloud アカウント	アカウント内の任意のアイデンティティ (アカウント自体、RAM ユーザー、または他の RAM ロール) がロールを引き受けることができます。アカウントは、ロールの所有者である場合も、別のアカウントである場合もあります。	RAM ユーザーは、コンソールで ID を切り替えるか、CLI または SDK 経由で `AssumeRole` を呼び出します。
Alibaba Cloud サービス	指定されたクラウドサービスがロールを引き受けることができます。これはサービスロールと呼ばれます。	クラウドサービスが代理で操作を実行できるようにします。たとえば、インスタンス RAM ロールを ECS インスタンスにアタッチして、そのアプリケーションが Object Storage Service (OSS) バケットにアクセスできるようにします。多くのクラウドサービスでは、その機能を有効にするために、サービスにリンクされた事前定義済みのロールであるサービスリンクロールも使用します。
ID プロバイダー (IdP)	指定された ID プロバイダー (IdP) (SAML 2.0 または OIDC をサポート) のユーザーがロールを引き受けることができます。これにより、ID フェデレーションが可能になります。	企業の ID プロバイダー (IdP) のユーザーは、ロールベースのシングルサインオン (SSO) を使用して Alibaba Cloud コンソールにログオンできます。フェデレーションユーザーは、IdP からのトークン (SAML アサーションまたは ID トークン) を提供して `AssumeRoleWithSAML` または `AssumeRoleWithOIDC` オペレーションを呼び出し、一時的な認証情報を取得できます。

説明

Alibaba Cloud アカウントが信頼されたプリンシパルである場合、デフォルトではそのアカウント内のどのアイデンティティもロールを引き受けることができます。特定の RAM ユーザーまたはロールにアクセスを制限するには、「RAM ロールの信頼ポリシーの変更」をご参照ください。

ロールの引き受け

RAM ロールを引き受けるとは、信頼されたプリンシパルが一時的にそのロールの権限を取得することです。STS は一時的なセキュリティ認証情報を発行し、ロールセッションを開始します。その間、元のアイデンティティの権限は一時停止されます。ロールは、同じアカウントまたは別のアカウント (クロスアカウントでの引き受け) に属することができます。

コンソールで ID を切り替えるか、AssumeRole や AssumeRoleWithSAML / AssumeRoleWithOIDC などの API 操作を呼び出すことで、ロールを担うことができます。

信頼ポリシー

信頼ポリシーは、RAM ロールにアタッチする必要がある JSON ドキュメントであり、どのアカウント、ユーザー、ロール、またはサービスなどのプリンシパルがそのロールを引き受けることができるかを定義します。これは、ロール自体をリソースとするリソースベースのポリシーです。

主な機能：

ロールを引き受けることができるプリンシパルを定義: Principal 要素は、信頼できるプリンシパルを指定します。
ロール引き受け条件の制御: Condition 要素を追加して、MFA や特定のソース IP の要求など、ロールを引き受けることができる場合を制限します。
アクセスポリシーとの連携：信頼ポリシーは誰がロールを引き受けることができるかを定義し、アクセスポリシーは引き受けた後にロールが何を実行できるかを定義します。

例：

この信頼ポリシーは、アカウント 123456789012**** 内の任意の ID がロールを引き受けることを許可します:

{
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Effect": "Allow",
      "Principal": {
        "RAM": [
          "acs:ram::123456789012****:root"
        ]
      }
    }
  ],
  "Version": "1"
}

ロールセッション

プリンシパルがロールを引き受けると、ロールセッションが開始されます。STS の一時的な認証情報はこのセッションに紐付けられ、それらを使用して実行されるすべてのアクションはセッションに関連付けられます。

ロールセッションには以下が含まれます。

セッション名 (RoleSessionName): ユーザーが指定するセッション識別子です。ActionTrail ログに表示され、アクションを引き受けたプリンシパルまで追跡できます。
セッション期間：固定のライフサイクルを持ち、セッションが終了すると認証情報は失効します。

説明

ロールを引き受ける際にインラインセッションポリシーを渡して、特定のセッションの権限を絞り込みます。有効な権限は、ロールのアクセスポリシーとセッションポリシーの共通部分です。詳細については、AssumeRole API リファレンスの Policy パラメーターをご参照ください。

ロールチェーン

ロールチェーンは、あるロールを使用して別のロールを引き受ける場合に発生します。たとえば、RAM ユーザーがロール A を引き受け、その STS トークンを使用してロール B を引き受けます。ロールは、同じアカウントまたは異なるアカウントに属することができます。

このパターンは、マルチアカウント環境で一般的です。たとえば、開発者は中央のジャンプアカウント (ロール A) にフェデレーションし、その後、特定のタスクのために本番アカウントの特権ロール (ロール B) を引き受けます。

Alibaba Cloud CLI、SDK、またはコンソールを使用してロールをチェーンします。「ロールチェーンの使用」をご参照ください。

RAM ロールと RAM ユーザーの違い

ロールとユーザーはどちらも RAM アイデンティティですが、異なる目的を果たします。

比較項目	RAM ユーザー	RAM ロール
使用法	特定の個人またはアプリケーションを表し、直接使用されます	権限のセットを表し、プリンシパルによって引き受けられる必要があります
認証情報	長期的な認証情報 (パスワードおよび/または AccessKey ペア) を持ちます	長期的な認証情報はありません。一時的な認証情報 (STS トークン) が引き受け時に生成されます
認証情報の有効期間	長期的 (手動で変更または削除されるまで)	一時的であり、設定可能な期間の後に失効します
信頼ポリシー	なし	誰がロールを引き受けることができるかを定義するために、信頼ポリシーが必要です

RAM ロールとユーザーグループ

RAM ロールにはメンバーリストがありません。RAM ロールの詳細ページを開いても、ユーザーのリストは表示されません。

RAM ユーザーは次のようにロールを引き受けます。

ロール詳細ページの [信頼ポリシー] タブで信頼されたエンティティを設定します。
RAM ユーザーは STS の AssumeRole 操作を呼び出して、一時的な認証情報を取得します。
RAM ユーザーは、一時的な認証情報を使用して、ロールとしてリソースにアクセスします。

これはユーザーグループとは異なります。ユーザーグループには [グループメンバー管理] タブがあり、そこでメンバーを直接追加したり表示したりできますが、RAM ロールにはメンバーリストがありません。

RAM ロールの制限については、「制限」をご参照ください。

ユースケース

一時的な権限昇格の付与

日常業務では権限が制限されている開発者が、本番データベースの変更などの機密性の高い操作を実行するために、管理者権限を持つロールを引き受けます。タスクが完了すると、権限は制限された状態に戻り、最小権限の原則が維持されます。

「RAM ロールを引き受ける方法」をご参照ください。
アカウント間でのアクセス委任

ある組織が、開発用 (アカウント A) と本番用 (アカウント B) に別々の Alibaba Cloud アカウントを持っているとします。アカウント A で実行されている CI/CD パイプラインがアカウント B の ECS にアプリケーションをデプロイできるようにするには、次のようにします。
1. アカウント B に、アカウント A を信頼するロールを作成します。
2. アカウント A の CI/CD サービスロールに、アカウント B のそのロールを引き受ける権限を付与します。
3. CI/CD パイプラインは、アカウント B のロールを引き受けて、アプリケーションをデプロイするための認証情報を取得します。
「クロスアカウントでのリソースアクセス」をご参照ください。
Alibaba Cloud サービスへのアクセス権の付与

ECS インスタンス上のアプリケーションが OSS バケットから読み取る必要があるとします。AccessKey ペアを埋め込む代わりに、読み取り権限を持つサービスロールを作成し、それをインスタンスにアタッチします。アプリケーションは、自動的に提供される一時的な認証情報を使用して OSS にアクセスします。

詳細については、「インスタンス RAM ロール」をご参照ください。
フェデレーテッドユーザーへのアクセス提供

企業が外部の ID プロバイダー (IdP) (Microsoft Entra ID や Okta など) を使用しているとします。SAML 2.0 または OIDC で ID フェデレーションを設定し、その ID プロバイダー (IdP) を信頼する RAM ロールを作成します。認証されたユーザーは、そのロールを引き受けて Alibaba Cloud にアクセスし、個別の RAM ユーザーを作成することなく一元的なユーザー管理を実現します。

「SAML を使用したロールベース SSO の概要」および「OIDC を使用したロールベース SSO の概要」をご参照ください。

Resource Access Management:RAM ロールの概要