

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

# AWS App Studio のセキュリティ
<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/)の一環として、サードパーティーの審査機関によって定期的にテストおよび検証されています。App Studio に適用されるコンプライアンスプログラムの詳細については、[AWS 「コンプライアンスプログラムによる対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウドのセキュリティ** – お客様の責任は、使用する AWS サービスによって決まります。また、お客様は、お客様のデータの機密性、組織の要件、および適用可能な法律および規制などの他の要因についても責任を担います。

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

**Topics**
+ [セキュリティに関する考慮事項と緩和策](security-considerations-and-mitigations.md)
+ [AWS App Studio でのデータ保護](data-protection.md)
+ [AWS App Studio と AWS Identity and Access Management (IAM)](security-iam.md)
+ [AWS App Studio のコンプライアンス検証](compliance-validation.md)
+ [AWS App Studio の耐障害性](disaster-recovery-resiliency.md)
+ [AWS App Studio のインフラストラクチャセキュリティ](infrastructure-security.md)
+ [AWS App Studio の設定と脆弱性の分析](vulnerability-analysis-and-management.md)
+ [サービス間での不分別な代理処理の防止](cross-service-confused-deputy-prevention.md)
+ [AWS App Studio でのクロスリージョンデータ転送](cross-region-data-transfer.md)

# セキュリティに関する考慮事項と緩和策
<a name="security-considerations-and-mitigations"></a>

## セキュリティに関する考慮事項
<a name="security-considerations"></a>

データコネクタ、データモデル、公開されたアプリケーションを処理する場合、データ漏洩、アクセスコントロール、潜在的な脆弱性に関連していくつかのセキュリティ上の懸念が発生します。次のリストには、主なセキュリティ上の懸念が含まれています。

### IAM ロールの設定が正しくない
<a name="security-considerations-improper-role-configuration"></a>

データコネクタの IAM ロールの設定が正しくないと、不正アクセスやデータリークにつながる可能性があります。データコネクタの IAM ロールへの過剰なアクセスを許可すると、権限のないユーザーが機密データにアクセスして変更できるようになります。

### IAM ロールを使用したデータオペレーションの実行
<a name="security-considerations-iam-data-operations"></a>

App Studio アプリのエンドユーザーは、アクションを実行するためにコネクタ設定で提供される IAM ロールを引き受けるため、これらのエンドユーザーは、通常アクセスできないデータにアクセスする可能性があります。

### 公開されたアプリケーションのデータコネクタの削除
<a name="security-considerations-deleting-data-connectors"></a>

データコネクタが削除されても、関連付けられたシークレット認証情報は、そのコネクタを既に使用している公開アプリケーションから自動的に削除されません。このシナリオでは、アプリケーションが特定のコネクタで公開され、それらのコネクタの 1 つが App Studio から削除された場合、公開されたアプリケーションは、以前に保存されたコネクタ認証情報を使用して引き続き動作します。コネクタを削除しても、公開されたアプリは影響を受けず、動作し続けることに注意してください。

### 公開されたアプリケーションでのデータコネクタの編集
<a name="security-considerations-editing-data-connectors"></a>

データコネクタを編集すると、そのコネクタを使用している公開アプリケーションに変更は自動的に反映されません。アプリケーションが特定のコネクタで公開されており、それらのコネクタの 1 つが App Studio で変更されている場合、公開されたアプリケーションは、以前に保存したコネクタ設定と認証情報を引き続き使用します。更新されたコネクタの変更を組み込むには、アプリケーションを再公開する必要があります。アプリが再公開されるまでは、正しくない非運用状態、または影響を受けない運用状態のままですが、最新のコネクタの変更は反映されません。

## セキュリティリスク軽減の推奨事項
<a name="security-mitigation"></a>

このセクションでは、前のセキュリティ上の考慮事項セクションで説明したセキュリティリスクを回避するための緩和推奨事項を一覧表示します。

1. **適切な IAM ロール設定:** データコネクタの IAM ロールが、不正アクセスやデータリークを防ぐために最小特権の原則で正しく設定されていることを確認します。

1. **制限されたアプリケーションアクセス:** アプリケーションデータを表示または実行する権限を持つユーザーとのみ、アプリケーションを共有します。

1. **アプリの発行:** コネクタが更新または削除されるたびにアプリが再発行されていることを確認します。

# AWS App Studio でのデータ保護
<a name="data-protection"></a>

 AWS App Studio でのデータ保護には、 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、または SDK を使用して AWS App Studio AWS CLIまたは他の AWS のサービス を操作する場合も同様です。 AWS SDKs タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。



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

App Studio は、保管中および転送中のデータを暗号化することで、データを安全に保存および転送します。

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

保存時の暗号化とは、保存中にデータを暗号化することで、不正なアクセスからデータを保護することです。App Studio は、デフォルトで AWS KMS キーを使用して保管時の暗号化を提供します。保管時のデータ暗号化に追加の設定を行う必要はありません。

App Studio は、アプリケーションのソースコード、ビルドアーティファクト、メタデータ、アクセス許可情報などのデータを安全に保存します。

 AWS KMS カスタマーマネージドキー (CMK) で暗号化されたデータソースを使用する場合、App Studio リソースは引き続き AWS マネージドキーを使用して暗号化されますが、暗号化されたデータソース内のデータは CMK によって暗号化されます。App Studio アプリケーションで暗号化されたデータソースを使用する方法の詳細については、「」を参照してください[CMKs](encrypted-data-cmk.md)。

App Studio は Amazon CloudFront を使用してユーザーにアプリを提供します。CloudFront は、エッジロケーション POP (Point Of Presence) 用に暗号化された SSD、およびリージョナルエッジキャッシュ (REC) 用に暗号化された EBS ボリュームを使用します。CloudFront Functions の関数コードと設定は、エッジロケーション POP の暗号化された SSD や、CloudFront で使用されるその他のストレージロケーションに、常に暗号化された形式で保存されます。

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

転送中の暗号化とは、通信エンドポイント間の移動中にデータが傍受されるのを防ぐことです。App Studio は、デフォルトで転送中のデータの暗号化を提供します。顧客と App Studio 間、および App Studio とそのダウンストリームの依存関係間のすべての通信は、署名バージョン 4 の署名プロセスを使用して署名された TLS 接続を使用して保護されます。すべての App Studio エンドポイントは AWS Certificate Manager 、プライベート認証局によって管理される SHA-256 証明書を使用します。

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

App Studio は暗号化キーの管理をサポートしていません。

## ネットワーク間トラフィックのプライバシー
<a name="inter-network-traffic-privacy"></a>

App Studio でインスタンスを作成するときは、そのインスタンスのデータとリソースが保存される AWS リージョンを選択します。アプリケーションビルドアーティファクトとメタデータがその AWS リージョンを離れることはありません。

ただし、次の情報に注意してください。
+ App Studio は Amazon CloudFront を使用してアプリケーションを提供し、Lambda@Edge を使用してアプリケーションへの認証を管理するため、CloudFront エッジロケーションからアクセスされる認証データ、認可データ、アプリケーションメタデータのセットは限られており、別のリージョンにある可能性があります。
+ AWS App Studio は、 AWS リージョン間でデータを転送して、サービス内の特定の生成 AI 機能を有効にします。クロスリージョンデータ転送で有効になる機能、 がリージョン間を移動するデータのタイプ、オプトアウトする方法の詳細については、「」を参照してください[AWS App Studio でのクロスリージョンデータ転送](cross-region-data-transfer.md)。

# AWS App Studio と AWS Identity and Access Management (IAM)
<a name="security-iam"></a>

 AWS App Studio では、IAM Identity Center のグループを App Studio の適切なロールに割り当てることで、サービスのアクセスとアクセス許可を管理します。グループメンバーのアクセス許可は、 AWS Identity and Access Management (IAM) でユーザー、ロール、またはアクセス許可を直接設定するのではなく、割り当てられたロールによって決定されます。App Studio でのアクセスとアクセス許可の管理の詳細については、「」を参照してください[App Studio でのアクセスとロールの管理](managing-access-and-roles.md)。

App Studio は、請求目的でインスタンスを検証するとき、および AWS アカウントに接続してその AWS アカウントでリソースを作成および使用する場合、IAM と統合されます。アプリケーションで使用するために App Studio を他の AWS サービスに接続する方法については、「」を参照してください[AWS サービスに接続する](add-connector-services.md)。

App Studio でインスタンスを作成するときは、インスタンスの請求および管理 AWS アカウントとして アカウントを接続する必要があります。主要な機能を有効にするために、App Studio はユーザーに代わってタスクを実行するために必要なアクセス許可をサービスに提供する [IAM サービスロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts)も作成します。

AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、誰を*認証* (サインイン) し、誰に App Studio リソースの使用*を許可する* (アクセス許可を付与する) かを制御します。IAM は、追加料金なしで使用できる AWS のサービス です。

**Topics**
+ [App Studio のアイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies)
+ [App Studio 内のリソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies)
+ [App Studio のポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions)
+ [App Studio のポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources)
+ [App Studio のポリシー条件キー](#security_iam_service-with-iam-id-based-policies-conditionkeys)
+ [App Studio ACLs](#security_iam_service-with-iam-acls)
+ [App Studio での ABAC](#security_iam_service-with-iam-tags)
+ [App Studio での一時的な認証情報の使用](#security_iam_service-with-iam-roles-tempcreds)
+ [App Studio のクロスサービスプリンシパルアクセス許可](#security_iam_service-with-iam-principal-permissions)
+ [App Studio のサービスロール](#security_iam_service-with-iam-roles-service)
+ [App Studio のサービスにリンクされたロール](#security_iam_service-with-iam-roles-service-linked)
+ [AWS AWS App Studio の マネージドポリシー](security-iam-awsmanpol.md)
+ [App Studio のサービスにリンクされたロール](appstudio-service-linked-roles.md)
+ [AWS App Studio のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)

IAM を使用して App Studio へのアクセスを管理する前に、App Studio で使用できる IAM 機能を確認してください。


**AWS App Studio で使用できる IAM 機能**  

| IAM 機能 | App Studio のサポート | 
| --- | --- | 
|  [アイデンティティベースのポリシー](#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)  |   はい  | 

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

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

**アイデンティティベースのポリシーのサポート:** あり

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

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

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

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

## App Studio 内のリソースベースのポリシー
<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)を参照してください。

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

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

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

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

App Studio アクションのリストを確認するには、*「サービス認可リファレンス*」の[AWS 「App Studio で定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsappstudio.html#awsappstudio-actions-as-permissions)」を参照してください。

App Studio のポリシーアクションは、アクションの前に次のプレフィックスを使用します。

```
appstudio
```

単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。

```
"Action": [
      "appstudio:action1",
      "appstudio:action2"
         ]
```

次のステートメントは、App Studio のすべてのアクションを一覧表示します。

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

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

App Studio のアクセス許可は、ポリシーの `Resource`要素でワイルドカード (`*`) のみをサポートします。

## App Studio のポリシー条件キー
<a name="security_iam_service-with-iam-id-based-policies-conditionkeys"></a>

**サービス固有のポリシー条件キーへのサポート:** なし 

App Studio はポリシー条件キーをサポートしていません。

## App Studio ACLs
<a name="security_iam_service-with-iam-acls"></a>

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

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

## App Studio での ABAC
<a name="security_iam_service-with-iam-tags"></a>

**ABAC (ポリシー内のタグ) のサポート:** なし 

App Studio は、属性ベースのアクセスコントロール (ABAC) をサポートしていません。

## App Studio での一時的な認証情報の使用
<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)」を参照してください。

## App Studio のクロスサービスプリンシパルアクセス許可
<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)」を参照してください。

## App Studio のサービスロール
<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 App Studio は、一部の機能に [IAM サービスロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts)を使用して、ユーザーに代わってタスクを実行するアクセス許可を App Studio に付与します。App Studio をセットアップすると、コンソールはサポートされている機能のサービスロールを自動的に作成します。

**警告**  
サービスロールのアクセス許可を変更すると、App Studio の機能が破損する可能性があります。App Studio が指示する場合にのみ、サービスロールを編集します。

## App Studio のサービスにリンクされたロール
<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 AWS App Studio の マネージドポリシー
<a name="security-iam-awsmanpol"></a>







ユーザー、グループ、ロールにアクセス許可を追加するには、自分でポリシーを記述するよりも AWS 管理ポリシーを使用する方が簡単です。チームに必要な権限のみを提供する [IAM カスタマーマネージドポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) には時間と専門知識が必要です。すぐに開始するには、 AWS マネージドポリシーを使用できます。これらのポリシーは、一般的なユースケースをターゲット範囲に含めており、 AWS アカウントで利用できます。 AWS 管理ポリシーの詳細については、*IAM ユーザーガイド*の「 [AWS 管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。

AWS サービスは、 AWS 管理ポリシーを維持および更新します。 AWS 管理ポリシーのアクセス許可は変更できません。サービスでは新しい機能を利用できるようにするために、 AWS マネージドポリシーに権限が追加されることがあります。この種類の更新はポリシーがアタッチされている、すべてのアイデンティティ (ユーザー、グループおよびロール) に影響を与えます。新しい機能が立ち上げられた場合や、新しいオペレーションが使用可能になった場合に、各サービスが AWS マネージドポリシーを更新する可能性が最も高くなります。サービスは AWS マネージドポリシーからアクセス許可を削除しないため、ポリシーの更新によって既存のアクセス許可が損なわれることはありません。

さらに、 は、複数のサービスにまたがるジョブ関数の マネージドポリシー AWS をサポートしています。例えば、**ReadOnlyAccess** AWS 管理ポリシーは、すべての AWS サービスとリソースへの読み取り専用アクセスを提供します。サービスが新機能を起動すると、 は新しいオペレーションとリソースの読み取り専用アクセス許可 AWS を追加します。ジョブ機能のポリシーの一覧および詳細については、「*IAM ユーザーガイド*」の「[AWS のジョブ機能のマネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)」を参照してください。









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

IAM エンティティに `AppStudioServiceRolePolicy` をアタッチすることはできません。このポリシーは、App Studio がユーザーに代わってアクションを実行できるようにするサービスにリンクされたロールにアタッチされます。詳細については、「[App Studio のサービスにリンクされたロール](appstudio-service-linked-roles.md)」を参照してください。



このポリシーは、サービスにリンクされたロールが AWS リソースを管理できるようにするアクセス許可を付与します。

### 許可の詳細
<a name="security-iam-awsmanpol-appstudioservicerolepolicy-permissions-details"></a>

このポリシーには以下を実行するための許可が含まれています。
+ `logs` - CloudWatch ロググループとログストリームを作成します。また、これらのロググループとストリームにログイベントを作成するアクセス許可も付与します。
+ `secretsmanager` - App Studio によって管理されるマネージドシークレットを作成、読み取り、更新、削除します。
+ `sso` - アプリケーションインスタンスを取得します。
+ `sso-directory` - ユーザーに関する情報を取得し、グループ内のメンバーのリストを取得します。

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

****  

```
{
 "Version":"2012-10-17",		 	 	 
 "Statement": [
     {
         "Sid": "AppStudioResourcePermissionsForCloudWatch",
         "Effect": "Allow",
         "Action": [
             "logs:CreateLogGroup",
             "logs:CreateLogStream",
             "logs:PutLogEvents"
         ],
         "Resource": [
             "arn:aws:logs:*:*:log-group:/aws/appstudio/*"
         ],
         "Condition": {
             "StringEquals": {
                 "aws:ResourceAccount": "${aws:PrincipalAccount}"
             }
         }
     },
     {
         "Sid": "AppStudioResourcePermissionsForSecretsManager",
         "Effect": "Allow",
         "Action": [
             "secretsmanager:CreateSecret",
             "secretsmanager:DeleteSecret",
             "secretsmanager:DescribeSecret",
             "secretsmanager:GetSecretValue",
             "secretsmanager:PutSecretValue",
             "secretsmanager:UpdateSecret",
             "secretsmanager:TagResource"
         ],
         "Resource": "arn:aws:secretsmanager:*:*:secret:appstudio-*",
         "Condition": {
             "ForAllValues:StringEquals": {
                 "aws:TagKeys": [
                     "IsAppStudioSecret"
                 ]
             },
             "StringEquals": {
                 "aws:ResourceAccount": "${aws:PrincipalAccount}",
                 "aws:ResourceTag/IsAppStudioSecret": "true"
             }
         }
     },
     {
         "Sid": "AppStudioResourcePermissionsForManagedSecrets",
         "Effect": "Allow",
         "Action": [
             "secretsmanager:DeleteSecret",
             "secretsmanager:DescribeSecret",
             "secretsmanager:GetSecretValue",
             "secretsmanager:PutSecretValue",
             "secretsmanager:UpdateSecret"
         ],
         "Resource": "arn:aws:secretsmanager:*:*:secret:appstudio!*",
         "Condition": {
             "StringEquals": {
                 "aws:ResourceAccount": "${aws:PrincipalAccount}",
                 "secretsmanager:ResourceTag/aws:secretsmanager:owningService": "appstudio"
             }
         }
     },
     {
         "Sid": "AppStudioResourceWritePermissionsForManagedSecrets",
         "Effect": "Allow",
         "Action": [
             "secretsmanager:CreateSecret"
         ],
         "Resource": "arn:aws:secretsmanager:*:*:secret:appstudio!*",
         "Condition": {
             "StringEquals": {
                 "aws:ResourceAccount": "${aws:PrincipalAccount}"
             }
         }
     },
     {
         "Sid": "AppStudioResourcePermissionsForSSO",
         "Effect": "Allow",
         "Action": [
             "sso:GetManagedApplicationInstance",
             "sso-directory:DescribeUsers",
             "sso-directory:ListMembersInGroup"
         ],
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                 "aws:ResourceAccount": "${aws:PrincipalAccount}"
             }
         }
     }
 ]
}
```

------

## AWS 管理ポリシーに対する App Studio の更新
<a name="security-iam-awsmanpol-updates"></a>

このサービスがこれらの変更の追跡を開始してからの App Studio の AWS マネージドポリシーの更新に関する詳細を表示します。


| 変更 | 説明 | 日付 | 
| --- | --- | --- | 
|  [AppStudioServiceRolePolicy](#security-iam-awsmanpol-appstudioservicerolepolicy) – 既存のポリシーの更新  |  App Studio は、App Studio マネージドシークレットの管理を許可する新しいアクセス許可を追加しました AWS Secrets Manager。  | 2025 年 3 月 14 日 | 
|  App Studio が変更の追跡を開始しました  |  App Studio は、 AWS 管理ポリシーの変更の追跡を開始しました。  | 2024 年 6 月 28 日 | 

# App Studio のサービスにリンクされたロール
<a name="appstudio-service-linked-roles"></a>

App Studio は [AWS Identity and Access Management (IAM) サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)を使用します。サービスにリンクされたロールは、App Studio に直接リンクされた一意のタイプの IAM ロールです。サービスにリンクされたロールは App Studio によって事前定義されており、サービスがユーザーに代わって他の AWS サービスを呼び出すために必要なすべてのアクセス許可が含まれています。

サービスにリンクされたロールを使用すると、必要なアクセス許可を手動で追加する必要がなくなるため、App Studio の設定が簡単になります。App Studio は、サービスにリンクされたロールのアクセス許可を定義します。特に定義されている場合を除き、App Studio のみがそのロールを引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。

サービスリンクロールを削除するには、最初に関連リソースを削除する必要があります。これにより、リソースへのアクセス許可が誤って削除されないため、App Studio リソースが保護されます。

**Topics**
+ [App Studio のサービスにリンクされたロールのアクセス許可](#slr-permissions)
+ [App Studio のサービスにリンクされたロールの作成](#create-slr)
+ [App Studio のサービスにリンクされたロールの編集](#edit-slr)
+ [App Studio のサービスにリンクされたロールの削除](#delete-slr)

## App Studio のサービスにリンクされたロールのアクセス許可
<a name="slr-permissions"></a>

App Studio は、 という名前のサービスにリンクされたロールを使用します`AWSServiceRoleForAppStudio`。これは、アプリケーション構築エクスペリエンスを維持するために、App Studio がサービスを永続的に管理するために必要な AWS サービスにリンクされたロールです。

`AWSServiceRoleForAppStudio` サービスにリンクされたロールは、サービスのみを信頼する次の信頼ポリシーを使用します`appstudio-service.amazonaws.com`。

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

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "appstudio-service.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
```

------

アクセス許可の場合、`AWSServiceRoleForAppStudio`サービスにリンクされたロールは次のサービスへのアクセス許可を提供します。
+ Amazon CloudWatch: App Studio の使用に関するログとメトリクスを送信します。
+ AWS Secrets Manager: App Studio でコネクタの認証情報を管理するには、アプリケーションを他の サービスに接続するために使用されます。
+ IAM アイデンティティセンター: ユーザーアクセスを管理するための読み取り専用アクセス。

具体的には、 で付与されるアクセス許可`AWSServiceRoleForAppStudio`は、アタッチされた`AppStudioServiceRolePolicy`管理ポリシーによって定義されます。含まれるアクセス許可を含む 管理ポリシーの詳細については、「」を参照してください[AWS マネージドポリシー: AppStudioServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-appstudioservicerolepolicy)。

## App Studio のサービスにリンクされたロールの作成
<a name="create-slr"></a>

サービスリンクロールを手動で作成する必要はありません。App Studio インスタンスを作成すると、App Studio によってサービスにリンクされたロールが作成されます。

このサービスにリンクされたロールを削除する場合は、App Studio インスタンスを作成して、別のインスタンスを自動的に作成することをお勧めします。

必須ではありませんが、前述の信頼ポリシースニペットのように、サービス名でサービスにリンクされたロールを作成することで、IAM コンソールまたは を使用して`appstudio-service.amazonaws.com`サービスにリンクされたロール AWS CLI を作成することもできます。詳細については、*IAM ユーザーガイド*の「[サービスリンクロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html)」を参照してください。

## App Studio のサービスにリンクされたロールの編集
<a name="edit-slr"></a>

App Studio では、`AWSServiceRoleForAppStudio`サービスにリンクされたロールを編集することはできません。サービスリンクロールを作成すると、多くのエンティティによってロールが参照される可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明の編集はできます。詳細については、「*IAM ユーザーガイド*」の「[サービスリンクロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。

## App Studio のサービスにリンクされたロールの削除
<a name="delete-slr"></a>

`AWSServiceRoleForAppStudio` ロールを削除する必要はありません。App Studio インスタンスを削除すると、App Studio はリソースをクリーンアップし、サービスにリンクされたロールを自動的に削除します。

推奨されませんが、IAM コンソールまたは AWS CLI を使用して、サービスにリンクされたロールを削除できます。これを行うには、まずサービスにリンクされたロールのリソースをクリーンアップしてから、削除する必要があります。

**注記**  
リソースを削除しようとしたときに App Studio がロールを使用している場合は、削除が失敗する可能性があります。その場合は、数分待ってからオペレーションを再試行してください。

**IAM を使用してサービスリンクロールを手動で削除するには**

1. App Studio インスタンスからアプリケーションとコネクタを削除します。

1. `AWSServiceRoleForAppStudio` サービスにリンクされたロールを削除するには、IAM コンソール、IAM CLI、または IAM API を使用します。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。

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

デフォルトでは、ユーザーとロールには App Studio リソースを作成または変更するアクセス許可はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。

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

各リソースタイプの ARNs*「サービス認可リファレンス*」の[AWS 「App Studio のアクション、リソース、および条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsappstudio.html)」を参照してください。

**Topics**
+ [ポリシーに関するベストプラクティス](#security_iam_service-with-iam-policy-best-practices)
+ [App Studio コンソールの使用](#security_iam_id-based-policy-examples-console)
+ [自分の権限の表示をユーザーに許可する](#security_iam_id-based-policy-examples-view-own-permissions)
+ [例 1: ユーザーに App Studio インスタンスの設定を許可する](#security_iam_id-based-policy-examples-set-up-appstudio-instance)
+ [例 2: ユーザーによる App Studio インスタンスの設定を拒否する](#security_iam_id-based-policy-examples-deny-set-up-appstudio-instance)

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

ID ベースのポリシーは、アカウント内で誰かが App Studio リソースを作成、アクセス、または削除できるかどうかを決定します。これらのアクションでは、 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) を参照してください。

## App Studio コンソールの使用
<a name="security_iam_id-based-policy-examples-console"></a>

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

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

ユーザーとロールが引き続き App Studio コンソールを使用できるようにするには、エンティティに App Studio `ConsoleAccess`または `ReadOnly` AWS 管理ポリシーもアタッチします。詳細については、「*IAM ユーザーガイド*」の「[ユーザーへのアクセス許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。

## 自分の権限の表示をユーザーに許可する
<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": "*"
        }
    ]
}
```

## 例 1: ユーザーに App Studio インスタンスの設定を許可する
<a name="security_iam_id-based-policy-examples-set-up-appstudio-instance"></a>

次の例は、ロールが App Studio インスタンスをセットアップすることを許可するアイデンティティベースのポリシーを示しています。

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

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "appstudio:GetAccountStatus",
            "appstudio:GetEnablementJobStatus",
            "appstudio:StartEnablementJob",
            "appstudio:StartRollbackEnablementJob",
            "appstudio:StartTeamDeployment"
        ],
        "Resource": "*"
    }]
}
```

------

## 例 2: ユーザーによる App Studio インスタンスの設定を拒否する
<a name="security_iam_id-based-policy-examples-deny-set-up-appstudio-instance"></a>

次の例は、ロールが App Studio インスタンスをセットアップすることを拒否するアイデンティティベースのポリシーを示しています。

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

****  

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

------

# AWS App Studio のコンプライアンス検証
<a name="compliance-validation"></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/)」を参照してください。

# AWS App Studio の耐障害性
<a name="disaster-recovery-resiliency"></a>

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

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

 AWS グローバルインフラストラクチャに加えて、 AWS App Studio には、データの耐障害性とバックアップのニーズをサポートするのに役立つ機能がいくつか用意されています。

# AWS App Studio のインフラストラクチャセキュリティ
<a name="infrastructure-security"></a>

マネージドサービスである AWS App Studio は、ホワイトペーパー[「Amazon Web Services: セキュリティプロセスの概要](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf)」に記載されている AWS グローバルネットワークセキュリティ手順で保護されています。

 AWS 公開された API コールを使用して、ネットワーク経由で App Studio にアクセスします。クライアントは少なくとも Transport Layer Security (TLS) 1.2 をサポートする必要がありますが、TLS 1.3 が推奨されます。また、DHE (Ephemeral Diffie-Hellman) や ECDHE (Elliptic Curve Ephemeral Diffie-Hellman) などの Perfect Forward Secrecy (PFS) を使用した暗号スイートもクライアントでサポートされている必要があります。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。

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

# AWS App Studio の設定と脆弱性の分析
<a name="vulnerability-analysis-and-management"></a>

設定と IT コントロールは、 AWS お客様と当社のお客様との間の責任共有です。詳細については、 AWS [「 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)」を参照してください。

# サービス間での不分別な代理処理の防止
<a name="cross-service-confused-deputy-prevention"></a>

混乱した代理問題は、アクションを実行するためのアクセス許可を持たないエンティティが、より特権のあるエンティティにアクションの実行を強制できてしまう場合に生じる、セキュリティ上の問題です。では AWS、サービス間のなりすましにより、混乱した代理問題が発生する可能性があります。サービス間でのなりすましは、1 つのサービス (*呼び出し元サービス*) が、別のサービス (*呼び出し対象サービス*) を呼び出すときに発生する可能性があります。呼び出し元サービスは、本来ならアクセスすることが許可されるべきではない方法でその許可を使用して、別のお客様のリソースに対する処理を実行するように操作される場合があります。これを防ぐため、 AWS では、アカウント内のリソースへのアクセス権が付与されたサービスプリンシパルですべてのサービスのデータを保護するために役立つツールを提供しています。

リソースポリシーで [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)および [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) グローバル条件コンテキストキーを使用して、 がリソースに別のサービスに付与するアクセス許可を制限することをお勧めします。クロスサービスアクセスにリソースを 1 つだけ関連付けたい場合は、`aws:SourceArn` を使用します。そのアカウント内のリソースをクロスサービスの使用に関連付けることを許可する場合は、`aws:SourceAccount` を使用します。

混乱した代理問題から保護するための最も効果的な方法は、リソースの完全な ARN を指定して、`aws:SourceArn` グローバル条件コンテキストキーを使用することです。リソースの完全な ARN が不明な場合や、複数のリソースを指定する場合には、グローバルコンテキスト条件キー `aws:SourceArn` で、ARN の未知部分を示すためにワイルドカード文字 (`*`) を使用します。例えば、`arn:aws:servicename:*:123456789012:*`。

`aws:SourceArn` の値に Amazon S3 バケット ARN などのアカウント ID が含まれていない場合は、両方のグローバル条件コンテキストキーを使用して、アクセス許可を制限する必要があります。

`aws:SourceArn` の値は ResourceDescription である必要があります。

次の例では、`aws:SourceArn` および `aws:SourceAccount` グローバル条件コンテキストキーを使用して、混乱した代理問題を回避する方法を示します。

# AWS App Studio でのクロスリージョンデータ転送
<a name="cross-region-data-transfer"></a>

AWS App Studio は、 AWS リージョン間でデータを転送して、サービス内の特定の生成 AI 機能を有効にします。このトピックでは、クロスリージョンデータ転送で有効になる機能、 がリージョン間を移動するデータの種類、オプトアウト方法について説明します。

次の機能はクロスリージョンデータ転送によって有効になり、オプトアウトするとインスタンスでアクセスできなくなります。

1. AI を使用してアプリを作成する。自然言語でアプリを記述し、リソースを作成することで、アプリ構築を開始するために使用します。

1. アプリケーションスタジオの AI チャット。アプリケーションの構築、公開、共有について質問するために使用されます。

次のデータはリージョン間で転送されます。

1. 前述の機能からのプロンプトまたはユーザー入力。

クロスリージョンデータ転送をオプトアウトし、それによって有効になる機能を使用するには、次の手順を使用してコンソールからオプトアウトリクエストフォームに入力します。

1. [https://console.aws.amazon.com/appstudio/](https://console.aws.amazon.com/appstudio/) で App Studio コンソールを開きます。

1. **データ転送のオプトアウト**を選択します。

1.  AWS アカウント ID を入力し、E メールアドレスを入力します。

1. [**Submit**] を選択してください。

1. 送信されると、クロスリージョンデータ転送のオプトアウトリクエストが処理されます。これには最大 60 日かかる場合があります。