# IAM のチュートリアル
次のチュートリアルでは、AWS Identity and Access Management (IAM) の一般的なタスクにおけるエンドツーエンドの一連の手順について説明します。これらはラボ型環境向けであり、架空の企業名やユーザー名などを含みます。目的は、一般的なガイダンスを提供することです。お客様の組織環境に固有のニーズを満たすかどうかの十分な確認や調整をすることなく、本番環境で直接使用するためのものではありません。
**Topics**
+ [AWS アカウント 間のロールを使用したアクセスの委任](tutorial_cross-account-with-roles.md)
+ [カスタマー管理ポリシーを作成する](tutorial_managed-policies.md)
+ [属性ベースのアクセスコントロール (ABAC) を使用する](tutorial_attribute-based-access-control.md)
+ [ユーザーが認証情報と MFA 設定を管理できるようにする](tutorial_users-self-manage-mfa-and-creds.md)
+ [CloudFormation を使用して SAML IdP を作成する](tutorial_saml-idp.md)
+ [CloudFormation を使用して SAML フェデレーションロールを作成する](tutorial_saml-federated-role.md)
+ [CloudFormation を使用して SAML IdP とフェデレーションロールを作成する](tutorial_saml-idp-and-federated-role.md)
# IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任
**重要**
IAM [ベストプラクティス](best-practices.md)では、長期的な認証情報を持つIAMユーザーを使用するのではなく、一時的な認証情報を使用して AWS にアクセスするために、IDプロバイダーとのフェデレーションを使用することを人間ユーザーに求めることを推奨します。IAM ユーザーは、フェデレーションユーザーでサポートされていない[特定のユースケース](gs-identities-iam-users.md)にのみ使用することをお勧めします。
このチュートリアルでは、ロールを使用して、**ターゲット**と**ソース**と呼ばれる、さまざまな AWS アカウント にあるリソースへのアクセスを委任する方法を説明します。特定のアカウントにあるリソースを別のアカウントのユーザーと共有します。このようにクロスアカウントアクセスを設定することで、お客様はアカウントごとに IAM ユーザーを作成する必要がなくなります。また、ユーザーは、異なる AWS アカウント のアカウントのリソースにアクセスするために、あるアカウントからサインアウトして別のアカウントにサインインする必要がなくなります。ロールを設定した後、AWS マネジメントコンソール、AWS CLI、API からロールを使用する方法について説明します。
このチュートリアルでは、**ターゲット**アカウントが、さまざまなアプリケーションやチームがアクセスするアプリケーションデータを管理します。各アカウントでは、Amazon S3 バケットにアプリケーション情報を保存します。IAM ユーザーは、**ソース**アカウントで管理します。ソースアカウントには、**デベロッパー**と**アナリスト**の 2 つの IAM ユーザーロールがあります。デベロッパーとアナリストは、**ソース**アカウントを使用して、複数のマイクロサービスによって共有されるデータを生成します。どちらのロールにも、ソースアカウントで作業し、そこにあるリソースにアクセスするための許可が付与されています。デベロッパーは、**ターゲット**アカウントの共有データを随時更新する必要があります。デベロッパーは、このデータを `amzn-s3-demo-bucket-shared-container` という Amazon S3 バケットに保存します。
このチュートリアルを終了すると、次のようになります。
+ **ターゲット**アカウントで特定のロールを引き受けることができる**ソース**アカウント (信頼されたアカウント) のユーザー。
+ 特定の Amazon S3 バケットへのアクセスを許可される**ターゲット**アカウント (信頼するアカウント) のロール。
+ **ターゲット**アカウントの `amzn-s3-demo-bucket-shared-container` バケット。
デベロッパーは、AWS マネジメントコンソール でロールを使用して**ターゲット**アカウントの `amzn-s3-demo-bucket-shared-container` バケットにアクセスできます。さらに、ロールにより提供される一時的な認証情報によって認証された API コールを使用してバケットにアクセスすることもできます。アナリストによるロールの使用の類似の試みは失敗します。
このワークフローに 3 つの基本的なステップがあります:
**[ターゲットアカウントにロールを作成する](#tutorial_cross-account-with-roles-1)**
まず、AWS マネジメントコンソール を使用して**ターゲット**アカウント (ID 番号 999999999999) と**ソース**アカウント (ID 番号 111111111111) との間の信頼を確立します。まず、UpdateData という名前の IAM ロールを作成します。ロールの作成時に、**ソース**アカウントを信頼されたエンティティとして定義し、信頼されたユーザーが `amzn-s3-demo-bucket-shared-container` バケットを更新することを許可する許可ポリシーを指定します。
**[ロールにアクセス許可を付与する](#tutorial_cross-account-with-roles-2)**
このセクションでは、ロールポリシーを変更して、アナリストが `UpdateData` ロールにアクセスするのを拒否します。このシナリオではアナリストに PowerUser アクセス許可があるため、ロールの使用を明示的に拒否する必要があります。
**[ロールを切り換えてアクセスをテストする](#tutorial_cross-account-with-roles-3)**
最後にデベロッパーとして、`UpdateData` ロールを使用して**ターゲット**アカウントの `amzn-s3-demo-bucket-shared-container` バケットを更新します。AWS コンソール、AWS CLI、API を使用してロールにアクセスする方法について説明します。
## 考慮事項
IAM ロールを使用して AWS アカウント 間でリソースアクセスを委任する前に、次を考慮することが重要です。
+ AWS アカウントのルートユーザー としてサインインしているときに、ロールを切り替えることはできません。
+ IAM ロールとリソースベースのポリシーは、単一のパーティション内のアカウント間でのみアクセスを委任します。例えば、標準 `aws` パーティションの米国西部 (北カリフォルニア)と、`aws-cn` パーティションの中国 (北京) にアカウントがあるとします。中国 (北京) アカウントの Amazon S3 リソースベースのポリシーを使用して、標準 `aws` アカウントのユーザーにアクセスを許可することはできません。
+ AWS IAM アイデンティティセンター を使用すると、Security Assertion Markup Language (SAML) を使用して、外部 AWS アカウント (AWS Organizations の外部のアカウント) のシングルサインオン (SSO) を容易にすることができます。詳細については、「[ Integrate external AWS アカウント into AWS IAM アイデンティティセンター for central access management with independent billing using SAML 2.0](https://community.aws/content/2dIMI8N7w7tGxbE0KQMrkSBfae4/aws-iam-identity-center-integration-with-external-aws-accounts-for-independent-billing?lang=en)」を参照してください。
+ Amazon EC2 インスタンスや AWS Lambda 関数などの AWS リソースにロールを関連付けることができます。詳細については、「[AWS サービスにアクセス許可を委任するロールを作成する](id_roles_create_for-service.md)」を参照してください。
+ アプリケーションが別の AWS アカウント でロールを引き受けるようにする場合は、AWS SDK を使用してクロスアカウントロールを引き受けることができます。詳細については、「AWS SDK およびツールのリファレンスガイド」の「[Authentication and access](https://docs.aws.amazon.com//sdkref/latest/guide/access.html)」を参照してください。
+ AWS マネジメントコンソール を使ったロールの切り替えは、`ExternalId` を必要としないアカウントでのみ機能します。たとえば、アカウントへのアクセス権を第三者に付与し、アクセス許可ポリシーの `Condition` 要素に `ExternalId` を要求するとします。その場合、第三者は AWS API またはコマンドラインツールを使用してのみ、お客様のアカウントにアクセスできます。第三者は、`ExternalId` の値を指定する必要があるため、コンソールを使用できません。このシナリオの詳細については、「AWS マネジメントコンソール」、および「[第三者が所有する AWS アカウント へのアクセス](id_roles_common-scenarios_third-party.md) セキュリティブログ」の「[How to enable cross account access to the AWS](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console)」を参照してください。
## 前提条件
このチュートリアルでは、以下を実行済みであることを前提としています。
+ 使用できる AWS アカウント を、それぞれ**ソース**アカウントと**ターゲット**アカウントを表す **2** つのアカウントに分けます。
+ **ソース**アカウントのユーザーとロールは次のように作成および構成されます。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ **ターゲット**アカウントでユーザーを作成する必要はありません。
+ **ターゲット**アカウントで作成された Amazon S3 バケット。このチュートリアルでは `amzn-s3-demo-bucket-shared-container` と呼びますが、S3 バケット名はグローバルに一意である必要があるため、別の名前のバケットを使用する必要があります。
## ターゲットアカウントにロールを作成する
ある AWS アカウント のユーザーに別の AWS アカウント のリソースへのアクセスを許可できます。このチュートリアルでは、誰がアクセスできるか、およびそのロールに切り替えるユーザーにどのような許可を付与するかを定義するロールを作成することでこれを実行します。
チュートリアルのこのステップでは、**ターゲット**アカウントにロールを作成し、**ソース**アカウントを信頼されたエンティティとして指定します。また、ロールのアクセス許可を `amzn-s3-demo-bucket-shared-container` バケットでの読み書き専用に制限します。ロールを使用するアクセス許可が付与されるすべてのユーザーは、`shared-container` バケットに対する読み取りと書き込みを実行できます。
ロールを作成する前に、**ソース** AWS アカウント のアカウント ID が必要です。各 AWS アカウント には、固有の識別子であるアカウント ID が割り当てられています。
**ソース AWS アカウント ID を取得するには**
1. **ソース**アカウントの管理者として AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。
1. IAM コンソールで、右上のナビゲーションバーのユーザー名を選択します。通常は ***username*@*account\$1ID\$1number\$1or\$1alias*** のように表示されます。
このシナリオでは、アカウント ID 111111111111 を**ソース**アカウントとして使用します。ただし、テスト環境でこのシナリオを使用する場合は、有効なアカウント ID を使用する必要があります。
**ソースアカウントで使用できるロールをターゲットアカウントで作成するには**
1. **ターゲット**アカウントの管理者として AWS マネジメントコンソール にサインインし、IAM コンソールを開きます。
1. ロールを作成する前に、ロールに必要なアクセス許可を定義する管理ポリシーを準備します。後の手順で、このポリシーをロールにアタッチします。
`amzn-s3-demo-bucket-shared-container` バケットの読み込みおよび書き込みのアクセスを設定します。AWS には Amazon S3 管理ポリシーがありますが、単一の Amazon S3 バケットへの読み取りおよび書き込みアクセスを提供するポリシーはありません。代わりにポリシーを自作することができます。
ナビゲーションペインで、[**Policies (ポリシー)**] を選択し、[**Create Policy (ポリシーの作成)**] を選択します。
1. [**JSON**] タブを選択し、以下の JSON ポリシードキュメントからテキストをコピーします。**[JSON]** (JSON) テキストボックスにこのテキストを貼り付け、リソース ARN (`arn:aws:s3:::shared-container`) を、Amazon S3 バケットの実際の ARN に置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container/*"
}
]
}
```
------
`ListAllMyBuckets` アクションは、リクエストの認証済み送信者によって所有されているすべてのバケットを一覧表示するアクセス許可を付与します。`ListBucket` アクセス許可は、ユーザーに `amzn-s3-demo-bucket-shared-container` バケットにあるオブジェクトの閲覧を許可します。`GetObject`、`PutObject`、`DeleteObject` アクセス許可によって、ユーザーは `amzn-s3-demo-bucket-shared-container` バケットの内容を表示、更新、および削除できます。
**注記**
いつでも **[ビジュアル]** と **[JSON]** エディタオプションを切り替えることができます。ただし、**[Visual]** エディタで **[次へ]** に変更または選択した場合、IAM はポリシーを再構成して visual エディタに合わせて最適化することがあります。詳細については、「[ポリシーの再構成](troubleshoot_policies.md#troubleshoot_viseditor-restructure)」を参照してください。
1. **[確認および作成]** ページで、ポリシー名として「**read-write-app-bucket**」と入力します。ポリシーによって割り当てられたアクセス許可を確認し、**[ポリシーの作成]** を選択して作業を保存します。
新しいポリシーが管理ポリシーの一覧に表示されます。
1. ナビゲーションペインで **[ロール]** を選択した後、**[ロールの作成]** を選択します。
1. **[AWS アカウント]** のロールタイプを選択します。
1. **[アカウント ID]** で、**ソース**アカウント ID を入力します。
このチュートリアルでは、**ソース**アカウントにサンプルのアカウント ID **111111111111** を使用します。有効なアカウント ID を使用してください。使用しているアカウント ID が無効 ( **111111111111** など) の場合は、IAM で新しいロールを作成することはできません。
現時点では、ロールを引き受けるために、外部 ID や多要素認証 (MFA) は必要ありません。これらのオプションは選択していない状態にしておきます。詳細については、「[IAM の AWS 多要素認証](id_credentials_mfa.md)」を参照してください。
1. [**Next: Permissions**] (次へ: アクセス許可) を選択して、そのロールに関連するアクセス許可を設定します。
1. 以前に作成したポリシーの横にあるチェックボックスをオンにします。
**ヒント**
**[Filter]** (フィルター) で、**[Customer managed]** (カスタマー管理ポリシー) を選択してリストをフィルター処理し、自分で作成したポリシーのみが含まれるようにします。これにより、AWS が作成したポリシーが非表示になり、必要なポリシーを見つけるのが簡単になります。
その後、**[Next]** を選択します。
1. (オプション) タグをキーバリューのペアとしてアタッチして、メタデータをロールに追加します。IAM におけるタグの使用の詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。
1. (オプション) **[説明]** には、新しいロールの説明を入力します。
1. ロールを確認したら、[**ロールの作成**] を選択します。
ロールのリストで、`UpdateData` ロールが表示されます。
ここで、ロールに固有の識別子である Amazon リソースネーム (ARN) を取得しなければいけません。ソースアカウントでデベロッパーのロールを変更する際には、ターゲットアカウントからロール ARN を指定して、許可を付与または拒否します。
**UpdateData の ARN を取得するには**
1. IAM コンソールのナビゲーションペインで **[ロール]** を選択します。
1. ロールのリストで、[`UpdateData`] ロールを選択します。
1. 詳細ペインの [**Summary (概要)**] セクションで、[**ロール ARN**] の値をコピーします。
ターゲットアカウントのアカウント ID が 999999999999 であるため、ロール ARN は `arn:aws:iam::999999999999:role/UpdateData` となります。ターゲットアカウントでは、実際の AWS アカウント ID を指定してください。
この時点で、**ターゲット**アカウントと**ソース**アカウントの間に信頼が確立されています。そのためには、**ソース**アカウントを信頼されたプリンシパルとして識別するロールを**ターゲット**アカウントに作成します。また、`UpdateData` ロールに切り替えるユーザーが何を実行できるかについても定義しました。
次に、デベロッパーロールの許可を変更します。
## ロールにアクセス許可を付与する
この時点で、アナリストとデベロッパーの両方には、**ソース**アカウントのデータを管理できるようにする許可が付与されています。ロールの切り替えを許可するアクセス許可を追加するには、この必要な手順に従ってください。
**UpdateData ロールに切り替えることを許可するようにデベロッパーロールを変更するには**
1. **ソース**アカウントの管理者としてサインインし、IAM コンソールを開きます。
1. **[ロール]**、**[デベロッパー]** の順に選択します。
1. [**アクセス許可**]タブを選択し、[**アクセス許可の追加**]を選択してから、[**インラインポリシーの作成]**を選択します。
1. **JSON** タブを選択します。
1. 次のポリシーステートメントを追加して、ターゲットアカウントの `UpdateData` ロールに対する `AssumeRole` アクションを許可します。必ず `Resource` 要素の *DESTINATION-ACCOUNT-ID* を、ターゲットアカウントの実際の AWS アカウント ID に変更してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
`Allow` エフェクトは、デベロッパーグループがターゲットアカウントの `UpdateData` ロールにアクセスすることを明示的に許可します。どのデベロッパーがこのロールにアクセスしようとしても成功します。
1. **[ポリシーの確認]** を選択します。
1. **allow-assume-S3-role-in-destination** などの**名前**を入力します。
1. [**Create policy**] (ポリシーの作成) を選択します。
ほとんどの環境では、次の手順は必要ありません。ただし、PowerUserAccess アクセス許可を使用している場合、グループによってはロールを切り替えることができます。次の手順は、ロールを引き受けることができないようにアナリストグループに `"Deny"` 許可を追加する方法を示しています。お客様の環境でこの手順が必要ない場合は、追加しないことをお勧めします。`"Deny"` アクセス許可を追加すると、アクセス許可の全体的な状況が複雑になり、管理しづらくなります。`"Deny"` アクセス許可は、他に良いオプションがない場合のみ使用してください。
**アナリストのロールを変更して、`UpdateData` ロールを引き受けるための許可を拒否する**
1. **[ロール]** を選択し、**[アナリスト]** を選択します。
1. [**アクセス許可**]タブを選択し、[**アクセス許可の追加**]を選択してから、[**インラインポリシーの作成]**を選択します。
1. **JSON** タブを選択します。
1. 次のポリシーステートメントを追加して、`AssumeRole` ロールに対する `UpdateData` アクションを拒否します。必ず `Resource` 要素の *DESTINATION-ACCOUNT-ID* を、ターゲットアカウントの実際の AWS アカウント ID に変更してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
`Deny` エフェクトは、アナリストグループがターゲットアカウントの `UpdateData` ロールにアクセスすることを明示的に拒否します。そのロールにアクセスしようとするアナリストは、アクセス拒否のメッセージを受け取ります。
1. **[ポリシーの確認]** を選択します。
1. **deny-assume-S3-role-in-destination** のような**名前**を入力します。
1. [**Create policy**] (ポリシーの作成) を選択します。
これで、デベロッパーロールは、ターゲットアカウントの `UpdateData` ロールを使用するための許可を持つようになりました。アナリストロールは、`UpdateData` ロールを使用できません。
次に、デベロッパーの David がターゲットアカウントの `amzn-s3-demo-bucket-shared-container` バケットにアクセスする方法について説明します。David は、AWS マネジメントコンソール、AWS CLI、または AWS API からバケットにアクセスできます。
## ロールを切り換えてアクセスをテストする
このチュートリアルの最初の 2 つのステップを完了した時点で、**ターゲット**アカウントのリソースに対するアクセス許可を付与するロールがあります。また、**ソース**アカウントには 1 つのロールがあり、ユーザーはそのロールの使用を許可されています。このステップでは、AWS マネジメントコンソール、AWS CLI、および AWS API のロールへの切り替えについて説明します。
IAM ロールの使用時に発生する可能性がある一般的な問題のヘルプについては、「[IAM ロールをトラブルシューティングする](troubleshoot_roles.md)」を参照してください。
### ロールの切り替え (コンソール)
David が AWS マネジメントコンソール の**ターゲット**アカウントのデータを更新する必要がある場合は、**[ロールの切り替え]** を使用して更新できます。アカウント ID またはエイリアスとロール名を指定すれば、David のアクセス権限は、ロールによって許可されているものに直ちに切り替わります。次に、David はコンソールを使用して `amzn-s3-demo-bucket-shared-container` バケットを使用できますが、**ターゲット**の他のリソースは一切使用できません。David がロールを使用中に、**ソース**アカウントのパワーユーザー特権を使用することもできません。これは、同時に有効にできるアクセス許可のセットは 1 つのみであるためです。
David が IAM で **[Switch Role]** (ロールの切り替え) ページに移動するには、2 つの方法があります。
+ David は事前定義されたロールの切り替え設定を指すリンクを管理者から受け取ります。リンクは [**ロールの作成**] ウィザードの最終ページ、またはクロスアカウントロールの [**ロールの概要**] ページで管理者に提供されます。このリンクを選択すると、[**ロールの切り替え**] ページに移動します。このページには、[**Account ID (アカウント ID)**] および [**ロール名**] フィールドがすでに入力されています。David は、**[ロールの切り替え]** ボタンを選択するだけです。
+ 管理者はメールでリンクを送信しませんが、代わりに [**Account ID (アカウント ID)**] 番号および [**ロール名**] の値を送信します。役割を切り替えるには、デビッドは手動でその値を入力する必要があります。これを次の手順に示します。
**ロールを引き受けるには**
1. David は、**ソース**アカウントで通常のユーザーを使用して AWS マネジメントコンソール にサインインします。
1. 管理者がユーザーに E メールするリンクを選択します。これにより、David は、**[ロールの切り替え]** ページに移動されます。このページには、アカウント ID、エイリアス、およびロール名情報がすでに入力されています。
-または-
David は、ナビゲーションバーのユーザー名 (ID メニュー) を選択してから、[**Switch Roles**.] (ロールの切り替え) を選択します。
David がこの方法で初めて [Switch Role] (スイッチロール) ページにアクセスする場合は、初回アクセス用の **[Switch Role]** (スイッチロール) ページが表示されます。このページでは、ロールを切り替えて AWS アカウント 全体にわたるリソースを管理できるようにする方法についての追加情報が説明されます。David がこの手順の残りを完了するには、このページの **[Switch Role]** (ロールの切り替え) ボタンを選択する必要があります。
1. 次に、ロールにアクセスするために、David はターゲットアカウント ID 番号 (`999999999999`) およびロール名 (`UpdateData`) を入力する必要があります。
またDavid は、現在 IAM でアクティブなロールと、関連するアクセス許可をモニタリングしたいと考えています。この情報を追跡するために、[**Display Name (表示名)**] テキストボックスに「`Destination`」と入力し、赤色のオプションを選択して、[**Switch Role (スイッチロール)**] を選択します。
1. これで、David は Amazon S3 コンソールを使用して、`UpdateData` ロールがアクセス許可を持つ バケットなどのリソースを操作できます。
1. 完了すると、David は元のアクセス権限に戻ることができます。そのためには、ナビゲーションバーのロール表示名 **[ターゲット]** を選択してから、**[David @ 111111111111 に戻る]** を選択します。
1. David が次回にロールに切り替えるために、ナビゲーションバーの **[ID]** メニューを選択すると、ターゲットエントリが前回からそのままになっています。そのエントリを選択するだけで、アカウント ID とロール名を再入力することなく、すぐにロールに切り替えることができます。
### ロールの切り替え (AWS CLI)
David がコマンドラインで**ターゲット**の環境を操作する必要がある場合、[AWS CLI](https://aws.amazon.com/cli/) を使用してこの切り替えを行うことができます。`aws sts assume-role` コマンドを実行し、ロールの ARN を渡して、そのロールの一時的なセキュリティ認証情報を取得します。次に、環境変数でそれらの認証情報を設定し、それ以降の AWS CLI コマンドが、ロールのアクセス許可を使用して動作するようにします。David がロールを使用中に、**ソース**アカウントのパワーユーザーの特権を使用することはできません。これは、一度に有効にできる許可のセットは 1 つのみであるためです。
すべてのアクセスキーとトークンは例にすぎず、実際にはそのように使用できないことに注意してください。ライブ環境の適切な値に置き換えてください。
**ロールを引き受けるには**
1. David はコマンドプロンプトウィンドウを開き、次のコマンドを実行して、AWS CLI クライアントが動作していることを確認します。
```
aws help
```
**注記**
David のデフォルト環境では、`David` コマンドで作成したデフォルトのプロファイルから、`aws configure` ユーザー認証情報を使用します。詳細については、「[AWS Command Line Interface ユーザーガイド](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration)」の「*AWS Command Line Interface の設定*。」を参照してください。
1. David は次のコマンドを実行してロールの切り替えプロセスを開始し、**ターゲット**アカウントで `UpdateData` ロールに切り替えます。ロールを作成した管理者から、ロールの ARN を取得しました。コマンドでは、セッション名も提供する必要もあります。セッション名には任意のテキストを選択できます。
```
aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateData" --role-session-name "David-ProdUpdate"
```
出力には次のように表示されます。
```
{
"Credentials": {
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"SessionToken": "AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLE
CvSRyh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDy
EXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3Uuysg
sKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87e
NhyDHq6ikBQ==",
"Expiration": "2014-12-11T23:08:07Z",
"AccessKeyId": "AKIAIOSFODNN7EXAMPLE"
}
}
```
1. 出力の [認証情報] セクションには、3 つの必要な情報が表示されます。
+ `AccessKeyId`
+ `SecretAccessKey`
+ `SessionToken`
以降の呼び出しでこれらのパラメータを使用するには、AWS CLI 環境を設定する必要があります。認証情報を設定するさまざまな方法の詳細については、「[AWS Command Line Interface の設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence)」を参照してください。セッショントークンの取得をサポートしていないため、`aws configure` コマンドを使用することはできません。ただし、設定ファイルに手動で情報を入力することができます。これらは有効期限が比較的短い一時的な認証情報なので、現在のコマンドラインセッションの環境に追加するのが最も簡単です。
1. David は、環境に 3 つの値を追加するため、前のステップの出力を切り取り、次のコマンドに貼り付けます。セッショントークン出力の改行の問題に対応するため、シンプルなテキストエディターで切り取りと貼り付けを行います。ここではわかりやすくするために改行して表示されていますが、1 行の長い文字列として入力する必要があります。
以下の例では「set」が環境変数を作成するためのコマンドとなっている Windows 環境で指定されたコマンドを示しています。Linux または Mac コンピュータでは、代わりに「export」コマンドを使用します。この例における他の部分はすべて、3 つの環境で有効です。
Windows Powershell 用ツールの使用方法の詳細については、[IAM ロールに切り替える (Tools for Windows PowerShell)](id_roles_use_switch-role-twp.md) を参照してください。
```
set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
set AWS_SESSION_TOKEN=AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvS
Ryh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXA
MPLEKEY9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UusKd
EXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLENhykxiHen
DHq6ikBQ==
```
この時点で、次のコマンドはいずれも、これらの認証情報によって識別されたロールのアクセス権限で実行されます。David の場合は、`UpdateData` ロールです。
**重要**
頻繁に利用される構成設定および認証情報を AWS CLI が維持するファイルに保存することができます。詳細については、「AWS Command Line Interface ユーザーガイド」の「[Using existing configuration and credentials files](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-existing)」を参照してください。
1. ターゲットアカウントのリソースにアクセスするコマンドを実行します。この例では、David は次のコマンドを使用して S3 バケットのコンテンツの一覧を示します。
```
aws s3 ls s3://shared-container
```
Amazon S3 バケット名は共通にユニークであるため、バケットを所有するアカウント ID を指定する必要はありません。その他の AWS サービスのリソースにアクセスするには、そのリソースを参照するために必要なコマンドと構文について記載されている対象サービスの AWS CLI のドキュメントを参照してください。
### AssumeRole (AWS API) の使用
David は、コードから**ターゲット**アカウントを更新する必要がある場合、`AssumeRole` を呼び出し、`UpdateData` ロールを取得します。この呼び出しは、David が**ターゲット**アカウントにある `amzn-s3-demo-bucket-shared-container` バケットにアクセスするために使用できる一時的な認証情報を返します。これらの認証情報を使用して、David は `amzn-s3-demo-bucket-shared-container` バケットを更新する API 呼び出しを行うことができます。ただし、**ソース**アカウントのパワーユーザー許可を持っていても、**ターゲット**アカウントの他のリソースにアクセスするために API コールを実行することはできません。
**ロールを引き受けるには**
1. デイビッドは、アプリケーションの一部として `AssumeRole` を呼び出します。ユーザーは、`UpdateData` ARN: `arn:aws:iam::999999999999:role/UpdateData` と指定する必要があります。
`AssumeRole` 呼び出しからのレスポンスには、`AccessKeyId` と `SecretAccessKey` を含む一時的な認証情報が含まれています。また、認証情報の有効期限を示す `Expiration` 時間も含まれており、新しい認証情報をリクエストする必要があります。AWS SDK を使用してロールチェーニングを設定すると、多くの認証情報プロバイダーは、失効前に認証情報を自動的に更新します。
1. 一時的な認証情報を使用して、デイビッドは `s3:PutObject` 呼び出しを行い、`amzn-s3-demo-bucket-shared-container` バケットを更新します。ユーザーは、`AuthParams` パラメータとして API 呼び出しに認証情報を渡します。ロールの一時的な認証情報は `amzn-s3-demo-bucket-shared-container` バケットでの読み取りおよび書き込み専用のアクセスであるため、ターゲットアカウントでの他のアクションは拒否されます。
コードの例 (Python を使用) については、「[IAM ロールを切り替える (AWS)](id_roles_use_switch-role-api.md)」を参照してください。
## その他のリソース
次のリソースは、このチュートリアルのトピックの詳細を理解するのに役立ちます。
+ IAM ユーザーの詳細については、「[IAM アイデンティティ](id.md)」を参照してください。
+ Amazon S3 バケットの詳細については、*Amazon Simple Storage Service ユーザーガイド*の「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html)」を参照してください。
+ 信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「[IAM Access Analyzer とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。
## 概要
これでクロスアカウント API アクセスのチュートリアルが終了しました。他のアカウントと信頼を構築するロールを作成し、信頼されたエンティティが実行できるアクションを定義しました。次に、ロールポリシーを変更して、どの IAM ユーザーがロールにアクセスできるかを制御しました。その結果、**ソース**アカウントのデベロッパーは、一時的な認証情報を使用して**ターゲット**アカウントにある `amzn-s3-demo-bucket-shared-container` バケットを更新することができます。
# IAM チュートリアル: はじめてのカスタマー管理ポリシーの作成とアタッチ
このチュートリアルでは、AWS マネジメントコンソール を使用して[カスタマー管理ポリシー](access_policies_managed-vs-inline.md#customer-managed-policies)を作成し、AWS アカウント のすべての IAM ユーザーにアタッチします。作成するポリシーでは、IAM テストユーザーに、AWS マネジメントコンソール に直接サインインする読み取り専用アクセス許可を付与します。
このワークフローに 3 つの基本的なステップがあります:
**[ステップ 1: ポリシーを作成する](#step1-create-policy)**
デフォルトでは IAM ユーザーにはアクセス許可はありません。ユーザーは許可されるまで、AWS マネジメントコンソールにアクセスしたり、その中のデータを管理したりすることはできません。このステップでは、アタッチされたユーザーにコンソールへのサインインを許可するカスタマー管理ポリシーを作成します。
**[ステップ 2: ポリシーのアタッチ](#step2-attach-policy)**
ユーザーにポリシーをアタッチする場合、ユーザーはポリシーに関連付けられているすべてのアクセス権限を継承します。このステップでは、テストユーザーに新しいポリシーをアタッチします。
**[ステップ 3: ユーザーアクセスのテスト](#step3-test-access)**
ポリシーがアタッチされると、ユーザーとしてサインインし、ポリシーをテストできます。
## 前提条件
このチュートリアルのステップを実行するには、以下を持っている必要があります:
+ 管理者アクセス許可を持つ IAM ユーザーとしてサインインできる AWS アカウント。
+ 以下のような権限またはメンバーシップが割り当てられていないテスト IAM ユーザー。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/tutorial_managed-policies.html)
## ステップ 1: ポリシーを作成する
このステップで作成するカスタマー管理ポリシーでは、アタッチされたユーザーに、AWS マネジメントコンソール にサインインして IAM データにアクセスする読み取り専用アクセス許可を付与します。
**テストユーザーのポリシーを作成するには**
1. 管理者権限を持つユーザーを使用して、[https：//console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)で IAM コンソールにサインインします。
1. ナビゲーションペインで、**ポリシー** を選択してください。
1. コンテンツペインで、[**ポリシーの作成**] を選択します。
1. [**JSON**] オプションを選択し、以下の JSON ポリシードキュメントからテキストをコピーします。このテキストを **[JSON]** ボックスに貼り付けます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [ {
"Effect": "Allow",
"Action": [
"iam:GenerateCredentialReport",
"iam:Get*",
"iam:List*"
],
"Resource": "*"
} ]
}
```
------
1. [ポリシーの検証](access_policies_policy-validator.md)中に生成されたセキュリティ警告、エラー、または一般警告をすべて解決してから、**[次へ]** を選択します。
**注記**
いつでも [**Visual**] と [**JSON**] エディタオプションを切り替えることができます。ただし、[**Visual editor**] タブで [**Review policy**] を変更または選択した場合、IAM はポリシーを再構成してビジュアルエディタに合わせて最適化することがあります。詳細については、「[ポリシーの再構成](troubleshoot_policies.md#troubleshoot_viseditor-restructure)」を参照してください。
1. **[確認および作成]** ページで、ポリシー名として「**UsersReadOnlyAccessToIAMConsole**」と入力します。ポリシーによって割り当てられたアクセス許可を確認し、[**ポリシーの作成**] を選択して作業を保存します。
新しいポリシーが管理ポリシーの一覧に表示され､アタッチの準備ができます。
## ステップ 2: ポリシーのアタッチ
次に、作成したポリシーをテスト IAM ユーザーにアタッチします。
**テストユーザーにポリシーをアタッチするには**
1. IAM コンソールのナビゲーションペインから、[**ポリシー**] を選択します。
1. ポリシーリストの上部にある検索ボックスに、ポリシーが表示されるまで「**UsersReadOnlyAccesstoIAMConsole**」と入力します。次に、リストの [**UsersReadOnlyAccessToIAMConsole**] の横にあるラジオボタンをオンにします。
1. **[Actions]** (アクション) ボタンを選択して、**[Attach]** (アタッチ) を選択します。
1. IAM エンティティでは、**ユーザー**をフィルタリングするオプションを選択します。
1. 検索ボックスで、そのユーザーがリストに表示されるまで「**PolicyUser**」と入力します。次に、リスト内のそのユーザーの横にあるチェックボックスをオンにします。
1. **[Attach policy]** (ポリシーのアタッチ) を選択します。
これで IAM テストユーザーにポリシーがアタッチされました。これは、ユーザーが読み取り専用アクセス許可で IAM コンソールにアクセスできることを意味します。
## ステップ 3: ユーザーアクセスのテスト
このチュートリアルでは、テストユーザーとしてサインインしてアクセスをテストし、ユーザーの体験を確認できるようにすることをお勧めします。
**テストユーザーにサインインしてアクセスをテストするには**
1. `PolicyUser` テストユーザーを使用して、[https：//console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)で IAM コンソールにサインインします。
1. コンソールのページを参照して、新しいユーザーまたはグループを作成します。`PolicyUser` はデータを表示できますが、IAM データを作成したり既存のデータを変更したりできなくなっています。
## 関連リソース
関連情報については、以下のリソースを参照してください。
+ [管理ポリシーとインラインポリシー](access_policies_managed-vs-inline.md)
+ [AWS マネジメントコンソール への IAM ユーザーアクセスを制御する](console_controlling-access.md)
## 概要
これで、カスタマー管理ポリシーを作成してアタッチするために必要なすべてのステップが完了しました。その結果、テストアカウントで IAM コンソールにサインインして、ユーザーのエクスペリエンスがどのように表示されるかを確認できます。
# IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する
属性ベースのアクセス制御 (ABAC) は、属性に基づいてアクセス許可を定義する認可戦略です。これらの属性は、AWS でタグと呼ばれています。タグは、IAM エンティティ (ユーザーまたはロール) を含む IAM リソースと、AWS リソースにアタッチできます。タグ条件キーを使用して、タグに基づいてプリンシパルにアクセス許可を付与するポリシーを定義できます。タグを使用して AWS リソースへのアクセスを制御すると、AWS ポリシーの変更を減らしてチームとリソースを拡張できます。ABAC ポリシーは、個々のリソースをリストする従来の AWS ポリシーよりも柔軟性があります。ABAC の詳細と、従来のポリシーに対する利点については、「[ABAC 認可で属性に基づいてアクセス許可を定義する](introduction_attribute-based-access-control.md)」を参照してください。
**注記**
セッションタグごとに 1 つの値を渡す必要があります。AWS Security Token Service は、複数値を持つセッションタグをサポートしていません。
**Topics**
+ [チュートリアルの概要](#tutorial_attribute-based-access-control-overview)
+ [前提条件](#tutorial_abac_prereqs)
+ [ステップ 1: テストユーザーを作成する](#tutorial_abac_step1)
+ [ステップ 2: ABAC ポリシーを作成する](#tutorial_abac_step2)
+ [ステップ 3: ロールを作成する](#tutorial_abac_step3)
+ [ステップ 4: シークレットの作成をテストする](#tutorial_abac_step4)
+ [ステップ 5: シークレットの表示をテストする](#tutorial_abac_step5)
+ [ステップ 6: スケーラビリティをテストする](#tutorial_abac_step6)
+ [ステップ 7: シークレットの更新と削除をテストする](#tutorial_abac_step7)
+ [概要](#tutorial-abac-summary)
+ [関連リソース](#tutorial_abac_related)
+ [IAM チュートリアル: ABAC で SAML セッションタグを使用する](tutorial_abac-saml.md)
## チュートリアルの概要
このチュートリアルでは、プリンシパルタグを持つ IAM ロールが、一致するタグを持つリソースにアクセスすることを許可するポリシーを作成およびテストする方法を示します。プリンシパルが AWS にリクエストを行うと、プリンシパルとリソースタグが一致するかどうかに基づいてアクセス許可が付与されます。この戦略により、個人は自分のジョブに必要な AWS リソースのみを表示または編集できます。
**シナリオ**
Example Corporation という大企業のリーダー開発者であり、経験豊富な IAM 管理者であるとします。IAM ユーザー、ロール、ポリシーの作成と管理に精通しています。開発エンジニアと品質保証チームのメンバーが、必要なリソースにアクセスできるようにする必要があります。また、企業の成長に合わせてスケールする戦略も必要です。
AWS リソースタグと IAM ロールプリンシパルタグを使用して、AWS Secrets Manager で始まるサービスをサポートする ABAC 戦略を実装することを選択します。タグに基づく認可をサポートするサービスについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。各サービスのアクションおよびリソースを含むポリシーで使用できるタグ付け条件キーについては、「[AWS のサービスのアクション、リソース、および条件キー](reference_policies_actions-resources-contextkeys.html)」を参照してください。[セッションタグ](id_session-tags.md)を AWS に渡すよう SAML ベースまたはウェブ ID プロバイダーを設定できます。従業員が AWS にフェデレートすると、その属性が AWS で結果のプリンシパルに適用されます。その後、ABAC を使用して、これらの属性に基づいてアクセス許可を許可または拒否できます。SAML フェデレーティッド ID でのセッションタグの使用とこのチュートリアルとの違いについては、「[IAM チュートリアル: ABAC で SAML セッションタグを使用する](tutorial_abac-saml.md)」を参照してください。
エンジニアリングおよび品質保証チームのメンバーは、[**Pegasus**] または [**Unicorn**] のいずれかのプロジェクトに参加しています。次の 3 文字のプロジェクトおよびチームタグ値を選択します。
+ `access-project` = [**Pegasus**] プロジェクトの場合は `peg`
+ `access-project` = [**Unicorn**] プロジェクト場合は `uni`
+ `access-team` = エンジニアリングチームの場合は `eng`
+ `access-team` = 品質保証チームの場合は `qas`
また、カスタム AWS 請求レポートを有効にするために、`cost-center` コスト配分タグを要求することを選択します。詳細については、*AWS Billing and Cost Managementユーザーガイド* の [[コスト配分タグの使用](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)] をご参照ください。
**主要な機能の概要**
+ 従業員は、 ユーザー認証情報を使用してサインインし、チームとプロジェクトの IAM ロールを引き受けます。会社に独自の ID システムがある場合は、従業員が IAM ユーザーなしでロールを引き受けることができるようにフェデレーションを設定できます。詳細については、「[IAM チュートリアル: ABAC で SAML セッションタグを使用する](tutorial_abac-saml.md)」を参照してください。
+ すべてのロールに同じポリシーがアタッチされます。アクションは、タグに基づいて許可または拒否されます。
+ 従業員は、ロールに適用される同じタグをリソースにアタッチする場合に限り、新しいリソースを作成できます。これにより、従業員は作成後にリソースを表示できます。管理者は、新しいリソースの ARN を使用してポリシーを更新する必要がなくなりました。
+ 従業員は、プロジェクトに関係なく、チームが所有するリソースを読み取ることができます。
+ 従業員は、自分のチームとプロジェクトが所有するリソースを更新および削除できます。
+ IAM 管理者は、新しいプロジェクトに新しいロールを追加できます。新しい IAM ユーザーを作成してタグ付けし、適切なロールへのアクセスを許可できます。管理者は、新しいプロジェクトまたはチームメンバーをサポートするためにポリシーを編集する必要はありません。
このチュートリアルでは、各リソースにタグ付けし、プロジェクトロールにタグ付けして、前述の動作を許可するポリシーをロールに追加します。結果として得られるポリシーではロール `Create`、`Read`、`Update`、および`Delete` は、同じプロジェクトタグとチームタグが付けられたリソースへのアクセスを許可します。このポリシーでは、同じチームでタグ付けされたリソースに対するクロスプロジェクト `Read` アクセスも許可されます。
![\[この図は、ロールがプロジェクト外では読み取り専用アクセスに制限されている一方で、自身のプロジェクト内ではリソースを作成、読み取り、更新、および削除するための許可を持つ 2 つのプロジェクトを示しています。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/tutorial-abac-cross-project.png)
## 前提条件
このチュートリアルのステップを実行するには、以下を持っている必要があります:
+ 管理者アクセス許可を持つユーザーとしてサインインできる AWS アカウント。
+ ステップ 3 でロールを作成するために使用する 12 桁のアカウント ID。
AWS マネジメントコンソールで AWS アカウント ID 番号を確認するには、ナビゲーションバーの右上にある [**サポート**] を選択してから、[**サポートセンター**] を選択します。左側のナビゲーションペインにアカウント番号 (ID) が表示されます。
![\[アカウント番号を示す サポート Center ページ。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/account-id-support-center.console.png)
+ AWS マネジメントコンソール での IAM ユーザー、ロール、ポリシーの作成と編集の経験。ただし、IAM 管理プロセスの記憶にサポートが必要な場合は、このチュートリアルでは、ステップバイステップの手順を参照できるリンクを提供します。
## ステップ 1: テストユーザーを作成する
テストでは、同じタグでロールを引き受けるアクセス許可を持つ 4 人の IAM ユーザーを作成します。これにより、チームにユーザーを追加しやすくなります。ユーザーにタグを付けると、ユーザーは正しいロールを引き受けるためのアクセス権を自動的に取得します。ユーザーが 1 つのプロジェクトとチームのみで作業する場合、ロールの信頼ポリシーにユーザーを追加する必要はありません。
1. そのために、次のカスタマー管理ポリシーを `access-assume-role` という名前で作成します。JSON ポリシーの作成の詳細については、「[IAM ポリシーの作成](access_policies_create-console.md#access_policies_create-start)」を参照してください。
**ABAC ポリシー: すべての ABAC ロールを引き受けるが、ユーザーとロールタグが一致する場合のみ**
次のポリシーでは、ユーザーは、 `access-` 名前プレフィックスを持つアカウント内の任意のロールを引き受けることを許可します。ロールには、ユーザーと同じプロジェクト、チーム、およびコストセンタータグでタグ付けする必要があります。
このポリシーを使用するには、*イタリック体のプレースホルダーテキスト*をお客様のアカウント情報と置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "TutorialAssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/access-*",
"Condition": {
"StringEquals": {
"iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
"iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
"iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
}
}
}
]
}
```
------
このチュートリアルを多数のユーザーにスケールするには、ポリシーをグループにアタッチし、各ユーザーをグループに追加します。詳細については、「[IAM グループを作成する](id_groups_create.md)」および「[IAM グループのユーザーを編集する](id_groups_manage_add-remove-users.md)」を参照してください。
1. 以下の IAM ユーザーを作成し、`access-assume-role` アクセス許可ポリシーをアタッチします。**[AWS マネジメントコンソール へのユーザーアクセスを提供]** が選択されていることを確認してから、次のタグを追加してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## ステップ 2: ABAC ポリシーを作成する
**access-same-project-team** という名前の次のポリシーを作成します。このポリシーは、後のステップでロールに追加します。JSON ポリシーの作成の詳細については、「[IAM ポリシーの作成](access_policies_create-console.md#access_policies_create-start)」を参照してください。
このチュートリアルに適応できるその他のポリシーについては、以下のページを参照してください。
+ [IAM プリンシパルへのアクセスの制御](access_iam-tags.md#access_iam-tags_control-principals)
+ [Amazon EC2: プログラムおよびコンソールでユーザーがタグ付けされた EC2 インスタンスの起動や停止を許可する](reference_policies_examples_ec2_tag-owner.md)
+ [EC2: 一致するプリンシパルタグとリソースタグに基づいてインスタンスを開始または停止する](reference_policies_examples_ec2-start-stop-match-tags.md)
+ [EC2: タグに基づくインスタンスの開始または停止](reference_policies_examples_ec2-start-stop-tags.md)
+ [IAM: 特定のタグを持つロールを引き受ける](reference_policies_examples_iam-assume-tagged-role.md)
**ABAC ポリシー: プリンシパルとリソースタグが一致する場合にのみ Access Secrets Manager リソースにアクセスする**
次のポリシーでは、リソースの作成、読み取り、編集、削除をプリンシパルに許可しますが、それらのリソースにプリンシパルと同じキーと値のペアがタグ付けされている場合に限ります。プリンシパルがリソースを作成するときに、プリンシパルのタグに一致する値を持つ`access-project`、`access-team`、および `cost-center` タグを追加する必要があります。このポリシーでは、オプションの `Name` または `OwnedBy` タグの追加も許可されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllActionsSecretsManagerSameProjectSameTeam",
"Effect": "Allow",
"Action": "secretsmanager:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"access-project",
"access-team",
"cost-center",
"Name",
"OwnedBy"
]
},
"StringEqualsIfExists": {
"aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}"
}
}
},
{
"Sid": "AllResourcesSecretsManagerNoTags",
"Effect": "Allow",
"Action": [
"secretsmanager:GetRandomPassword",
"secretsmanager:ListSecrets"
],
"Resource": "*"
},
{
"Sid": "ReadSecretsManagerSameTeam",
"Effect": "Allow",
"Action": [
"secretsmanager:Describe*",
"secretsmanager:Get*",
"secretsmanager:List*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}"
}
}
},
{
"Sid": "DenyUntagSecretsManagerReservedTags",
"Effect": "Deny",
"Action": "secretsmanager:UntagResource",
"Resource": "*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "access-*"
}
}
},
{
"Sid": "DenyPermissionsManagement",
"Effect": "Deny",
"Action": "secretsmanager:*Policy",
"Resource": "*"
}
]
}
```
------
**このポリシーで行うこと**
+ `AllActionsSecretsManagerSameProjectSameTeam` ステートメントは、リソースタグがプリンシパルタグと一致する場合のみ、関連するすべてのリソースでこのサービスのすべてのアクションを許可します。`"Action": "secretsmanager:*"` をポリシーに追加することで、ポリシーは Secrets Manager が大きくなるにつれて大きくなります。Secrets Manager が新しい API オペレーションを追加する場合、そのアクションをステートメントに追加する必要はありません。ステートメントは、3 つの条件ブロックを使用して ABAC を実装します。リクエストは、3 つのブロックすべてが true を返す場合にのみ許可されます。
+ 指定されたタグキーがリソースに存在し、その値がプリンシパルのタグと一致する場合、このステートメントの最初の条件ブロックは true を返します。このブロックは、一致しないタグ、またはリソースタグ付けをサポートしていないアクションに対して false を返します。このブロックで許可されていないアクションについては、「[AWS Secrets Manager のアクション、リソース、および条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html)」を参照してください。このページは、[[**Secret**] リソースタイプ](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-resources-for-iam-policies)で実行されるアクションが `secretsmanager:ResourceTag/tag-key` 条件キーをサポートしていることを示しています。一部の [Secrets Manager アクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-actions-as-permissions)では、`GetRandomPassword` や `ListSecrets` など、そのリソースタイプをサポートしません。これらのアクションを許可するには、追加のステートメントを作成する必要があります。
+ 2 番目の条件ブロックは、リクエストで渡されたすべてのタグキーが指定されたリストに含まれている場合に true を返します。これは、 `StringEquals` 条件演算子とともに `ForAllValues` を使用して行われます。キーまたはキーのセットのサブセットが渡されない場合、条件は true を返します。これにより、リクエストでタグを渡すことを許可しない `Get*` オペレーションが可能になります。リクエスタにリストにないタグキーが含まれている場合、条件は false を返します。リクエストで渡されるすべてのタグキーは、このリストのメンバーと一致する必要があります。詳細については、「[複数値のコンテキストキーの演算子を設定する](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys)」を参照してください。
+ 3 番目の条件ブロックは、リクエストでタグの受け渡しがサポートされている場合、3 つすべてのタグが存在する場合、およびプリンシパルタグの値に一致する場合に true を返します。このブロックは、リクエストがタグの受け渡しをサポートしていない場合も true を返します。これは、条件演算子の [`...IfExists`](reference_policies_elements_condition_operators.md#Conditions_IfExists) のおかげです。ブロックは、それをサポートするアクション中に渡されたタグがない場合、またはタグのキーと値が一致しない場合、false を返します。
+ `AllResourcesSecretsManagerNoTags` ステートメントでは、最初のステートメントでは許可されていない `GetRandomPassword` および `ListSecrets` アクションを許可します。
+ `ReadSecretsManagerSameTeam` ステートメントは、プリンシパルがリソースと同じアクセスチームタグでタグ付けされている場合、読み取り専用オペレーションを許可します。これは、プロジェクトまたはコストセンタータグに関係なく許可されます。
+ `DenyUntagSecretsManagerReservedTags` ステートメントは、Secrets Manager から「access-」で始まるキーを持つタグを削除するリクエストを拒否します。これらのタグはリソースへのアクセスを制御するために使用されるため、タグを削除するとアクセス許可が削除される可能性があります。
+ `DenyPermissionsManagement` ステートメントは、Secrets Manager リソースベースのポリシーを作成、編集、または削除することを拒否します。これらのポリシーは、シークレットのアクセス許可を変更するために使用できます。
**重要**
このポリシーでは、サービスに対するすべてのアクションを許可する戦略が使用されますが、アクセス許可を変更するアクションは明示的に拒否されます。アクションを拒否すると、プリンシパルがそのアクションの実行を許可する他のポリシーよりも優先されます。これにより、意図しない結果が生じる可能性があります。ベストプラクティスとして、明示的な拒否は、そのアクションを許可する状況がない場合にのみ使用します。それ以外の場合、個々のアクションのリストを許可し、不要なアクションはデフォルトで拒否されます。
## ステップ 3: ロールを作成する
以下の IAM ロールを作成し、前のステップで作成した **access-same-project-team** ポリシーをアタッチします。IAM ロールの作成の詳細については、「[IAM ユーザーにアクセス許可を付与するロールを作成する](id_roles_create_for-user.md)」を参照してください。IAM ユーザーとロールの代わりにフェデレーションを使用する場合は、「[IAM チュートリアル: ABAC で SAML セッションタグを使用する](tutorial_abac-saml.md)」を参照してください。
| ジョブ関数 | ロール名 | ロールタグ | ロールの説明 |
| --- | --- | --- | --- |
| プロジェクト Pegasus エンジニアリング | access-peg-engineering | access-project = `peg` access-team = `eng` cost-center = `987654` | エンジニアがすべてのエンジニアリングリソースを読み取り、Pegasus エンジニアリングリソースを作成および管理できるようにします。 |
| プロジェクト Pegasus 品質保証 | access-peg-quality-assurance | access-project = `peg` access-team = `qas` cost-center = `987654` | QA チームがすべての QA リソースを読み取り、すべての Pegasus QA リソースを作成および管理できるようにします。 |
| プロジェクト Unicorn エンジニアリング | access-uni-engineering | access-project= `uni` access-team = `eng` cost-center = `123456` | エンジニアがすべてのエンジニアリングリソースを読み取り、Unicorn のエンジニアリングリソースを作成および管理できるようにします。 |
| プロジェクト Unicorn 品質保証 | access-uni-quality-assurance | access-project = `uni` access-team = `qas` cost-center = `123456` | QA チームがすべての QA リソースを読み取り、すべての Unicorn QA リソースを作成および管理できるようにします。 |
## ステップ 4: シークレットの作成をテストする
ロールにアタッチされたアクセス許可ポリシーにより、従業員はシークレットを作成できます。これは、シークレットがプロジェクト、チーム、およびコストセンターでタグ付けされている場合にのみ許可されます。ユーザーとしてサインインし、正しいロールを引き受け、Secrets Manager でアクティビティをテストすることで、アクセス許可が想定どおりに機能していることを確認します。
**必要なタグがある場合とない場合のシークレットの作成をテストするには**
1. IAM のユーザー、ロール、ポリシーを確認できるように、メインブラウザウィンドウで、管理者ユーザーとしてサインインしたままにします。テストには、ブラウザの匿名ウィンドウまたは別のブラウザを使用します。そこに、`access-Arnav-peg-eng` IAM ユーザーをとしてサインインし、[https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/) で Secrets Manager コンソールを 開きます。
1. `access-uni-engineering` ロールへの切り替えを試みます。
このオペレーションは、`access-Arnav-peg-eng` ユーザーおよび `access-uni-engineering` ロールで `access-project` および `cost-center` タグ値が一致しないため失敗します。
AWS マネジメントコンソールでのロールの切り替えの詳細については、「[ユーザーから IAM ロールに切り替える (コンソール)](id_roles_use_switch-role-console.md)」を参照してください。
1. `access-peg-engineering` ロールに切り替えます。
1. 以下の情報を使用して新しいシークレットを保存します。シークレットを保存する方法については、「AWS Secrets Manager ユーザーガイド」の「[基本的なシークレットの作成](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html)」を参照してください。
**重要**
Secrets Manager は、Secrets Manager と連携する追加の AWS サービスに対する権限がないというアラートを表示します。例えば、Amazon RDS データベースの認証情報を作成するには、RDS インスタンス、RDS クラスター、Amazon Redshift クラスターを記述するアクセス許可が必要です。このチュートリアルではこれらの特定の AWS サービスを使用していないため、これらのアラートは無視してかまいません。
1. [**Select secret type (シークレットタイプの選択)**] セクションで、[**Other type of secrets (他の種類のシークレット)**] を選択します。2 つのテキストボックスに、「`test-access-key`」と「`test-access-secret`」と入力します。
1. [**Secret name (シークレット名)**] フィールドに「`test-access-peg-eng`」と入力します。
1. 次の表から異なるタグの組み合わせを追加し、想定される動作を確認します。
1. [**Store (保存)**] を選択して、シークレットの作成を試みます。ストレージに障害が発生した場合は、前の Secrets Manager コンソールページに戻り、以下のテーブルから次のタグセットを使用します。最後のタグセットは許可され、シークレットを正常に作成します。
次の表は、`test-access-peg-eng` ロールの ABAC タグの組み合わせを示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
1. サインアウトし、以下の各ロールとタグ値について、この手順の最初の 3 つのステップを繰り返します。この手順の 4 番目のステップでは、欠落しているタグ、オプションのタグ、許可されていないタグ、無効なタグ値のセットをテストします。次に、必要なタグを使用して、次のタグと名前を持つシークレットを作成します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## ステップ 5: シークレットの表示をテストする
各ロールにアタッチしたポリシーにより、従業員はプロジェクトに関係なく、チーム名でタグ付けされたシークレットを表示できます。Secrets Manager でロールをテストして、アクセス許可が想定どおりに動作していることを確認します。
**必要なタグがある場合とない場合のシークレットの表示をテストするには**
1. 次のいずれかの IAM ユーザーとしてサインインします。
+ `access-Arnav-peg-eng`
+ `access-Mary-peg-qas`
+ `access-Saanvi-uni-eng`
+ `access-Carlos-uni-qas`
1. 一致するロールに切り替えます。
+ `access-peg-engineering`
+ `access-peg-quality-assurance`
+ `access-uni-engineering`
+ `access-uni-quality-assurance`
AWS マネジメントコンソール でのロールの切り替えの詳細については、「[ユーザーから IAM ロールに切り替える (コンソール)](id_roles_use_switch-role-console.md)」を参照してください。
1. 左側のナビゲーションペインで、メニューアイコンを選択してメニューを展開し、[**Secrets (シークレット)**]を選択します。
1. 現在のロールに関係なく、テーブルに 4 つのシークレットすべてが表示されます。これは、`access-same-project-team` という名前のポリシーですべてのリソースに対して `secretsmanager:ListSecrets` アクションが許可されるためです。
1. いずれかのシークレットの名前を選択します。
1. シークレットの詳細ページで、ロールのタグによって、ページのコンテンツを表示できるかどうかが決まります。ロールの名前とシークレットの名前を比較します。同じチーム名を共有する場合、`access-team` タグは一致します。一致しない場合、アクセスは拒否されます。
次のテーブルは、各ロールの ABAC シークレットの表示動作を示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
1. ページの上部にあるパンくずリストから、[**Secrets (シークレット)**] を選択してシークレットのリストに戻ります。異なるロールを使用して、この手順のステップを繰り返し、各シークレットを表示できるかどうかをテストします。
## ステップ 6: スケーラビリティをテストする
ロールベースのアクセスコントロール (RBAC) よりも属性ベースのアクセスコントロール (ABAC) を使用する重要な理由は、スケーラビリティです。会社が新しいプロジェクト、チーム、または人員を AWS に追加する場合、ABAC 主導のポリシーを更新する必要はありません。例えば、Example Company が [**Centaur**] という名前の新しいプロジェクトに資金を提供しているとします。Saanvi Sarkar というエンジニアが [**Centaur**] のリードエンジニアとなり、[**ユニコーン**] プロジェクトに取り組んでいます。また、Saanvi は **Peg** プロジェクトの作業も確認します。また、Nikhil Jayashankar をはじめ、[**Centaur**] プロジェクトのみに取り組む新しく採用されたエンジニアもいます。
**新しいプロジェクトを AWS に追加するには**
1. IAM 管理者ユーザーとしてサインインし、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。
1. 左側のナビゲーションペインで、[**ロール**] を選択し、`access-cen-engineering` という名前の IAM ロールを追加します。**access-same-project-team** アクセス許可ポリシーをロールにアタッチし、次のロールタグを追加します。
+ `access-project` = `cen`
+ `access-team` = `eng`
+ `cost-center` = `101010`
1. 左側のナビゲーションペインで、**[ユーザー]** を選択します。
1. `access-Nikhil-cen-eng` という名前の新しいユーザーを追加し、`access-assume-role` という名前のポリシーをアタッチして、次のユーザータグを追加します。
+ `access-project` = `cen`
+ `access-team` = `eng`
+ `cost-center` = `101010`
1. 「[ステップ 4: シークレットの作成をテストする](#tutorial_abac_step4)」および「[ステップ 5: シークレットの表示をテストする](#tutorial_abac_step5)」の手順を使用します。別のブラウザウィンドウで、Nikhil が [**Centaur**] エンジニアリングシークレットのみを作成できること、および Nikhil がすべてのエンジニアリングシークレットを表示できることをテストします。
1. 管理者としてサインインしたメインブラウザウィンドウで、ユーザー `access-Saanvi-uni-eng` を選択します。
1. [**Permissions (アクセス許可)**] タブで、[**access-assume-role**] アクセス許可ポリシーを削除します。
1. `access-assume-specific-roles` という名前の次のインラインポリシーを追加します。ユーザーへのインラインポリシーの追加の詳細については、「[ユーザーまたはロールのインラインポリシーを埋め込むには (コンソール)](access_policies_manage-attach-detach.md#embed-inline-policy-console)」を参照してください。
**ABAC ポリシー: 特定のロールのみ継承する**
このポリシーでは、Saanvi が **Pegasus** および **Centaur** プロジェクトのエンジニアリングロールを引き受けることを許可します。IAM は複数値タグをサポートしていないため、このカスタムポリシーを作成する必要があります。Saanvi のユーザーに `access-project` = `peg` および `access-project` = `cen` のタグを付けることはできません。さらに、AWS 認可モデルが両方の値に一致することはできません。詳細については、「[IAM および AWS STS でのタグ付けの規則](id_tags.md#id_tags_rules)」を参照してください。代わりに、引き受けることができる 2 つのロールを手動で指定する必要があります。
このポリシーを使用するには、*イタリック体のプレースホルダーテキスト*をお客様のアカウント情報と置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "TutorialAssumeSpecificRoles",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/access-peg-engineering",
"arn:aws:iam::111122223333:role/access-cen-engineering"
]
}
]
}
```
------
1. 「[ステップ 4: シークレットの作成をテストする](#tutorial_abac_step4)」および「[ステップ 5: シークレットの表示をテストする](#tutorial_abac_step5)」の手順を使用します。別のブラウザウィンドウで、Saanvi が両方のロールを引き受けることができることを確認します。ロールのタグに応じて、プロジェクト、チーム、およびコストセンターのみのシークレットを作成できることを確認します。また、作成したばかりのシークレットを含め、エンジニアリングチームが所有するすべてのシークレットに関する詳細を表示できることを確認します。
## ステップ 7: シークレットの更新と削除をテストする
ロールにアタッチされた `access-same-project-team` ポリシーにより、従業員はプロジェクト、チーム、コストセンターでタグ付けされたシークレットを更新および削除できます。Secrets Manager でロールをテストして、アクセス許可が想定どおりに動作していることを確認します。
**必要なタグの有無にかかわらず、シークレットの更新と削除をテストするには**
1. 次のいずれかの IAM ユーザーとしてサインインします。
+ `access-Arnav-peg-eng`
+ `access-Mary-peg-qas`
+ `access-Saanvi-uni-eng`
+ `access-Carlos-uni-qas`
+ `access-Nikhil-cen-eng`
1. 一致するロールに切り替えます。
+ `access-peg-engineering`
+ `access-peg-quality-assurance`
+ `access-uni-engineering`
+ `access-peg-quality-assurance`
+ `access-cen-engineering`
AWS マネジメントコンソール でのロールの切り替えの詳細については、「[ユーザーから IAM ロールに切り替える (コンソール)](id_roles_use_switch-role-console.md)」を参照してください。
1. ロールごとに、シークレットの説明を更新し、次のシークレットを削除してみてください。詳細については、「AWS Secrets Manager ユーザーガイド」の「[シークレットの変更](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html)」および「[シークレットの削除と復元](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html)」を参照してください。
次のテーブルは、各ロールの ABAC シークレットの更新と削除動作を示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## 概要
これで、属性ベースのアクセスコントロール (ABAC) のタグを使用するために必要なすべてのステップが正常に完了しました。タグ付け戦略を定義する方法を学びました。この戦略をプリンシパルとリソースに適用しました。Secrets Manager の戦略を適用するポリシーを作成して適用しました。また、ABAC は、新しいプロジェクトやチームメンバーを追加すると簡単にスケールできることも学びました。その結果、テストロールを使用して IAM コンソールにサインインし、AWS で ABAC のタグを使用する方法を体験できます。
**注記**
特定の条件下でのみアクションを許可するポリシーを追加しました。より広範なアクセス許可を持つユーザーまたはロールに別のポリシーを適用する場合、アクションはタグ付けを必要とするだけではないことがあります。例えば、`AdministratorAccess` AWS 管理ポリシーを使用してユーザーに完全な管理アクセス許可を付与しても、これらのポリシーではそのアクセスが制限されません。複数のポリシーが関係する場合のアクセス許可の決定方法の詳細については、「[AWS エンフォースメントコードロジックがリクエストを評価してアクセスを許可または拒否する方法](reference_policies_evaluation-logic_policy-eval-denyallow.md)」を参照してください。
## 関連リソース
関連情報については、以下のリソースを参照してください。
+ [ABAC 認可で属性に基づいてアクセス許可を定義する](introduction_attribute-based-access-control.md)
+ [AWS グローバル条件コンテキストキー](reference_policies_condition-keys.md)
+ [IAM ユーザーにアクセス許可を付与するロールを作成する](id_roles_create_for-user.md)
+ [AWS Identity and Access Management リソースのタグ](id_tags.md)
+ [タグを使用した AWS リソースへのアクセスの制御](access_tags.md)
+ [ユーザーから IAM ロールに切り替える (コンソール)](id_roles_use_switch-role-console.md)
+ [IAM チュートリアル: ABAC で SAML セッションタグを使用する](tutorial_abac-saml.md)
アカウントのタグをモニタリングする方法については、「[サーバーレスワークフローおよび Amazon CloudWatch Events を使用して AWS リソースでタグの変更を監視する](https://aws.amazon.com/blogs/mt/monitor-tag-changes-on-aws-resources-with-serverless-workflows-and-amazon-cloudwatch-events/)」を参照してください。
# IAM チュートリアル: ABAC で SAML セッションタグを使用する
属性ベースのアクセス制御 (ABAC) は、属性に基づいてアクセス許可を定義する認可戦略です。AWS では、これらの属性はタグと呼ばれます。タグは、IAM エンティティ (ユーザーまたはロール) を含む IAM リソースと、AWS リソースにアタッチできます。エンティティが AWS へのリクエストを行うために使用されると、エンティティはプリンシパルになり、プリンシパルにはタグが含まれます。
ロールを引き受けるとき、またはユーザーをフェデレートするときに [セッションタグ](id_session-tags.md) を渡すこともできます。その後、タグ条件キーを使用して、タグに基づいてプリンシパルにアクセス許可を付与するポリシーを定義できます。タグを使用して AWS リソースへのアクセスを制御すると、AWS ポリシーの変更を減らしてチームとリソースを拡張できます。ABAC ポリシーは、個々のリソースをリストする従来の AWS ポリシーよりも柔軟性があります。ABAC の詳細と、従来のポリシーに対する利点については、「[ABAC 認可で属性に基づいてアクセス許可を定義する](introduction_attribute-based-access-control.md)」を参照してください。
会社で SAML ベースの ID プロバイダー (IdP) を使用して企業ユーザー ID を管理する場合は、SAML 属性を使用して、AWS のきめ細かなアクセス制御を行うことができます。属性には、コストセンター ID、ユーザーの E メールアドレス、部門分類、およびプロジェクト割り当てを含めることができます。これらの属性をセッションタグとして渡すと、これらのセッションタグに基づいて AWS へのアクセスを制御できます。
SAML 属性をセッションプリンシパルに渡して [ABAC チュートリアル](tutorial_attribute-based-access-control.md) を完了するには、このトピックに含まれる変更を使用して「[IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する](tutorial_attribute-based-access-control.md)」のタスクを実行します。
## 前提条件
ABAC で SAML セッションタグを使用するステップを実行するには、次のものが必要です。
+ 特定の属性を持つテストユーザーを作成できる SAML ベースの IdP へのアクセス。
+ 管理者アクセス許可を持つユーザーとしてサインインできること。
+ AWS マネジメントコンソール での IAM ユーザー、ロール、ポリシーの作成と編集の経験。ただし、IAM 管理プロセスの記憶にサポートが必要な場合は、ABAC チュートリアルでは、ステップバイステップの手順を参照できるリンクを提供します。
+ IAM で SAML ベースの IdP を設定した経験があります。詳細および詳細 IAM ドキュメントへのリンクを表示するには、「[AssumeRoleWithSAML を使用したセッションタグの受け渡し](id_session-tags.md#id_session-tags_adding-assume-role-saml)」を参照してください。
## ステップ 1: テストユーザーを作成する
[ステップ 1: テストユーザーを作成する](tutorial_attribute-based-access-control.md#tutorial_abac_step1) の手順に従います。ID はプロバイダーで定義されるため、従業員の IAM ユーザーを追加する必要はありません。
## ステップ 2: ABAC ポリシーを作成する
[ステップ 2: ABAC ポリシーを作成する](tutorial_attribute-based-access-control.md#tutorial_abac_step2) の手順に従って、IAM で指定した管理ポリシーを作成します。
## ステップ 3: SAML ロールを作成して設定する
SAML の ABAC チュートリアルを使用する場合は、追加のステップを実行し、ロールを作成します。SAML IdP を設定し、AWS マネジメントコンソール アクセスを有効にする必要があります。詳細については、「[ステップ 3: ロールを作成する](tutorial_attribute-based-access-control.md#tutorial_abac_step3)」を参照してください。
### ステップ 3A: SAML ロールを作成する
SAML ID プロバイダーと、ステップ 1 で作成した `test-session-tags` ユーザーを信頼する 1 つのロールを作成します。ABAC チュートリアルでは、異なるロールタグを持つ個別のロールを使用します。SAML IdP からセッションタグを渡すため、必要なロールは 1 つだけです。SAML ベースのロールを作成する方法については、「[SAML 2.0 フェデレーション用のロールを作成する (コンソール)](id_roles_create_for-idp_saml.md)」を参照してください。
ロールに `access-session-tags` という名前を付けます。`access-same-project-team` アクセス許可ポリシーをロールにアタッチします。ロールの信頼ポリシーを編集して、次のポリシーを使用します。ロールの信頼関係を編集する方法の詳細については、「[ロール信頼ポリシーを更新する](id_roles_update-role-trust-policy.md)」を参照してください。
次のロール信頼ポリシーでは、SAML ID プロバイダーと `test-session-tags` ユーザーがロールを引き受けることができます。ロールを引き受けるときは、指定した 3 つのセッションタグを渡す必要があります。`sts:TagSession` アクションは、セッションタグを渡すことを許可するために必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSamlIdentityAssumeRole",
"Effect": "Allow",
"Action": [
"sts:AssumeRoleWithSAML",
"sts:TagSession"
],
"Principal": {"Federated":"arn:aws:iam::123456789012:saml-provider/ExampleCorpProvider"},
"Condition": {
"StringLike": {
"aws:RequestTag/cost-center": "*",
"aws:RequestTag/access-project": "*",
"aws:RequestTag/access-team": [
"eng",
"qas"
]
},
"StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"}
}
}
]
}
```
------
この `AllowSamlIdentityAssumeRole`ステートメントにより、エンジニアリングチームおよび品質保証チームのメンバーは、Example Corporation IdP から AWS にフェデレーションするときに、このロールを引き受けることができます。`ExampleCorpProvider` SAML プロバイダーは IAM で定義されています。管理者は、必要な 3 つのセッションタグを渡すように SAML アサーションをすでに設定しています。アサーションは追加のタグを渡すことができますが、これら 3 つは存在する必要があります。ID の属性は、`cost-center` タグと `access-project` タグに対して任意の値を持つことができます。ただし、`access-team` 属性値は、ID がエンジニアリングチームまたは品質保証チームにあることを示す `eng` か `qas` に一致する必要があります。
### ステップ 3B: SAML IdP を設定する
`cost-center`、`access-project`、`access-team` の各属性をセッションタグとして渡すように SAML IdP を設定します。詳細については、「[AssumeRoleWithSAML を使用したセッションタグの受け渡し](id_session-tags.md#id_session-tags_adding-assume-role-saml)」を参照してください。
これらの属性をセッションタグとして渡すには、SAML アサーションに以下の要素を含めます。
```
987654
peg
eng
```
### ステップ 3C: コンソールアクセスを有効にする
フェデレーティッド SAML ユーザーのコンソールアクセスを有効にします。詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)」を参照してください。
## ステップ 4: シークレットの作成をテストする
`access-session-tags` ロールを使用して AWS マネジメントコンソール にフェデレートします。詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)」を参照してください。次に、[ステップ 4: シークレットの作成をテストする](tutorial_attribute-based-access-control.md#tutorial_abac_step4) の手順に従ってシークレットを作成します。属性を持つ異なる SAML ID を使用して、ABAC チュートリアルで示されているタグと一致させます。詳細については、「[ステップ 4: シークレットの作成をテストする](tutorial_attribute-based-access-control.md#tutorial_abac_step4)」を参照してください。
## ステップ 5: シークレットの表示をテストする
[ステップ 5: シークレットの表示をテストする](tutorial_attribute-based-access-control.md#tutorial_abac_step5) の手順に従って、前のステップで作成したシークレットを表示します。属性を持つ異なる SAML ID を使用して、ABAC チュートリアルで示されているタグと一致させます。
## ステップ 6: スケーラビリティをテストする
[ステップ 6: スケーラビリティをテストする](tutorial_attribute-based-access-control.md#tutorial_abac_step6) の指示に従って、スケーラビリティをテストします。これを行うには、SAML ベースの IdP に次の属性を持つ新しい ID を追加します。
+ `cost-center = 101010`
+ `access-project = cen`
+ `access-team = eng`
## ステップ 7: シークレットの更新と削除をテストする
「[ステップ 7: シークレットの更新と削除をテストする](tutorial_attribute-based-access-control.md#tutorial_abac_step7)」の手順に従って、シークレットを更新および削除します。属性を持つ異なる SAML ID を使用して、ABAC チュートリアルで示されているタグと一致させます。
**重要**
課金されないように、作成したシークレットをすべて削除します。Secrets Manager の料金設定の詳細については、「[AWS Secrets Manager 料金設定](https://aws.amazon.com/secrets-manager/pricing/)」を参照してください。
## 概要
これで、アクセス許可の管理に SAML セッションタグとリソースタグを使用するために必要なすべてのステップが正しく完了しました。
**注記**
特定の条件下でのみアクションを許可するポリシーを追加しました。より広範なアクセス許可を持つユーザーまたはロールに別のポリシーを適用する場合、アクションはタグ付けを必要とするだけではないことがあります。例えば、`AdministratorAccess` AWS 管理ポリシーを使用してユーザーに完全な管理アクセス許可を付与しても、これらのポリシーではそのアクセスが制限されません。複数のポリシーが関係する場合のアクセス許可の決定方法の詳細については、「[AWS エンフォースメントコードロジックがリクエストを評価してアクセスを許可または拒否する方法](reference_policies_evaluation-logic_policy-eval-denyallow.md)」を参照してください。
# IAM チュートリアル: ユーザーに自分の認証情報および MFA 設定を許可する
ユーザーが **[セキュリティ認証情報]** ページで自分の多要素認証 (MFA) デバイスと認証情報を管理することを許可できます。AWS マネジメントコンソール を使用して、認証情報 (アクセスキー、パスワード、デジタル署名用証明書、SSH パブリックキー) を設定したり、不要な認証情報を削除または非アクティブ化したり、ユーザーの MFA デバイスを有効にしたりできます。これは少数のユーザーにとっては便利ですが、ユーザーの数が増えるとすぐに、このタスクは時間がかかるようになる可能性があります。このチュートリアルでは、このようなベストプラクティスを管理者に負担を与えずに実現する方法を説明します。
このチュートリアルでは、AWS サービスへのアクセスをユーザーに許可する方法を示します。ただし、ユーザーが MFA を使用してサインインした場合に**限ります**。MFA デバイスでサインインしていない場合、ユーザーは他のサービスにアクセスできません。
このワークフローには 3 つの基本的な手順が含まれます。
**[ステップ 1: MFA サインインを強制するポリシーを作成する](#tutorial_mfa_step1)**
いくつかの IAM アクションを**除く**、すべてのアクションを禁止するカスタマー管理ポリシーを作成します。これらの例外により、ユーザーは **[セキュリティ認証情報]** ページで自分の認証情報を変更したり、MFA デバイスを管理したりすることができます。該当ページへのアクセスの詳細については、「[IAM ユーザー自身によるパスワードの変更方法 (コンソール)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console)」を参照してください。
**[ステップ 2: テストユーザーグループにポリシーをアタッチする](#tutorial_mfa_step2)**
メンバーが MFA でサインインすると、すべての Amazon EC2 アクションにフルアクセスできるグループを作成します。このようなユーザーグループを作成するには、`AmazonEC2FullAccess` という AWS 管理ポリシーと最初の手順で作成したカスタマー管理ポリシーの両方をアタッチします。
**[ステップ 3: ユーザーアクセスをテストする](#tutorial_mfa_step3)**
テストユーザーとしてサインインし、ユーザーが MFA デバイスを作成する*まで* Amazon EC2 へのアクセスがブロックされていることを確認します。ユーザーは、そのデバイスを使用してサインインできます。
## 前提条件
このチュートリアルのステップを実行するには、以下を持っている必要があります:
+ 管理者アクセス許可を持つ IAM ユーザーとしてサインインできる AWS アカウント。
+ アカウント ID 番号。ステップ 1 のポリシーに入力します。
アカウント ID 番号を確認するには、ページ上部のナビゲーションバーで [**サポート**]、[**サポートセンター**] の順に選択します。アカウント ID 番号は、このページの [**サポート**] メニューの下で確認できます。
+ [仮想 (ソフトウェアベース) MFA デバイス](id_credentials_mfa_enable_virtual.md)、[FIDO セキュリティキー](id_credentials_mfa_enable_fido.md)、または[ハードウェアベース MFA デバイス](id_credentials_mfa_enable_physical.md)。
+ ユーザーグループのメンバーであるテスト IAM ユーザーは次のとおりです。
| ユーザー名 | ユーザー名に関する指示 | ユーザーグループ名 | メンバーとしてユーザーを追加する | ユーザーグループに関する指示 |
| --- | --- | --- | --- | --- |
| MFAUser | [コンソールアクセスを有効にする - オプション] のオプションのみを選択し、パスワードを割り当てます。 | EC2MFA | MFAUser | このユーザーグループへのポリシーのアタッチや、アクセス許可の付与は行わないでください。 |
## ステップ 1: MFA サインインを強制するポリシーを作成する
まず、IAM ユーザー各自の認証情報と MFA デバイスの管理に必要な権限を除いて、すべてのアクセス権限を拒否する IAM カスタマー管理ポリシーを作成します。
1. 管理者認証情報を使用してユーザーとして AWS マネジメントコンソール にサインインします。IAM のベストプラクティスに準拠し、AWS アカウントのルートユーザー 認証情報ではサインインしないでください。
**重要**
IAM [ベストプラクティス](best-practices.md)では、長期的な認証情報を持つIAMユーザーを使用するのではなく、一時的な認証情報を使用して AWS にアクセスするために、IDプロバイダーとのフェデレーションを使用することを人間ユーザーに求めることを推奨します。IAM ユーザーは、フェデレーションユーザーでサポートされていない[特定のユースケース](gs-identities-iam-users.md)にのみ使用することをお勧めします。
1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソール を開きます。
1. ナビゲーションペインで **ポリシー**を選択してから **ポリシーの作成**を選択します。
1. [**JSON**] タブを選択し、以下の JSON ポリシードキュメントからテキストをコピーします。[AWS: MFA で認証された IAM ユーザーが [セキュリティ認証情報] ページで自分の認証情報を管理できるようにします](reference_policies_examples_aws_my-sec-creds-self-manage.md)
1. このポリシーに関するテキストを [**JSON**] ボックスに貼り付けます。ポリシーの検証中に生成されたセキュリティ警告、エラー、または一般的な警告を解決してから、**[次へ]** を選択します。
**注記**
いつでも **[Visual エディタ]** と **[JSON]** オプションを切り替えることができます。ただし、上記のポリシーには `NotAction` 要素が含まれていますが、これはビジュアルエディタではサポートされていません。このポリシーについては、**[ビジュアルエディタ]** タブに通知が表示されます。**[JSON]** に戻り、このポリシーの操作を続行します。
このポリシー例では、初めて AWS マネジメントコンソール にサインインする際のパスワードのリセットをユーザーに許可していません。新しいユーザーがサインインしてパスワードをリセットするまで、そのユーザーにアクセス許可を付与しないことを推奨しています。
1. **[確認および作成]** ページで、ポリシー名として「**Force\$1MFA**」と入力します。ポリシーの説明の **[タグ]** 領域に **This policy allows users to manage their own passwords and MFA devices but nothing else unless they authenticate with MFA.** と入力すると、オプションでタグのキーと値のペアをカスタマー管理ポリシーに追加できます。ポリシーによって割り当てられたアクセス許可を確認し、**[ポリシーの作成]** を選択して作業を保存します。
新しいポリシーが管理ポリシーの一覧に表示され､アタッチの準備ができます。
## ステップ 2: テストユーザーグループにポリシーをアタッチする
次に、MFA で保護されたアクセス許可を付与するために使用されるテスト IAM ユーザーグループに、2 つのポリシーをアタッチします。
1. ナビゲーションペインで、[**ユーザーグループ**] を選択します。
1. 検索ボックスに「**`EC2MFA`**」と入力し、リストのグループ名 (チェックボックスではありません) を選択します。
1. **[アクセス許可]** タブを選択し、**[アクセス許可の追加]** を選択してから、**[ポリシーの添付]** を選択します。
1. [**Attach permission policies to EC2MFA group**] (許可ポリシーを EC2MFA グループにアタッチする) ページの検索ボックスに、**EC2Full** と入力します。次に、リストで、**AmazonEC2FullAccess** の横にあるチェックボックスをオンにします。変更はまだ保存しないでください。
1. 検索ボックスに「**Force**」と入力し、リストの **[Force\$1MFA]** の横にあるチェックボックスをオンにします。
1. **ポリシーのアタッチ** を選択します。
## ステップ 3: ユーザーアクセスをテストする
チュートリアルのこの部分では、テストユーザーとしてサインインし、ポリシーが意図したとおりに動作することを確認します。
1. 前のセクションで割り当てたパスワードを使用し、**MFAUser** として AWS アカウント にサインインします。URL: `https://.signin.aws.amazon.com/console` を使用します。
1. [**EC2**] を選択して Amazon EC2 コンソールを開き、ユーザーには一切の操作を行うアクセス許可がないことを確認します。
1. 右上のナビゲーションバーで `MFAUser` ユーザー名を選択し、続いて **[Security credentials]** (セキュリティ認証情報) を選択します。
![\[AWS マネジメントコンソールのセキュリティ認証情報へのリンク。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)
1. ここで MFA デバイスを追加します。[**Multi-Factor Authentication(MFA) (多要素認証 (MFA))**] セクションで、[**Assign MFA device (MFA デバイスを割り当てる)**] を選択します。
**注記**
`iam:DeleteVirtualMFADevice` を実行することを認可されていないというエラーが表示されることがあります。これは、誰かが以前にこのユーザーに仮想 MFA デバイスの割り当てを開始し、プロセスをキャンセルした場合に発生する可能性があります。続行するには、ユーザーまたは他の管理者がユーザーの既存の割り当てられていない仮想化 MFA デバイスを削除する必要があります。詳細については、「[iam:DeleteVirtualMFADevice を実行することを認可されていません](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa)」を参照してください。
1. このチュートリアルでは、携帯電話で Google Authenticator アプリなどの仮想 (ソフトウェアベース) MFA デバイスを使用します。**[認証アプリケーション]** を選択し、**[次へ]** をクリックします。
IAM が QR コードを含む仮想 MFA デバイスの設定情報を生成して表示します。図は、QR コードに対応していないデバイスでの手動入力に利用できるシークレット設定キーを示しています。
1. 仮想 MFA アプリを開きます。(仮想 MFA デバイスをホストするために使用できるアプリのリストについては、「[仮想 MFA アプリケーション](https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications)」を参照) 仮想 MFA アプリが複数のアカウント (複数の仮想 MFA デバイス) をサポートしている場合は、新しいアカウント (新しい仮想 MFA デバイス) を作成するオプションを選択します。
1. MFA アプリが QR コードをサポートしているかどうかを確認してから、次のいずれかを実行します。
+ ウィザードから、[**Show QR code (QR コードの表示)**] を選択します。QR コードをスキャンするアプリを使用します。例えば、カメラアイコンまたは **[Scan code]** (スキャンコード) に似たオプションを選択し、デバイスのカメラを使用してコードをスキャンします。
+ **[デバイスの設定]** ウィザードで **[シークレットキーを表示]** を選択し、MFA アプリケーションにシークレットキーを入力します。
これで仮想 MFA デバイスはワンタイムパスワードの生成を開始します。
1. **[Set up device]** (デバイスの設定) ウィザードの **[Enter the code from your authenticator app.]** (認証アプリケーションからコードを入力) ボックスに、現在仮想 MFA デバイスに表示されているワンタイムパスワードを入力します。**[MFA の登録]** を選択します。
**重要**
コードを生成したら、即時にリクエストを送信します。コードを生成した後にリクエストを送信するまで時間がかかりすぎる場合、MFA デバイスはユーザーと正常に関連付けられます。ただし、MFA デバイスは同期しません。これは、タイムベースドワンタイムパスワード (TOTP) の有効期間が短いために起こります。その場合は、[デバイスの再同期](id_credentials_mfa_sync.md)ができます。
これで仮想 MFA デバイスを AWS で使用できます。
1. コンソールからサインアウトし、再度 **MFAUser** としてサインインします。今回は AWS により、携帯電話から MFA コードを取得するよう求められます。コードを取得したら、それをボックスに入力し、[**Submit (送信)**] を選択します。
1. **[EC2]** を選択し、再度 Amazon EC2 コンソールを開きます。今回は、すべての情報を表示して、必要なアクションを実行することができます。このユーザーとして他のコンソールに移動すると、アクセス拒否メッセージが表示されます。その理由は、このチュートリアルのポリシーでは Amazon EC2 へのアクセスのみが許可されるためです。
## 関連リソース
詳細については、以下のトピックを参照してください。
+ [IAM の AWS 多要素認証](id_credentials_mfa.md)
+ [MFA 対応のサインイン](console_sign-in-mfa.md)
# IAM チュートリアル: CloudFormation テンプレートを使用して SAML ID プロバイダー (IdP) を作成する
AWS アカウントの SAML フェデレーションを設定するには、SAML ID プロバイダー (IdP) を作成する必要があります。このチュートリアルでは、CloudFormation テンプレートを使用して、AWS と外部 IdP 間の信頼を確立する SAML IdP を作成する方法を説明します。
テンプレートは、IdP のメタデータドキュメントで設定された SAML IdP を作成します。その後、フェデレーション IAM ロールがこの IdP を参照して、外部 IdP から認証されたユーザーが AWS リソースにアクセスできるようにします。
デプロイされたリソースは、IdP のメタデータドキュメントとオプションの暗号化設定によって設定された SAML IdP で構成されます。
## 前提条件
このチュートリアルでは、以下を実行済みであることを前提としています。
+ このチュートリアルで IdP の SAML メタデータ XML ファイルをフォーマットするために使用する Python コマンドを実行するには、ローカル マシンに Python 3.6 以降がインストールされている必要があります。
+ 外部 IdP からの SAML メタデータドキュメントを XML ファイルとして保存していること。
## CloudFormation を使用して SAML IdP を作成する
SAML IdP を作成するために、CloudFormation テンプレートを作成し、それを使用して IdP リソースが含まれるスタックを作成します。
### テンプレートを作成する
まず、CloudFormation テンプレートを作成します。
1. [テンプレート](#tutorial_saml-idp-template) セクションで、**[JSON]** または **[YAML]** タブのコピーアイコンをクリックして、テンプレートの内容をコピーします。
1. テンプレートの内容を新しいファイルに貼り付けます。
1. ファイルをローカルに保存します。
### スタックを作成します。
次に、保存したテンプレートを使用して CloudFormation スタックをプロビジョニングします。
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. **[スタック]** ページでは、**[スタックの作成]** メニューで **[新しいリソースを使用 (標準)]** を選択します。
1. テンプレートを指定します。
1. **[前提条件]** で、**[既存のテンプレートを選択]** を選択します。
1. **[テンプレートの指定]** で、**[テンプレートファイルのアップロード]** を選択します。
1. **[ファイルを選択]** を選択し、テンプレートファイルに移動して選択します。
1. [**次へ**] を選択します。
1. 次のスタックの詳細を指定します。
1. スタック名を入力します。
1. **[IdentityProviderName]** は、空のままにするとスタック名に基づいて名前を自動生成できます。または、SAML IdP のカスタム名を入力することもできます。カスタム名には、英数字、ピリオド、アンダースコア、ハイフンのみを含めることができます。
1. **[IdentityProviderSAMLMetadataDocument]** では、このフィールドに貼り付ける前に、SAML メタデータ XML ファイルを 1 行にフォーマットする必要があります。CloudFormation コンソールでコンソールパラメータを渡すときに XML コンテンツを 1 行にフォーマットする必要があるため、この処理が必要です。
次の Python コマンドを使用して、XML ファイルを再フォーマットします。
```
python3 -c "import sys, re; content=open(sys.argv[1]).read(); print(re.sub(r'>\s+<', '><', content.replace('\n', '').replace('\r', '').strip()))" saml-metadata.xml
```
**注記**
IdP の SAML メタデータドキュメントは、コンソールパラメータ入力用に 1 行にフォーマットする必要があります。この Python コマンドは、改行と余分な空白を削除して、元のコンテンツと構造をすべて維持した状態で必要なフォーマットを作成します。
Python コマンドの出力をコピーし、**[IdentityProviderSAMLMetadataDocument]** フィールドに貼り付けます。
フォーマットされた SAML メタデータドキュメントの例 (抜粋):
```
MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV...urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
```
1. その他のパラメータについては、デフォルト値を受け入れるか、要件に応じて独自の値を入力します。
+ **IdentityProviderAddPrivateKey** – SAML アサーションを復号するためのオプションのプライベートキー
+ **IdentityProviderAssertionEncryptionMode** – 必要に応じて、SAML アサーションの暗号化モードを設定する (許可、必須、または空)
1. [**次へ**] を選択します。
1. スタックオプションを設定します。
1. **[スタック障害オプション]** で、**[新しく作成されたリソースをすべて削除]** を選択します。
**注記**
このオプションを選択すると、スタックの作成に失敗した場合でも削除ポリシーで保持するように指定されているリソースに対して、課金される可能性を防ぐことができます。
1. 他はすべて、デフォルト値を受け入れます。
1. **[機能]** では、チェックボックスをオンにして、CloudFormation によってアカウントに IAM リソースが作成される場合があることを承認します。
1. [**次へ**] を選択します。
1. スタックの詳細を確認して、**[送信]** を選択します。
CloudFormation によってスタックが作成されます。スタックの作成が完了すると、スタックリソースを使用する準備が整います。スタックの詳細ページの **[リソース]** タブを使用して、アカウントにプロビジョニングされたリソースを表示できます。
スタックは次の値を出力します。値は **[出力]** タブで確認できます。
+ **ProviderARN**: 作成された SAML IdP の ARN (`arn:aws:iam::123456789012:saml-provider/CompanyIdP` など)。このプロバイダーを信頼するロールを作成するときに、この ARN が必要になります。
+ **ProviderName**: 作成された SAML IdP の名前 (カスタム名を指定した場合は `CompanyIdP`、デフォルトの命名を使用した場合は `my-saml-stack-saml-provider` など)。
これらの出力もエクスポートされるため、`Fn::ImportValue` 関数を使用して他の CloudFormation スタックにインポートできます。
## SAML IdP を検証する
SAML IdP が作成されたら、その設定を検証し、フェデレーションロールで使用する ARN を書き留めます。
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. ナビゲーションペインで、**[ID プロバイダー]** を選択します。
新しく作成された SAML IdP がリストに表示されるはずです。
1. IdP 名を選択すると、その詳細が表示されます。
IdP の詳細ページで、SAML メタデータドキュメントやその他の設定の詳細を確認できます。
1. 詳細ページに表示される **[プロバイダー ARN]** を書き留めます。
この IdP を信頼するフェデレーション IAM ロールを作成するときに、この ARN が必要になります。
1. メタデータドキュメントを確認して、外部 IdP から提供した内容と一致することを確認します。
これで、SAML IdP をフェデレーション IAM ロールで使用する準備ができました。この IdP を信頼するロールを作成して、外部 IdP から認証されたユーザーがそれらのロールを引き受け、AWS リソースにアクセスできるように許可できます。
## クリーンアップ: リソースを削除する
最後のステップとして、スタックとそれに含まれるリソースを削除します。
1. CloudFormation コンソールを開きます。
1. **[スタック]** ページで、テンプレートから作成されたスタックを選択し、**[削除]** を選択してから、**[削除]** で確定します。
CloudFormation は、スタックとそれに含まれるすべてのリソースの削除を開始します。
## CloudFormation テンプレートファイルの詳細
### リソース
このチュートリアルで使用する CloudFormation テンプレートでは、以下のリソースがアカウントに作成されます。
[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html): AWS と外部 IdP の間の信頼を確立する SAML IdP。
### 設定
テンプレートには、以下の設定可能なパラメータが含まれています。
+ **IdentityProviderName** – SAML IdP の名前 (自動生成された名前にする場合は空のままにします)
例: `CompanyIdP` または `EnterpriseSSO`
+ **IdentityProviderSAMLMetadataDocument** – 外部 IdP からの SAML メタデータドキュメント (1 行のフォーマット)
+ **IdentityProviderAddPrivateKey** – SAML アサーションを復号するためのオプションのプライベートキー
+ **IdentityProviderAssertionEncryptionMode** – 必要に応じて、SAML アサーションの暗号化モードを設定します
## CloudFormation テンプレート
次の JSON または YAML コードを別のファイルとして保存し、このチュートリアルの CloudFormation テンプレートとして使用します。
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-idp",
"Parameters": {
"IdentityProviderName": {
"Type": "String",
"Description": "Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens"
},
"IdentityProviderSAMLMetadataDocument": {
"Type": "String",
"Description": "SAML metadata document from identity provider"
},
"IdentityProviderAddPrivateKey": {
"Type": "String",
"Description": "Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.",
"Default": ""
},
"IdentityProviderAssertionEncryptionMode": {
"Type": "String",
"Description": "Optional, sets encryption mode for SAML assertions",
"Default": "",
"AllowedValues": ["", "Allowed", "Required"]
}
},
"Conditions": {
"HasPrivateKey": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAddPrivateKey"}, ""]}]},
"HasEncryptionMode": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAssertionEncryptionMode"}, ""]}]},
"HasCustomName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderName"}, ""]}]}
},
"Resources": {
"SAMLProvider": {
"Type": "AWS::IAM::SAMLProvider",
"Properties": {
"Name": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Ref": "AWS::NoValue"}]},
"SamlMetadataDocument": {"Ref": "IdentityProviderSAMLMetadataDocument"},
"Tags": [
{
"Key": "Name",
"Value": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Fn::Sub": "${AWS::StackName}-saml-provider"}]}
}
],
"AddPrivateKey": {"Fn::If": ["HasPrivateKey", {"Ref": "IdentityProviderAddPrivateKey"}, {"Ref": "AWS::NoValue"}]},
"AssertionEncryptionMode": {"Fn::If": ["HasEncryptionMode", {"Ref": "IdentityProviderAssertionEncryptionMode"}, {"Ref": "AWS::NoValue"}]}
}
}
},
"Outputs": {
"ProviderARN": {
"Description": "ARN of the created SAML Identity Provider",
"Value": {"Ref": "SAMLProvider"},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-ProviderARN"}
}
},
"ProviderName": {
"Description": "Name of the SAML Identity Provider",
"Value": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Fn::Sub": "${AWS::StackName}-saml-provider"}]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-ProviderName"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-idp'
Parameters:
IdentityProviderName:
Type: String
Description: Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[a-zA-Z0-9._-]+$'
ConstraintDescription: 'Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens'
IdentityProviderSAMLMetadataDocument:
Type: String
Description: SAML metadata document from identity provider
IdentityProviderAddPrivateKey:
Type: String
Description: Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.
Default: ""
IdentityProviderAssertionEncryptionMode:
Type: String
Description: Optional, sets encryption mode for SAML assertions
Default: ""
AllowedValues:
- ""
- "Allowed"
- "Required"
Conditions:
HasPrivateKey: !Not [!Equals [!Ref IdentityProviderAddPrivateKey, ""]]
HasEncryptionMode: !Not [!Equals [!Ref IdentityProviderAssertionEncryptionMode, ""]]
HasCustomName: !Not [!Equals [!Ref IdentityProviderName, ""]]
Resources:
SAMLProvider:
Type: 'AWS::IAM::SAMLProvider'
Properties:
Name: !If
- HasCustomName
- !Ref IdentityProviderName
- !Ref AWS::NoValue
SamlMetadataDocument: !Ref IdentityProviderSAMLMetadataDocument
Tags:
- Key: Name
Value: !If
- HasCustomName
- !Ref IdentityProviderName
- !Sub '${AWS::StackName}-saml-provider'
AddPrivateKey: !If
- HasPrivateKey
- !Ref IdentityProviderAddPrivateKey
- !Ref AWS::NoValue
AssertionEncryptionMode: !If
- HasEncryptionMode
- !Ref IdentityProviderAssertionEncryptionMode
- !Ref AWS::NoValue
Outputs:
ProviderARN:
Description: 'ARN of the created SAML Identity Provider'
Value: !Ref SAMLProvider
Export:
Name: !Sub '${AWS::StackName}-ProviderARN'
ProviderName:
Description: 'Name of the SAML Identity Provider'
Value: !If
- HasCustomName
- !Ref IdentityProviderName
- !Sub '${AWS::StackName}-saml-provider'
Export:
Name: !Sub '${AWS::StackName}-ProviderName'
```
------
# IAM チュートリアル: CloudFormation テンプレートを使用して SAML フェデレーション IAM ロールを作成する
AWS アカウントで既存の SAML ID プロバイダー (IdP) を設定している場合は、その IdP を信頼するフェデレーション IAM ロールを作成できます。このチュートリアルでは、CloudFormation テンプレートを使用して、外部 IdP で認証されたユーザーが引き受けることができる SAML フェデレーション IAM ロールを作成する方法を説明します。
このテンプレートは、SAML IdP がロールを引き受けることを許可する信頼ポリシーを持つフェデレーション IAM ロールを作成します。外部 IdP によって認証されたユーザーは、このロールを引き受けて、ロールにアタッチされたアクセス許可に基づいて AWS リソースにアクセスできます。
デプロイされたリソースは、以下で構成されます。
+ 既存の SAML IdP を信頼するフェデレーション IAM ロール。
+ 特定のアクセス許可を付与するためにロールにアタッチできる設定可能なマネージドポリシー。
+ オプションのアクセス許可の境界とセッション期間の設定。
## 前提条件
このチュートリアルでは、以下を実行済みであることを前提としています。
+ AWS アカウントに設定された既存の SAML IdP。ない場合は、[IAM チュートリアル: CloudFormation テンプレートを使用して SAML ID プロバイダー (IdP) を作成する](tutorial_saml-idp.md) チュートリアルを使用して作成できます。
+ SAML IdP の ARN。スタックの作成時にパラメータとして指定する必要があります。
+ このチュートリアルで IdP の SAML メタデータ XML ファイルをフォーマットするために使用する Python コマンドを実行するには、ローカル マシンに Python 3.6 以降がインストールされている必要があります。
## CloudFormation を使用して SAML フェデレーションロールを作成する
SAML フェデレーションロールを作成するために、CloudFormation テンプレートを作成し、それを使用してロールが含まれるスタックを作成します。
### テンプレートを作成する
まず、CloudFormation テンプレートを作成します。
1. [テンプレート](#tutorial_saml-federated-role-template) セクションで、**[JSON]** または **[YAML]** タブのコピーアイコンをクリックして、テンプレートの内容をコピーします。
1. テンプレートの内容を新しいファイルに貼り付けます。
1. ファイルをローカルに保存します。
### スタックを作成します。
次に、保存したテンプレートを使用して CloudFormation スタックをプロビジョニングします。
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. **[スタック]** ページでは、**[スタックの作成]** メニューで **[新しいリソースを使用 (標準)]** を選択します。
1. テンプレートを指定します。
1. **[前提条件]** で、**[既存のテンプレートを選択]** を選択します。
1. **[テンプレートの指定]** で、**[テンプレートファイルのアップロード]** を選択します。
1. **[ファイルを選択]** を選択し、テンプレートファイルに移動して選択します。
1. [**次へ**] を選択します。
1. 次のスタックの詳細を指定します。
1. スタック名を入力します。
1. **[SAMLProviderARN]** には、既存の SAML IdP の ARN を入力します。これは `arn:aws:iam::123456789012:saml-provider/YourProviderName` 形式である必要があります。
例:`arn:aws:iam::123456789012:saml-provider/CompanyIdP`
**注記**
[IAM チュートリアル: CloudFormation テンプレートを使用して SAML ID プロバイダー (IdP) を作成する](tutorial_saml-idp.md) チュートリアルを使用して SAML IdP を作成した場合は、その CloudFormation スタックの [出力] タブにプロバイダー ARN が表示されます。
1. **[RoleName]** では、空のままにするとスタック名に基づいて名前を自動生成できます。または、IAM ロールのカスタム名を入力できます。
例: `SAML-Developer-Access` または `SAML-ReadOnly-Role`
1. その他のパラメータについては、デフォルト値を受け入れるか、要件に応じて独自の値を入力します。
+ **RoleSessionDuration** – 最大セッション期間 (秒) (3600～43200、デフォルトは 7200)
例: `14400` (4 時間)
+ **RolePermissionsBoundary** – アクセス許可の境界ポリシーのオプション ARN
例:`arn:aws:iam::123456789012:policy/DeveloperBoundary`
+ **RolePath** – IAM ロールのパス (デフォルトは /)
例:`/saml-roles/`
+ **ManagedPolicy1-5** – アタッチする最大 5 つのマネージドポリシーのオプション ARN
ManagedPolicy1 の例: `arn:aws:iam::aws:policy/ReadOnlyAccess`
ManagedPolicy2 の例: `arn:aws:iam::123456789012:policy/CustomPolicy`
1. [**次へ**] を選択します。
1. スタックオプションを設定します。
1. **[スタック障害オプション]** で、**[新しく作成されたリソースをすべて削除]** を選択します。
**注記**
このオプションを選択すると、スタックの作成に失敗した場合でも削除ポリシーで保持するように指定されているリソースに対して、課金される可能性を防ぐことができます。
1. 他はすべて、デフォルト値を受け入れます。
1. **[機能]** では、チェックボックスをオンにして、CloudFormation によってアカウントに IAM リソースが作成される場合があることを承認します。
1. [**次へ**] を選択します。
1. スタックの詳細を確認して、**[送信]** を選択します。
CloudFormation によってスタックが作成されます。スタックの作成が完了すると、スタックリソースを使用する準備が整います。スタックの詳細ページの **[リソース]** タブを使用して、アカウントにプロビジョニングされたリソースを表示できます。
スタックは次の値を出力します。値は **[出力]** タブで確認できます。
+ **RoleARN**: 作成された IAM ロールの ARN (自動生成された名前を使用する場合は、`arn:aws:iam::123456789012:role/SAML-Developer-Access` または `arn:aws:iam::123456789012:role/stack-name-a1b2c3d4` など)。
ロールの引き受けのために適切な SAML 属性を送信するように IdP を設定する場合は、このロール ARN が必要です。
## SAML フェデレーションロールをテストする
SAML フェデレーションロールが作成されたら、その設定を検証し、フェデレーション設定をテストできます。
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. ナビゲーションペインで **Roles (ロール) ** を選択してください。
1. 新しく作成されたフェデレーションロールを見つけて選択します。
カスタムロール名を指定した場合は、その名前を探します。RoleName パラメータを空のままにすると、ロールにはスタック名と一意の識別子に基づいて自動生成された名前が付けられます。
1. **[信頼関係]** タブを選択して、信頼ポリシーを確認します。
信頼ポリシーには、SAML オーディエンス (`SAML:aud`) が `https://signin.aws.amazon.com/saml` と一致することを条件として、SAML IdP がこのロールを引き受けるように信頼されていることが示されているはずです。
1. **[アクセス許可]** タブで、アタッチされたポリシーを確認します。
作成時にロールにアタッチされたマネージドポリシーを確認できます。
1. ロールの概要ページに表示される **[ロール ARN]** を書き留めます。
ユーザーがこのロールを引き受けることができるように外部 IdP を設定するには、この ARN が必要です。
これで、SAML フェデレーションロールを使用する準備ができました。SAML アサーションにこのロールの ARN を含めるように外部 IdP を設定すると、認証されたユーザーはこのロールを引き受けて AWS リソースにアクセスすることができます。
## クリーンアップ: リソースを削除する
最後のステップとして、スタックとそれに含まれるリソースを削除します。
1. CloudFormation コンソールを開きます。
1. **[スタック]** ページで、テンプレートから作成されたスタックを選択し、**[削除]** を選択してから、**[削除]** で確定します。
CloudFormation は、スタックとそれに含まれるすべてのリソースの削除を開始します。
## CloudFormation テンプレートファイルの詳細
### リソース
このチュートリアルで使用する CloudFormation テンプレートでは、以下のリソースがアカウントに作成されます。
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html): SAML IdP を介して認証されたユーザーが引き受けることができるフェデレーション IAM ロール。
### 設定
テンプレートには、以下の設定可能なパラメータが含まれています。
+ **RoleName** – IAM ロールの名前 (自動生成された名前にする場合は空のままにします)
+ **SAMLProviderARN** – SAML IdP の ARN (必須)
+ **RoleSessionDuration** – 最大セッション期間 (秒) (3600～43200、デフォルトは 7200)
+ **RolePermissionsBoundary** – アクセス許可の境界ポリシーのオプション ARN
+ **RolePath** – IAM ロールのパス (デフォルトは /)
+ **ManagedPolicy1-5** – アタッチする最大 5 つのマネージドポリシーのオプション ARN
## CloudFormation テンプレート
次の JSON または YAML コードを別のファイルとして保存し、このチュートリアルの CloudFormation テンプレートとして使用します。
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-federated-role",
"Parameters": {
"RoleName": {
"Type": "String",
"Description": "Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[\\w+=,.@-]{1,64}$",
"ConstraintDescription": "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
},
"SAMLProviderARN": {
"Type": "String",
"Description": "ARN of the SAML Identity Provider",
"AllowedPattern": "^arn:aws:iam::\\d{12}:saml-provider/[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be a valid SAML provider ARN"
},
"RoleSessionDuration": {
"Type": "Number",
"Description": "The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)",
"MinValue": 3600,
"MaxValue": 43200,
"Default": 7200
},
"RolePermissionsBoundary": {
"Type": "String",
"Description": "Optional ARN of the permissions boundary policy (leave empty for none)",
"Default": ""
},
"RolePath": {
"Type": "String",
"Description": "Path for the IAM role (must start and end with /)",
"Default": "/",
"AllowedPattern": "^\/.*\/$|^\/$",
"ConstraintDescription": "Role path must start and end with forward slash (/)"
},
"RoleManagedPolicy1": {
"Type": "String",
"Description": "Optional managed policy ARN 1",
"Default": ""
},
"RoleManagedPolicy2": {
"Type": "String",
"Description": "Optional managed policy ARN 2",
"Default": ""
},
"RoleManagedPolicy3": {
"Type": "String",
"Description": "Optional managed policy ARN 3",
"Default": ""
},
"RoleManagedPolicy4": {
"Type": "String",
"Description": "Optional managed policy ARN 4",
"Default": ""
},
"RoleManagedPolicy5": {
"Type": "String",
"Description": "Optional managed policy ARN 5",
"Default": ""
}
},
"Conditions": {
"HasCustomRoleName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleName"}, ""]}]},
"HasPermissionsBoundary": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RolePermissionsBoundary"}, ""]}]},
"HasPolicy1": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy1"}, ""]}]},
"HasPolicy2": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy2"}, ""]}]},
"HasPolicy3": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy3"}, ""]}]},
"HasPolicy4": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy4"}, ""]}]},
"HasPolicy5": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy5"}, ""]}]}
},
"Resources": {
"SAMLFederatedRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"RoleName": {"Fn::If": ["HasCustomRoleName", {"Ref": "RoleName"}, {"Ref": "AWS::NoValue"}]},
"Description": "IAM role with SAML provider trust",
"MaxSessionDuration": {"Ref": "RoleSessionDuration"},
"PermissionsBoundary": {"Fn::If": ["HasPermissionsBoundary", {"Ref": "RolePermissionsBoundary"}, {"Ref": "AWS::NoValue"}]},
"Path": {"Ref": "RolePath"},
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": {"Ref": "SAMLProviderARN"}
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
},
"ManagedPolicyArns": {
"Fn::Split": [
",",
{
"Fn::Join": [
",",
[
{"Fn::If": ["HasPolicy1", {"Ref": "RoleManagedPolicy1"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy2", {"Ref": "RoleManagedPolicy2"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy3", {"Ref": "RoleManagedPolicy3"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy4", {"Ref": "RoleManagedPolicy4"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy5", {"Ref": "RoleManagedPolicy5"}, {"Ref": "AWS::NoValue"}]}
]
]
}
]
}
}
}
},
"Outputs": {
"RoleARN": {
"Description": "ARN of the created IAM Role",
"Value": {"Fn::GetAtt": ["SAMLFederatedRole", "Arn"]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-RoleARN"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-federated-role'
Parameters:
RoleName:
Type: String
Description: 'Name of the IAM Role (leave empty for auto-generated name like ''{StackName}-{UniqueId}'')'
Default: ""
AllowedPattern: '^$|^[\w+=,.@-]{1,64}$'
ConstraintDescription: 'Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-'
SAMLProviderARN:
Type: String
Description: 'ARN of the SAML Identity Provider'
AllowedPattern: '^arn:aws:iam::\d{12}:saml-provider/[a-zA-Z0-9._-]+$'
ConstraintDescription: 'Must be a valid SAML provider ARN'
RoleSessionDuration:
Type: Number
Description: 'The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)'
MinValue: 3600
MaxValue: 43200
Default: 7200
RolePermissionsBoundary:
Type: String
Description: Optional ARN of the permissions boundary policy (leave empty for none)
Default: ""
RolePath:
Type: String
Description: 'Path for the IAM role (must start and end with /)'
Default: "/"
AllowedPattern: '^\/.*\/$|^\/$'
ConstraintDescription: 'Role path must start and end with forward slash (/)'
RoleManagedPolicy1:
Type: String
Description: Optional managed policy ARN 1
Default: ""
RoleManagedPolicy2:
Type: String
Description: Optional managed policy ARN 2
Default: ""
RoleManagedPolicy3:
Type: String
Description: Optional managed policy ARN 3
Default: ""
RoleManagedPolicy4:
Type: String
Description: Optional managed policy ARN 4
Default: ""
RoleManagedPolicy5:
Type: String
Description: Optional managed policy ARN 5
Default: ""
Conditions:
HasCustomRoleName: !Not [!Equals [!Ref RoleName, ""]]
HasPermissionsBoundary: !Not [!Equals [!Ref RolePermissionsBoundary, ""]]
HasPolicy1: !Not [!Equals [!Ref RoleManagedPolicy1, ""]]
HasPolicy2: !Not [!Equals [!Ref RoleManagedPolicy2, ""]]
HasPolicy3: !Not [!Equals [!Ref RoleManagedPolicy3, ""]]
HasPolicy4: !Not [!Equals [!Ref RoleManagedPolicy4, ""]]
HasPolicy5: !Not [!Equals [!Ref RoleManagedPolicy5, ""]]
Resources:
SAMLFederatedRole:
Type: 'AWS::IAM::Role'
Properties:
RoleName: !If
- HasCustomRoleName
- !Ref RoleName
- !Ref AWS::NoValue
Description: 'IAM role with SAML provider trust'
MaxSessionDuration: !Ref RoleSessionDuration
PermissionsBoundary: !If
- HasPermissionsBoundary
- !Ref RolePermissionsBoundary
- !Ref AWS::NoValue
Path: !Ref RolePath
AssumeRolePolicyDocument:
Version: '2012-10-17 '
Statement:
- Effect: Allow
Principal:
Federated: !Ref SAMLProviderARN
Action: 'sts:AssumeRoleWithSAML'
Condition:
StringEquals:
'SAML:aud': 'https://signin.aws.amazon.com/saml'
ManagedPolicyArns:
!Split
- ','
- !Join
- ','
- - !If [HasPolicy1, !Ref RoleManagedPolicy1, !Ref 'AWS::NoValue']
- !If [HasPolicy2, !Ref RoleManagedPolicy2, !Ref 'AWS::NoValue']
- !If [HasPolicy3, !Ref RoleManagedPolicy3, !Ref 'AWS::NoValue']
- !If [HasPolicy4, !Ref RoleManagedPolicy4, !Ref 'AWS::NoValue']
- !If [HasPolicy5, !Ref RoleManagedPolicy5, !Ref 'AWS::NoValue']
Outputs:
RoleARN:
Description: 'ARN of the created IAM Role'
Value: !GetAtt SAMLFederatedRole.Arn
Export:
Name: !Sub '${AWS::StackName}-RoleARN'
```
------
# IAM チュートリアル: CloudFormation テンプレートを使用して SAML ID プロバイダー (IdP) と SAML フェデレーション IAM ロールを作成する
SAML フェデレーションとその機能を理解するために、CloudFormation テンプレートを使用して SAML ID プロバイダー (IdP) と関連するフェデレーション IAM ロールを設定します。このチュートリアルでは、両方のリソースを 1 つのスタックにまとめて作成する方法を説明します。
テンプレートは、AWS リソースへのフェデレーションアクセスに使用できる SAML IdP と、SAML プロバイダーを信頼する IAM ロールを作成します。外部 IdP によって認証されたユーザーは、このロールを引き受けて AWS リソースにアクセスできます。
デプロイされたリソースは、以下で構成されます。
+ IdP のメタデータドキュメントで設定された SAML IdP。
+ SAML IdP を信頼し、認証されたユーザーが引き受けることができるフェデレーション IAM ロール。
+ 特定のアクセス許可を付与するためにロールにアタッチできる設定可能なマネージドポリシー。
## 前提条件
このチュートリアルでは、以下を実行済みであることを前提としています。
+ このチュートリアルで IdP の SAML メタデータ XML ファイルをフォーマットするために使用する Python コマンドを実行するには、ローカル マシンに Python 3.6 以降がインストールされている必要があります。
+ 外部 IdP からの SAML メタデータドキュメントを XML ファイルとして保存していること。
## CloudFormation を使用して SAML IdP とロールを作成する
SAML IdP とフェデレーションロールを作成するために、CloudFormation テンプレートを作成し、それを使用して両方のリソースが含まれるスタックを作成します。
### テンプレートを作成する
まず、CloudFormation テンプレートを作成します。
1. [テンプレート](#tutorial_saml-idp-and-federated-role-template) セクションで、**[JSON]** または **[YAML]** タブのコピーアイコンをクリックして、テンプレートの内容をコピーします。
1. テンプレートの内容を新しいファイルに貼り付けます。
1. ファイルをローカルに保存します。
### スタックを作成します。
次に、保存したテンプレートを使用して CloudFormation スタックをプロビジョニングします。
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. **[スタック]** ページでは、**[スタックの作成]** メニューで **[新しいリソースを使用 (標準)]** を選択します。
1. テンプレートを指定します。
1. **[前提条件]** で、**[既存のテンプレートを選択]** を選択します。
1. **[テンプレートの指定]** で、**[テンプレートファイルのアップロード]** を選択します。
1. **[ファイルを選択]** を選択し、テンプレートファイルに移動して選択します。
1. [**次へ**] を選択します。
1. 次のスタックの詳細を指定します。
1. スタック名を入力します。
1. **[IdentityProviderName]** は、空のままにするとスタック名に基づいて名前を自動生成できます。または、SAML IdP のカスタム名を入力することもできます。
例: `CompanyIdP` または `EnterpriseSSO`
1. **[IdentityProviderSAMLMetadataDocument]** では、このフィールドに貼り付ける前に、SAML メタデータ XML ファイルを 1 行にフォーマットする必要があります。CloudFormation コンソールでコンソールパラメータを渡すときに XML コンテンツを 1 行にフォーマットする必要があるため、この処理が必要です。
次の Python コマンドを使用して、XML ファイルを再フォーマットします。
```
python3 -c "import sys, re; content=open(sys.argv[1]).read(); print(re.sub(r'>\s+<', '><', content.replace('\n', '').replace('\r', '').strip()))" saml-metadata.xml
```
**注記**
IdP の SAML メタデータドキュメントは、コンソールパラメータ入力用に 1 行にフォーマットする必要があります。この Python コマンドは、改行と余分な空白を削除して、元のコンテンツと構造をすべて維持した状態で必要なフォーマットを作成します。
Python コマンドの出力をコピーし、**[IdentityProviderSAMLMetadataDocument]** フィールドに貼り付けます。
フォーマットされた SAML メタデータドキュメントの例 (抜粋):
```
MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV...urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
```
1. **[RoleName]** では、空のままにするとスタック名に基づいて名前を自動生成できます。または、フェデレーション IAM ロールのカスタム名を入力できます。
例: `SAML-Developer-Access` または `SAML-ReadOnly-Role`
1. その他のパラメータについては、デフォルト値を受け入れるか、要件に応じて独自の値を入力します。
+ **IdentityProviderAddPrivateKey** – SAML アサーションを復号するためのオプションのプライベートキー
+ **IdentityProviderAssertionEncryptionMode** – SAML アサーションの暗号化モード
値の例: `Allowed`、`Required`、または暗号化なしの場合は空のままにする
+ **RoleSessionDuration** – 最大セッション期間 (秒) (3600～43200、デフォルトは 7200)
例: `14400` (4 時間)
+ **RolePermissionsBoundary** – アクセス許可の境界ポリシーのオプション ARN
例:`arn:aws:iam::123456789012:policy/DeveloperBoundary`
+ **RolePath** – IAM ロールのパス (デフォルトは /)
例:`/saml-roles/`
+ **RoleManagedPolicy1-5** – アタッチする最大 5 つのマネージドポリシーのオプション ARN
RoleManagedPolicy1 の例: `arn:aws:iam::aws:policy/ReadOnlyAccess`
RoleManagedPolicy2 の例: `arn:aws:iam::123456789012:policy/CustomPolicy`
1. [**次へ**] を選択します。
1. スタックオプションを設定します。
1. **[スタック障害オプション]** で、**[新しく作成されたリソースをすべて削除]** を選択します。
**注記**
このオプションを選択すると、スタックの作成に失敗した場合でも削除ポリシーで保持するように指定されているリソースに対して、課金される可能性を防ぐことができます。
1. 他はすべて、デフォルト値を受け入れます。
1. **[機能]** では、チェックボックスをオンにして、CloudFormation によってアカウントに IAM リソースが作成される場合があることを承認します。
1. [**次へ**] を選択します。
1. スタックの詳細を確認して、**[送信]** を選択します。
CloudFormation によってスタックが作成されます。スタックの作成が完了すると、スタックリソースを使用する準備が整います。スタックの詳細ページの **[リソース]** タブを使用して、アカウントにプロビジョニングされたリソースを表示できます。
スタックは次の値を出力します。値は **[出力]** タブで確認できます。
+ **RoleARN**: 作成された IAM ロールの ARN (自動生成された名前を使用する場合は、`arn:aws:iam::123456789012:role/SAML-Developer-Access` または `arn:aws:iam::123456789012:role/stack-name-a1b2c3d4` など)。
+ **IdentityProviderARN**: 作成された SAML IdP の ARN (`arn:aws:iam::123456789012:saml-provider/CompanyIdP` など)。
ロールの引き受けのために適切な SAML 属性を送信するように IdP を設定する場合は、これら両方の ARN が必要です。
## SAML フェデレーションをテストする
SAML IdP とフェデレーションロールが作成されたら、フェデレーション設定をテストできます。
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. ナビゲーションペインで、**[ID プロバイダー]** を選択します。
新しく作成された SAML IdP がリストに表示されるはずです。
1. IdP 名を選択すると、その詳細が表示されます。
IdP の詳細ページで、SAML メタデータドキュメントやその他の設定の詳細を確認できます。
1. ナビゲーションペインで **Roles (ロール) ** を選択してください。
1. 新しく作成されたフェデレーションロールを見つけて選択します。
ロールの詳細ページで、SAML IdP がこのロールを引き受けることを許可する信頼ポリシーを確認できます。
1. **[信頼関係]** タブを選択して、信頼ポリシーを確認します。
信頼ポリシーには、SAML オーディエンス (`SAML:aud`) が `https://signin.aws.amazon.com/saml` と一致することを条件として、SAML IdP がこのロールを引き受けるように信頼されていることが示されているはずです。
## クリーンアップ: リソースを削除する
最後のステップとして、スタックとそれに含まれるリソースを削除します。
1. CloudFormation コンソールを開きます。
1. **[スタック]** ページで、テンプレートから作成されたスタックを選択し、**[削除]** を選択してから、**[削除]** で確定します。
CloudFormation は、スタックとそれに含まれるすべてのリソースの削除を開始します。
## CloudFormation テンプレートファイルの詳細
### リソース
このチュートリアルで使用する CloudFormation テンプレートでは、以下のリソースがアカウントに作成されます。
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html): AWS と外部 IdP の間の信頼を確立する SAML IdP。
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html): SAML IdP を介して認証されたユーザーが引き受けることができるフェデレーション IAM ロール。
### 設定
テンプレートには、以下の設定可能なパラメータが含まれています。
+ **IdentityProviderName** – SAML IdP の名前 (自動生成された名前にする場合は空のままにします)
+ **IdentityProviderSAMLMetadataDocument** – IdP の SAML メタデータドキュメント (必須)。
+ **IdentityProviderAddPrivateKey** – SAML アサーションを復号するためのオプションのプライベートキー
+ **IdentityProviderAssertionEncryptionMode** – SAML アサーションの暗号化モード
+ **RoleName** – IAM ロールの名前 (自動生成された名前にする場合は空のままにします)
+ **RolePath** – IAM ロールのパス (デフォルトは /)
+ **RolePermissionsBoundary** – アクセス許可の境界ポリシーのオプション ARN
+ **RoleSessionDuration** – 最大セッション期間 (秒) (3600～43200、デフォルトは 7200)
+ **RoleManagedPolicy1-5** – アタッチする最大 5 つのマネージドポリシーのオプション ARN
## CloudFormation テンプレート
次の JSON または YAML コードを別のファイルとして保存し、このチュートリアルの CloudFormation テンプレートとして使用します。
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-idp-and-federated-role",
"Parameters": {
"IdentityProviderName": {
"Type": "String",
"Description": "Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens"
},
"IdentityProviderSAMLMetadataDocument": {
"Type": "String",
"Description": "SAML metadata document from identity provider"
},
"IdentityProviderAddPrivateKey": {
"Type": "String",
"Description": "Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.",
"Default": ""
},
"IdentityProviderAssertionEncryptionMode": {
"Type": "String",
"Description": "Optional, sets encryption mode for SAML assertions",
"Default": "",
"AllowedValues": ["", "Allowed", "Required"]
},
"RoleName": {
"Type": "String",
"Description": "Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[\\w+=,.@-]{1,64}$",
"ConstraintDescription": "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
},
"RolePath": {
"Type": "String",
"Description": "Path for the IAM Role",
"AllowedPattern": "(^\\/$)|(^\\/.*\\/$)",
"Default": "/"
},
"RolePermissionsBoundary": {
"Type": "String",
"Description": "Optional ARN of the permissions boundary policy (leave empty for none)",
"Default": ""
},
"RoleSessionDuration": {
"Description": "The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)",
"Type": "Number",
"MinValue": 3600,
"MaxValue": 43200,
"Default": 7200
},
"RoleManagedPolicy1": {
"Type": "String",
"Description": "Optional managed policy ARN 1",
"Default": ""
},
"RoleManagedPolicy2": {
"Type": "String",
"Description": "Optional managed policy ARN 2",
"Default": ""
},
"RoleManagedPolicy3": {
"Type": "String",
"Description": "Optional managed policy ARN 3",
"Default": ""
},
"RoleManagedPolicy4": {
"Type": "String",
"Description": "Optional managed policy ARN 4",
"Default": ""
},
"RoleManagedPolicy5": {
"Type": "String",
"Description": "Optional managed policy ARN 5",
"Default": ""
}
},
"Conditions": {
"HasCustomProviderName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderName"}, ""]}]},
"HasCustomRoleName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleName"}, ""]}]},
"HasPermissionsBoundary": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RolePermissionsBoundary"}, ""]}]},
"HasPolicy1": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy1"}, ""]}]},
"HasPolicy2": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy2"}, ""]}]},
"HasPolicy3": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy3"}, ""]}]},
"HasPolicy4": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy4"}, ""]}]},
"HasPolicy5": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy5"}, ""]}]},
"HasPrivateKey": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAddPrivateKey"}, ""]}]},
"HasAssertionEncryptionMode": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAssertionEncryptionMode"}, ""]}]}
},
"Resources": {
"SAMLProvider": {
"Type": "AWS::IAM::SAMLProvider",
"Properties": {
"Name": {"Fn::If": ["HasCustomProviderName", {"Ref": "IdentityProviderName"}, {"Ref": "AWS::NoValue"}]},
"SamlMetadataDocument": {"Ref": "IdentityProviderSAMLMetadataDocument"},
"AddPrivateKey": {"Fn::If": ["HasPrivateKey", {"Ref": "IdentityProviderAddPrivateKey"}, {"Ref": "AWS::NoValue"}]},
"AssertionEncryptionMode": {"Fn::If": ["HasAssertionEncryptionMode", {"Ref": "IdentityProviderAssertionEncryptionMode"}, {"Ref": "AWS::NoValue"}]}
}
},
"SAMLFederatedRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"RoleName": {"Fn::If": ["HasCustomRoleName", {"Ref": "RoleName"}, {"Ref": "AWS::NoValue"}]},
"Path": {"Ref": "RolePath"},
"Description": "SAML federated IAM role for SSO access with specified permissions",
"MaxSessionDuration": {"Ref": "RoleSessionDuration"},
"PermissionsBoundary": {"Fn::If": ["HasPermissionsBoundary", {"Ref": "RolePermissionsBoundary"}, {"Ref": "AWS::NoValue"}]},
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": {"Ref": "SAMLProvider"}
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
},
"ManagedPolicyArns": {
"Fn::Split": [
",",
{
"Fn::Join": [
",",
[
{"Fn::If": ["HasPolicy1", {"Ref": "RoleManagedPolicy1"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy2", {"Ref": "RoleManagedPolicy2"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy3", {"Ref": "RoleManagedPolicy3"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy4", {"Ref": "RoleManagedPolicy4"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy5", {"Ref": "RoleManagedPolicy5"}, {"Ref": "AWS::NoValue"}]}
]
]
}
]
}
}
}
},
"Outputs": {
"RoleARN": {
"Description": "ARN of the created IAM Role",
"Value": {"Fn::GetAtt": ["SAMLFederatedRole", "Arn"]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-RoleARN"}
}
},
"IdentityProviderARN": {
"Description": "ARN of the created SAML Identity Provider",
"Value": {"Ref": "SAMLProvider"},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-IdentityProviderARN"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-idp-and-federated-role'
Parameters:
IdentityProviderName:
Type: String
Description: Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[a-zA-Z0-9._-]+$'
ConstraintDescription: Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens
IdentityProviderSAMLMetadataDocument:
Type: String
Description: SAML metadata document from identity provider
IdentityProviderAddPrivateKey:
Type: String
Description: Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.
Default: ""
IdentityProviderAssertionEncryptionMode:
Type: String
Description: Optional, sets encryption mode for SAML assertions
Default: ""
AllowedValues:
- ""
- "Allowed"
- "Required"
RoleName:
Type: String
Description: Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[\w+=,.@-]{1,64}$'
ConstraintDescription: "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
RolePath:
Type: String
Description: Path for the IAM Role
AllowedPattern: (^\/$)|(^\/.*\/$)
Default: "/"
RolePermissionsBoundary:
Type: String
Description: Optional ARN of the permissions boundary policy (leave empty for none)
Default: ""
RoleSessionDuration:
Description: The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)
Type: Number
MinValue: 3600
MaxValue: 43200
Default: 7200
RoleManagedPolicy1:
Type: String
Description: Optional managed policy ARN 1
Default: ""
RoleManagedPolicy2:
Type: String
Description: Optional managed policy ARN 2
Default: ""
RoleManagedPolicy3:
Type: String
Description: Optional managed policy ARN 3
Default: ""
RoleManagedPolicy4:
Type: String
Description: Optional managed policy ARN 4
Default: ""
RoleManagedPolicy5:
Type: String
Description: Optional managed policy ARN 5
Default: ""
Conditions:
HasCustomProviderName: !Not [!Equals [!Ref IdentityProviderName, ""]]
HasCustomRoleName: !Not [!Equals [!Ref RoleName, ""]]
HasPermissionsBoundary: !Not [!Equals [!Ref RolePermissionsBoundary, ""]]
HasPolicy1: !Not [!Equals [!Ref RoleManagedPolicy1, ""]]
HasPolicy2: !Not [!Equals [!Ref RoleManagedPolicy2, ""]]
HasPolicy3: !Not [!Equals [!Ref RoleManagedPolicy3, ""]]
HasPolicy4: !Not [!Equals [!Ref RoleManagedPolicy4, ""]]
HasPolicy5: !Not [!Equals [!Ref RoleManagedPolicy5, ""]]
HasPrivateKey: !Not [!Equals [!Ref IdentityProviderAddPrivateKey, ""]]
HasAssertionEncryptionMode: !Not [!Equals [!Ref IdentityProviderAssertionEncryptionMode, ""]]
Resources:
SAMLProvider:
Type: AWS::IAM::SAMLProvider
Properties:
Name: !If
- HasCustomProviderName
- !Ref IdentityProviderName
- !Ref AWS::NoValue
SamlMetadataDocument: !Ref IdentityProviderSAMLMetadataDocument
AddPrivateKey: !If
- HasPrivateKey
- !Ref IdentityProviderAddPrivateKey
- !Ref AWS::NoValue
AssertionEncryptionMode: !If
- HasAssertionEncryptionMode
- !Ref IdentityProviderAssertionEncryptionMode
- !Ref AWS::NoValue
SAMLFederatedRole:
Type: AWS::IAM::Role
Properties:
RoleName: !If
- HasCustomRoleName
- !Ref RoleName
- !Ref AWS::NoValue
Path: !Ref RolePath
Description: "SAML federated IAM role for SSO access with specified permissions"
MaxSessionDuration: !Ref RoleSessionDuration
PermissionsBoundary: !If
- HasPermissionsBoundary
- !Ref RolePermissionsBoundary
- !Ref AWS::NoValue
AssumeRolePolicyDocument:
Version: '2012-10-17 '
Statement:
- Effect: Allow
Principal:
Federated: !Ref SAMLProvider
Action:
- 'sts:AssumeRole'
- 'sts:SetSourceIdentity'
- 'sts:TagSession'
Condition:
StringEquals:
'SAML:aud': 'https://signin.aws.amazon.com/saml'
ManagedPolicyArns: !Split
- ','
- !Join
- ','
- - !If [HasPolicy1, !Ref RoleManagedPolicy1, !Ref "AWS::NoValue"]
- !If [HasPolicy2, !Ref RoleManagedPolicy2, !Ref "AWS::NoValue"]
- !If [HasPolicy3, !Ref RoleManagedPolicy3, !Ref "AWS::NoValue"]
- !If [HasPolicy4, !Ref RoleManagedPolicy4, !Ref "AWS::NoValue"]
- !If [HasPolicy5, !Ref RoleManagedPolicy5, !Ref "AWS::NoValue"]
Outputs:
RoleARN:
Description: ARN of the created IAM Role
Value: !GetAtt SAMLFederatedRole.Arn
Export:
Name: !Sub '${AWS::StackName}-RoleARN'
IdentityProviderARN:
Description: ARN of the created SAML Identity Provider
Value: !Ref SAMLProvider
Export:
Name: !Sub '${AWS::StackName}-IdentityProviderARN'
```
------