

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 의 보안 AWS Device Farm
<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 Device Farm참조하세요.
+ **클라우드 내 보안** – 귀하의 책임은 귀하가 사용하는 AWS 서비스에 의해 결정됩니다. 또한 귀하는 귀사의 데이터 민감도, 귀사의 요구 사항, 관련 법률 및 규정을 비롯한 기타 요소에 대해서도 책임이 있습니다.

이 설명서는 Device Farm 사용 시 공동 책임 모델을 적용하는 방법을 이해하는 데 도움이 됩니다. 다음 주제에서는 보안 및 규정 준수 목표를 충족하도록 Device Farm을 구성하는 방법을 보여줍니다. 또한 Device Farm 리소스를 모니터링하고 보호하는 데 도움이 되는 다른 AWS 서비스를 사용하는 방법을 배우게 됩니다.

**Topics**
+ [AWS Device Farm의 Identity and Access Management](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)
+ [디바이스 에이전트의 보안 모범 사례](security-best-practices.md)

# AWS Device Farm의 Identity and Access Management
<a name="security-iam"></a>

## 대상
<a name="security_iam_audience"></a>

 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 ID 기반 정책 예제](security_iam_id-based-policy-examples.md) 참조)

## ID를 통한 인증
<a name="security_iam_authentication"></a>

