

# AWS Well-Architected Tool のためのアイデンティティおよびアクセス管理
<a name="security-iam"></a>

AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御するために役立つ AWS のサービス です。IAM 管理者は、誰を*認証* (サインイン) し、誰に AWS WA Tool リソースの使用を*許可する* (権限を持たせる) かを制御します。IAM は、無料で使用できる AWS のサービスです。

**Topics**
+ [対象者](#security_iam_audience)
+ [アイデンティティによる認証](#security_iam_authentication)
+ [ポリシーを使用したアクセス権の管理](#security_iam_access-manage)
+ [AWS Well-Architected Tool と IAM の連携方法](security_iam_service-with-iam.md)
+ [AWS Well-Architected Tool アイデンティティベースポリシーの例](security_iam_id-based-policy-examples.md)
+ [AWS の マネージドポリシーAWS Well-Architected Tool](security-iam-awsmanpol.md)
+ [AWS Well-Architected Tool ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)

## 対象者
<a name="security_iam_audience"></a>

AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。
+ **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[AWS Well-Architected Tool ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。
+ **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[AWS Well-Architected Tool と IAM の連携方法](security_iam_service-with-iam.md)」を参照)
+ **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[AWS Well-Architected Tool アイデンティティベースポリシーの例](security_iam_id-based-policy-examples.md)」を参照)

## アイデンティティによる認証
<a name="security_iam_authentication"></a>

認証とは、アイデンティティ認証情報を使用して AWS にサインインする方法です。ユーザーは、IAM ユーザー の AWS アカウントのルートユーザー として、または IAM ロールを引き受けることによって、認証される 必要があります。

AWS IAM アイデンティティセンター (IAM アイデンティティセンター)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーテッドアイデンティティとしてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。

プログラムによるアクセスの場合、AWS はリクエストに暗号で署名するための SDK と CLI を提供します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対する AWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。

### AWS アカウント のルートユーザー
<a name="security_iam_authentication-rootuser"></a>

 AWS アカウントを作成すると、すべての AWS のサービスとリソースに対する完全なアクセス権を持つ AWS アカウント *ルートユーザー*と呼ばれる 1 つのサインイン ID を使用して開始します。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。

### フェデレーテッドアイデンティティ
<a name="security_iam_authentication-federated"></a>

ベストプラクティスでは、人間のユーザーが一時的な認証情報を使用して AWS のサービス にアクセスする際、アイデンティティプロバイダーとのフェデレーションを使用することが求められます。

*フェデレーテッドアイデンティティ*は、エンタープライズディレクトリ、ウェブ ID プロバイダー、Directory Service のユーザーであり、ID ソースからの認証情報を使用して AWS のサービス にアクセスするユーザーです。フェデレーテッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。

アクセスを一元管理する場合は、AWS IAM アイデンティティセンター をお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[IAM アイデンティティセンターとは](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。

### IAM ユーザーとグループ
<a name="security_iam_authentication-iamuser"></a>

*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするには ID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。

[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。

### IAM ロール
<a name="security_iam_authentication-iamrole"></a>

*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。[ユーザーから IAM ロール (コンソール) に切り替える](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)、または AWS CLI や AWS API オペレーションを呼び出すことで、ロールを引き受けることができます。詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。

IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、*IAM ユーザーガイド* の [IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。

## ポリシーを使用したアクセス権の管理
<a name="security_iam_access-manage"></a>

AWS でアクセスを制御するには、ポリシーを作成して AWS ID またはリソースにアタッチします。ポリシーは、アイデンティティやリソースとの関連付けに伴うアクセス許可を定義します。AWS は、プリンシパルがリクエストを行うときに、これらのポリシーを評価します。大半のポリシーは JSON ドキュメントとして AWS に保存されます。JSON ポリシードキュメントの詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。

管理者は、ポリシーを使用して、どの**プリンシパル**がどの**リソース**に対して、どのような**条件**で**アクション**を実行できるかを定義することで、誰が何にアクセスできるかを指定します。

デフォルトでは、ユーザーやロールにアクセス許可はありません。IAM 管理者は IAM ポリシーを作成してロールに追加し、このロールをユーザーが引き受けられるようにします。IAM ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。

### アイデンティティベースのポリシー
<a name="security_iam_access-manage-id-based-policies"></a>

アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティがどのリソースに対してどのような条件下でどのようなアクションを実行できるかを制御します。アイデンティティベースポリシーの作成方法については、*IAM ユーザーガイド* の [カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) を参照してください。

アイデンティティベースのポリシーは、*インラインポリシー* (単一の ID に直接埋め込む) または*管理ポリシー* (複数の ID にアタッチされたスタンドアロンポリシー) にすることができます。管理ポリシーとインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。

### リソースベースのポリシー
<a name="security_iam_access-manage-resource-based-policies"></a>

リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。例としては、IAM *ロール信頼ポリシー*や Amazon S3 *バケットポリシー*などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。リソースベースのポリシーでは、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。

リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーで IAM の AWS マネージドポリシーを使用することはできません。

### その他のポリシータイプ
<a name="security_iam_access-manage-other-policies"></a>

AWS は、より一般的なポリシータイプで付与された最大数のアクセス許可を設定できる、追加のポリシータイプをサポートしています。
+ **アクセス許可の境界** – アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の数の上限を設定します。詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** - AWS Organizations 内の組織または組織単位の最大のアクセス許可を指定します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+ **リソースコントロールポリシー (RCP)** – は、アカウント内のリソースで利用できる最大数のアクセス許可を定義します。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。
+ **セッションポリシー** – ロールまたはフェデレーションユーザーの一時セッションを作成する際にパラメータとして渡される高度なポリシーです。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。

### 複数のポリシータイプ
<a name="security_iam_access-manage-multiple-policies"></a>

1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWS が決定する方法の詳細については、「*IAM ユーザーガイド*」の「[ポリシーの評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。

# AWS Well-Architected Tool と IAM の連携方法
<a name="security_iam_service-with-iam"></a>

IAM を使用して AWS WA Tool へのアクセスを管理する前に、AWS WA Tool で利用できる IAM の機能について学びます。


**AWS Well-Architected Tool で使用できる IAM の機能**  

| IAM 機能 | AWS WA Tool のサポート | 
| --- | --- | 
|  [アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies)  |   あり  | 
|  [リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies)  |   なし   | 
|  [ポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions)  |   あり  | 
|  [ポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources)  |   はい  | 
|  [ポリシー条件キー (サービス固有)](#security_iam_service-with-iam-id-based-policies-conditionkeys)  |   はい  | 
|  [ACL](#security_iam_service-with-iam-acls)  |   なし   | 
|  [ABAC (ポリシー内のタグ)](#security_iam_service-with-iam-tags)  |   あり  | 
|  [一時的な認証情報](#security_iam_service-with-iam-roles-tempcreds)  |   あり  | 
|  [プリンシパルアクセス権限](#security_iam_service-with-iam-principal-permissions)  |   あり  | 
|  [サービスロール](#security_iam_service-with-iam-roles-service)  |   いいえ   | 
|  [サービスリンクロール](#security_iam_service-with-iam-roles-service-linked)  |   いいえ   | 

AWS WA Tool およびその他 AWS のサービスがほとんどの IAM 機能と連携する方法の概要を把握するには、「**IAM ユーザーガイド」の「[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。

## AWS WA Tool アイデンティティベースのポリシー
<a name="security_iam_service-with-iam-id-based-policies"></a>

**ポリシーアクションのサポート:** あり

管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどのような**リソース**にどのような**条件**で**アクション**を実行できるかということです。

JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。

## AWS WA Tool 内のリソースベースのポリシー
<a name="security_iam_service-with-iam-resource-based-policies"></a>

**リソースベースのポリシーのサポート:** なし 

リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーションユーザー、または AWS のサービス を含めることができます。

クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。詳細については、IAM ユーザーガイド**の[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)を参照してください。

## AWS WA Tool のポリシーアクション
<a name="security_iam_service-with-iam-id-based-policies-actions"></a>

**ポリシーアクションのサポート:** あり

管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどのような**リソース**にどのような**条件**で**アクション**を実行できるかということです。

JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは、関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。

AWS WA Tool のポリシーアクションは、アクションの前に次のプレフィックスを使用します: `wellarchitected:`。たとえば、エンティティがワークロードを定義できるようにするには、管理者は `wellarchitected:CreateWorkload` アクションを許可するポリシーをアタッチする必要があります。同様に、エンティティによるワークロードの削除を防止するため、管理者は `wellarchitected:DeleteWorkload` アクションを拒否するポリシーをアタッチできます。ポリシーステートメントには、`Action` 要素または `NotAction` 要素のいずれかを含める必要があります。AWS WA Tool は、このサービスで実行できるタスクを説明する独自の一連のアクションを定義します。

AWS WA Tool アクションのリストを確認するには、「**サービス認可リファレンス」の「[AWS Well-Architected Tool で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswell-architectedtool.html#awswell-architectedtool-actions-as-permissions)」を参照してください。

## ポリシーリソース
<a name="security_iam_service-with-iam-id-based-policies-resources"></a>

**ポリシーリソースのサポート:** あり

管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。

`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルの権限をサポートしないアクションの場合は、ワイルドカード (\$1) を使用してステートメントがすべてのリソースに適用されることを示します。

```
"Resource": "*"
```

AWS WA Tool リソースのタイプとその ARN のリストを確認するには、「**サービス認可リファレンス」の「[AWS Well-Architected Tool で定義されるリソース](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswell-architectedtool.html#your_service-resources-for-iam-policies)」を参照してください。どのアクションで各リソースの ARN を指定できるかについては、「[AWS Well-Architected Tool で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswell-architectedtool.html#your_service-actions-as-permissions)」を参照してください。

AWS WA Tool ワークロードリソースには、次の ARN があります。

```
arn:${Partition}:wellarchitected:${Region}:${Account}:workload/${ResourceId} 
```

ARN の形式の詳細については、「[Amazon リソースネーム (ARN) と AWS サービスの名前空間](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)」を参照してください。

ARN は、ワークロードの [**ワークロードのプロパティ**] ページにあります。たとえば、特定のワークロードを指定するには、次のようにします。

```
"Resource": "arn:aws:wellarchitected:us-west-2:123456789012:workload/11112222333344445555666677778888" 
```

特定のアカウントに属するすべてのワークロードを指定するには、ワイルドカード (\$1) を使用します。

```
"Resource": "arn:aws:wellarchitected:us-west-2:123456789012:workload/*" 
```

ワークロードの作成とリスト化など、一部の AWS WA Tool アクションは、特定のリソースで実行できません。このような場合はワイルドカード \$1を使用する必要があります。

```
"Resource": "*"
```

AWS WA Tool リソースのタイプとその ARN のリストを確認するには、*サービス認可リファレンス*の [AWS Well-Architected Tool で定義されるリソース](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswell-architectedtool.html#awswell-architectedtool-resources-for-iam-policies)を参照してください。どのアクションで各リソースの ARN を指定できるかについては、「[AWS Well-Architected Tool で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswell-architectedtool.html#awswell-architectedtool-actions-as-permissions)」を参照してください。

## AWS WA Tool 向けのポリシー条件キー
<a name="security_iam_service-with-iam-id-based-policies-conditionkeys"></a>

**サービス固有のポリシー条件キーのサポート:** あり

管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどんな**リソース**にどんな**条件**で**アクション**を実行できるかということです。

`Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を参照してください。

AWS WA Tool はサービス固有の条件キーを 1 つ提供し (`wellarchitected:JiraProjectKey`)、いくつかのグローバル条件キーの使用をサポートします。すべての AWS グローバル条件キーを確認するには、「*サービス認可リファレンス*」の「[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。

管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどんな**リソース**にどんな**条件**で**アクション**を実行できるかということです。

`Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を参照してください。

## AWS WA Tool の ACL
<a name="security_iam_service-with-iam-acls"></a>

**ACL のサポート:** なし 

アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。

## AWS WA Tool タグに基づく認可
<a name="security_iam_service-with-iam-tags"></a>

**ABAC (ポリシー内のタグ) のサポート:** あり

属性ベースのアクセス制御 (ABAC) は、タグと呼ばれる属性に基づいてアクセス許可を定義する認可戦略です。IAM エンティティと AWS リソースにタグを付けることで、プリンシパルのタグがリソースタグと一致するときに操作を許可する ABAC ポリシーを設計できます。

タグに基づいてアクセスを管理するには、`aws:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。

サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値は**あり**です。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「**部分的**」になります。

ABAC の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可でアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。ABAC をセットアップする手順を説明するチュートリアルについては、「*IAM ユーザーガイド*」の「[属性ベースのアクセスコントロール (ABAC) を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)」を参照してください。

## AWS WA Tool での一時的な認証情報の使用
<a name="security_iam_service-with-iam-roles-tempcreds"></a>

**一時的な認証情報のサポート:** あり

一時的な認証情報は、AWSリソースへの短期的なアクセスを提供し、フェデレーションの使用時またはロールの切り替え時に自動的に作成されます。AWS では、長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成することをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[IAM の一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)」および「[AWS のサービス と IAM との連携](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。

## AWS WA Tool のクロスサービスプリンシパル権限
<a name="security_iam_service-with-iam-principal-permissions"></a>

**転送アクセスセッション (FAS) のサポート:** あり

 転送アクセスセッション (FAS) は、AWS のサービス を呼び出すプリンシパルのアクセス許可を AWS のサービス のリクエストと合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。

## AWS WA Tool のサービスロール
<a name="security_iam_service-with-iam-roles-service"></a>

**サービスロールのサポート:** なし 

 サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、「*IAM ユーザーガイド*」の「[AWS のサービス に許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。

## AWS WA Tool のサービスにリンクされたロール
<a name="security_iam_service-with-iam-roles-service-linked"></a>

**サービスにリンクされたロールのサポート:** なし 

 サービスにリンクされたロールは、AWS のサービス にリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。

サービスにリンクされたロールの作成または管理の詳細については、「[IAM と提携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。表の「**サービスリンクロール**」列に `Yes` と記載されたサービスを見つけます。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、**[はい]** リンクを選択します。

# AWS Well-Architected Tool アイデンティティベースポリシーの例
<a name="security_iam_id-based-policy-examples"></a>

デフォルトでは、ユーザーおよびロールには、AWS WA Tool リソースを作成または変更するアクセス許可はありません。AWS マネジメントコンソール、AWS CLI、または AWS API を使用してタスクを実行することもできません。IAM 管理者は、ユーザーとロールに必要な、指定されたリソースで特定の API オペレーションを実行する権限をユーザーとロールに付与する IAM ポリシーを作成する必要があります。続いて、管理者はそれらのアクセス許可が必要なユーザーまたはグループにそのポリシーをアタッチします。

JSON ポリシードキュメントのこれらの例を使用して、IAM アイデンティティベースのポリシーを作成する方法については、「**IAM ユーザーガイド」の「[JSON タブでのポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)」を参照してください。

**Topics**
+ [ポリシーのベストプラクティス](#security_iam_service-with-iam-policy-best-practices)
+ [AWS WA Tool コンソールを使用する](#security_iam_id-based-policy-examples-console)
+ [ユーザーが自分の許可を表示できるようにする](#security_iam_id-based-policy-examples-view-own-permissions)
+ [ワークロードへのフルアクセスの付与](#security_iam_id-based-policy-examples-full-access)
+ [ワークロードへの読み取り専用アクセスの付与](#security_iam_id-based-policy-examples-readonly-access)
+ [1 つのワークロードへのアクセス](#security_iam_id-based-policy-examples-access-one-workload)
+ [AWS Well-Architected Tool Connector for Jira のサービス固有の条件キーの使用](#security_iam_id-based-policy-examples-service-specific-condition-key)

## ポリシーのベストプラクティス
<a name="security_iam_service-with-iam-policy-best-practices"></a>

ID ベースのポリシーは、ユーザーのアカウントで誰かが AWS WA Tool リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションを実行すると、AWS アカウント に料金が発生する可能性があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ **AWS マネージドポリシーの使用を開始し、最小特権のアクセス許可に移行する** – ユーザーとワークロードへのアクセス許可の付与を開始するには、多くの一般的なユースケースのためにアクセス許可を付与する *AWS マネージドポリシー*を使用します。これらは AWS アカウントで使用できます。ユースケースに固有の AWS カスタマー管理ポリシーを定義して、アクセス許可を絞り込むことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能の AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、*最小特権アクセス許可*とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。また、CloudFormation などの特定の AWS のサービス を介して使用する場合、条件を使用してサービスアクションへのアクセスを許可することもできます。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – AWS アカウントで IAM ユーザーまたはルートユーザーを要求するシナリオがある場合は、セキュリティを強化するために MFA をオンにします。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。

IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。

## AWS WA Tool コンソールを使用する
<a name="security_iam_id-based-policy-examples-console"></a>

AWS Well-Architected Tool コンソールにアクセスするには、一連の最小限のアクセス許可が必要です。これらのアクセス許可により、AWS アカウント の AWS WA Tool リソースの詳細をリストおよび表示できます。最小限の必要なアクセス許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) に対してコンソールが意図したとおりに機能しなくなります。

これらのエンティティが AWS WA Tool コンソールを使用できるように、エンティティに次の AWS 管理ポリシーもアタッチします。

```
WellArchitectedConsoleReadOnlyAccess
```

ワークロードを作成、変更、および削除するためには、次の AWS 管理ポリシーをエンティティにアタッチします。

```
WellArchitectedConsoleFullAccess
```

詳細については、「**IAM ユーザーガイド」の「[ユーザーへのアクセス許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。

AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。

## ユーザーが自分の許可を表示できるようにする
<a name="security_iam_id-based-policy-examples-view-own-permissions"></a>

この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI か AWS API を使用してプログラム的に、このアクションを完了するアクセス許可が含まれています。

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}
```

## ワークロードへのフルアクセスの付与
<a name="security_iam_id-based-policy-examples-full-access"></a>

この例では、ユーザーにワークロードへの AWS アカウント のフルアクセスを許可します。フルアクセスにより、ユーザーは AWS WA Tool ですべてのアクションを実行できます。このアクセスは、ワークロードの定義、ワークロードの削除、ワークロードの表示、ワークロードの更新に必要です。

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement" : [  
     {
     "Effect" : "Allow",
     "Action" : [
          "wellarchitected:*"
     ],
     "Resource": "*"
     }
   ]
}
```

------

## ワークロードへの読み取り専用アクセスの付与
<a name="security_iam_id-based-policy-examples-readonly-access"></a>

この例では、ユーザーにワークロードへの AWS アカウント の読み取り専用アクセスを許可します。読み取り専用アクセスでは、ユーザーは AWS WA Tool のワークロードを表示できるのみです。

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement" : [  
     {
     "Effect" : "Allow",
     "Action" : [
          "wellarchitected:Get*",
          "wellarchitected:List*"
     ],
     "Resource": "*"
     }
   ]
}
```

------

## 1 つのワークロードへのアクセス
<a name="security_iam_id-based-policy-examples-access-one-workload"></a>

この例では、ユーザーに、`us-west-2` リージョン内の 1 つのワークロードである `99999999999955555555555566666666` への AWS アカウント の読み取り専用アクセス許可を付与します。お客様の アカウント ID は です`777788889999`

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement" : [  
     {
     "Effect" : "Allow",
     "Action" : [
          "wellarchitected:Get*",
          "wellarchitected:List*"
     ],
     "Resource": "arn:aws:wellarchitected:us-west-2:777788889999:workload/999999999999555555555555666666666"
     }
   ]
}
```

------

## AWS Well-Architected Tool Connector for Jira のサービス固有の条件キーの使用
<a name="security_iam_id-based-policy-examples-service-specific-condition-key"></a>

 この例では、サービス固有の条件キー `wellarchitected:JiraProjectKey` を使用して、アカウント内のワークロードにリンクできる Jira プロジェクトを制御する方法を示します。

 ここでは、条件キーが次のように使用されます。
+  **`CreateWorkload:`** `wellarchitected:JiraProjectKey` を `CreateWorkload` に適用すると、ユーザーが作成したワークロードにリンクできるカスタム Jira プロジェクトを定義できます。例えば、ユーザーがプロジェクト ABC で新しいワークロードを作成しようとしても、ポリシーでプロジェクト PQR のみが指定されていると、アクションは拒否されます。
+  **`UpdateWorkload:`** `wellarchitected:JiraProjectKey` を `UpdateWorkload` に適用すると、この特定のワークロードまたは任意のワークロードにリンクできるカスタム Jira プロジェクトを定義できます。例えば、ユーザーがプロジェクト ABC で既存のワークロードを更新しようとしても、ポリシーでプロジェクト PQR が指定されていると、アクションは拒否されます。さらに、プロジェクト PQR にリンクされたワークロードがあり、そのワークロードを更新してプロジェクト ABC にリンクしようとした場合も、アクションは拒否されます。
+  **`UpdateGlobalSettings:`** `wellarchitected:JiraProjectKey` を `UpdateGlobalSettings` に適用すると、AWS アカウントにリンクできるカスタム Jira プロジェクトを定義できます。アカウントレベルの設定は、アカウント内の、アカウントレベルの Jira 設定を上書きしないワークロードを保護します。例えば、ユーザーが `UpdateGlobalSettings` にアクセスした場合、ポリシーで指定されていないプロジェクトにアカウント内のワークロードをリンクすることはできません。

------
#### [ JSON ]

****  

```
{
	"Version":"2012-10-17",		 	 	 
	"Statement": [
		{
			"Sid": "VisualEditor0",
			"Effect": "Allow",
			"Action": [
				"wellarchitected:UpdateGlobalSettings",
				"wellarchitected:CreateWorkload"
			],
			"Resource": "*",
			"Condition": {
				"StringEqualsIfExists": {
					"wellarchitected:JiraProjectKey": ["ABC, PQR"]
				}
			}
		},
		{
			"Sid": "VisualEditor1",
			"Effect": "Allow",
			"Action": [
				"wellarchitected:UpdateWorkload"
			],
			"Resource": "arn:aws:wellarchitected:us-east-1:111122223333:workload/example-workload",
			"Condition": {
				"StringEqualsIfExists": {
					"wellarchitected:JiraProjectKey": ["ABC, PQR"]
				}
			}
		}
	]
}
```

------

# AWS の マネージドポリシーAWS Well-Architected Tool
<a name="security-iam-awsmanpol"></a>

AWS マネージドポリシーは、AWS が作成および管理するスタンドアロンポリシーです。AWS マネージドポリシーは、多くの一般的なユースケースに対してアクセス許可を提供するように設計されているため、ユーザー、グループ、ロールへのアクセス許可の割り当てを開始できます。

AWS マネージドポリシーは、ご利用の特定のユースケースに対して最小特権のアクセス許可を付与しない場合があることにご注意ください。これは、すべての AWS ユーザーが使用できるようになるのを避けるためです。ユースケースに固有の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義して、アクセス許可を絞り込むことをお勧めします。

AWS マネージドポリシーで定義されたアクセス許可は変更できません。AWS が AWS マネージドポリシーに定義されているアクセス許可を更新すると、更新はポリシーがアタッチされているすべてのプリンシパルアイデンティティ (ユーザー、グループ、ロール) に影響します。新しい AWS のサービス を起動するか、既存のサービスで新しい API オペレーションが使用可能になると、AWS が AWS マネージドポリシーを更新する可能性が最も高くなります。

詳細については、「*IAM ユーザーガイド*」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。

## AWS マネージドポリシー: WellArchitectedConsoleFullAccess
<a name="security-iam-awsmanpol-WellArchitectedConsoleFullAccess"></a>

`WellArchitectedConsoleFullAccess` ポリシーを IAM IDにアタッチできます。

このポリシーは、AWS Well-Architected Tool へのフルアクセスを許可します。

**アクセス許可の詳細**

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement" : [  
     {
     "Effect" : "Allow",
     "Action" : [
          "wellarchitected:*"
     ],
     "Resource": "*"
     }
   ]
}
```

------

## AWS マネージドポリシー: WellArchitectedConsoleReadOnlyAccess
<a name="security-iam-awsmanpol-WellArchitectedConsoleReadOnlyAccess"></a>

`WellArchitectedConsoleReadOnlyAccess` ポリシーを IAM IDにアタッチできます。

このポリシーは、AWS Well-Architected Tool に読み取り専用アクセスを許可します。

**アクセス許可の詳細**

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "wellarchitected:Get*",
                "wellarchitected:List*",
                "wellarchitected:ExportLens"
            ],
            "Resource": "*"
        }
    ]
}
```

------

## AWS マネージドポリシー: AWSWellArchitectedOrganizationsServiceRolePolicy
<a name="security-iam-awsmanpol-AWSWellArchitectedOrganizationsServiceRolePolicy"></a>

`AWSWellArchitectedOrganizationsServiceRolePolicy` ポリシーを IAM IDにアタッチできます。

このポリシーは、AWS Organizations の管理者アクセス許可を付与します。このアクセス許可は AWS Well-Architected Tool と組織の統合をサポートするために必要です。これらのアクセス許可により、組織管理アカウントは AWS WA Tool にリソースを共有できるようになります。

**アクセス許可の詳細**

このポリシーには、以下のアクセス許可が含まれています。
+ `organizations:ListAWSServiceAccessForOrganization` — AWS サービスアクセスを AWS WA Tool に対して有効化できるかを確認をプリンシパルに許可します。
+ `organizations:DescribeAccount` - 組織内のアカウントに関する情報の取得をプリンシパルに許可します。
+ `organizations:DescribeOrganization` - 組織設定に関する情報の取得を、プリンシパルに許可します。
+ `organizations:ListAccounts` - 組織に属するアカウントリストの取得を、プリンシパルに許可します。
+ `organizations:ListAccountsForParent` - 組織に属するアカウントのリストを組織の指定ルートノードから取得することをプリンシパルに許可します。
+ `organizations:ListChildren` - 組織に属するアカウントのリストの組織部門を組織の指定ルートノードから取得することをプリンシパルに許可します。
+ `organizations:ListParents` - 組織内の OU またはアカウントで指定された直属の親リストの取得をプリンシパルに許可します。
+ `organizations:ListRoots` - 組織内のすべてのルートノードの一覧の取得をプリンシパルに許可します。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "organizations:ListAWSServiceAccessForOrganization",
                "organizations:DescribeAccount",
                "organizations:DescribeOrganization",
                "organizations:ListAccounts",
                "organizations:ListAccountsForParent",
                "organizations:ListChildren",
                "organizations:ListParents",
                "organizations:ListRoots"
            ],
            "Resource": "*"
        }
    ]
}
```

------

## AWS マネージドポリシー: AWSWellArchitectedDiscoveryServiceRolePolicy
<a name="security-iam-awsmanpol-AWSWellArchitectedDiscoveryServiceRolePolicy"></a>

`AWSWellArchitectedDiscoveryServiceRolePolicy` ポリシーを IAM IDにアタッチできます。

このポリシーにより、AWS Well-Architected Tool は、AWS サービスおよび AWS WA Tool リソースに関連するリソースにアクセスできるようになります。

**アクセス許可の詳細**

このポリシーには、以下のアクセス許可が含まれています。
+ `trustedadvisor:DescribeChecks` — 利用可能な Trusted Advisor チェックを一覧表示します。
+ `trustedadvisor:DescribeCheckItems` — Trusted Advisor がフラグを付けたステータスおよびリソースを含む Trusted Advisor チェックデータをフェッチします。
+ `servicecatalog:GetApplication` — AppRegistry アプリケーションの詳細をフェッチします。
+ `servicecatalog:ListAssociatedResources` — AppRegistry アプリケーションに関連するリソースを一覧表示します。
+ `cloudformation:DescribeStacks` — CloudFormation スタックの詳細を取得します。
+ `cloudformation:ListStackResources` — CloudFormation スタックに関連するリソースを一覧表示します。
+ `resource-groups:ListGroupResources` — ResourceGroup のリソースを一覧表示します。
+ `tag:GetResources` — ListGroupResources には必須。
+ `servicecatalog:CreateAttributeGroup` — 必要に応じてサービス管理属性グループを作成します。
+ `servicecatalog:AssociateAttributeGroup` — サービス管理属性グループを AppRegistry アプリケーションに関連付けます。
+ `servicecatalog:UpdateAttributeGroup` — サービス管理属性グループを更新します。
+ `servicecatalog:DisassociateAttributeGroup` — AppRegistry アプリケーションからサービス管理属性グループの関連性を解除します。
+ `servicecatalog:DeleteAttributeGroup` — 必要に応じてサービス管理属性グループを削除します。

------
#### [ JSON ]

****  

```
{
	"Version":"2012-10-17",		 	 	 
	"Statement": [
		{
			"Effect": "Allow",
			"Action": [
				"trustedadvisor:DescribeChecks",
				"trustedadvisor:DescribeCheckItems"
			],
			"Resource": [
				"*"
			]
		},
		{
			"Effect": "Allow",
			"Action": [
				"cloudformation:DescribeStacks",
				"cloudformation:ListStackResources",
				"resource-groups:ListGroupResources",
				"tag:GetResources"
			],
			"Resource": [
				"*"
			]
		},
		{
			"Effect": "Allow",
			"Action": [
				"servicecatalog:ListAssociatedResources",
				"servicecatalog:GetApplication",
				"servicecatalog:CreateAttributeGroup"
			],
			"Resource": [
				"*"
			]
		},
		{
			"Effect": "Allow",
			"Action": [
				"servicecatalog:AssociateAttributeGroup",
				"servicecatalog:DisassociateAttributeGroup"
			],
			"Resource": [
				"arn:*:servicecatalog:*:*:/applications/*",
				"arn:*:servicecatalog:*:*:/attribute-groups/AWS_WellArchitected-*"
			]
		},
		{
			"Effect": "Allow",
			"Action": [
				"servicecatalog:UpdateAttributeGroup",
				"servicecatalog:DeleteAttributeGroup"
			],
			"Resource": [
				"arn:*:servicecatalog:*:*:/attribute-groups/AWS_WellArchitected-*"
			]
		}
	]
}
```

------

## AWS WA Tool による AWS マネージドポリシーの更新
<a name="security-iam-awsmanpol-updates"></a>

このサービスがこれらの変更の追跡を開始してからの、AWS WA Tool の AWS マネージドポリシーの更新に関する詳細を表示します。このページの変更に関する自動通知については、[AWS WA Tool [ドキュメント履歴](document-revisions.md)] ページの RSS フィードをサブスクライブします。


| 変更 | 説明 | 日付 | 
| --- | --- | --- | 
| AWS WA Tool マネージドポリシーの変更 | `"wellarchitected:Export*"` が ` WellArchitectedConsoleReadOnlyAccess` に追加されました。 | 2023 年 6 月 22 日 | 
|  AWS WA Tool が追加したサービスロールポリシー  |  `AWSWellArchitectedDiscoveryServiceRolePolicy` を追加すると、AWS Well-Architected Tool が AWS サービスおよび AWS WA Tool リソースに関連するリソースにアクセスできるようになります。  | 2023 年 5 月 3 日 | 
|  AWS WA Tool が追加したアクセス許可  |  AWS サービスアクセスが AWS WA Tool に対して有効になっているかどうかを AWS WA Tool が確認できるよう `ListAWSServiceAccessForOrganization` に許可する新しいアクションを追加しました。  | 2022 年 7 月 22 日 | 
|  AWS WA Tool は変更の追跡を開始しました  |  AWS WA Tool が AWS マネージドポリシーの変更の追跡を開始しました。  | 2022 年 7 月 22 日 | 

# AWS Well-Architected Tool ID とアクセスのトラブルシューティング
<a name="security_iam_troubleshoot"></a>

次の情報は、AWS WA Tool と IAM の使用に伴って発生する可能性がある一般的な問題の診断や修正に役立ちます。

**Topics**
+ [でアクションを実行する権限がありませんAWS WA Tool](#security_iam_troubleshoot-no-permissions)

## でアクションを実行する権限がありませんAWS WA Tool
<a name="security_iam_troubleshoot-no-permissions"></a>

AWS マネジメントコンソール から、アクションを実行する権限がないと通知された場合は、管理者に問い合わせてサポートを依頼する必要があります。管理者とは、サインイン認証情報を提供した担当者です。

以下の例のエラーは、*mateojackson* ユーザーがコンソールを使用して、`DeleteWorkload` アクションを実行しようとしたが、アクセス許可がない場合に発生します。

```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: wellarchitected:DeleteWorkload on resource: 11112222333344445555666677778888
```

この例の場合は、`wellarchitected:DeleteWorkload` アクションを使用して `11112222333344445555666677778888` リソースへのアクセスを許可するように、管理者にポリシーを更新してもらいます。