# 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)」を参照してください。