인증은 자격 증명 자격 증명을 AWS 사용하여에 로그인하는 방법입니다. AWS 계정 루트 사용자, IAM 사용자 또는 IAM 역할을 수임하여 인증되어야 합니다.

 AWS IAM Identity Center (IAM Identity Center), Single Sign-On 인증 또는 Google/Facebook 자격 증명과 같은 자격 증명 소스의 자격 증명을 사용하여 페더레이션 자격 증명으로 로그인할 수 있습니다. 로그인하는 방법에 대한 자세한 내용은 *AWS Sign-In 사용 설명서*의 [AWS 계정에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 섹션을 참조하세요.

프로그래밍 방식 액세스를 위해는 요청에 암호화 방식으로 서명할 수 있는 SDK 및 CLI를 AWS 제공합니다. 자세한 내용은 *IAM 사용 설명서*의 [API 요청용AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) 섹션을 참조하세요.

### AWS 계정 루트 사용자
<a name="security_iam_authentication-rootuser"></a>

 를 생성할 때 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한이 있는 AWS 계정 *theroot 사용자*라는 하나의 로그인 자격 증명으로 AWS 계정시작합니다. 일상적인 태스크에 루트 사용자를 사용하지 않을 것을 강력히 권장합니다. 루트 사용자가 필요한 작업 목록은 *IAM 사용자 설명서*의 [루트 사용자 자격 증명이 필요한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)을 참조하세요.

### IAM 사용자 및 그룹
<a name="security_iam_authentication-iamuser"></a>

*[IAM 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*는 단일 개인 또는 애플리케이션에 대한 특정 권한을 가진 ID입니다. 장기 자격 증명이 있는 IAM 사용자 대신 임시 자격 증명을 사용하는 것이 좋습니다. 자세한 내용은 *IAM 사용 설명서*의 자격 [증명 공급자와의 페더레이션을 사용하여 임시 자격 증명을 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 역할
<a name="security_iam_authentication-iamrole"></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 사용 설명서*의 [교차 계정 리소스 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)를 참조하세요.

# AWS Device Farm이 IAM과 연동되는 방식
<a name="security_iam_service-with-iam"></a>

IAM을 사용하여 Device Farm에 대한 액세스를 관리하려면 먼저 어떤 IAM 기능을 Device Farm에 사용할 수 있는지를 이해해야 합니다. 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 자격 증명 기반 정책
<a name="security_iam_service-with-iam-id-based-policies"></a>

IAM 자격 증명 기반 정책을 사용하면 허용되거나 거부되는 작업과 리소스 및 작업이 허용되거나 거부되는 조건을 지정할 수 있습니다. Device Farm은 특정 작업, 리소스 및 조건 키를 지원합니다. 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"></a>

관리자는 AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.

JSON 정책의 `Action`요소는 정책에서 액세스를 허용하거나 거부하는 데 사용할 수 있는 작업을 설명합니다. 연결된 작업을 수행할 수 있는 권한을 부여하기 위한 정책에 작업을 포함하세요.

Device Farm의 정책 작업은 작업 앞에 다음 접두사 `devicefarm:`를 사용합니다. 예를 들어 Device Farm 데스크톱 브라우저를 통한 `CreateTestGridUrl` API 작업 테스트로 Selenium 세션을 시작할 수 있는 권한을 부여하려면 정책에 `devicefarm:CreateTestGridUrl` 작업을 포함합니다. 정책 문에는 `Action` 또는 `NotAction` 요소가 포함되어야 합니다. CodeDeploy는 이 서비스로 수행할 수 있는 작업을 설명하는 고유한 작업 세트를 정의합니다.

명령문 하나에 여러 태스크를 지정하려면 다음과 같이 쉼표로 구분합니다.

```
"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)을 참조하세요.

### 리소스
<a name="security_iam_service-with-iam-id-based-policies-resources"></a>

관리자는 AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.

`Resource` JSON 정책 요소는 작업이 적용되는 하나 이상의 객체를 지정합니다. 모범 사례에 따라 [Amazon 리소스 이름(ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)을 사용하여 리소스를 지정합니다. 리소스 수준 권한을 지원하지 않는 작업의 경우, 와일드카드(\$1)를 사용하여 해당 문이 모든 리소스에 적용됨을 나타냅니다.

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



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)을 참조하세요.

### 조건 키
<a name="security_iam_service-with-iam-id-based-policies-conditionkeys"></a>

관리자는 AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지 지정할 수 있습니다. 즉, 어떤 **보안 주체**가 어떤 **리소스**와 어떤 **조건**에서 **작업**을 수행할 수 있는지를 지정할 수 있습니다.

`Condition` 요소는 정의된 기준에 따라 문이 실행되는 시기를 지정합니다. 같음(equals) 또는 미만(less than)과 같은 [조건 연산자](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) 단원을 참조하세요.

### 예제
<a name="security_iam_service-with-iam-id-based-policies-examples"></a>



CodeDeploy ID 기반 정책 예제를 보려면 [AWS Device Farm ID 기반 정책 예제](security_iam_id-based-policy-examples.md) 단원을 참조하세요.

## Device Farm 리소스 기반 정책
<a name="security_iam_service-with-iam-resource-based-policies"></a>

Device Farm은 리소스 기반 정책을 지원하지 않습니다.

## 액세스 제어 목록
<a name="security_iam_service-with-iam-acls"></a>

Device Farm은 액세스 제어 목록(ACL)을 지원하지 않습니다.

## Device Farm 태그 기반 권한 부여
<a name="security_iam_service-with-iam-tags"></a>

태그를 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 역할
<a name="security_iam_service-with-iam-roles"></a>

[IAM 역할은](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 특정 권한이 있는 AWS 계정의 엔터티입니다.

### Device Farm에서 임시 보안 인증 사용
<a name="security_iam_service-with-iam-roles-tempcreds"></a>

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 작업을 호출하여 임시 보안 자격 증명을 얻습니다.

### 서비스 연결 역할
<a name="security_iam_service-with-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 서비스가 다른 서비스의 리소스에 액세스하여 사용자를 대신하여 작업을 완료할 수 있습니다. 서비스 연결 역할은 IAM 계정에 나타나고 서비스가 소유합니다. IAM 관리자는 서비스 연결 역할의 권한을 볼 수는 있지만 편집할 수는 없습니다.

Device Farm은 Device Farm 데스크톱 브라우저 테스트 기능에서 서비스 연결 역할을 사용합니다. 이러한 역할에 대한 자세한 내용은 개발자 안내서의 [Device Farm 데스크톱 브라우저 테스트에서 서비스 연결 역할 사용](https://docs.aws.amazon.com//devicefarm/latest/testgrid/using-service-linked-roles.html)을 참조하십시오.

### 서비스 역할
<a name="security_iam_service-with-iam-roles-service"></a>

Device Farm은 서비스 역할을 지원하지 않습니다.

이 기능을 사용하면 서비스가 사용자를 대신하여 [서비스 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role)을 수임할 수 있습니다. 이 역할을 사용하면 서비스가 다른 서비스의 리소스에 액세스해 사용자를 대신해 작업을 완료할 수 있습니다. 서비스 역할은 IAM 계정에 나타나고, 해당 계정이 소유합니다. 즉, IAM 관리자가 이 역할에 대한 권한을 변경할 수 있습니다. 그러나 권한을 변경하면 서비스의 기능이 손상될 수 있습니다.



## 정책을 사용하여 액세스 관리
<a name="security_iam_access-manage"></a>

정책을 AWS 생성하고 자격 증명 또는 리소스에 연결하여 AWS 에서 액세스를 제어합니다. 정책은 자격 증명 또는 리소스와 연결될 때 권한을 정의합니다.는 보안 주체가 요청할 때 이러한 정책을 AWS 평가합니다. 대부분의 정책은에 JSON 문서 AWS 로 저장됩니다. JSON 정책 문서에 대한 자세한 내용은 *IAM 사용 설명서*의 [JSON 정책 개요](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) 섹션을 참조하세요.

정책을 사용하여 관리자는 어떤 **보안 주체**가 어떤 **리소스**에 대해 어떤 **조건**에서 **작업**을 수행할 수 있는지 정의하여 누가 무엇을 액세스할 수 있는지 지정합니다.

기본적으로 사용자 및 역할에는 어떠한 권한도 없습니다. IAM 관리자는 IAM 정책을 생성하고 사용자가 수임할 수 있는 역할에 추가합니다. IAM 정책은 작업을 수행하기 위해 사용하는 방법과 관계없이 작업에 대한 권한을 정의합니다.

### ID 기반 정책
<a name="security_iam_access-manage-id-based-policies"></a>

ID 기반 정책은 ID(사용자, 사용자 그룹 또는 역할)에 연결하는 JSON 권한 정책 문서입니다. 이러한 정책은 자격 증명이 수행할 수 있는 작업, 대상 리소스 및 이에 관한 조건을 제어합니다. ID 기반 정책을 생성하는 방법을 알아보려면 *IAM 사용 설명서*에서 [고객 관리형 정책으로 사용자 지정 IAM 권한 정의](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)를 참조하세요.

ID 기반 정책은 *인라인 정책*(단일 ID에 직접 포함) 또는 *관리형 정책*(여러 ID에 연결된 독립 실행형 정책)일 수 있습니다. 관리형 정책 또는 인라인 정책을 선택하는 방법을 알아보려면 *IAM 사용 설명서*의 [관리형 정책 및 인라인 정책 중에서 선택](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) 섹션을 참조하세요.

다음 표에는 Device Farm AWS 관리형 정책의 개요가 서술되어 있습니다.


| 변경 | 설명 | Date | 
| --- | --- | --- | 
|  [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일 | 

### 기타 정책 유형
<a name="security_iam_access-manage-other-policies"></a>

AWS 는 보다 일반적인 정책 유형에서 부여한 최대 권한을 설정할 수 있는 추가 정책 유형을 지원합니다.
+ **권한 경계** - ID 기반 정책에서 IAM 엔터티에 부여할 수 있는 최대 권한을 설정합니다. 자세한 정보는 *IAM 사용 설명서*의 [IAM 엔터티의 권한 범위](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)를 참조하세요.
+ **서비스 제어 정책(SCP)** - AWS Organizations내 조직 또는 조직 단위에 대한 최대 권한을 지정합니다. 자세한 내용은AWS Organizations 사용 설명서의 [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)을 참조하세요.**
+ **리소스 제어 정책(RCP)** – 계정의 리소스에 사용할 수 있는 최대 권한을 설정합니다. 자세한 내용은 *AWS Organizations 사용 설명서*의 [리소스 제어 정책(RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)을 참조하세요.
+ **세션 정책** – 역할 또는 페더레이션 사용자에 대해 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책입니다. 자세한 내용은 *IAM 사용 설명서*의 [세션 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)을 참조하세요.

### 여러 정책 유형
<a name="security_iam_access-manage-multiple-policies"></a>

여러 정책 유형이 요청에 적용되는 경우, 결과 권한은 이해하기가 더 복잡합니다. 에서 여러 정책 유형이 관련될 때 요청을 허용할지 여부를 AWS 결정하는 방법을 알아보려면 *IAM 사용 설명서*의 [정책 평가 로직](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)을 참조하세요.

# AWS Device Farm ID 기반 정책 예제
<a name="security_iam_id-based-policy-examples"></a>

기본적으로 IAM 사용자 및 역할은 Device Farm 리소스를 생성하거나 수정할 수 있는 권한이 없습니다. 또한 AWS Management Console AWS CLI또는 AWS API를 사용하여 작업을 수행할 수 없습니다. IAM 관리자는 지정된 리소스에서 특정 API 작업을 수행할 수 있는 권한을 사용자와 역할에게 부여하는 IAM 정책을 생성해야 합니다. 그런 다음 관리자는 해당 권한이 필요한 IAM 사용자 또는 그룹에 이러한 정책을 연결해야 합니다.

이러한 예제 JSON 정책 문서를 사용하여 IAM ID 기반 정책을 생성하는 방법을 알아보려면 *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)
+ [하나의 Device Farm 데스크톱 브라우저 테스트 프로젝트 액세스](#security_iam_id-based-policy-examples-access-one-project)
+ [태그를 기반으로 하는 Device Farm 데스크톱 브라우저 테스트 프로젝트 보기](#security_iam_id-based-policy-examples-view-project-tags)

## 정책 모범 사례
<a name="security_iam_service-with-iam-policy-best-practices"></a>

ID 기반 정책에 따라 계정에서 사용자가 Device Farm 리소스를 생성, 액세스 또는 삭제할 수 있는지 여부가 결정됩니다. 이 작업으로 인해 AWS 계정에 비용이 발생할 수 있습니다. ID 기반 정책을 생성하거나 편집할 때는 다음 지침과 권장 사항을 따르세요.
+ ** 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 Access Analyzer를 통해 IAM 정책을 확인하여 안전하고 기능적인 권한 보장** - IAM Access Analyzer에서는 IAM 정책 언어(JSON)와 모범 사례가 정책에서 준수되도록 새로운 및 기존 정책을 확인합니다. IAM Access Analyzer는 100개 이상의 정책 확인 항목과 실행 가능한 추천을 제공하여 안전하고 기능적인 정책을 작성하도록 돕습니다. 자세한 내용은 *IAM 사용 설명서*의 [IAM Access Analyzer에서 정책 검증](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)을 참조하세요.
+ **다중 인증(MFA) 필요 -**에서 IAM 사용자 또는 루트 사용자가 필요한 시나리오가 있는 경우 추가 보안을 위해 MFA를 AWS 계정켭니다. 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)를 참조하세요.

## 사용자가 자신의 고유한 권한을 볼 수 있도록 허용
<a name="security_iam_id-based-policy-examples-view-own-permissions"></a>

이 예제는 IAM 사용자가 자신의 사용자 ID에 연결된 인라인 및 관리형 정책을 볼 수 있도록 허용하는 정책을 생성하는 방법을 보여줍니다. 이 정책에는 콘솔에서 또는 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": "*"
        }
    ]
}
```

## 하나의 Device Farm 데스크톱 브라우저 테스트 프로젝트 액세스
<a name="security_iam_id-based-policy-examples-access-one-project"></a>

이 예제에서는 AWS 계정의 IAM 사용자에게 Device Farm Destktop 브라우저 테스트 프로젝트 중 하나인에 대한 액세스 권한을 부여하려고 합니다`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 정책은 CI 실행기가 업로드를 생성하고 해당 업로드를 사용하여 테스트 실행을 예약함으로써 새로운 Device Farm 기본 앱 테스트를 시작할 수 있도록 허용하는 최소 정책을 보여줍니다.

## 태그를 기반으로 하는 Device Farm 데스크톱 브라우저 테스트 프로젝트 보기
<a name="security_iam_id-based-policy-examples-view-project-tags"></a>

ID 기반 정책의 조건을 사용하여 태그를 기반으로 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 보안 인증 및 액세스 문제 해결
<a name="security_iam_troubleshoot"></a>

다음 정보를 사용하여 Device Farm 및 IAM에서 발생할 수 있는 공통적인 문제를 진단하고 수정할 수 있습니다.

## Device Farm에서 작업을 수행할 권한이 없음
<a name="security_iam_troubleshoot-no-permissions"></a>

에서 작업을 수행할 권한이 AWS Management Console 없다는 오류가 수신되면 관리자에게 문의하여 도움을 받아야 합니다. 관리자는 사용자 이름과 암호를 제공한 사람입니다.

다음 예제 오류는 IAM 사용자인 `mateojackson`가 콘솔을 사용하여 실행에 대한 세부 정보를 보려고 하지만 `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을 수행하도록 인증되지 않음
<a name="security_iam_troubleshoot-passrole"></a>

`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`작업을 수행할 수 있도록 Mary의 정책을 업데이트해야 합니다.

도움이 필요한 경우 AWS 관리자에게 문의하세요. 관리자는 로그인 자격 증명을 제공한 사람입니다.

## 액세스 키를 보아야 합니다.
<a name="security_iam_troubleshoot-access-keys"></a>

IAM 사용자 액세스 키를 생성한 후에는 언제든지 액세스 키 ID를 볼 수 있습니다. 하지만 보안 액세스 키는 다시 볼 수 없습니다. 보안 액세스 키를 잃어버린 경우 새로운 액세스 키 페어를 생성해야 합니다.

액세스 키는 액세스 키 ID(예: `AKIAIOSFODNN7EXAMPLE`)와 보안 액세스 키(예: `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`)의 두 가지 부분으로 구성됩니다. 사용자 이름 및 암호와 같이 액세스 키 ID와 보안 액세스 키를 함께 사용하여 요청을 인증해야 합니다. 사용자 이름과 암호를 관리하는 것처럼 안전하게 액세스 키를 관리합니다.

**중요**  
[정식 사용자 ID를 찾는 데](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId) 도움이 되더라도 액세스 키를 타사에 제공하지 마시기 바랍니다. 이렇게 하면 누군가에게에 대한 영구 액세스 권한을 부여할 수 있습니다 AWS 계정.

액세스 키 페어를 생성할 때는 액세스 키 ID와 보안 액세스 키를 안전한 위치에 저장하라는 메시지가 나타납니다. 보안 액세스 키는 생성할 때만 사용할 수 있습니다. 하지만 보안 액세스 키를 잃어버린 경우 새로운 액세스 키를 IAM 사용자에게 추가해야 합니다. 최대 두 개의 액세스 키를 가질 수 있습니다. 이미 두 개가 있는 경우 새로 생성하려면 먼저 키 페어 하나를 삭제해야 합니다. 지침을 보려면 *IAM 사용 설명서*의 [액세스 키 관리](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)를 참조하십시오.

## 관리자인데, 다른 사용자가 Device Farm에 액세스할 수 있게 허용하려고 합니다
<a name="security_iam_troubleshoot-admin-delegate"></a>

다른 사용자가 Device Farm에 액세스하도록 허용하려면 액세스가 필요한 사람 또는 애플리케이션에 권한을 부여해야 합니다. AWS IAM Identity Center 를 사용하여 사용자 및 애플리케이션을 관리하는 경우 사용자 또는 그룹에 권한 세트를 할당하여 액세스 수준을 정의합니다. 권한 세트는 IAM 정책을 자동으로 생성하고 사용자 또는 애플리케이션과 연결된 IAM 역할에 할당합니다. 자세한 내용은 *AWS IAM Identity Center 사용 설명서*에서 [권한 세트](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)를 참조하세요.

IAM Identity Center를 사용하지 않는 경우 액세스가 필요한 사용자 또는 애플리케이션에 대한 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 리소스에 액세스하도록 허용하고 싶습니다.
<a name="security_iam_troubleshoot-cross-account-access"></a>

다른 계정의 사용자 또는 조직 외부의 사람이 리소스에 액세스할 때 사용할 수 있는 역할을 생성할 수 있습니다. 역할을 수임할 신뢰할 수 있는 사람을 지정할 수 있습니다. 리소스 기반 정책 또는 액세스 제어 목록(ACL)을 지원하는 서비스의 경우, 이러한 정책을 사용하여 다른 사람에게 리소스에 대한 액세스 권한을 부여할 수 있습니다.

자세한 내용은 다음을 참조하세요.
+ Device Farm에서 이러한 기능을 지원하는지 여부를 알아보려면 [AWS Device Farm이 IAM과 연동되는 방식](security_iam_service-with-iam.md) 단원을 참조하세요.
+ 소유 AWS 계정 한의 리소스에 대한 액세스 권한을 제공하는 방법을 알아보려면 [IAM 사용 설명서의 소유한 다른의 IAM 사용자에게 액세스 권한 제공을 참조 AWS 계정 하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html). ** 
+ 리소스에 대한 액세스 권한을 타사에 제공하는 방법을 알아보려면 *IAM 사용 설명서*의 [타사 AWS 계정 소유에 대한 액세스 권한 제공을](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) AWS 계정참조하세요.
+ 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
<a name="ATP-compliance"></a>

타사 감사자는 여러 AWS 규정 준수 프로그램의 일환으로 AWS Device Farm의 보안 및 규정 준수를 평가합니다. 여기에는 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(을)를 사용하여 타사 감사 보고서를 다운로드할 수 있습니다. 자세한 내용은 [AWS Artifact에서 보고서 다운로드](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
<a name="data-protection"></a>

 AWS [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/) AWS Device Farm (Device Farm)의 데이터 보호에 적용됩니다. 이 모델에 설명된 대로 AWS 는 모든를 실행하는 글로벌 인프라를 보호할 책임이 있습니다 AWS 클라우드. 사용자는 이 인프라에 호스팅되는 콘텐츠에 대한 통제 권한을 유지할 책임이 있습니다. 사용하는 AWS 서비스 의 보안 구성과 관리 태스크에 대한 책임도 사용자에게 있습니다. 데이터 프라이버시에 관한 자세한 내용은 [데이터 프라이버시 FAQ](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 Identity Center 또는 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 S3에 저장된 민감한 데이터를 검색하고 보호하는 데 도움이 되는 Amazon Macie와 같은 고급 관리형 보안 서비스를 사용합니다.
+ 명령줄 인터페이스 또는 API를 AWS 통해에 액세스할 때 FIPS 140-3 검증 암호화 모듈이 필요한 경우 FIPS 엔드포인트를 사용합니다. 사용 가능한 FIPS 엔드포인트에 대한 자세한 내용은 [연방 정보 처리 표준(FIPS) 140-3](https://aws.amazon.com/compliance/fips/)을 참조하세요.

고객의 이메일 주소와 같은 기밀 정보나 중요한 정보는 태그나 **이름** 필드와 같은 자유 형식 텍스트 필드에 입력하지 않는 것이 좋습니다. 여기에는 Device Farm 또는 기타 AWS 서비스 에서 콘솔 AWS CLI, API 또는 AWS SDKs를 사용하여 작업하는 경우가 포함됩니다. 이름에 사용되는 태그 또는 자유 형식 텍스트 필드에 입력하는 모든 데이터는 청구 또는 진단 로그에 사용될 수 있습니다. 외부 서버에 URL을 제공할 때 해당 서버에 대한 요청을 검증하기 위해 자격 증명을 URL에 포함해서는 안 됩니다.

## 전송 중 암호화
<a name="data-protection-encryption-transit"></a>

 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) 참조하세요.

테스트되는 애플리케이션에서 수행하는 모든 통신과 디바이스 테스트를 실행하는 과정에서 설치되는 모든 애플리케이션을 암호화하고 보안을 유지하는 것은 사용자의 책임입니다.

## 저장 중 암호화
<a name="data-protection-encryption-rest"></a>

Device Farm의 데스크톱 브라우저 테스트 기능은 테스트 중에 생성된 아티팩트에 대해 저장 중 암호화를 지원합니다.

Device Farm의 물리적 모바일 디바이스 테스트 데이터는 저장 중 암호화되지 않습니다.

## 데이터 보존
<a name="data-protection-retention"></a>

Device Farm의 데이터는 제한된 시간 동안 보존됩니다. 보존 기간이 만료되면 Device Farm의 백업 스토리지에서 데이터가 제거됩니다.


| 콘텐츠 유형 | 보존 기간(일) | 메타데이터 보존 기간(일) | 
| --- | --- | --- | 
| 업로드된 애플리케이션 | 30 | 30 | 
| 업로드된 테스트 패키지 | 30 | 30 | 
| 로그 | 400 | 400 | 
| 비디오 녹화 자료 및 기타 아티팩트 | 400 | 400 | 

더 오랜 보존을 위해 콘텐츠를 아카이빙하는 것은 사용자의 책임입니다.

## 데이터 관리
<a name="data-protection-management"></a>

Device Farm 의 데이터는 사용되는 기능에 따라 다르게 관리됩니다. 이 섹션에서는 Device Farm을 사용하는 동안과 사용한 후에 데이터를 관리하는 방법에 대해 설명합니다.

### 데스크톱 브라우저 테스트
<a name="data-protection-management-testgrid"></a>

Selenium 세션 중에 사용된 인스턴스는 저장되지 않습니다. 세션이 종료되면 브라우저 상호 작용의 결과로 생성된 모든 데이터가 삭제됩니다.

이 기능은 현재 테스트 중에 생성된 아티팩트에 대해 저장 중 암호화를 지원합니다.

### 물리적 디바이스 테스트
<a name="data-protection-management-physical"></a>

다음 섹션에서는 Device Farm을 사용한 후 디바이스를 정리하거나 폐기하는 데 AWS 필요한 단계에 대한 정보를 제공합니다.

Device Farm의 물리적 모바일 디바이스 테스트 데이터는 저장 시 암호화되지 않습니다.

#### 퍼블릭 디바이스 플릿
<a name="data-protection-management-public"></a>

테스트 실행이 완료되면 이 앱 설치 제거를 비롯하여 퍼블릭 디바이스 플릿의 각 디바이스에서 일련의 정리를 수행합니다. 앱 설치 제거나 다른 정리 단계를 확인할 수 없는 경우 다시 사용하기 전에 디바이스가 초기 기본값을 수신합니다.

**참고**  
경우에 따라, 특히 앱 컨텍스트 밖에서 디바이스 시스템을 이용하는 경우 세션 간에 데이터를 유지할 수 있습니다. 이 이유로 인해 그리고 각 디바이스를 사용하는 동안 발생하는 활동 로그와 비디오를 Device Farm이 캡처하기 때문에 자동 테스트 및 원격 액세스 세션 중에는 중요한 정보(예: Google 계정 또는 Apple ID), 개인 정보, 기타 보안상 중요한 세부 정보를 입력하지 않는 것이 좋습니다.

#### 프라이빗 디바이스
<a name="data-protection-management-private"></a>

프라이빗 디바이스 계약이 만료되거나 종료된 후에는 AWS 파쇄 정책에 따라 사용할 수 없도록 디바이스가 제거되며 안전하게 파쇄됩니다. 자세한 내용은 [AWS Device Farm의 프라이빗 디바이스](working-with-private-devices.md) 단원을 참조하세요.

## 키 관리
<a name="data-protection-key-management"></a>

 현재 Device Farm은 저장이나 전송 중인 데이터의 암호화를 위한 외부 키 관리 기능을 제공하지 않습니다.

## 인터네트워크 트래픽 개인 정보
<a name="data-protection-traffic-privacy"></a>

 Device Farm은 Amazon VPC 엔드포인트를 사용하여 AWS의 리소스에 연결하도록 프라이빗 디바이스에 대해서만 구성할 수 있습니다. 계정과 연결된 모든 비공개 AWS 인프라(예: 퍼블릭 IP 주소가 없는 Amazon EC2 인스턴스)에 대한 액세스는 Amazon VPC 엔드포인트를 사용해야 합니다. VPC 엔드포인트 구성과 관계없이 Device Farm은 Device Farm 네트워크 전체의 다른 사용자로부터 트래픽을 격리합니다.

 AWS 네트워크 외부의 연결은 보안 또는 안전이 보장되지 않으며 애플리케이션이 수행하는 인터넷 연결을 보호하는 것은 사용자의 책임입니다.

# AWS Device Farm의 복원성
<a name="disaster-recovery-resiliency"></a>

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
<a name="infrastructure-security"></a>

관리형 서비스인 AWS Device Farm 는 AWS 글로벌 네트워크 보안으로 보호됩니다. AWS 보안 서비스 및가 인프라를 AWS 보호하는 방법에 대한 자세한 내용은 [AWS 클라우드 보안을](https://aws.amazon.com/security/) 참조하세요. 인프라 보안 모범 사례를 사용하여 AWS 환경을 설계하려면 *보안 원칙 AWS Well‐Architected Framework*의 [인프라 보호를](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(Ephemeral Diffie-Hellman) 또는 ECDHE(Elliptic Curve Ephemeral Diffie-Hellman)와 같은 완전 전송 보안(PFS)이 포함된 암호 제품군. Java 7 이상의 최신 시스템은 대부분 이러한 모드를 지원합니다.

또한 요청은 액세스 키 ID 및 IAM 위탁자와 관련된 시크릿 액세스 키를 사용하여 서명해야 합니다. 또는 [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html)(AWS STS)를 사용하여 임시 보안 자격 증명을 생성하여 요청에 서명할 수 있습니다.

## 물리적 디바이스 테스트 시 인프라 보안
<a name="infrastructure-security-physical-device-testing"></a>

디바이스는 물리적 디바이스 테스트 시 물리적으로 분리됩니다. 네트워크 격리로 무선 네트워크를 통한 디바이스 간 통신이 차단됩니다.

퍼블릭 디바이스는 공유되며 Device Farm은 시간 경과에 따라 디바이스를 안전하게 유지하기 위해 최선의 노력을 기울입니다. 디바이스에 대한 완전한 관리자 권리를 획득하려는 시도(*루팅* 또는 *탈옥*이라고 하는 사례)와 같은 특정 작업으로 인해 퍼블릭 디바이스가 격리됩니다. 퍼블릭 디바이스는 퍼블릭 풀에서 자동으로 제거되고 수동 검토에 배치됩니다.

프라이빗 디바이스는 명시적으로 권한이 부여된 AWS 계정만 액세스할 수 있습니다. Device Farm은 이러한 디바이스를 다른 디바이스로부터 물리적으로 분리하여 별도의 네트워크에 보관합니다.

프라이빗 관리형 디바이스에서는 Amazon VPC 엔드포인트를 사용하여 AWS 계정 안팎의 연결을 보호하도록 테스트를 구성할 수 있습니다.

## 데스크톱 브라우저 테스트 시 인프라 보안
<a name="infrastructure-security-desktop-browser-testing"></a>

데스크톱 브라우저 테스트 기능을 사용하는 경우 모든 테스트 세션이 서로 분리됩니다. Selenium 인스턴스는 외부의 중간 타사 없이는 교차 통신할 수 없습니다 AWS.

Selenium WebDriver 컨트롤러에 대한 모든 트래픽은 `createTestGridUrl`을 사용하여 생성된 HTTPS 엔드포인트를 통해 이루어져야 합니다.

각 Device Farm 테스트 인스턴스에서 테스트하는 리소스에 안전하게 액세스할 수 있는지 사용자가 확인해야 합니다. 기본적으로 Device Farm의 데스크톱 브라우저 테스트 인스턴스는 퍼블릭 인터넷에 액세스할 수 있습니다. VPC에 인스턴스를 연결하면 VPC의 구성 및 연결된 네트워킹 구성 요소에 따라 결정된 리소스에 액세스할 수 있는 다른 EC2 인스턴스처럼 동작합니다. 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의 구성 취약성 분석 및 관리
<a name="security-vulnerability-analysis-and-management"></a>

Device Farm을 사용하면 공급업체(예: OS 공급업체, 하드웨어 공급업체 또는 통신사)에서 적극적으로 유지 관리하거나 패치하지 않는 소프트웨어를 실행할 수 있습니다. Device Farm은 소프트웨어를 최신 상태로 유지하기 위해 최선을 다하지만 잠재적으로 취약한 소프트웨어를 사용할 수 있도록 설계된 물리적 디바이스 내 소프트웨어의 특정 버전이 최신 상태임을 보장하지는 않습니다.

예를 들어 Android 4.4.2를 실행하는 장치에서 테스트를 수행하는 경우는 [StageFright라고 하는 Android의 취약성](https://en.wikipedia.org/wiki/Stagefright_(bug))에 대해 디바이스가 패치되었는지 보장하지 않습니다. 디바이스에 보안 업데이트를 제공하는 것은 디바이스의 공급업체(때로는 통신사)에 달려 있습니다. 이 취약성을 사용하는 악성 애플리케이션은 자동 격리에 의해 포착되지 않을 수 있습니다.

프라이빗 디바이스는 계약에 따라 유지됩니다 AWS.

 Device Farm은 고객 애플리케이션이 *루팅*이나 *탈옥*과 같은 행동을 하지 못하도록 최선을 다합니다. Device Farm은 격리된 디바이스를 수동으로 검토할 때까지 공용 풀에서 제거합니다.

Python wheel 및 Ruby gem과 같이 테스트에 사용하는 소프트웨어의 모든 라이브러리 또는 버전을 최신 상태로 유지하는 것은 사용자의 책임입니다. Device Farm은 테스트 라이브러리를 업데이트할 것을 권장합니다.

이러한 리소스는 테스트 종속성을 최신 상태로 유지하는 데 도움이 될 수 있습니다.
+ Ruby Gem의 보안을 유지하는 방법에 대한 자세한 내용은 RubyGems 웹 사이트의 [Security Practices](https://guides.rubygems.org/security/)를 참조하세요.
+ Pipenv가 사용하고 Python 패키지 기관이 보증하여 종속성 그래프에서 알려진 취약성을 검사하는 안전 패키지에 대한 자세한 내용은 GitHub의 [보안 취약성 탐지](https://github.com/pypa/pipenv/blob/master/docs/advanced.rst#-detection-of-security-vulnerabilities)를 참조하세요.
+ 오픈 웹 애플리케이션 보안 프로젝트(OWASP) Maven 종속성 검사기에 대한 자세한 내용은 OWASP 웹 사이트의 [OWASP DependencyCheck](https://owasp.org/www-project-dependency-check/)을 참조하세요.

자동화된 시스템이 알려진 보안 문제가 없는 것으로 판단하더라도 보안 문제가 있을 수 있음을 기억하는 것이 중요합니다. 타사의 라이브러리 또는 도구를 사용할 때는 항상 상당한 주의를 기울이고 가능하거나 필요한 경우 암호화 서명을 확인하세요.

# Device Farm에서의 사고 대응
<a name="security-incident-response"></a>

Device Farm은 보안 문제를 나타낼 수 있는 동작이 있는지 디바이스를 지속적으로 모니터링합니다. AWS 가 테스트 결과 또는 퍼블릭 디바이스에 기록된 파일과 같은 고객 데이터에 다른 고객이 액세스할 수 있는 경우를 인지한 경우는 AWS 서비스 전체에서 사용되는 표준 인시던트 알림 및 보고 정책에 따라 영향을 받는 고객에게 AWS 연락합니다.

# Device Farm에서 로깅 및 모니터링
<a name="security-logging-monitoring"></a>

이 서비스는 AWS CloudTrail에 대한 호출을 기록하고 AWS Amazon S3 버킷에 로그 파일을 AWS 계정 전송하는 서비스인를 지원합니다. CloudTrail에서 수집한 정보를 사용하여 성공적으로 수행된 요청, 요청을 수행한 AWS 서비스사람, 요청이 수행된 시간 등을 확인할 수 있습니다. 설정 방법 및 로그 파일을 찾는 방법을 비롯한 CloudTrail에 대한 자세한 내용은 [AWS CloudTrail 사용 설명서](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)를 참조하세요.

CodeDeploy에서 CloudTrail 사용에 관한 자세한 내용은 [AWS CloudTrail을 사용하여 AWS Device Farm API 호출 로깅](logging-using-cloudtrail.md) 단원을 참조하세요.

# 디바이스 에이전트의 보안 모범 사례
<a name="security-best-practices"></a>

 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) 단원을 참조하세요.