Resource Access Management:SourceIdentity を使用したロールの引き受けのトレーサビリティとアクセスの制御

フォーマット要件

• 値の長さは 2～64 文字である必要があります。

• 値には、文字、数字、および次の特殊文字を含めることができます：=、,、.、@、-、_。

• 値には、acs:、aliyun:、alibabacloud: など、Alibaba Cloud が予約したプレフィックスは使用できません。

権限操作

権限操作の設定例

RAM ユーザーや RAM ロールなどの ID が AssumeRole を呼び出す際に SourceIdentity を設定できるようにするには、プリンシパルのID ベースのアクセスポリシーと、ターゲットロールのロール信頼ポリシーの両方で sts:SetSourceIdentity 権限を付与する必要があります。Action ブロックに sts:SetSourceIdentity を追加します。

• ID ベースのアクセスポリシーの例 (プリンシパルに付与)：

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_ID:role/TARGET_ROLE"
      }
    ]
  }

• ロール信頼ポリシーの例 (引き受けられるロールに設定)：

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

ロールベース SSO シナリオにおける権限操作の設定例

AssumeRoleWithSAML または AssumeRoleWithOIDC 操作を呼び出してロールを引き受ける場合、ターゲットロールのロール信頼ポリシーで sts:SetSourceIdentity 権限を付与するだけで済みます。次の例は、SAML ロールベース SSO のポリシーを示しています。

{
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "saml:recipient": [
            "https://signin.aliyun.com/saml-role/sso"
          ]
        }
      },
      "Effect": "Allow",
      "Principal": {
        "Federated": [
          "acs:ram::ACCOUNT_ID:saml-provider/PROVIDER_NAME"
        ]
      }
    }
  ],
  "Version": "1"
}

条件キー

sts:SourceIdentity と acs:SourceIdentity の条件キーの違いは次のとおりです。

• sts:SourceIdentity は、ロールの引き受けリクエスト内の SourceIdentity 属性と照合されます。

• acs:SourceIdentity は、ロールが正常に引き受けられた後、STS トークンを含むロールセッションに存在する SourceIdentity 属性と照合されます。

初めてロールを引き受ける場合は、ポリシー (ID ベースのアクセスポリシーとロール信頼ポリシーを含む) に sts:SourceIdentity 条件キーを設定する必要があります。この時点ではまだ有効なロールセッションが生成されていないため、acs:SourceIdentity 条件キーを使用するとロールの引き受けは失敗します。

条件制御の例

ポリシーの Condition ブロックで sts:SourceIdentity 条件キーを使用すると、ロールが引き受けられる際に特定の SourceIdentity 値を渡すことを要求できます。次のいずれかまたは両方のタイプのポリシーで条件を設定できます。

• ID ベースのアクセスポリシーで条件を設定する：ID が特定のロールを引き受ける際に、特定の SourceIdentity 値を設定するように制限します。

• ロール信頼ポリシーで条件を設定する：任意の ID がそのロールを引き受ける際に、特定の SourceIdentity 値を設定するように制限します。

ポリシーの Action ブロックに sts:SetSourceIdentity 権限も追加する必要があることに注意してください。そうしないと、条件制御機能は機能しません。

本番環境用の高権限 RAM ロール prod-role があるとします。管理者は、次の制御を実装する必要があります。

1. RAM ユーザーの Alice と Bob のみが prod-role を引き受けることができます。

2. prod-role を引き受ける際、SourceIdentity を設定する必要があり、その値はプリンシパルのユーザー名と一致する必要があります。例えば、Alice がロールを引き受ける場合、値は alice または alice@exampledomain.com に設定できます。

ステップ 1：prod-role のロール信頼ポリシーの設定

このポリシーにより、Alice と Bob のみがこのロールを引き受けることができ、リクエストには alice または bob で始まる SourceIdentity 値が含まれている必要があります。

{
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringLike": {
          "sts:SourceIdentity": [
            "alice*",
            "bob*"
          ]
        }
      },
      "Effect": "Allow",
      "Principal": {
        "RAM": [
          "acs:ram::ACCOUNT_ID:user/alice",
          "acs:ram::ACCOUNT_ID:user/bob"
        ]
      }
    }
  ],
  "Version": "1"
}

