Resource Access Management:RAM role overview

RAM ロールとは

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

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

基本概念

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

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

ロールセッション

プリンシパルがロールを引き受けると、ロールセッションが開始されます。セキュリティトークンサービス (STS) によって発行された一時的な認証情報は、このセッションに関連付けられます。これらの認証情報を使用して実行されたすべてのアクションは、ロールセッションに帰属します。

ロールセッションには次のものがあります。

1. セッション名 (RoleSessionName): セッションのユーザーが提供する識別子。ActionTrail ログに表示されるため、アクションをロールを引き受けたユーザーまたはアプリケーションに追跡できます。

2. セッション期間: 固定されたライフサイクル。セッションが終了すると認証情報は期限切れになります。

ロールチェイニング

ロールチェイニングは、ロールを使用して2番目のロールを引き受けるときに発生します。たとえば、RAM ユーザーがロール A を引き受け、ロール A のセキュリティトークンサービス (STS) トークンを使用してロール B を引き受けます。ロールは、同じアカウントまたは異なるアカウントに属することができます。

ロールチェイニングは、複雑なマルチアカウント環境で一般的です。たとえば、開発者は中央の「ジャンプ」アカウントにフェデレーションし (ロール A を引き受け)、そこから本番アカウントでより特権的なロール (ロール B) を引き受けて特定のタスクを実行する場合があります。

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

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

RAM ロールと RAM ユーザーはどちらも RAM ID ですが、異なる目的を果たします。次の表は、主要な違いを強調しています。

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

ユースケース

• 一時的な昇格された権限の付与

  開発者は、限られた権限を持つ RAM ユーザーで日常的に作業します。本番データベースの変更など、機密性の高い操作を実行する必要がある場合、そのタスクに必要な管理権限を付与するロールを引き受けることができます。タスクの完了後、ロールの使用を停止すると、権限は限られたセットに戻ります。これは、最小権限の原則 (PoLP) に準拠しています。

  詳細については、「RAM ロールを引き受ける方法」をご参照ください。

• アカウント間のアクセス委任

  組織に開発 (アカウント A) と本番 (アカウント B) 用の別々の Alibaba Cloud アカウントがあるとします。アカウント A で実行されている CI/CD パイプラインがアカウント B の ECS にアプリケーションをデプロイできるようにするには、次の手順を実行します。

  1. アカウント A を信頼するロールをアカウント B に作成します。

  2. アカウント A の CI/CD サービスロールに、アカウント B のそのロールを引き受ける権限を付与します。

  3. CI/CD パイプラインはアカウント B のロールを引き受けて、アプリケーションをデプロイするための認証情報を取得します。

  詳細については、「クロスアカウントリソースアクセス」をご参照ください。

• Alibaba Cloud サービスへのアクセス付与

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

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

• フェデレーションユーザーへのアクセス提供

  企業が外部 IdP (Microsoft Entra ID や Okta など) を使用しているとします。従業員が 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 リソースへのアクセスを許可する