# AWS パートナーの IAM 一時委任
## 概要:
IAM の一時委任を使用すると、AWS の顧客は、インタラクティブなガイド付きワークフローを使って AWS パートナーの製品を自分の AWS 環境にシームレスにオンボードあるいは統合することができます。顧客は、必要とする AWS サービスを設定するときに、制限付きの一時的なアクセス権を AWS パートナーに付与することで、オンボーディングにまつわる問題を取り除き価値実現までに要する時間を短縮することができます。
IAM の一時委任を使えばパートナーは以下のようなことが行えます。
+ リソースのプロビジョニングを自動化して顧客のオンボーディングを簡素化する
+ 手動での設定手順をなくし統合における複雑な要素を取り除く
+ 顧客が承認した透過的なアクセス許可を使用して信頼性を高める
+ アクセス許可の境界を使用して長期的なアクセスパターンにより継続的なオペレーションを実現する
## 仕組み
1. *パートナーが委任リクエストを作成する* – パートナーが、必要なアクセス許可と必要とする期間とを指定したリクエストを作成します。
1. *顧客が AWS コンソールで確認する* – パートナーがリクエストしたアクセス許可とその理由を顧客が確認します。
1. *顧客が承認する* – 顧客がリクエストを承認し、交換トークンをリリースします。トークンはここで指定した SNS トピック上でパートナーに送信されます。
1. *パートナーが一時的な認証情報を受け取る* – パートナーがトークンを一時的な AWS 認証情報と交換します。
1. *パートナーがリソースを設定する* – パートナーが認証情報を使用して顧客のアカウントに必要なリソースを設定します。
## パートナーの要件
一時委任を組み込むには、パートナーは次の要件を満たしている必要があります。
+ *ISV Accelerate に登録している* – パートナーは [ISV Accelerate (ISVA)](https://aws.amazon.com/partners/programs/isv-accelerate/) プログラムに登録している必要があります。
+ *AWS Marketplace に出品している* – パートナーは製品を AWS Marketplace に出品し「AWS にデプロイ済み」のバッジを付ける必要があります。
## オンボーディングプロセス
製品に一時委任を組み込むには、次の手順を行います。
1. *ステップ 1: 要件を確認する*
本ドキュメントを読んで要件を確認し、以下のパートナーアンケートに回答します。
1. *ステップ 2: オンボーディングリクエストを送信する*
aws-iam-partner-onboarding@amazon.com に E メールを送信するか、または AWS の担当者に連絡します。その際、必須項目のすべてを記載した以下のパートナーアンケートの回答を作成し、添付します。
1. *ステップ 3: AWS が確認およびチェックを行う*
AWS の動作:
+ パートナーが要件を満たしていることを確認します
+ ポリシーテンプレートとアクセス許可の境界をチェックします
+ パートナーから届いたアーティファクトにフィードバックを行います
1. *ステップ 4: ポリシーを改良する*
AWS のフィードバックに対処し、必要に応じて最新のポリシーテンプレートまたはアクセス許可の境界を送信します。
1. *ステップ 5: 登録を完了する*
承認されると、AWS が以下を行います。
+ 指定されたアカウントの API アクセスを有効にする
+ ポリシーテンプレートとアクセス許可の境界の ARN を共有する (該当する場合)
オンボーディングが完了するとお手元に確認メッセージが届きます。届いたら、登録したアカウントから一時委任 API、CreateDelegationRequest と GetDelegatedAccessToken にアクセスすれば、委任リクエストのワークフローを製品に組み込めるようになります。
## パートナーアンケート
以下の表は、パートナーのオンボーディングに必要な情報を一覧にしたものです。
| 情報 | 説明 | 必須 |
| --- | --- | --- |
| パートナーセントラルのアカウント ID | [AWS パートナーセントラル](https://partnercentral.awspartner.com/partnercentral2/s/login)に登録されている AWS アカウントのアカウント ID。 | はい |
| PartnerId | [AWS パートナーセントラル](https://partnercentral.awspartner.com/partnercentral2/s/login)から提供されたパートナー ID。 | いいえ |
| AWS Marketplace の製品 ID | [AWS パートナーセントラル](https://partnercentral.awspartner.com/partnercentral2/s/login)から提供されたパートナー製品の製品 ID。 | はい |
| AWS アカウントの ID | 一時委任 API の呼び出しに使用する AWS アカウント ID の一覧。これには本番稼働用と非本番稼働/テスト用の両方のアカウントを含める必要があります。 | はい |
| パートナー名 | この名前は、顧客が一時委任リクエストを確認する際に AWS マネジメントコンソールに表示されます。 | はい |
| 連絡用メールアドレス | サービスの組み込みに関するご連絡に使用可能な 1 件以上の E メールアドレス。 | はい |
| リクエストしたユーザーのドメイン | お使いのドメイン (www.example.com など) | はい |
| 統合の説明 | この機能を使用するユースケースに関する短い説明。参考ドキュメントやその他公開資料へのリンクを含めていただいてもかまいません。 | はい |
| アーキテクチャ図 | 組み込みの統合ユースケースの図解 (複数可)。 | いいえ |
| ポリシーテンプレート | この機能ではポリシーテンプレートを 1 つ以上登録する必要があります。ポリシーテンプレートは、顧客の AWS アカウントでリクエストする一時的な許可を定義するものです。詳細については「ポリシーテンプレート」の項目を参照してください。 | はい |
| ポリシーテンプレート名 | 登録するポリシーテンプレートの名前。 | はい |
| アクセス許可の境界 | 一時的な許可を使用して顧客のアカウントに IAM ロールを作成する場合は、アクセス許可の境界を IAM に登録する必要があります。アクセス許可の境界は、ロールに対するアクセス許可の上限を規定するために作成する IAM ロールにアタッチされます。選択した AWS 管理ポリシーをアクセス許可の境界として使用するか、新しいカスタムのアクセス許可の境界 (JSON) を登録することができます。詳細については「アクセス許可の境界」の項目を参照してください。 | いいえ |
| アクセス許可の境界名 | アクセス許可の境界の名前です。形式は以下のとおり。arn:aws:iam::partner:policy/permission\$1boundary//\$1。ポリシー名には作成日をサフィックスとして含める必要があります。この名前は、アクセス許可の境界の作成後は更新できません。既存の AWS 管理ポリシーを使用している場合は、代わりに管理ポリシー ARN を指定します。 | いいえ |
| アクセス許可の境界の説明 | アクセス許可の境界に関する説明です。この説明は、アクセス許可の境界の作成後は更新できません。 | 不可 |
# 統合について
オンボーディングプロセスが完了すると、IAM 一時委任との統合を構築することができます。完全な統合は、通常、次の 3 つの作業で構成されています。
## 1. ユーザーエクスペリエンスとワークフローの設計
一時委任のワークフローを使って、顧客をガイドするフロントエンドのエクスペリエンスをパートナーアプリケーションに構築します。パートナーアプリケーションは以下を行う必要があります。
+ 顧客が一時的なアクセス許可を付与できる、オンボーディングまたは設定の明確なフローを提示します。このアクションに「IAM 一時委任を使ってデプロイする」といったわかりやすいラベルを付けます。
+ CreateDelegationRequest API が返すコンソールリンクを使用して、顧客を AWS マネジメントコンソールにリダイレクトし、委任リクエストを確認および承認します。
+ リクエストされたアクセス許可とその理由に関する適切なメッセージを提供します。顧客は、このメッセージを委任リクエストの詳細ページで確認できます。
+ AWS での承認が完了したら、アプリケーションへの顧客からの返信に対処します。
## 2. API の統合
IAM 一時委任 API を使用して、委任リクエストを送信および管理します。AWS アカウントが登録されると、次の API にアクセスできます。
+ *IAM CreateDelegationRequest* – 顧客の AWS アカウントの委任リクエストを作成します。この API は、リクエストの確認および承認用に、顧客をリダイレクトするコンソールリンクを返します。
+ *AWS STS GetDelegatedAccessToken* – 顧客が委任リクエストを承認した後、一時的な AWS 認証情報を取得します。顧客のアカウントでアクションを実行するときはこれらの認証情報を使用します。
統合により、リクエストの作成、ステータスのモニタリング、承認時の一時的な認証情報の取得など、委任リクエストのすべてのライフサイクルに対処できる必要があります。
## 3. リソース設定とオーケストレーション
一時的な認証情報を取得したら、顧客の AWS アカウントで必要なワークフローを組み立ててリソースを設定します。これには、次のようなものがあります。
+ AWS サービス API を直接呼び出してリソースを作成および設定する
+ AWS CloudFormation テンプレートを使用してインフラストラクチャをデプロイする
+ 継続的なアクセスのため IAM ロールを作成する (アクセス許可の境界を使用する必要あり)
顧客は、委任の承認を再試行または変更する必要がある場合があるため、オーケストレーションのロジックはべき等とし、障害を適切に処理する必要があります。
# アクセス許可について
機能のオンボーディングプロセスの一環として、ユーザーは、顧客の AWS アカウントでリクエストを行うためのアクセス許可を定義するポリシーを、IAM に登録する必要があります。この登録プロセスは、顧客向けにより一貫性のあるエクスペリエンスが用意されているため、ポリシー作成時のよくある落とし穴を回避できます。
登録中、AWS はユーザーのポリシーを一連の妥当性に照らして評価します。これらの妥当性は、ポリシーの形式と構造を標準化し、既知のアンチパターンに対して基本的な保護を行うことを目的としています。また、権限昇格、意図しないクロスアカウントアクセス、顧客アカウント内の高価値なリソースに対する広範なアクセス、に関連したリスクも軽減します。
## アクセス許可タイプ
AWS は、アクセス許可には一時的な許可と長期的な許可の 2 種類があるとみなしています。
### 一時的なアクセス許可
一時的なアクセス許可は、一時的に委任されたアクセスセッションに割り当てられたアクセス許可を制限します。一時的なアクセス許可は、委任セッションに適用されるポリシーテンプレートで説明されています。このテンプレートは、委任リクエストの作成時にユーザーが指定するパラメータをサポートします。その後、これらのパラメータ値はセッションに結び付けられます。一時的なアクセス許可は、AWS STS 現在利用可能なセッションポリシーと同じ方法で機能します。セッションポリシーは、基盤となるユーザーの機能を制限しますが、追加のアクセス許可は付与しません。詳細については、セッションポリシーに関する AWS STS のドキュメントを参照してください。
### 有効期間の長いアクセス許可
有効期間の長いアクセス許可は、一時的なアクセス許可を通じて作成または管理されているロールのアクセス許可を制限します。有効期間の長いアクセス許可は、IAM アクセス許可の境界として実装されます。アクセス許可の境界は、オンボーディングの一環として 1 つ以上を AWS に送信することができます。承認されると、AWS はユーザーに、ユーザーのポリシーで参照できるポリシー ARN を共有します。
これらの境界ポリシーには注目すべき 2 つの機能があります。1 つめはイミュータブルであることです。アクセス許可を更新するときは、新しいアクセス許可の境界を登録できます。その後、新しい委任リクエストを送信することで新しいアクセス許可の境界を顧客のロールにアタッチできます。2 つめは、ポリシーがテンプレート化されないことです。同一の境界ポリシーがグローバルに共有されているため、ポリシーを顧客ごとに変えることはできません。
**重要**
アクセス許可の境界の文字数の上限は 6,144 文字です。
**注記**
アクセス許可の境界またはポリシーテンプレートを更新する場合は、IAM (aws-iam-partner-onboarding@amazon.com) までご連絡ください。新しいアクセス許可の境界が登録されたら、顧客に委任リクエストを送信して IAM ロールを更新し、新しく登録されたアクセス許可の境界をアタッチすることができます。詳細は、「例」の項目を参照してください。
## ユースケース例: データ処理のワークロード
製品プロバイダーがデータ処理のワークロードを顧客アカウントで実行するケースを考えてみましょう。このプロバイダーは、最初のオンボーディング中にインフラストラクチャをセットアップする必要がありますが、ワークロードを操作するには継続的なアクセス許可も必要です。
*一時的なアクセス許可 (初期設定用):*
+ Amazon EC2 インスタンス、VPC、セキュリティグループを作成する
+ 処理されたデータの Amazon S3 バケットを作成する
+ 継続的な操作用の IAM ロールを作成する
+ アクセス許可の境界を IAM ロールにアタッチする
*有効期間の長いアクセス許可 (継続的な操作向けの、アクセス許可の境界を持つ IAM ロール):*
+ 処理ジョブを実行するために Amazon EC2 インスタンスを起動/停止する
+ Amazon S3 バケットから入力データを読み取る
+ 処理の結果を Amazon S3 バケットに書き込む
一時的なアクセス許可は、インフラストラクチャを設定するオンボーディングの最中に 1 回使用します。この処理の最中に作成された IAM ロールには、継続的なワークロード管理に必要な操作のみにアクセス許可の上限を制限するアクセス許可の境界があります。これにより、ロールのポリシーが変更された場合でも、この境界で定義されたアクセス許可を超えることはできなくなります。
# ポリシー評価のガイドライン
AWS は、送信されてきたポリシーを一連のガイドラインに照らして評価します。ポリシーテンプレートとアクセス許可の境界には同一の評価ガイドラインを適用し、必要に応じて両者の微妙な違いを指摘します。
当社は、評価のためサービスを複数のグループに分類しています。最も重要なグループは、アクセス許可、認証情報、キーを管理する機密性の高いサービスが対象です。こうしたサービスへのアクセスを付与するポリシーは、そこで行われる作業に的を絞る必要があります。機密性の高いサービスには、AWS Identity and Access Management (IAM)、AWS Key Management Service (KMS)、AWS Resource Access Manager (RAM)、AWS IAM Identity Center、AWS Organizations、AWS Secrets Manager などがあります。
もう 1 つのグループは、アカウントの境界を越えてデータにアクセスできるサービスです。このサービス向けのポリシーには、意図しないクロスアカウントアクセスを防ぐ保護を含める必要があります。
## すべてのポリシーに共通する確認事項
すべてのポリシーステートメントは、次のガイドラインに従う必要があります。
+ すべてのステートメントには、Effect、Action (または NotAction)、Resource、Condition の各フィールドがこの順番で含まれている必要があります
+ 1 個のステートメントに含まれるすべてのアクションは、アルファベット順に並べる必要があります。
+ ポリシーに含まれるすべての ARN は、関連するサービスの公開ドキュメントで定義された構文に、従っている必要があります。
+ NotAction フィールドは、Deny ステートメントのみで使用できます。
+ Allow ステートメントのアクションには、サービスコードを含める必要があります。汎用のワイルドカード (「\$1」) は使用できません
## 機密性の高いサービスの制限事項
上記の機密性の高いサービスには、次の制限が適用されます。
+ Allow ステートメントのアクションは、[service]:\$1 よりも具体的に記す必要があります。
+ 一時的なアクセスポリシーのテンプレートの、Allow ステートメントのアクションには、ワイルドカードを含めることはできません
+ iam:PassRole や iam:CreateServiceLinkedRole のような機密性の高いアクションには、具体的なリソースや条件チェックなどによる追加の絞り込みが必要になります。アクションには以下が含まれます。
+ IAM ロールの通過
+ IAM ロールの変更アクション
+ IAM ポリシーの変更アクション
+ AWS KMS の書き込みまたは暗号化オペレーション
+ AWS RAM の書き込みまたは共有オペレーション
+ シークレットの取得または変更、もしくはリソースポリシーの変更など AWS Secrets Manager のオペレーション
+ その他のアクションでは iam:ListUsers や iam:GetPolicy などのワイルドカードリソースを使用する場合があります
+ iam:CreateAccessKey などの認証情報を管理するアクションはブロックされます
## IAM に固有の制限事項
IAM の場合
+ IAM ロールとポリシーには、制限付きの書き込みオペレーションのみが許可されます。ユーザー、グループ、証明書など他の IAM リソースへのアクセス許可をリクエストすることはできません。
+ ポリシーのアタッチ、またはインラインポリシーの管理アクションは、アクセス許可の境界を持つロールに制限されます。アクセス許可の境界は、パートナーが定義するか、または、許可されている AWS 管理ポリシーのリストに含める必要があります。AWS 管理ポリシーは高度な権限または管理者権限を付与していない場合に許可される場合があります。例えば、特定のジョブ機能または SecurityAudit ポリシーの AWS 管理ポリシーは、許容される場合があります。AWS は、オンボーディングプロセス中に各 AWS 管理ポリシーを個別に確認します。
+ ポリシー管理は、次のパートナー固有のパスを持つポリシーのみで許可されます。arn:aws:iam::@\$1AccountId\$1:policy/partner\$1domain.com/[feature]\$1
+ タグは、リソースの作成時のみ、ロールとポリシーに対してのみ適用できます。
+ iam:PassRole チェックは、特定の名前またはパスプレフィックスと一致している必要があります
## AWS STS に固有の制限事項
AWS STS の場合:
+ sts:AssumeRole は、特定のロール ARN、ロール ARN プレフィックスに範囲を絞るか、一連のアカウントまたは組織 ID/組織単位に限定する必要があります
## IAM アイデンティティセンターの制限事項
AWS IAM Identity Center では次のアクションはブロックされます。
+ アクセス許可の管理に対応するすべてのアクション (sso:AttachCustomerManagedPolicyReferenceToPermissionSet など)
+ AWS Identity Store のユーザー、グループ、メンバーシップの変更
+ タグの管理
## AWS Organizations の制限事項
AWS Organizations では、読み取りアクションのみ許可されます。
## その他サービス固有の検証事項
+ シークレットまたは認証情報を取得するアクション (glue:GetConnection や redshift:GetClusterCredentials など) には、完全な ARN、ARN プレフィックス、タグのいずれかに一致する条件が必要です
+ Amazon Redshift の場合、redshift:GetClusterCredentials は、特定のデータベース名のみで許可され、redshift:GetClusterCredentialsWithIAM は、特定のワークグループ名のみで許可されます。
**注記**
IAM リソースをアカウントで管理する場合は、自分の名前を示すパスを使用することが推奨されます。例: arn:aws:iam::111122223333:role/partner.com/rolename そうすれば、統合に関連するリソースを簡単に見分けられ、顧客は検索、監査、分析を容易に行えます。
## クロスアカウントアクセス要件
クロスアカウントアクセスを許可する可能性のあるステートメントには、次のいずれか 1 つを含める必要があります。
+ リソースのアカウントまたは組織を指定する条件 (例: 1 つ以上の想定値に一致する aws:ResourceOrgId)
+ 特定のアカウントを含む Resource フィールド (例: arn:aws:sqs:\$1:111122223333:\$1)
+ ワイルドカード以外のアカウントと完全なリソース名を含む Resource フィールド (例: arn:aws:s3:::full–bucket–name)
**注記**
クロスアカウントアクセスは、ビジネス上の正当化根拠を必要とする機密性の高い機能です。クロスアカウントアクセスの必要性は、AWS がオンボーディングプロセス中に慎重に確認作業を行います。
# ポリシーテンプレート
ポリシーテンプレートとは、顧客のアカウントでパートナーがリクエストする一時的なアクセス許可を定義するための、新しい IAM コンストラクトです。従来の IAM ポリシーと同様、Effect、Action、Resource、Condition の各要素を含むステートメントを使用してアクセス許可を定義します。従来のポリシーとの大きな違いは、ポリシーテンプレートに、委任リクエストを作成する際に実際の値に置き換えられるパラメータ (@\$1bucketName\$1 など) が含まれている点です。
## ポリシーテンプレートの仕組み
ユーザーは、オンボーディングプロセスの最中にポリシーテンプレートを AWS に登録します。AWS は、各テンプレートに、委任リクエストの作成時に参照する一意の ARN を割り当てます。
委任リクエストを作成するときは、以下を指定します。
+ ポリシーテンプレート ARN
+ テンプレートに代入するパラメータ値
AWS は、テンプレートをパラメータ値と組み合わせて、標準の IAM ポリシーを生成します。顧客は、委任リクエストを承認するときに生成されたこの最終版のポリシーを確認し、付与されるアクセス許可を完全な形で目にします。
**注記**
生成された最終版のポリシーの、文字数の上限は 2048 文字です。
テンプレートの置換の仕組みを、以下の簡単な例でご紹介します。
ポリシーテンプレート
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::@{bucketName}/*"
}
]
}
```
委任リクエストで指定されるパラメータ
```
{
"Name": "bucketName",
"Values": ["customer-data-bucket"],
"Type": "String"
}
```
生成された最終版のポリシー (顧客が目にする内容)
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::customer-data-bucket/*"
}
]
}
```
## テンプレートの構文
ポリシーテンプレートは、パラメータ置換と条件ステートメントという 2 つの主要な機能により柔軟性を高めています。パラメータ置換を使用すると、委任リクエストの作成時に実際の値に置き換えられるプレースホルダーをテンプレートで定義できます。条件ステートメントを使用すると、パラメータ値に基づいて、ポリシーステートメント全体を含めたり除外したりできます。
### パラメータ置換とタイプ
@\$1parameterName\$1 構文は、ポリシーテンプレートでパラメータを定義するときに使用します。委任リクエストを作成するときは、各パラメータのタイプを指定します。
#### String
テンプレートに直接代入される 1 個の値です。
テンプレート:
```
"Resource": "arn:aws:s3:::@{bucketName}/*"
```
パラメータ :
```
{
"Name": "bucketName",
"Values": ["my-bucket"],
"Type": "String"
}
```
生成された結果
```
"Resource": "arn:aws:s3:::my-bucket/*"
```
#### StringList
複数のリソースエントリを生成する複数の値です。StringList パラメータは、リソース ARN で使用すると、値ごとに個別のリソースエントリを作成するように拡張します。
テンプレート:
```
"Resource": "arn:aws:s3:::@{bucketNames}/*"
```
パラメータ :
```
{
"Name": "bucketNames",
"Values": ["bucket-1", "bucket-2"],
"Type": "StringList"
}
```
生成された結果
```
"Resource": [
"arn:aws:s3:::bucket-1/*",
"arn:aws:s3:::bucket-2/*"
]
```
#### クロス積の動作
複数のパラメータを同じリソース ARN で使用すると、StringList パラメータはすべての組み合わせのクロス積を作成します。
テンプレート:
```
"Resource": "arn:aws:s3:::@{bucketNames}/@{prefix}/*"
```
パラメータ :
```
[
{
"Name": "bucketNames",
"Values": ["bucket-1", "bucket-2"],
"Type": "StringList"
},
{
"Name": "prefix",
"Values": ["data"],
"Type": "String"
}
]
```
生成された結果
```
"Resource": [
"arn:aws:s3:::bucket-1/data/*",
"arn:aws:s3:::bucket-2/data/*"
]
```
### 条件ステートメント
@Enabled ディレクティブは、パラメータ値に基づいてステートメント全体を条件付きで包含または除外するときに使用します。
構文:
+ @Enabled: "parameterName" – このステートメントは、パラメータ値が「True」のときに含めます
+ @Enabled: "\$1parameterName" – このステートメントは、パラメータ値が「True」ではない (否定) のときに含めます
テンプレート:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "*"
},
{
"@Enabled": "ENABLE_S3_WRITE",
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": "arn:aws:s3:::@{bucketName}/*"
}
]
}
```
パラメータ (ENABLE\$1S3\$1WRITE が「True」のとき)
```
[
{
"Name": "bucketName",
"Values": ["my-bucket"],
"Type": "String"
},
{
"Name": "ENABLE_S3_WRITE",
"Values": ["True"],
"Type": "String"
}
]
```
生成された結果
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
```
パラメータ (ENABLE\$1S3\$1WRITE が「False」のとき)
```
[
{
"Name": "bucketName",
"Values": ["my-bucket"],
"Type": "String"
},
{
"Name": "ENABLE_S3_WRITE",
"Values": ["False"],
"Type": "String"
}
]
```
生成された結果
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "*"
}
]
}
```
ENABLE\$1S3\$1WRITE を「True」に設定すると条件ステートメントが含まれます。「False」に設定すると、ステートメントは生成されたポリシーから除外されます。
## その他の例
一時委任でポリシーテンプレートを使用する際の、共通するパターンの例を以下にご紹介します。長期間有効なアクセス許可を提供するために、アクセス許可の境界を持つ IAM ロールを作成することに焦点をあて、特定のリソースに的を絞ったアクセス許可を設定するためのさまざまな戦略をご紹介します。こちらの例では、ARN プレフィックス、リソースのタグ付け、アクセス許可の境界の更新といった方法を使用することで、柔軟性とセキュリティの間のバランスを取っています。
### 例 1: 特定のリソースへのアクセスを長期間許可する
次のアクセス許可の境界は、「partner.com」の「SQSAccessorBoundary」として送信されます。
```
{
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
```
**注記**
これには、オープンなリソースポリシーを持つ他のアカウントの、キューへのアクセスを許可しないための、同一アカウント条件が含まれます。この境界は全顧客間で共有されテンプレート化ができないため、顧客のアカウント ID への直接参照は、含めることができません。
こちらはこのポリシーの初版であるため、ARN は以下のようになります。arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary\$12025\$101\$115
一時的なアクセス許可については、次のポリシーテンプレートが送信されます。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sqs:ListQueues"
],
"Resource": "arn:aws:sqs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:PutRolePermissionsBoundary",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15"
}
}
}
]
}
```
### 例 2: ARN プレフィックスを使用する
アクセス許可の境界を使用すると、リソース ARN プレフィックスを指定してアクセスを制限することができます。
```
"Resource": "arn:aws:sqs:*:@{AccountId}:PartnerPrefix*"
```
それにより、アクセスできるのはこのプレフィックスを持つリソースのみに限定され、アクセス可能なリソースの範囲が狭められます。
### 例 3: リソースアクセスコントロールにタグを使用する
一時委任によるアクセスの最中にリソースにタグを付け、それらのタグを使って長期間のアクセス制御が行えます。
タグ付けされたリソースへのアクセスを許可するアクセス許可の境界
```
{
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"Null": {
"aws:ResourceTag/ManagedByPartnerDotCom": "false"
},
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
```
作成時に新しいキューにタグを付けるポリシーテンプレート
```
{
"Effect": "Allow",
"Action": [
"sqs:CreateQueue",
"sqs:TagQueue"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"Null": {
"aws:RequestTag/ManagedByPartnerDotCom": "false"
}
}
}
```
既存のキューにタグ付けしてロールを作成するポリシーテンプレート
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sqs:TagQueue"
],
"Resource": "arn:aws:sqs:*:@{AccountId}:@{QueueName}",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": "ManagedByPartnerDotCom"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:PutRolePermissionsBoundary",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15"
}
}
}
]
}
```
この方法を使えば、顧客は自分がどのリソースに長期間アクセスできるのかを明示的に確認できます。
### 例 4: アクセス許可の境界を更新する
アクセス許可の境界を更新するには、新しいバージョンを新しい日付サフィックスに登録し、それを置き換えるアクセス許可をリクエストします。
追加のアクセス許可を使ってアクセス許可の境界を更新する
```
{
"Effect": "Allow",
"Action": [
"sqs:DeleteMessage",
"sqs:PurgeQueue",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:*:*:*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
```
第 2 版として、このポリシーには次の ARN が含まれます。arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary\$12025\$101\$120
既存のロールのアクセス許可の境界を更新するポリシーテンプレート
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:PutRolePermissionsBoundary"
],
"Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_20"
}
}
}
]
}
```
顧客は、既存のロールのアクセス許可の境界を更新するには、この委任リクエストを承認する必要があります。
# 統合の構築
## リクエストのライフサイクルについて
統合を構築するときは、まず、委任リクエストの作成から完了までのプロセスを理解する必要があります。
### リクエストのステータス
委任リクエストは以下のステータスを経て進行します。
| 状態 | 説明 |
| --- | --- |
| 未割り当て | リクエストは作成済みですが、まだ顧客アカウントや IAM プリンシパルに関連付けられていない状態です。リクエストは、ターゲットアカウントを指定せずに作成されたか、ターゲットアカウントの ID は指定されているものの、そのアカウントの所有者からまだ請求されていない可能性があります。 |
| 割り当て済み | リクエストは顧客アカウントに関連付けられ、確認待ちの状態です |
| 承認待ち | リクエストは承認のため顧客から管理者に転送されています |
| 承諾 | リクエストは顧客によって承認済みですが、交換トークンはまだ発行されていない状態です |
| 完了 | 交換トークンは製品プロバイダーに発行済みです。委任期間 (交換トークンが有効な期間) は、リクエストのステータスが「完了」になったときから始まります |
| 拒否 | リクエストは顧客から拒否されています |
| 失効 | リクエストは非アクティブまたはタイムアウトのため期限が切れています |
### ステータスの移行
*通常のフロー (承認の流れ)*
+ 未割り当て → 割り当て済み: 顧客がリクエストを自分のアカウントに関連付ける
+ 割り当て済み → 承認済みまたは割り当て済み → 承認待ち: 顧客がリクエストを直接承認するまたは管理者に転送して承認を受ける
+ 承認待ち → 承諾済み: 管理者がリクエストを承認する
+ 承認済み → 完了: 顧客が交換トークンを発行する
*拒否の流れ*
+ 割り当て済み → 拒否: 顧客がリクエストを拒否する
+ 承認待ち → 拒否: 管理者がリクエストを拒否する
+ 承認済み → 拒否: 顧客がトークンの発行前に承認を取り消す
*期限切れの流れ*
指定した期間内にアクションが 1 つも実行されなかった場合、リクエストは自動的に期限切れになります。
+ 未割り当て → 期限切れ (1 日)
+ 割り当て済み → 期限切れ (7 日間)
+ 承認待ち → 期限切れ (7 日間)
+ 承認済み → 期限切れ (7 日間)
+ 拒否 → 期限切れ (7 日間)
+ 完了 → 期限切れ (7 日間)
*ターミナルステータス*
以下のステータスは「ターミナル」です (移行はここで終わりです)。
+ 完了: 交換トークンは送信済みです
+ 拒否: リクエストは拒否されました
+ 期限切れ: リクエストはタイムアウトしたか委任期間が終了しています
期限が切れたリクエストは、保持期間が過ぎるとシステムから削除されます。
### 委任リクエストのステータスをアプリケーションで管理する
パートナーであるユーザーは、委任リクエストのステータスを自分のシステムで追跡し、顧客に見せる必要があります。ステータスの変更に関する SNS 通知がお手元に届いたら、その更新をバックエンドに保存して顧客向けの UI に反映させます。特に「承認待ち」のステータスには注意が必要です。顧客が承認を受けるためリクエストを管理者に転送した場合、ユーザーには AWS から「承認待ち」の通知が届きます。リクエストは、管理者のアクションを待つ間、最大で 7 日間このステータスに留まることができます。この間、顧客には、リクエストが管理者の承認待ちであることをアプリケーション内で知らせます。顧客がリクエストのステータスをチェックしたり管理者をフォローしたりできる AWS コンソールの、ディープリンクを提供することを検討しましょう。バックエンドでステートマシンを適切に処理し、各段階で顧客に正しいステータス情報を見せることは、優れた統合体験の提供に欠かせません。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/delegation-states.png)
## 通知の設定
IAM は、委任リクエストのステータス変更の通知に Amazon Simple Notification Service (SNS) を使用します。委任リクエストを作成するときは、登録済みの AWS アカウントから SNS トピック ARN を指定する必要があります。IAM は、顧客がリクエストを承認または拒否したときや交換トークンの準備が完了したときなど、重要なイベントの際にこのトピックにメッセージを発行します。
**注記**
SNS トピックは、オプトインの AWS リージョンには配置できません。SNS トピックはデフォルトで有効になっている AWS リージョンに配置する必要があります。オプトインリージョンの一覧については「AWS アカウント管理ガイド」の「AWS リージョンの管理」を参照してください。
### SNS トピックの設定
委任リクエストの通知を受けとるには、IAM アクセス許可を付与してメッセージを発行するように、SNS トピックを設定する必要があります。以下のポリシーステートメントを SNS トピックのポリシーに追加します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowIAMServiceToPublish",
"Effect": "Allow",
"Principal": {
"Service": "iam.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:REGION:ACCOUNT-ID:TOPIC-NAME"
}
]
}
```
**重要**
SNS トピックは、登録済み AWS アカウントのうちの 1 つに配置する必要があります。IAM は、他のアカウントの SNS トピックは受け入れません。トピックポリシーが正しく設定されていないと、ステータスの変更通知や交換トークンを受けとれません。
### 通知タイプ
IAM は次の 2 種類の通知を送信します。
*StateChange 通知*
委任リクエストが新しいステータス (割り当て済み、承認待ち、承認済み、完了、拒否、期限切れ) に移行すると送信されます。
*ExchangeToken 通知*
顧客が委任トークンを発行すると送信されます (ステータスは「完了」)。この通知には、認証情報の取得に必要な交換トークンが含まれています。
### 通知のステータス
ユーザーには、以下の委任リクエストのステータスに関する通知が届きます。
| State | 通知タイプ | 説明 |
| --- | --- | --- |
| 割り当て済み | StateChange | リクエストは顧客アカウントに関連付けられています |
| 承認待ち | StateChange | リクエストは承認のため顧客から管理者に転送されています |
| 承認済み | StateChange | リクエストは顧客によって承認済みですが、交換トークンはまだ発行されていません |
| 完了 | StateChange | 交換トークンが顧客によって発行済みです |
| 完了 | ExchangeToken | この通知には交換トークンが含まれています |
| 拒否 | StateChange | リクエストは顧客によって拒否されました |
| EXPIRED | StateChange | リクエストは完了前に期限が切れました |
### 通知メッセージの書式
IAM は標準の SNS 通知を発行します。委任リクエストの情報は、「Message」のフィールドに JSON 文字列で含まれています。
*共通のフィールド (すべての通知)*
| フィールド | タイプ | 説明 |
| --- | --- | --- |
| タイプ | String | 「StateChange」または「ExchangeToken」のいずれか |
| RequestId | String | IAM 委任リクエストの ID |
| RequestorWorkflowId | String | リクエストの作成時に指定したワークフローの ID |
| State | String | リクエストの現在のステータス |
| OwnerAccountId | String | 顧客の AWS アカウントの ID |
| UpdatedAt | String | ステータスが変更された時点のタイムスタンプ (ISO 8601 形式) |
*その他のフィールド (ExchangeToken 通知のみ)*
| フィールド | タイプ | 説明 |
| --- | --- | --- |
| ExchangeToken | String | AWS STS GetDelegatedAccessToken API を使用して認証情報と交換するトークン |
| ExpiresAt | String | 委任されたアクセス許可の期限が切れたとき (ISO 8601 形式) |
### 通知の例
*StateChange 通知*
```
{
"Type": "Notification",
"MessageId": "61ee8ad4-6eec-56b5-8f3d-eba57556aa13",
"TopicArn": "arn:aws:sns:us-east-1:123456789012:partner-notifications",
"Message": "{\"RequestorWorkflowId\":\"workflow-12345\",\"Type\":\"StateChange\",\"RequestId\":\"dr-abc123\",\"State\":\"ACCEPTED\",\"OwnerAccountId\":\"111122223333\",\"UpdatedAt\":\"2025-01-15T10:30:00.123Z\"}",
"Timestamp": "2025-01-15T10:30:00.456Z",
"SignatureVersion": "1",
"Signature": "...",
"SigningCertURL": "...",
"UnsubscribeURL": "..."
}
```
*ExchangeToken 通知*
```
{
"Type": "Notification",
"MessageId": "e44e5435-c72c-5333-aba3-354406782f5b",
"TopicArn": "arn:aws:sns:us-east-1:123456789012:partner-notifications",
"Message": "{\"RequestId\":\"dr-abc123\",\"RequestorWorkflowId\":\"workflow-12345\",\"State\":\"FINALIZED\",\"OwnerAccountId\":\"111122223333\",\"ExchangeToken\":\"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...\",\"ExpiresAt\":\"2025-01-15T18:30:00.123Z\",\"UpdatedAt\":\"2025-01-15T10:30:00.456Z\",\"Type\":\"ExchangeToken\"}",
"Timestamp": "2025-01-15T10:30:00.789Z",
"SignatureVersion": "1",
"Signature": "...",
"SigningCertURL": "...",
"UnsubscribeURL": "..."
}
```
## 交換トークン
交換トークンは、顧客が委任リクエストを承認して完了したときに IAM から発行されます。製品プロバイダーは、この交換トークンを使用して AWS AWS STS GetDelegatedAccessToken API を呼び出し、顧客が承認したアクセス許可を持つ一時的な AWS 認証情報を取得します。交換トークン自体は AWS リソースへのアクセスを許可するものではなく、AWS STS を介して実際の認証情報と交換する必要があります。
交換トークンは、委任リクエストを作成した製品プロバイダーアカウントからのみ、引き換えが可能です。リクエストを行ったアカウントはこのトークンに埋め込まれ、承認された製品プロバイダーのみが、顧客アカウントにアクセスするための認証情報を取得できるようになっています。
### アクセス許可の有効期間
委任期間は顧客が交換トークンを発行した時点からはじまります。製品プロバイダーが交換トークンを引き替えた時点ではありません。顧客がトークンを発行すると、
+ 製品プロバイダーは SNS 通知を介してトークンを受けとります
+ トークンは直ちに認証情報と交換できます
+ 認証情報は、発行時間から承認済みの期間が経過すると期限が切れます。
+ 製品プロバイダーは、期限が切れる前にトークンを複数回交換し、必要に応じて新しい認証情報を取得することができます。
### 複数の引き換え
製品プロバイダーは、有効期間中にトークンを複数回交換して、新しい認証情報を取得することができます。ただし、同じ交換トークンから取得した認証情報はすべて、トークンを発行した時刻に基づき同時に期限が切れます。
例: 2 時間の委任リクエストを承認し、午前 10 時にトークンを発行する場合
| トークンの発行時刻 | トークン交換時刻 | 認証情報の有効期限 | 使用可能な時間 |
| --- | --- | --- | --- |
| 10:00 am | 10:00 am | 12:00 pm | 2 時間 |
| 10:00 am | 午前 10 時 20 分 | 12:00 pm | 1 時間 40 分 |
| 10:00 am | 午前 11 時 40 分 | 12:00 pm | 20 分 |
| 10:00 am | 12:10 pm | 失敗 (トークンの有効期限切れ) | 0 分 |
表に示すように、有効期間の後半でトークンを交換すると、製品プロバイダーの使用可能時間は短くなります。