ステップ 2：Alice と Bob の ID ベースのアクセスポリシーの設定

以下のポリシーは、Alice と Bob に prod-role を引き受ける権限を付与し、リクエストでそれぞれのユーザー名に一致する SourceIdentity 値を設定することを要求します。

• Alice の ID ベースのアクセスポリシー

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_ID:role/prod-role",
        "Condition": {
          "StringLike": {
            "sts:SourceIdentity": [
              "alice*"
            ]
          }
        }
      }
    ]
  }

• Bob の ID ベースのアクセス ポリシー

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_ID:role/prod-role",
        "Condition": {
          "StringLike": {
            "sts:SourceIdentity": [
              "bob*"
            ]
          }
        }
      }
    ]
  }

{
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "saml:recipient": [
            "https://signin.aliyun.com/saml-role/sso"
          ],
          "sts:SourceIdentity": [
            "employeeid-alice",
            "employeeid-bob"
          ]
        }
      },
      "Effect": "Allow",
      "Principal": {
        "Federated": [
          "acs:ram::ACCOUNT_ID:saml-provider/PROVIDER_NAME"
        ]
      }
    }
  ],
  "Version": "1"
}

シナリオの説明

Jenkins などの継続的インテグレーション/継続的デプロイメント (CI/CD) 自動化ツールは、RAM ロール automation-role を使用して実行されます。このロールは、Alice や Bob などの開発者が引き受けることができます。

Alice などの開発者は、このツールを使用して、本番環境の OSS バケットにアプリケーションをデプロイします。このデプロイ操作では、OSS バケットへの書き込み権限を持つ、より高い権限のロール deploy-role を引き受ける必要があります。

Alice、Bob、および automation-role は Alibaba Cloud アカウント A に属しています。deploy-role は Alibaba Cloud アカウント B に属しています。

ビジネス要件とワークフロー

automation-role は、元の呼び出し元が Alice の場合にのみ deploy-role を正常に引き受けることができます。Bob などの他のユーザーからの呼び出しリクエストは拒否される必要があります。

ワークフローは次のとおりです：

1. Alice は AssumeRole 操作を呼び出して automation-role を引き受け、リクエストで SourceIdentity を alice に設定します。

2. automation-role が STS トークンを取得した後、再度 AssumeRole 操作を呼び出して deploy-role を引き受けます。SourceIdentity の値は自動的に渡されます。

3. deploy-role の信頼ポリシーは、受信した SourceIdentity が alice であるかどうかをチェックします。検証が成功した場合、ロールの引き受けが許可されます。

ポリシー設定手順

ステップ 1：deploy-role の信頼ポリシーを修正する

このポリシーは、アカウント A の automation-role ロールからのロール引き受けリクエストのみを信頼し、SourceIdentity の値が alice であることを要求します。

{
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "acs:SourceIdentity": [
            "alice"
          ]
        }
      },
      "Effect": "Allow",
      "Principal": {
        "RAM": [
          "acs:ram::ACCOUNT_A_ID:role/automation-role"
        ]
      }
    }
  ],
  "Version": "1"
}

ステップ 2：automation-role のアクセスポリシーと信頼ポリシーの変更

• アクセスポリシー：automation-role ロールがアカウント B の deploy-role ロールを引き受けることを許可します。

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_B_ID:role/deploy-role"
      }
    ]
  }

• 信頼ポリシー：Alice と Bob が automation-role を引き受けることを許可します。

  {
    "Statement": [
      {
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Effect": "Allow",
        "Principal": {
          "RAM": [
            "acs:ram::ACCOUNT_A_ID:user/alice",
            "acs:ram::ACCOUNT_A_ID:user/bob"
          ]
        }
      }
    ],
    "Version": "1"
  }

ステップ 3：Alice と Bob の ID ベースのアクセスポリシーの変更

automation-role ロールを引き受けることを許可し、ユーザー名と完全に一致する SourceIdentity 値を設定することを要求します。

