

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# タグエディタ のセキュリティ
<a name="security"></a>

でのクラウドセキュリティが最優先事項 AWS です。 AWS のお客様は、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャからメリットを得られます。

セキュリティは、 AWS とお客様の間で共有される責任です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、この責任がクラウド*の*セキュリティおよびクラウド*内*のセキュリティとして説明されています。
+ **クラウドのセキュリティ** – AWS は、 AWS のサービス で実行されるインフラストラクチャを保護する責任があります AWS クラウド。 AWS また、 は、お客様が安全に使用できるサービスも提供します。[「AWS 」 コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティーの監査が定期的にセキュリティの有効性をテストおよび検証しています。タグエディタ に適用されるコンプライアンスプログラムの詳細については、「[AWS コンプライアンスプログラムによる対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウド内のセキュリティ** – お客様の責任は AWS のサービス 、使用する によって決まります。また、ユーザーは、データの機密性、会社の要件、適用される法律や規制など、その他の要因についても責任を負います。

このドキュメントは、タグエディタ を使用する際に責任共有モデルを適用する方法を理解するのに役立ちます。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成するように タグエディタ を設定する方法について説明します。

**Topics**
+ [タグエディタ でのデータ保護](security_data-protection.md)
+ [タグエディタ の Identity and Access Management](security-iam.md)
+ [タグエディタ でのログ記録とモニタリング](security_logging-monitoring.md)
+ [タグエディタ のコンプライアンス検証](security_compliance.md)
+ [タグエディタ における耐障害性](security_resilience.md)
+ [タグエディタ でのインフラストラクチャセキュリティ](security_infrastructure.md)

# タグエディタ でのデータ保護
<a name="security_data-protection"></a>

タグエディタ でのデータ保護には、 AWS [責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)が適用されます。このモデルで説明されているように、 AWS はすべての を実行するグローバルインフラストラクチャを保護する責任があります AWS クラウド。ユーザーは、このインフラストラクチャでホストされるコンテンツに対する管理を維持する責任があります。また、使用する「 AWS のサービス 」のセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、[データプライバシーに関するよくある質問](https://aws.amazon.com/compliance/data-privacy-faq/)を参照してください。欧州でのデータ保護の詳細については、*AWS セキュリティブログ*に投稿された [AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) のブログ記事を参照してください。

データ保護の目的で、認証情報を保護し AWS アカウント 、 AWS IAM アイデンティティセンター または AWS Identity and Access Management (IAM) を使用して個々のユーザーを設定することをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ で API とユーザーアクティビティのログ記録を設定します AWS CloudTrail。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「 *AWS CloudTrail ユーザーガイド*」の[CloudTrail 証跡の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)」を参照してください。
+  AWS 暗号化ソリューションと、その中のすべてのデフォルトのセキュリティコントロールを使用します AWS のサービス。
+ Amazon Macie などの高度な管理されたセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。
+ コマンドラインインターフェイスまたは API AWS を介して にアクセスするときに FIPS 140-3 検証済み暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。

お客様の E メールアドレスなどの極秘または機密情報を、タグ、または **[名前]** フィールドなどの自由形式のテキストフィールドに含めないことを強くお勧めします。これは、コンソール、API、または AWS CLI SDK を使用してタグエディタまたは他の AWS のサービス を使用する場合も同様です。 AWS SDKs タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。

## データ暗号化
<a name="protection-encryption"></a>

タグ情報は暗号化されません。タグには暗号化されていませんが、セキュリティ戦略の一部として使用される情報が含まれる場合があるため、リソースのタグにアクセスできるユーザーを管理することが重要です。タグを変更できるユーザーを管理することは特に重要です。なぜなら、そのようなアクセスは権限の昇格に利用される可能性があるからです。

### 保管中の暗号化
<a name="protection-encryption-rest"></a>

タグエディタ 固有のサービスまたはネットワークトラフィックを分離するその他の方法はありません。該当する場合は、 AWS 特定の分離を使用します。仮想プライベートクラウド (VPC) で タグエディタ API とコンソールを使用することで、プライバシーとインフラストラクチャのセキュリティを最大限に高めることができます。

### 転送中の暗号化
<a name="protection-encryption-transit"></a>

タグエディタ データは、転送中に暗号化され、サービスの内部データベースにバックアップされます。これはユーザーが設定できません。

### キー管理
<a name="protection-key-management"></a>

タグエディタは現在 と統合されておらず AWS Key Management Service 、 もサポートしていません AWS KMS keys。

## インターネットトラフィックのプライバシー
<a name="protection-privacy"></a>

タグエディタは、タグエディタユーザーと 間のすべての送信に HTTPS を使用します AWS。タグエディタ はTransport Layer Security (TLS) 1.3 を使用しますが、TLS 1.2 もサポートします。

# タグエディタ の Identity and Access Management
<a name="security-iam"></a>

AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、誰が認証(サインイン) され、タグエディタ リソースを使用する認可を受ける (許可がある) ことができるかを制御します。IAM は、追加料金なしで使用できる AWS のサービス です。

**Topics**
+ [オーディエンス](#security_iam_audience_taged)
+ [アイデンティティを使用した認証](#security_iam_authentication_taged)
+ [ポリシーを使用したアクセスの管理](#security_iam_access-manage-taged)
+ [IAM で タグエディタ を使用する方法](security_iam_service-with-iam.md)
+ [タグエディタ アイデンティティベースポリシーの例](security_iam_id-based-policy-examples.md)
+ [タグエディタ アイデンティティとアクセスのトラブルシューティング](security_iam_troubleshoot.md)

## オーディエンス
<a name="security_iam_audience_taged"></a>

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

## アイデンティティを使用した認証
<a name="security_iam_authentication_taged"></a>

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

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

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

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

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

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

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

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

*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。ユーザー[から IAM ロール (コンソール) に切り替えるか、 または API オペレーションを呼び出すことで、ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)を引き受けることができます。 AWS CLI AWS 詳細については、「*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-taged"></a>

でアクセスを制御する AWS には、ポリシーを作成し、ID AWS またはリソースにアタッチします。ポリシーは、アイデンティティまたはリソースに関連付けられたときにアクセス許可を定義します。 は、プリンシパルがリクエストを行うときにこれらのポリシー 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-taged"></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-taged"></a>

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

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

### アクセスコントロールリスト (ACL)
<a name="security_iam_access-manage-acl-taged"></a>

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

Amazon S3、および Amazon VPC は AWS WAF、ACLs。ACL の詳細については、*Amazon Simple Storage Service デベロッパーガイド* の [アクセスコントロールリスト (ACL) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) を参照してください。

### その他のポリシータイプ
<a name="security_iam_access-manage-other-policies-taged"></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-taged"></a>

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

# IAM で タグエディタ を使用する方法
<a name="security_iam_service-with-iam"></a>

タグエディタ へのアクセスを管理するために IAM を使用する前に、タグエディタ でどの IAM 機能が使用できるかを理解しておく必要があります。タグエディタやその他の が IAM と AWS のサービス 連携する方法の概要を把握するには、[AWS のサービス 「IAM ユーザーガイド」の「IAM と連携する ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。 **

**Topics**
+ [タグエディタ のアイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies-arg-te)
+ [リソースベースのポリシー](#security_iam_resource-based-policies)
+ [タグに基づく認可](#security_iam_tags)
+ [タグエディタの IAM ロール](#security_iam_roles)

## タグエディタ のアイデンティティベースのポリシー
<a name="security_iam_service-with-iam-id-based-policies-arg-te"></a>

IAM のアイデンティティベースのポリシーでは、アクションを許可または拒否する条件に加えて、許可または拒否するアクションとリソースを指定できます。タグエディタ は、特定のアクション、リソース、および条件キーをサポートしています。JSON ポリシーで使用するすべての要素については「*IAM ユーザーガイド*」の「[IAM JSON ポリシーエレメントのリファレンス](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。

### アクション
<a name="security_iam_service-with-iam-id-based-policies-actions-arg-te"></a>

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

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

タグエディタ のポリシーアクションは、アクションの前にプレフィックスを使用します: `tag:`。タグエディタのアクションはコンソールで完全に実行されますが、ログエントリにプレフィックス `tag` が付けられます。

たとえば、`tag:TagResources` API オペレーションを使用してリソースにタグ付けするアクセス許可を付与するには、ポリシーに `tag:TagResources` アクションを含めます。ポリシーステートメントには`Action` または `NotAction` 要素を含める必要があります。タグエディタ は、このサービスで実行できるタスクを記述する独自のアクションのセットを定義します。

単一のステートメントに複数のタグ付けアクションを指定するには、次のようにコンマで区切ります。

```
"Action": [
      "tag:action1",
      "tag:action2",
      "tag:action3"
```

ワイルドカード \$1を使用して複数のアクションを指定することができます。例えば、`Get` という単語で始まるすべてのアクションを指定するには、次のアクションを含めます。

```
"Action": "tag:Get*"
```

タグエディタのアクションのリストについては、*サービス認可リファレンス*の「[タグエディタのアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_tageditor.html)」を参照してください。

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

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

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

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

タグエディタ には独自のリソースはありません。代わりに、他の AWS のサービスが作成したリソースにアタッチされたメタデータ (タグ) を操作します。

### 条件キー
<a name="security_iam_id-based-policies-conditionkeys"></a>

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

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

タグエディタ は、サービス固有の条件キーを定義しません。

### 例
<a name="security_iam-id-based-policies-examples"></a>

タグエディタ のアイデンティティベースのポリシーの例を表示するには、「[タグエディタ アイデンティティベースポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。

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

タグエディタ は独自のリソースを定義しないため、リソースベースのポリシーはサポートされていません。

## タグに基づく認可
<a name="security_iam_tags"></a>

タグに基づく認可は、属性ベースのアクセス制御 (ABAC) と呼ばれるセキュリティ戦略の一部です。

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

リソースのタグに基づいてリソースへのアクセスを制限するためのアイデンティティベースポリシーの例を表示するには、「[タグに基づいたグループの表示](security_iam_id-based-policy-examples.md#security_iam_policy-examples-view-tags)」を参照してください。属性ベースのアクセスコントロール (ABAC) の詳細については、*IAM ユーザーガイド*の[「ABAC とは AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。

## タグエディタの IAM ロール
<a name="security_iam_roles"></a>

[IAM ロール](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles.html)は、特定のアクセス許可 AWS アカウント を持つ 内のエンティティです。タグエディタ にはサービスロールがないか、または使用しません。

### タグエディタ での一時的な認証情報の使用
<a name="security_iam_roles-tempcreds"></a>

タグエディタ では、一時的な認証情報を使用して、フェデレーションでサインインする、IAM ロールを引き受ける、またはクロスアカウントロールを引き受けることができます。一時的なセキュリティ認証情報を取得するには、 [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html)や などの AWS STS API オペレーションを呼び出します[https://docs.aws.amazon.com//STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_GetFederationToken.html)。

### サービスリンクロール
<a name="security_iam_roles-service-linked"></a>

[サービスにリンクされたロール](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)を使用すると AWS のサービス 、 は他の サービスのリソースにアクセスして、ユーザーに代わってアクションを実行できます。

タグエディタ にはサービスにリンクされたロールがないか、または使用しません。

### サービス役割
<a name="security_iam_roles-service"></a>

この機能により、ユーザーに代わってサービスが[サービスロール](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role)を引き受けることが許可されます。

タグエディタ にはサービスロールがないか、または使用しません。

# タグエディタ アイデンティティベースポリシーの例
<a name="security_iam_id-based-policy-examples"></a>

デフォルトでは、ロールやユーザーなどの IAM プリンシパルには、タグを作成または変更するアクセス許可はありません。また、、 AWS Command Line Interface (AWS CLI) AWS マネジメントコンソール、または AWS APIs を使用してタスクを実行することはできません。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_policy-best-practices)
+ [タグエディタ コンソールと リソースグループのタグ付け API を使用する](#security_iam_policy-examples-console)
+ [自分の権限の表示をユーザーに許可する](#security_iam_policy-examples-own-permissions)
+ [タグに基づいたグループの表示](#security_iam_policy-examples-view-tags)

## ポリシーに関するベストプラクティス
<a name="security_iam_policy-best-practices"></a>

アイデンティティベースポリシーは、ユーザーのアカウントで誰かが タグエディタ リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションでは、 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 を使用して送信するように指定できます。条件を使用して、サービスアクションが などの特定の を通じて使用されている場合に AWS のサービス、サービスアクションへのアクセスを許可することもできます CloudFormation。詳細については、*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) を要求する** – で IAM ユーザーまたはルートユーザーを必要とするシナリオがある場合は AWS アカウント、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) を参照してください。

## タグエディタ コンソールと リソースグループのタグ付け API を使用する
<a name="security_iam_policy-examples-console"></a>

タグエディタ コンソールおよび リソースグループのタグ付け API にアクセスするには、一連の最小限のアクセス許可が必要です。これらのアクセス許可により、 のリソースにアタッチされたタグの詳細を一覧表示および表示できます AWS アカウント。最小限必要な許可よりも制限されたアイデンティティベースのポリシーを作成すると、そのポリシーを持つ IAM プリンシパルに対しては、コンソールおよび API コマンドが意図したとおりに機能しません。

これらのプリンシパルがまだ タグエディタ を使用できるように、エンティティに次のポリシー (または次のポリシーに記載されているアクセス許可を含むポリシー) をアタッチします。詳細については、*IAM ユーザーガイド*」の「[ユーザーへの許可の追加](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。

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

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "tag:GetResources",
        "tag:TagResources",
        "tag:UntagResources",
        "tag:getTagKeys",
        "tag:getTagValues",
        "resource-explorer:List*"
      ],
      "Resource": "*"
    }
  ]
}
```

------

タグエディタ および リソースグループのタグ付け API へのアクセス権限を付与する方法については、 [タグエディタ を使用するためのアクセス許可を付与する](gettingstarted-prereqs-permissions.md#gettingstarted-prereqs-permissions-howto) を参照してください。

## 自分の権限の表示をユーザーに許可する
<a name="security_iam_policy-examples-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_policy-examples-view-tags"></a>

アイデンティティベースのポリシーの条件を使用して、タグに基づいて タグエディタ リソースへのアクセスをコントロールできます。この例では、リソースを表示できるポリシーを作成する方法、この場合はリソースグループについて表示します 。ただし、アクセス許可が付与されるのは、`project` グループタグが、呼び出し元のプリンシパルに付けられた `project` タグと同じ値を持つ場合のみです。

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

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "resource-groups:ListGroups",
            "Resource": "arn:aws:resource-groups:us-east-1:111122223333:group/group_name"
        },
        {
            "Effect": "Allow",
            "Action": "resource-groups:ListGroups",
            "Resource": "arn:aws:resource-groups:us-east-1:111122223333:group/group_name",
            "Condition": {
                "StringEquals": {"aws:ResourceTag/project": "${aws:PrincipalTag/project}"}
            }
        }
    ]
}
```

------

このポリシーをアカウントの ユーザーにアタッチできます。`project``alpha`タグキーとタグ値を持つユーザーがリソースグループを表示しようとした場合、そのグループにもタグを付ける必要があります`project=alpha`。それ以外の場合、ユーザーはアクセスを拒否されます。条件キー名では大文字と小文字が区別されないため、条件タグキー `project` は `Project` と `project` の両方に一致します。詳細については、*IAM ユーザーガイド*の[IAM JSON ポリシー要素: 条件](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_elements_condition.html)を参照してください。

# タグエディタ アイデンティティとアクセスのトラブルシューティング
<a name="security_iam_troubleshoot"></a>

次の情報は、タグエディタ と IAM の使用に伴って発生する可能性がある一般的な問題の診断や修復に役立ちます。

**Topics**
+ [タグエディタ でアクションを実行する権限がない](#security_iam_troubleshoot-permissions-taged)
+ [iam:PassRole を実行する権限がない](#security_troubleshoot-passrole)

## タグエディタ でアクションを実行する権限がない
<a name="security_iam_troubleshoot-permissions-taged"></a>

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

以下の例のエラーは、`mateojackson` ユーザーがコンソールを使用して、 リソースのタグを表示しようとしているが、 `tag:GetTagKeys` のアクセス許可がない場合に発生します。

```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: tag:GetTagKeys on resource: arn:aws:resource-groups::us-west-2:123456789012:resource-type/my-test-resource
```

この場合、Mateo は、`tag:GetTagKeys` アクションを使用して `my-test-resource` リソースにアクセスできるように、管理者にポリシーの更新を依頼します。

## iam:PassRole を実行する権限がない
<a name="security_troubleshoot-passrole"></a>

`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して タグエディタ にロールを渡すことができるようにする必要があります。

一部の AWS のサービス では、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、そのサービスに既存のロールを渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。

以下の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して タグエディタ でアクションを実行しようする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。

```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```

この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。

サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。

# タグエディタ でのログ記録とモニタリング
<a name="security_logging-monitoring"></a>

すべてのタグエディタアクションがログインされます AWS CloudTrail。

## CloudTrail による タグエディタ API コールのログ記録
<a name="logging-using-cloudtrail"></a>

タグエディタは、ユーザー AWS CloudTrail、ロール、または タグエディタの によって実行されたアクションを記録するサービスである と統合 AWS のサービス されています。CloudTrail は、タグエディタ のコンソールからの呼び出しや リソースグループのタグ付け API へのコード呼び出しを含む、タグエディタ のすべての API コールをイベントとしてキャプチャします。証跡を作成する場合、 タグエディタ のイベントなど、Amazon S3 バケットへの CloudTrail イベントの継続的な配信を有効にすることができます。追跡を設定しない場合でも、CloudTrail コンソールの **イベント履歴**で最新のイベントを表示できます。CloudTrail で収集された情報を使用して、 タグエディタ に対するリクエスト、リクエスト元の IP アドレス、リクエスト者、リクエスト日時などの詳細を確認できます。

CloudTrail の詳細については、「[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)」を参照してください。

### CloudTrail での タグエディタ 情報
<a name="resource-groups-info-in-cloudtrail"></a>

CloudTrail は、アカウントの作成 AWS アカウント 時に で有効になります。タグエディタまたはタグエディタコンソールでアクティビティが発生すると、そのアクティビティはイベント履歴の他の AWS のサービス イベントとともに CloudTrail イベントに記録されます。 ****で最近のイベントを表示、検索、ダウンロードできます AWS アカウント。詳細については、「[CloudTrail イベント履歴でのイベントの表示](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/view-cloudtrail-events.html)」を参照してください。

タグエディタのイベントなど AWS アカウント、 のイベントの継続的な記録については、証跡を作成します。証跡により、CloudTrail はログファイルを Amazon S3 バケットに配信できます。デフォルトでは、コンソールで証跡を作成するときに、証跡がすべての AWS リージョンに適用されます。証跡は、 AWS パーティション内のすべてのリージョンからのイベントをログに記録し、指定した Amazon S3 バケットにログファイルを配信します。さらに、CloudTrail ログで収集されたイベントデータをさらに分析して処理 AWS のサービス するように他の を設定できます。詳細については、以下のリソースを参照してください。
+ [の証跡の作成 AWS アカウント](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail がサポートされているサービスと統合](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html)
+ 「[CloudTrail の Amazon SNS 通知の設定](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/getting_notifications_top_level.html)」
+ [CloudTrail ログファイルを複数のリージョンから受け取る](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html)、[複数のアカウントから CloudTrail ログファイルを受け取る](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)

すべての タグエディタ のアクションは、 CloudTrail によりログに記録され、 「[タグエディタ API リファレンス](https://docs.aws.amazon.com//ARG/latest/APIReference/)」に文書化されます。コンソール内の タグエディタ のアクションは CloudTrail によりログに記録され、`tagging.amazonaws.com` を `eventSource` としたイベントとして表示されます。

各イベントまたはログエントリには、誰がリクエストを生成したかという情報が含まれます。同一性情報は次の判断に役立ちます。
+ リクエストが、ルートと IAM ユーザー認証情報のどちらを使用して送信されたか。
+ リクエストがロールまたはフェデレーションユーザーの一時的なセキュリティ認証情報を使用して行われたかどうか。
+ リクエストが、別の AWS のサービスによって送信されたかどうか。

詳細については、[CloudTrail `userIdentity` 要素](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html)を参照してください。

### タグエディタ のログファイルエントリの概要
<a name="understanding-service-name-entries"></a>

「トレイル」は、指定した Amazon S3 バケットにイベントをログファイルとして配信するように設定できます。CloudTrail のログファイルは、単一か複数のログエントリを含みます。イベントはあらゆるソースからの単一のリクエストを表し、リクエストされたアクション、アクションの日時、リクエストのパラメータなどの情報が含まれます。CloudTrail ログファイルは、公開 API コールの順序付けられたスタックトレースではないため、特定の順序では表示されません。

以下の例は、`TagResources` アクションを示す CloudTrail ログエントリです。

```
{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROAEXAMPLEEXAMPLE:botocore-session-1661372702",
        "arn": "arn:aws:sts::123456789012:assumed-role/cli-role/botocore-session-1661372702",
        "accountId": "123456789012",
        "accessKeyId": "AKIAIOSFODNN7EXAMPLE",
        "sessionContext": {
            "sessionIssuer": {
                "type": "Role",
                "principalId": "AROAEXAMPLEEXAMPLE",
                "arn": "arn:aws:iam::123456789012:role/cli-role",
                "accountId": "123456789012",
                "userName": "cli-role"
            },
            "webIdFederationData": {},
            "attributes": {
                "creationDate": "2022-08-24T20:25:03Z",
                "mfaAuthenticated": "false"
            }
        }
    },
    "eventTime": "2022-08-24T20:27:14Z",
    "eventSource": "tagging.amazonaws.com",
    "eventName": "TagResources",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "72.21.198.65",
    "userAgent": "aws-cli/2.7.14 Python/3.9.11 Windows/10 exe/AMD64 prompt/off command/resourcegroupstaggingapi.tag-resources",
    "requestParameters": {
        "resourceARNList": [
            "arn:aws:events:us-east-1:123456789012:rule/SecretsManagerMonitorRule"
        ],
        "tags": {
            "owner": "alice"
        }
    },
    "responseElements": {
        "failedResourcesMap": {}
    },
    "requestID": "8f9ea891-4125-460c-802f-26c11EXAMPLE",
    "eventID": "b2c9322a-aad7-424b-8f0b-423daEXAMPLE",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "123456789012",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.2",
        "cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
        "clientProvidedHostHeader": "tagging.us-east-1.amazonaws.com"
    }
}
```

# タグエディタ のコンプライアンス検証
<a name="security_compliance"></a>

 AWS のサービス が特定のコンプライアンスプログラムの範囲内にあるかどうかを確認するには、「コンプライアンス[AWS のサービス プログラムによるスコープ](https://aws.amazon.com/compliance/services-in-scope/)」の「コンプライアンス」を参照して、関心のあるコンプライアンスプログラムを選択します。一般的な情報については、[AWS 「コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。

を使用して、サードパーティーの監査レポートをダウンロードできます AWS Artifact。詳細については、[「Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。

を使用する際のお客様のコンプライアンス責任 AWS のサービス は、お客様のデータの機密性、貴社のコンプライアンス目的、適用される法律および規制によって決まります。を使用する際のコンプライアンス責任の詳細については AWS のサービス、[AWS 「 セキュリティドキュメント](https://docs.aws.amazon.com/security/)」を参照してください。

# タグエディタ における耐障害性
<a name="security_resilience"></a>

タグエディタ は、内部サービスリソースへの自動バックアップを実行します。これらのバックアップはユーザーが設定できません。バックアップは、保管時と転送中のいずれも暗号化されます。タグエディタ は Amazon DynamoDB に顧客データを保存します。

 AWS グローバルインフラストラクチャは、 AWS リージョン およびアベイラビリティーゾーンを中心に構築されています。 は、低レイテンシー、高スループット、および高度に冗長なネットワークで接続された、物理的に分離および分離された複数のアベイラビリティーゾーン AWS リージョン を提供します。アベイラビリティーゾーンでは、アベイラビリティーゾーン間で中断せずに、自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、およびスケーラビリティが優れています。

タグを誤って削除した場合は、[AWS サポート センター](https://console.aws.amazon.com/support/home#/)にお問い合わせください。

 AWS リージョン およびアベイラビリティーゾーンの詳細については、[AWS 「 グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。

# タグエディタ でのインフラストラクチャセキュリティ
<a name="security_infrastructure"></a>

タグエディタ には、サービスまたはネットワークトラフィックを分離するその他の方法はありません。該当する場合は、 AWS 特定の分離を使用します。仮想プライベートクラウド (VPC) で タグエディタ API とコンソールを使用することで、プライバシーとインフラストラクチャのセキュリティを最大限に高めることができます。

 AWS 公開された API コールを使用して、ネットワーク経由でタグエディタにアクセスします。クライアントは以下をサポートする必要があります。
+ トランスポート層セキュリティ (TLS) TSL 1.2 および TSL 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。

さらに、 ( AWS Identity and Access Management IAM) プリンシパルに関連付けられたアクセスキー ID とシークレットアクセスキーを使用してリクエストに署名する必要があります。または、[AWS Security Token Service](https://docs.aws.amazon.com//STS/latest/APIReference/) (AWS STS) を使用して、一時的なセキュリティ認証情報を生成し、リクエストに署名することもできます。

タグエディタ では、リソースベースのポリシーをサポートしません。

タグエディタ API オペレーションは任意のネットワークの場所から呼び出すことができますが、 タグエディタ ではリソースベースのアクセスポリシーがサポートされているため、ソース IP アドレスに基づく制限を含めることができます。また、 タグエディタ ポリシーを使用して、特定の Amazon Virtual Private Cloud (Amazon VPC) エンドポイントまたは特定の VPC からのアクセスを制御することもできます。実質的に、このアプローチは、ネットワーク内の特定の VPC からのみ、特定のリソースへの AWS ネットワークアクセスを分離します。