Resource Access Management:RAM ロールの概要

RAM ロールとは？

Resource Access Management (RAM) ロールは、RAM ユーザーと同様に特定のポリシーがアタッチされた RAM ID です。ただし、ロールは単一の人物やアプリケーションと一意に紐付けられません。代わりに、その権限を必要とする信頼されたプリンシパル（ユーザーまたは他のサービスなど）によって仮装されます。ロールにはパスワードや AccessKey ペアなどの長期的な認証情報は存在しません。プリンシパルがロールを仮装すると、セキュリティトークンサービス (STS) がそのセッションのみ有効な一時的なセキュリティ認証情報を動的に発行します。

各 RAM ロールは、アカウント内のリソースであり、固有の Alibaba Cloud リソース名 (ARN) を持ちます：acs:ram::<account-id>:role/<role-name>。この ARN を使用して、ポリシーや API 呼び出しでロールを参照します。ロールの ARN の確認方法については、「RAM ロールの情報を表示する」をご参照ください。

基本概念

RAM ロールを効果的に活用するには、以下の概念を理解することが不可欠です。

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

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

両者とも RAM ID ですが、用途は異なります。以下の表に主な相違点を示します。

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

ロールセッション

プリンシパルがロールを仮装すると、ロールセッションが開始されます。STS が発行する一時的な認証情報は、このセッションに関連付けられます。これらの認証情報を使用して実行されたすべての操作は、ロールセッションに帰属します。

ロールセッションには以下の要素があります。

1. セッション名（RoleSessionName）：ユーザーが指定するセッションの識別子です。ActionTrail のログに記録されるため、ロールを仮装したユーザーまたはアプリケーションによる操作を追跡できます。

2. セッション期間：固定のライフサイクルを持ち、セッション終了時に認証情報が有効期限切れになります。

ロールチェイニング

ロールチェイニングとは、あるロールを使用して第 2 のロールを仮装する状況を指します。たとえば、RAM ユーザーがロール A を仮装し、その STS トークンを使ってロール B を仮装するといったケースです。これらのロールは同一アカウント内にあっても、異なるアカウント内にあっても構いません。

ロールチェイニングは、複雑なマルチアカウント環境でよく見られます。たとえば、開発者が中央の「ジャンプ」アカウント（ロール A を仮装）にフェデレートし、そこから本番アカウント内のより特権の高いロール（ロール B）を仮装して特定のタスクを実行するといったユースケースです。

Alibaba Cloud CLI、SDK、またはコンソールでのロール切り替えにより、ロールチェイニングを実行できます。詳細については、「ロールチェイニングの使用」をご参照ください。

適用範囲／利用シーン

• 一時的な特権の付与

  開発者は日常業務で権限が限定された 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 ペアを埋め込む代わりに、バケットに対する読み取り権限を持つ ECS 向けサービスロールを作成し、それを ECS インスタンスにアタッチします。その後、アプリケーションは自動的に提供される一時的な認証情報を使用して、OSS に安全にアクセスできます。

  詳細については、「インスタンス RAM ロール」をご参照ください。

• フェデレーテッドユーザーへのアクセス付与

  企業が Microsoft Entra ID や Okta などの外部 ID プロバイダー (IdP) を使用している場合、従業員が Alibaba Cloud コンソールにアクセスできるようにするには、SAML 2.0 または OIDC を使用した ID フェデレーションを設定し、当該 IdP を信頼する RAM ロールを作成します。ユーザーがログインすると、IdP がユーザーを認証し、ユーザーはロールを仮装して Alibaba Cloud にアクセスします。これにより、Alibaba Cloud 内に個別の RAM ユーザーを作成することなく、IdP でユーザーを一元管理できます。

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

参考文献

• 制限事項

• サービスリンクロール

• アクセスポリシーの概要

• SAML を使用したロールベース SSO の概要

• ECS インスタンス向け RAM ロール

• STS トークンを使用してモバイルアプリに Alibaba Cloud リソースへのアクセスを許可する