• Alice の ID ベースのアクセスポリシー

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_A_ID:role/automation-role",
        "Condition": {
          "StringEquals": {
            "sts:SourceIdentity": [
              "alice"
            ]
          }
        }
      }
    ]
  }

• Bob の ID ベースのアクセスポリシー

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "sts:SetSourceIdentity"
        ],
        "Resource": "acs:ram::ACCOUNT_A_ID:role/automation-role",
        "Condition": {
          "StringEquals": {
            "sts:SourceIdentity": [
              "bob"
            ]
          }
        }
      }
    ]
  }

シナリオ 1：ID ベースのアクセスポリシーに起因する問題

エラーメッセージ：

{
  "RequestId": "AC9DDEC1-3E1F-50B8-A2D1-BAA155FD****",
  "Code": "NoPermission",
  "Message": "You are not authorized to do this action. You should be authorized by RAM.",
  "AccessDeniedDetail": {
    "PolicyType": "AccountLevelIdentityBasedPolicy",
    "AuthAction": "sts:SetSourceIdentity",
    ...
  }
}

原因分析：

• "PolicyType": "AccountLevelIdentityBasedPolicy" は、エラーが呼び出し元のID ベースのアクセスポリシーに起因することを示します。

• "AuthAction": "sts:SetSourceIdentity" は、sts:SetSourceIdentity 操作の権限が不足していることを示します。

解決策：管理者に連絡して、呼び出し元の ID ベースのアクセスポリシーを確認し、以下を確認してもらってください。

1. ポリシーに "Action": "sts:SetSourceIdentity" が含まれていること。

2. ポリシーの Resource 範囲に、引き受けようとしているターゲットロールが含まれていること。

3. ポリシーに Condition ブロックが含まれている場合、リクエスト内の SourceIdentity の値が条件を満たしていることを確認してください。

シナリオ 2：ロール信頼ポリシーに起因する問題

エラーメッセージ：

{
  "RequestId": "ECC91EE1-0EB0-5E79-B3F5-E54FD8B9****",
  "Code": "NoPermission",
  "Message": "You are not authorized to do this action. You should be authorized by RAM.",
  "AccessDeniedDetail": {
    "PolicyType": "AssumeRolePolicy",
    "AuthAction": "sts:SetSourceIdentity",
    ...
  }
}

原因分析：

• "PolicyType": "AssumeRolePolicy" は、エラーがターゲットロールのロール信頼ポリシーに起因することを示します。

• "AuthAction": "sts:SetSourceIdentity" は、ターゲットロールが sts:SetSourceIdentity 操作を信頼していないことを示します。

解決策：管理者に連絡して、ターゲットロールのロール信頼ポリシーを確認し、以下を確認してもらってください。

1. ポリシーに "Action": "sts:SetSourceIdentity" が含まれていること。

2. ポリシーに Condition ブロックが含まれている場合、リクエスト内の SourceIdentity の値が条件を満たしていることを確認してください。

一般的なトラブルシューティングの推奨事項

1. 範囲を絞り込む：SourceIdentity の設定時に権限の問題が発生した場合は、まず SourceIdentity パラメーターを削除して再度ロールを引き受けてみてください。操作が成功した場合、問題は SourceIdentity の権限設定に関連している可能性が高いです。

2. エラーの分析：エラーメッセージの AccessDeniedDetail セクション、特に PolicyType フィールドを注意深く読んでください。これにより、問題が ID ベースのアクセスポリシーとロール信頼ポリシーのどちらに起因するのかを迅速に判断できます。

3. 診断ツールの使用：RequestId しかない場合は、 OpenAPI Troubleshoot ツールを使用します。RequestId を入力すると、システムが詳細な診断情報を返し、権限の問題を特定するのに役立ちます。例：

   

4. ポリシーとリクエストの比較：特定のポリシーを特定した後、Resource と Condition の設定を注意深く確認してください。それらが、ターゲットロールの ARN や SourceIdentity 値など、API リクエストのパラメーターと一致していることを確認してください。

権限の問題のトラブルシューティング方法の詳細については、「権限不足によるアクセスエラーのトラブルシューティング方法」をご参照ください。