翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# のセキュリティ AWS Device Farm
のクラウドセキュリティが最優先事項 AWS です。お客様は AWS 、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャを活用できます。
セキュリティは、 AWS お客様とお客様の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)ではこれをクラウド*の*セキュリティおよびクラウド*内*のセキュリティと説明しています。
+ **クラウドのセキュリティ** – AWS クラウドで AWS サービスを実行するインフラストラクチャを保護する AWS 責任があります。 AWS また、 では、安全に使用できるサービスも提供しています。サードパーティーの監査者は、[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)コンプライアンスプログラムの一環として、当社のセキュリティの有効性を定期的にテストおよび検証。が適用されるコンプライアンスプログラムの詳細については AWS Device Farm、「コンプライアンスプログラム[による AWS 対象範囲内のサービスコンプライアンスプログラム](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウド内のセキュリティ** - ユーザーの責任は、使用する AWS のサービスに応じて異なります。またお客様は、データの機密性、企業要件、適用される法令と規制などの他の要因も責務となります。
このドキュメントは、Device Farm を使用する際に責任共有モデルを適用する方法を理解するのに役立ちます。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成するために Device Farm を構成する方法を示します。また、Device Farm リソースのモニタリングや保護に役立つ他の AWS サービスの使用方法についても説明します。
**Topics**
+ [AWS Device Farm のアイデンティティとアクセス管理](security-iam.md)
+ [のコンプライアンス検証AWS Device Farm](ATP-compliance.md)
+ [でのデータ保護 AWS Device Farm](data-protection.md)
+ [AWS Device Farm での耐障害性](disaster-recovery-resiliency.md)
+ [のインフラストラクチャセキュリティ AWS Device Farm](infrastructure-security.md)
+ [Device Farm での構成の脆弱性の分析と管理](security-vulnerability-analysis-and-management.md)
+ [Device Farm でのインシデント応答](security-incident-response.md)
+ [Device Farm でのロギングとモニタリング](security-logging-monitoring.md)
+ [Device Farm のセキュリティベストプラクティス](security-best-practices.md)
# AWS Device Farm のアイデンティティとアクセス管理
## オーディエンス
AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。
+ **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[AWS Device Farm のアイデンティティとアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。
+ **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[AWS Device Farm と IAM の連携方法](security_iam_service-with-iam.md)」を参照)
+ **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[AWS Device Farm アイデンティティベースポリシーの例](security_iam_id-based-policy-examples.md)」を参照)
## アイデンティティを使用した認証
認証とは、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 アカウント ルートユーザー
を作成するときは AWS アカウント、すべての AWS のサービス および リソースへの完全なアクセス権を持つ AWS アカウント *ルートユーザー*と呼ばれる 1 つのサインインアイデンティティから始めます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ 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)」を参照してください。
### IAM ロール
*[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) を参照してください。
# AWS Device Farm と IAM の連携方法
Device Farm へのアクセス権を管理するために IAM を使用する前に、Device Farm でどの IAM 機能が使用できるかを理解しておく必要があります。Device Farm およびその他の AWS のサービスが IAM と連携する方法の概要を把握するには、IAM *ユーザーガイド*の[AWS 「IAM と連携する のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
**Topics**
+ [Device Farm のアイデンティティベースポリシー](#security_iam_service-with-iam-id-based-policies)
+ [Device Farm のリソースベースポリシー](#security_iam_service-with-iam-resource-based-policies)
+ [アクセスコントロールリスト](#security_iam_service-with-iam-acls)
+ [Device Farm タグに基づく認可](#security_iam_service-with-iam-tags)
+ [Device Farm IAM ロール](#security_iam_service-with-iam-roles)
## Device Farm のアイデンティティベースポリシー
IAM のアイデンティティベースポリシーでは、許可または拒否するアクションとリソース、およびアクションが許可または拒否される条件を指定できます。Device Farm は、特定のアクション、リソース、および条件キーをサポートしています。JSON ポリシーで使用するすべての要素については、「IAM ユーザーガイド」の「[IAM JSON ポリシー要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
### アクション
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。関連付けられたオペレーションを実行する権限を付与するポリシーでのアクションを含みます。
Device Farm のポリシーアクションは、アクションの前に以下のプレフィックス「`devicefarm:`」を使用します: 例えば、Device Farm デスクトップブラウザテスト `CreateTestGridUrl` API オペレーションで Selenium セッションを開始する権限を誰かに付与するには、そのポリシーに `devicefarm:CreateTestGridUrl` アクションを含めます。ポリシーステートメントには`Action` または `NotAction` 要素を含める必要があります。Device Farm は、このサービスで実行できるタスクを記述する独自のアクションセットを定義します。
単一ステートメントに複数アクションを指定するには、次のようにカンマで区切ります:
```
"Action": [
"devicefarm:action1",
"devicefarm:action2"
```
ワイルドカード (\$1) を使用して複数アクションを指定できます。たとえば、「`List`」という単語で始まるすべてのアクションを指定するには、次のアクションを含めます:
```
"Action": "devicefarm:List*"
```
Device Farm アクションのリストを確認するには、「*IAM サービス認可リファレンス*」の「[AWS Device Farmにより定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-actions-as-permissions)」を参照してください。
### リソース
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
Amazon EC2 インスタンスのリソースには次のような ARN があります:
```
arn:${Partition}:ec2:${Region}:${Account}:instance/${InstanceId}
```
ARN の形式の詳細については、[「Amazon リソースネーム (ARNs)」と AWS 「サービス名前空間](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)」を参照してください。
例えば、ステートメントで `i-1234567890abcdef0` インスタンスを指定するには、次の ARN を使用します:
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0"
```
アカウントに属するすべてのインスタンスを指定するには、ワイルドカード (\$1) を使用します:
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*"
```
リソースの作成など、一部の Device Farm アクションは、リソースで実行できません。このような場合はワイルドカード \$1を使用する必要があります。
```
"Resource": "*"
```
Amazon EC2 API アクションの多くが複数のリソースと関連します。例えば、`AttachVolume` では Amazon EBS ボリュームをインスタンスにアタッチするため、IAM ユーザーはボリュームおよびインスタンスを使用する権限が必要です。複数リソースを単一ステートメントで指定するには、ARN をカンマで区切ります。
```
"Resource": [
"resource1",
"resource2"
```
Device Farm リソースのタイプとその ARN のリストを確認するには、「*IAM サービス認可リファレンス*」の「[AWS Device Farmにより定義されるリソース](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-resources-for-iam-policies)」を参照してください。各リソースの ARN を指定できるアクションについては、「*IAM サービス認可リファレンス*」の「[AWS Device Farmにより定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-actions-as-permissions)」を参照してください。
### 条件キー
管理者は 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)」を参照してください。
Device Farm は独自の条件キーセットを定義し、一部のグローバル条件キーの使用もサポートしています。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の[AWS 「グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
Device Farm の条件キーのリストを確認するには、「*IAM サービス認可リファレンス*」の「[AWS Device Farmの条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-policy-keys)」を参照してください。条件キーを使用できるアクションとリソースについては、「*IAM サービス認可リファレンス*」の「[AWS Device Farmで定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdevicefarm.html#awsdevicefarm-actions-as-permissions)」を参照してください。
### 例
Device Farm のアイデンティティベースポリシーの例を表示するには、「[AWS Device Farm アイデンティティベースポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
## Device Farm のリソースベースポリシー
Device Farm では、リソースベースポリシーはサポートされていません。
## アクセスコントロールリスト
Device Farm では、アクセスコントロールリスト (ACL) はサポートされていません。
## Device Farm タグに基づく認可
タグを Device Farm リソースにアタッチしたり、Device Farm へのリクエストでタグを渡したりできます。タグに基づいてアクセスを管理するには、`aws:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの「[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)」でタグ情報を提供します。Device Farm リソースのタギングの詳細については、「[AWS Device Farm リソースのタギング](tagging.md)」を参照してください。
リソースのタグに基づいてリソースへのアクセスを制限するためのアイデンティティベースポリシーの例を表示するには、「[タグに基づく Device Farm デスクトップブラウザテストプロジェクトの表示](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-view-project-tags)」を参照してください。
## Device Farm IAM ロール
[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)は、特定のアクセス許可を持つ AWS アカウントのエンティティです。
### Device Farm での一時的な認証情報の使用
Device Farm は、一時的な認証情報の使用をサポートしています。
一時的な認証情報を使用して、フェデレーションでサインインし、IAM ロールまたはクロスアカウントロールの引き受けを行えます。一時的なセキュリティ認証情報を取得するには、[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) や [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) などの AWS STS API オペレーションを呼び出します。
### サービスリンクロール
[サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)を使用すると、 AWS サービスは他の サービスのリソースにアクセスして、ユーザーに代わってアクションを実行できます。サービスリンクロールは、IAM アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールの権限を表示できますが、編集することはできません。
Device Farm は、Device Farm デスクトップブラウザテスト機能でサービスリンクロールを使用します。これらのロールの詳細については、開発者ガイドの「[Device Farm デスクトップブラウザテストのサービスリンクロールの使用](https://docs.aws.amazon.com//devicefarm/latest/testgrid/using-service-linked-roles.html)」を参照してください。
### サービスロール
Device Farm はサービスロールをサポートしていません。
この機能により、お客様に代わってサービスが[サービスロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role)を引き受けることが許可されます。この役割により、サービスがお客様に代わって他のサービスのリソースにアクセスし、アクションを完了することが許可されます。サービスロールはIAM アカウントに表示され、アカウントによって所有されます。つまり、IAM 管理者はこの役割の権限を変更できます。ただし、それにより、サービスの機能が損なわれる場合があります。
## ポリシーを使用したアクセス権の管理
でアクセスを制御する 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 ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。
### アイデンティティベースのポリシー
アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる 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)」を参照してください。
次の表で、Device Farm AWS 管理ポリシーの概要を説明します。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWSDeviceFarmFullAccess](https://console.aws.amazon.com/iam/home?region=us-east-1#/policies/arn:aws:iam::aws:policy/AWSDeviceFarmFullAccess$jsonEditor) | すべての AWS Device Farm オペレーションへのフルアクセスを提供します。 | 2015 年 7 月 15 日 |
| [AWSServiceRoleForDeviceFarmTestGrid](https://docs.aws.amazon.com//devicefarm/latest/testgrid/using-service-linked-roles.html) | 代わりに、Device Farm で AWS リソースにアクセスできます。 | 2021 年 5 月 20 日 |
### 他のポリシータイプ
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)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。が複数のポリシータイプが関与する場合にリクエストを許可するかどうか AWS を決定する方法については、*「IAM ユーザーガイド*」の[「ポリシー評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。
# AWS Device Farm アイデンティティベースポリシーの例
デフォルトでは、IAM ユーザーおよびロールには、Device Farm リソースを作成したり変更したりする権限はありません。また、 AWS マネジメントコンソール、 AWS CLI、または AWS API を使用してタスクを実行することはできません。IAM 管理者は、ユーザーとロールに必要な、指定されたリソースで特定の API オペレーションを実行する権限をユーザーとロールに付与する IAM ポリシーを作成する必要があります。続いて、管理者はそれらの権限が必要な 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)
+ [ユーザーが自分の権限を表示できるようにする](#security_iam_id-based-policy-examples-view-own-permissions)
+ [1 つの Device Farm デスクトップブラウザテストプロジェクトへのアクセス](#security_iam_id-based-policy-examples-access-one-project)
+ [タグに基づく Device Farm デスクトップブラウザテストプロジェクトの表示](#security_iam_id-based-policy-examples-view-project-tags)
## ポリシーに関するベストプラクティス
アイデンティティベースポリシーは、ユーザーのアカウントで誰かが Device Farm リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションでは、 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)」を参照してください。
## ユーザーが自分の権限を表示できるようにする
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を 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 つの Device Farm デスクトップブラウザテストプロジェクトへのアクセス
この例では、 AWS アカウントの IAM ユーザーに Device Farm のデスクトップブラウザテストプロジェクトの 1 つへのアクセス権を付与します`arn:aws:devicefarm:us-west-2:111122223333:testgrid-project:123e4567-e89b-12d3-a456-426655441111`。アカウントでそのプロジェクトに関連するアイテムを表示できるようにする必要があります。
`devicefarm:GetTestGridProject` エンドポイントに加えて、アカウントには `devicefarm:ListTestGridSessions`、`devicefarm:GetTestGridSession`、`devicefarm:ListTestGridSessionActions`、および `devicefarm:ListTestGridSessionArtifacts` エンドポイントが必要です。
CI システムを使用している場合は、各 CI 実行者に一意のアクセス認証情報を付与する必要があります。例えば、CI システムでは、`devicefarm:ScheduleRun` または `devicefarm:CreateUpload` よりも多くの権限が必要になることはほとんどありません。以下の IAM ポリシーでは、アップロードを作成してそのアップロードによりテスト実行をスケジュールすることで、新しい Device Farm ネイティブアプリケーションテストを開始することを、CI 実行者に許可する最小限のポリシーを概説します:
## タグに基づく Device Farm デスクトップブラウザテストプロジェクトの表示
アイデンティティベースポリシーの条件を使用して、タグに基づいて Device Farm リソースへのアクセスを管理できます。この例では、プロジェクトとセッションの表示を許可するポリシーを作成する方法を示しています。リクエスト先のリソースの `Owner` タグがリクエスト元のアカウントのユーザー名と一致する場合、権限が付与されます。
このポリシーはアカウントの IAM ユーザーにアタッチできます。`richard-roe` という名前のユーザーが Device Farm プロジェクトまたはセッションを表示しようとする場合、プロジェクトに `Owner=richard-roe` または `owner=richard-roe` というタグが付いている必要があります。それ以外の場合、ユーザーはアクセスを拒否されます。条件キー名では大文字と小文字は区別されないため、条件タグキー `Owner` は `Owner` と `owner` に一致します。詳細については、「*IAM ユーザーガイド*」の「[IAM JSON ポリシー要素: 条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)」を参照してください。
# AWS Device Farm のアイデンティティとアクセスのトラブルシューティング
次の情報は、Device Farm と IAM による作業に伴って発生する可能性がある一般的な問題の診断や修復に役立ちます。
## Device Farm でアクションを実行する権限がない
で、アクションを実行する権限がない AWS マネジメントコンソール というエラーが表示された場合は、管理者に連絡してサポートを依頼する必要があります。お客様のユーザー名とパスワードを発行したのが、担当の管理者です。
以下の例のエラーは、`mateojackson` という IAM ユーザーがコンソールを使用して、実行の詳細を表示しようとしているが、`devicefarm:GetRun` 権限がない場合に発生します。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: devicefarm:GetRun on resource: arn:aws:devicefarm:us-west-2:123456789101:run:123e4567-e89b-12d3-a456-426655440000/123e4567-e89b-12d3-a456-426655441111
```
この場合、Mateo は管理者に依頼し、`devicefarm:GetRun` アクションを使用して `arn:aws:devicefarm:us-west-2:123456789101:run:123e4567-e89b-12d3-a456-426655440000/123e4567-e89b-12d3-a456-426655441111` リソースに対する `devicefarm:GetRun` にアクセスできるようにポリシーを更新してもらいます。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して Device Farm にロールを渡すことができるようにする必要があります。
一部の AWS のサービス では、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、既存のロールをそのサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
以下の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して Device Farm でアクションを実行しようとする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与された権限が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。
## アクセスキーを表示したい
IAM ユーザーアクセスキーを作成した後は、いつでもアクセスキー ID を表示できます。ただし、シークレットアクセスキーを再表示することはできません。シークレットアクセスキーを紛失した場合は、新しいアクセスキーペアを作成する必要があります。
アクセスキーは、アクセスキー ID (例: `AKIAIOSFODNN7EXAMPLE`) とシークレットアクセスキー (例: `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`) の 2 つで構成されています。ユーザー名とパスワードと同様に、リクエストを認証するために、アクセスキー ID とシークレットアクセスキーの両方を使用する必要があります。ユーザー名とパスワードと同様に、アクセスキーは安全に管理してください。
**重要**
[正規のユーザー ID を確認する](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId)ためであっても、アクセスキーを第三者に提供しないでください。これにより、 への永続的なアクセス権をユーザーに付与できます AWS アカウント。
アクセスキーペアを作成する場合、アクセスキー ID とシークレットアクセスキーを安全な場所に保存するように求めるプロンプトが表示されます。このシークレットアクセスキーは、作成時にのみ使用できます。シークレットアクセスキーを紛失した場合、IAM ユーザーに新規アクセスキーを追加する必要があります。アクセスキーは最大 2 つまで持つことができます。既に 2 つある場合は、新規キーペアを作成する前に、いずれかを削除する必要があります。手順を表示するには、IAM ユーザーガイドの「[アクセスキーの管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)」を参照してください。
## 管理者として Device Farm へのアクセスを他のユーザーに許可したい
他のユーザーが Device Farm にアクセスすることを許可するには、アクセスが必要なユーザーまたはアプリケーションにアクセス許可を付与する必要があります。 AWS IAM アイデンティティセンター を使用してユーザーとアプリケーションを管理する場合は、アクセスレベルを定義するアクセス許可セットをユーザーまたはグループに割り当てます。アクセス許可セットは、ユーザーまたはアプリケーションに関連付けられている IAM ロールに自動的に IAM ポリシーを作成して割り当てます。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[アクセス許可セット](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)」を参照してください。
IAM アイデンティティセンターを使用していない場合は、アクセスを必要としているユーザーまたはアプリケーションの IAM エンティティ (ユーザーまたはロール) を作成する必要があります。次に、Device Farm の適切な権限を付与するエンティティにポリシーをアタッチする必要があります。アクセス許可が付与されたら、ユーザーまたはアプリケーション開発者に認証情報を提供します。これらの認証情報を使用して AWSにアクセスします。IAM ユーザー、グループ、ポリシー、アクセス許可の作成の詳細については、「*IAM ユーザーガイド*」の「[IAM アイデンティティ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)」と「[IAM のポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)」を参照してください。
## AWS アカウント外のユーザーに Device Farm リソースへのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください:
+ Device Farm がこれらの機能をサポートしているかどうかについては、「[AWS Device Farm と IAM の連携方法](security_iam_service-with-iam.md)」で参照できます。
+ 所有 AWS アカウント している のリソースへのアクセスを提供する方法については、[「IAM ユーザーガイド」の「所有 AWS アカウント している別の の IAM ユーザーへのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。 **
+ リソースへのアクセスをサードパーティーに提供する方法については AWS アカウント、*IAM ユーザーガイド*の[「サードパーティー AWS アカウント が所有する へのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。
+ クロスアカウントアクセスにおけるロールとリソースベースのポリシーの使用方法の違いについては、「*IAM ユーザーガイド*」の「[IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)」を参照してください。
# のコンプライアンス検証AWS Device Farm
サードパーティーの監査者は、複数の AWS Device Farm コンプライアンスプログラムの一環として AWS のセキュリティとコンプライアンスを評価します。これらのプログラムとしては SOC、PCI、FedRAMP、HIPAA などがあります。AWS Device Farm は AWS コンプライアンスプログラムの対象ではありません。
特定のコンプライアンスプログラムの対象となる AWS サービスのリストについては、「[コンプライアンスプログラムによる AWS 対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。一般的な情報については、「[AWSコンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。
AWS Artifact を使用して、サードパーティーの監査レポートをダウンロードできます。詳細については、[Downloading Reports in AWS](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) および を参照してください。
Device Farm を使用する際のユーザーのコンプライアンス責任は、ユーザーのデータの機密性や貴社のコンプライアンス目的、適用される法律および規制によって決まります。AWS では、コンプライアンスに役立つ以下のリソースを提供しています。
+ [セキュリティおよびコンプライアンスのクイックスタートガイド](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) – これらのデプロイガイドでは、アーキテクチャ上の考慮事項について説明し、セキュリティとコンプライアンスに重点を置いたベースライン環境を AWS でデプロイするための手順を説明します。
+ [AWS コンプライアンスリソース](https://aws.amazon.com/compliance/resources/) – このワークブックおよびガイドのコレクションは、お客様の業界と拠点に適用される場合があります。
+ *AWS Config デベロッパーガイド*の「[ルールでのリソースの評価](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)」– AWS Config は、リソース設定が、社内のプラクティス、業界のガイドラインそして規制にどの程度適合しているのかを評価します。
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – この AWS のサービスは、AWS 内でのユーザーのセキュリティ状態に関する包括的な見解を提供し、業界のセキュリティ標準、およびベストプラクティスに対するコンプライアンスを確認するために役立ちます。
# でのデータ保護 AWS Device Farm
責任 AWS [共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)、 AWS Device Farm (Device Farm) でのデータ保護に適用されます。このモデルで説明されているように、 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 を使用して Device Farm AWS CLIまたは他の AWS のサービス を使用する場合も同様です。 AWS SDKs タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーへ URL を提供する場合は、そのサーバーへのリクエストを有効にするために認証情報を URL に含めないことを強くお勧めします。
## 転送中の暗号化
Device Farm エンドポイントは、特に明記されていない限り、署名された HTTPS (SSL/TLS) リクエストのみをサポートしています。アップロード URL を通じて Amazon S3 が取得元または配置先となるすべてのコンテンツは、SSL/TLS を使用して暗号化されます。HTTPS リクエストのサインイン方法の詳細については AWS、 AWS 全般のリファレンス[の AWS API リクエストの署名](https://docs.aws.amazon.com//general/latest/gr/signing_aws_api_requests.html)を参照してください。
テスト対象のアプリケーションが行う通信と、デバイスでのテストの実行中にインストールされるアプリケーションを暗号化して保護するのは、お客様の責任です。
## 保管中の暗号化
Device Farm のデスクトップブラウザーテスト機能は、テスト中に生成されたアーティファクトの保存時の暗号化をサポートします。
Device Farm の物理的モバイルデバイスのテストデータは保管時に暗号化されません。
## データ保持
Device Farm のデータは一定期間保持されます。保持期間が終了すると、データは Device Farm のバッキングストレージから削除されます。
| コンテンツタイプ | 保持期間 (日数) | メタデータ保持期間 (日数) |
| --- | --- | --- |
| アップロードされたアプリケーション | 30 | 30 |
| アップロードされたテストパッケージ | 30 | 30 |
| ログ | 400 | 400 |
| ビデオ録画や他のアーティファクト | 400 | 400 |
長期間保持するコンテンツをアーカイブするのは、お客様の責任です。
## データ管理
Device Farm のデータは、使用する機能に応じて異なる方法で管理されます。このセクションでは、Device Farm の使用中および使用後のデータの管理方法について説明します。
### デスクトップブラウザテスト
Selenium セッション中に使用されるインスタンスは保存されません。ブラウザ操作の結果として生成されたすべてのデータは、セッションが終了すると破棄されます。
この機能は現在、テスト中に生成されたアーティファクトの保存時の暗号化をサポートしています。
### 物理デバイスのテスト
以下のセクションでは、Device Farm を使用した後にデバイスをクリーンアップまたは破棄 AWS する手順について説明します。
Device Farm の物理的モバイルデバイスのテストデータは保管時に暗号化されません。
#### パブリックデバイスフリート
テスト実行が完了すると、Device Farm はパブリックデバイスフリートの各デバイスで、一連のクリーンアップタスク (アプリケーションのアンインストールなど) を実行します。アプリケーションのアンインストールまたは他のいずれかのクリーンアップステップを確認できない場合、デバイスが再利用される前にファクトリのリセットが実行されます。
**注記**
場合によっては (特に、アプリケーションのコンテキスト外で デバイスシステムを使用する場合)、セッション間でデータが保持されることがあります。また、Device Farm は各デバイスの使用中に行われるアクティビティのビデオとログをキャプチャするため、自動テストおよびリモートアクセスセッション中に、機密情報 (Google アカウント、Apple ID など)、個人情報、および他のセキュリティ上センシティブな詳細は入力しないことをお勧めします。
#### プライベートデバイス
プライベートデバイス契約の終了または解除後、デバイスは使用から除外され、AWS 破壊ポリシーに従って安全に破壊されます。詳細については、「[AWS Device Farm のプライベートデバイス](working-with-private-devices.md)」を参照してください。
## キー管理
現在 Device Farm は、保管中または転送中のデータ暗号化用外部キー管理は提供していません。
## ネットワーク間のトラフィックのプライバシー
Device Farm は、プライベートデバイスに対してのみ、Amazon VPC エンドポイントを使用して AWSのリソースに接続するように構成できます。アカウントに関連付けられた非パブリック AWS インフラストラクチャ (パブリック IP アドレスのない Amazon EC2 インスタンスなど) へのアクセスには、Amazon VPC エンドポイントを使用する必要があります。VPC エンドポイントの構成に関係なく、Device Farm は Device Farm ネットワーク全体でトラフィックを他のユーザーから分離します。
AWS ネットワーク外の接続は保護または安全である保証はなく、アプリケーションが行うインターネット接続を保護するのはユーザーの責任です。
# AWS Device Farm での耐障害性
AWS のグローバルインフラストラクチャは、AWS リージョンとアベイラビリティーゾーンを中心として構築されています。AWSリージョンには、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立および隔離されたアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、ゾーン間で中断することなく自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、および拡張性が優れています。
AWS リージョンとアベイラビリティーゾーンの詳細については、「[AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
Device Farm は `us-west-2` リージョンでのみ利用できるため、バックアップおよび復旧プロセスを実装することを強くお勧めします。Device Farm は、アップロードされたコンテンツの唯一のソースであってはなりません。
Device Farm では、パブリックデバイスの可用性が保たれるとは限りません。これらのデバイスは、障害発生率や隔離ステータスなどのさまざまな要因に応じて、パブリックデバイスプールに対して追加または削除されます。パブリックデバイスプール内のいずれかのデバイスの可用性に依存することはお勧めしません。
# のインフラストラクチャセキュリティ AWS Device Farm
マネージドサービスである AWS Device Farm は、 AWS グローバルネットワークセキュリティによって保護されています。 AWS セキュリティサービスと がインフラストラクチャ AWS を保護する方法については、[AWS 「 クラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して AWS 環境を設計するには、*「Security Pillar AWS Well‐Architected Framework*」の[「Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。
AWS 公開された API コールを使用して、ネットワーク経由で Device Farm にアクセスします。クライアントは次をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。
また、リクエストにはアクセスキー ID と、IAM プリンシパルに関連付けられているシークレットアクセスキーを使用して署名する必要があります。または、[AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) を使用して、一時的セキュリティ認証情報を生成し、リクエストに署名することもできます。
## 物理デバイステストのインフラストラクチャセキュリティ
物理デバイスのテスト中、デバイスは物理的に分離されています。ネットワークの分離により、ワイヤレスネットワークを介したデバイス間通信が防止されます。
パブリックデバイスは共有され、Device Farm はベストエフォートベースでデバイスを長期間にわたって安全に保ちます。デバイスに対する完全な管理者権限を取得する試み (*ルート化*または*脱獄*と呼ばれる行為) などの特定アクションが検出されると、パブリックデバイスが隔離されます。それらのデバイスは自動的にパブリックプールから削除され、手動点検の対象になります。
プライベートデバイスには、明示的に許可されている AWS アカウントのみがアクセスできます。Device Farm は、これらのデバイスを他のデバイスから物理的に隔離し、別のネットワークで保持します。
プライベートマネージドデバイスでは、Amazon VPC エンドポイントを使用して AWS アカウント内外の接続を保護するようにテストを設定できます。
## デスクトップブラウザテストのインフラストラクチャセキュリティ
デスクトップブラウザテスト機能を使用すると、すべてのテストセッションが互いに分離されます。Selenium インスタンスは、外部の中間サードパーティーなしでクロスコミュニケートすることはできません AWS。
Selenium WebDriver コントローラーへのすべてのトラフィックは、`createTestGridUrl` で生成された HTTPS エンドポイントを通過する必要があります。
各 Device Farm テストインスタンスがテスト対象のリソースに安全にアクセスできることを確認するのは、お客様の責任です。デフォルトでは、Device Farm のデスクトップブラウザテストインスタンスはパブリックインターネットにアクセスできます。インスタンスを VPC にアタッチすると、他の EC2 インスタンスと同様に動作し、VPC の設定と関連するネットワークコンポーネントによって決定されるリソースにアクセスします。AWS では、VPC のセキュリティを強化するために、[セキュリティグループ](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-security-groups.html)と[ネットワークアクセスコントロールリスト (ACL)](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-network-acls.html) を提供しています。セキュリティグループは、リソースのインバウンドトラフィックとアウトバウンドトラフィックをコントロールします。ネットワーク ACL は、サブネットのインバウンドトラフィックとアウトバウンドトラフィックをコントロールします。セキュリティグループは、ほとんどのサブネットに対して十分なアクセス制御を提供します。VPC に追加のセキュリティレイヤーが必要な場合は、ネットワーク ACL を使用できます。Amazon VPC を使用する際のセキュリティのベストプラクティスに関する一般的なガイドラインについては、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[VPC のセキュリティのベスト プラクティス](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-security-best-practices.html)」を参照してください。
# Device Farm での構成の脆弱性の分析と管理
Device Farm を使用すると、OS ベンダー、ハードウェアベンダー、電話キャリアなど、ベンダーによってアクティブに保守またはパッチされていないソフトウェアを実行できます。Device Farm は、ベストエフォート型として、最新のソフトウェアを管理しようとしますが、その設計上、脆弱な可能性があるソフトウェアの使用を認めることがあり、物理デバイスの特定のソフトウェアのバージョンが最新であるとは保証しません。
例えば、Android 4.4.2 で動作しているデバイスでテストを実行しても、Device Farm は、[StageFright と呼ばれる Android の脆弱性](https://en.wikipedia.org/wiki/Stagefright_(bug))に対してデバイスがパッチされていることを保証しません。デバイスにセキュリティ更新を提供するのは、デバイスのベンダー (場合によってはキャリア) の責任です。また、この脆弱性を使用する悪意のあるアプリケーションが自動検疫で検出されることは保証されません。
プライベートデバイスは、 との契約に従って維持されます AWS。
Device Farm は、お客様のアプリケーションが*ルーティング*または*ジェイルブレイキング*などのアクションを実行しないよう誠意ある最善の努力を行います。Device Farm は、パブリックプールから隔離されたデバイスを、手動で確認されるまで削除します。
お客様は、Python ホイールや Ruby Gem など、テストで使用するソフトウェアのライブラリやバージョンを最新に保つ責任があります。Device Farm では、テストライブラリを更新することをお勧めします。
これらのリソースは、テストの依存関係を最新に保つのに役立ちます:
+ Ruby Gem を保護する方法については、RubyGems ウェブサイトの「[セキュリティ慣行](https://guides.rubygems.org/security/)」を参照してください。
+ 既知の脆弱性の依存関係グラフをスキャンするために Pipenv によって使用され、Python Packaging Authority によって承認される安全パッケージについては、GitHub の「[セキュリティ脆弱性の検出](https://github.com/pypa/pipenv/blob/master/docs/advanced.rst#-detection-of-security-vulnerabilities)」を参照してください。
+ Open Web Application Security Project (OWASP) Maven 依存関係チェッカーについては、OWASP ウェブサイトの「[OWASP DependencyCheck](https://owasp.org/www-project-dependency-check/)」を参照してください。
自動化システムによって既知のセキュリティ問題が検出されなくても、セキュリティ問題がないことを意味するわけではありません。サードパーティーのライブラリまたはツールを使用するときは、常にデューデリジェンスを使用し、可能または合理的な場合は、暗号化署名を点検してください。
# Device Farm でのインシデント応答
Device Farm は、セキュリティの問題を示す可能性のある動作に関してデバイスを継続的にモニタリングします。 AWS が、テスト結果やパブリックデバイスに書き込まれたファイルなどの顧客データに別の顧客がアクセスできるケースを認識した場合、 は、 AWS サービス全体で使用される標準のインシデントアラートおよびレポートポリシーに従って、影響を受ける顧客 AWS に連絡します。
# Device Farm でのロギングとモニタリング
このサービスは、 の呼び出しを記録 AWS AWS アカウント し AWS CloudTrail、ログファイルを Amazon S3 バケットに配信するサービスである をサポートします。CloudTrail によって収集された情報を使用して、正常に行われたリクエスト AWS のサービス、リクエスト者、リクエスト日時などを判断できます。CloudTrail の詳細 (有効にする方法、ログファイルを検索する方法を含む) については、「[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)」を参照してください。
Device Farm による CloudTrail の使用についての詳細は、「[AWS CloudTrail による AWS Device Farm API コールのロギング](logging-using-cloudtrail.md)」を参照してください。
# Device Farm のセキュリティベストプラクティス
Device Farm には、独自のセキュリティポリシーを策定および実装する際に考慮すべきさまざまなセキュリティ機能が備わっています。以下のベストプラクティスは一般的なガイドラインであり、完全なセキュリティソリューションを説明するものではありません。これらのベストプラクティスはお客様の環境に必ずしも適切または十分でない可能性があるので、処方箋ではなく、あくまで有用な考慮事項とお考えください。
+ 使用する継続的統合 (CI) システムに、IAM で可能な最小限の権限を付与します。各 CI システムテストには一時的な認証情報を使用することを検討してください。これにより、CI システムが不正アクセスされても偽のリクエストを行えなくなります。一時的な認証情報についての詳細は、「[IAM ユーザーガイド](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerole)」を参照してください。
+ カスタムテスト環境で `adb` コマンドを使用して、アプリケーションによって作成されたコンテンツをクリーンアップします。カスタムテスト環境の詳細については、「[AWS Device Farm のカスタムテスト環境](custom-test-environments.md)」を参照してください。