

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

# 데스크톱 뷰 또는 애플리케이션 뷰 선택
<a name="choosing-desktop-view-or-application-view"></a>

 애플리케이션 뷰 또는 데스크톱 뷰 선택 여부는 성능이나 비용에 영향을 미치지 않습니다. WorkSpaces 애플리케이션 플릿당 언제든지 하나의 뷰에만 액세스할 수 있습니다. **스트림 뷰** 옵션을 변경할 수 있습니다. 스트림 뷰를 변경하려면 플릿을 다시 시작해야 하므로 사용량이 적은 업무 시간에 이 변경을 계획하세요.

 스트림 뷰에 대한 단일 모범 사례는 없습니다. 스트림 뷰 옵션의 영향은 다음을 통해 요약됩니다.
+  관리자를 위한 **사용량 보고서** 기능을 통해 애플리케이션 사용에 대한 세부 보고 
+  최종 사용자를 위한 전반적인 경험 및 워크플로(예: 전체 데스크톱이 사용 사례의 요구 사항을 해결하는지 아니면 애플리케이션을 보는 것만으로 충분할까요?).

## 데스크톱 뷰
<a name="desktop-view"></a>

 모든 사용자 워크플로가 세션에서 수행되는 사용 사례의 경우 데스크톱 뷰는 모든 애플리케이션이 하나의 환경에 집중되도록 하여 사용자 환경을 단순화합니다. 데스크톱 뷰는 운영 체제(OS)와의 통합이 필요한 3\~5개 이상의 애플리케이션을 배포할 때 보다 일관된 사용자 환경을 제공할 수 있습니다. 데스크톱 뷰는 분리되고 서로 다른 두 환경을 유지 관리할 때 효과적입니다. 예를 들어 사용자는 프로덕션 데스크톱 환경과 사전 프로덕션 데스크톱 환경 모두에 동시에 액세스하여 레이아웃, 구성 및 애플리케이션 액세스에 대한 변경 사항을 검증할 수 있습니다.

 WorkSpaces 애플리케이션 사용 보고서는 데스크톱 보기에 대한 일일 애플리케이션 보고서를 생성합니다. 애플리케이션의 결과 출력은 단순히 '데스크톱'이며 WorkSpaces 애플리케이션 세션에 직접 매핑됩니다. 자세한 내용은 이 문서의 [**사용자 사용 모니터링**](monitoring.md#monitoring-user-usage) 섹션을 참조하세요.

## 애플리케이션 전용 뷰
<a name="applications-only-view"></a>

 애플리케이션 전용 보기는 WorkSpaces 애플리케이션 스택이 간헐적으로 필요한 몇 가지 애플리케이션을 제공하기 위한 경우에도 유효합니다. 키오스크 환경에서는 애플리케이션 뷰를 통해 안전하게 잠긴 애플리케이션 전송을 제공합니다. Application View를 사용하면 WorkSpaces 애플리케이션이 기본 Windows 셸을 사용자 지정 셸로 대체합니다. 이 사용자 지정 셸은 실행 중인 애플리케이션만 표시하므로 OS의 공격 범위를 최소화합니다.

 WorkSpaces 애플리케이션을 사용하여 기존 조직의 데스크톱 환경을 보강하는 사용 사례의 경우 애플리케이션 전용 보기가 선호됩니다. WorkSpaces 애플리케이션 Windows 클라이언트를 [*네이티브 애플리케이션 모드로*](https://docs.aws.amazon.com/appstream2/latest/developerguide/client-system-requirements-feature-support.html#feature-support-native-application-mode) 배포하여 키보드 바로 가기를 완전히 사용할 수 있도록 하여 사용자 혼란을 최소화합니다.

 Amazon WorkSpaces 애플리케이션 사용 보고서는 애플리케이션 보기에 대한 일일 애플리케이션 보고서를 생성합니다. 애플리케이션 및 실행 사용에 대한 보다 세밀한 보고를 원하면 운영 체제 수준에서 보고하는 타사 솔루션을 고려해 보세요. 보고 모드에서 Microsoft AppLocker를 사용하거나 Liquidware의 [*Stratusphere UX*](https://aws.amazon.com/marketplace/pp/prodview-ghxb36werkone)와 같이 AWS Marketplace에서 사용할 수 있는 솔루션을 고려할 수 있습니다.

## AWS Identity and Access Management 역할 구성
<a name="identity-and-access-management-role-configuration"></a>

워크로드에서 WorkSpaces 애플리케이션 최종 사용자가 세션 내에서 다른 AWS 서비스에 액세스해야 하는 경우 [AWS Identity and Access Management (IAM) 역할을](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 사용하여 액세스를 위임하는 것이 가장 좋습니다. [플릿 수준의 할당](https://docs.aws.amazon.com/appstream2/latest/developerguide/using-iam-roles-to-grant-permissions-to-applications-scripts-streaming-instances.html#how-to-use-iam-role-with-streaming-instances)을 통해 IAM 역할을 최종 사용자 세션에 직접 연결할 수 있습니다. WorkSpaces 애플리케이션에서 IAM 역할을 사용할 때의 추가 모범 사례는 [관리자 안내서의이 섹션을 참조하세요](https://docs.aws.amazon.com/appstream2/latest/developerguide/using-iam-roles-to-grant-permissions-to-applications-scripts-streaming-instances.html#best-practices-for-using-iam-role-with-streaming-instances).

### 정적 보안 인증 사용
<a name="using-static-credentials"></a>

일부 워크로드의 경우 IAM 액세스 키를 연결된 역할에서 상속하는 대신 정적 입력이 필요할 수 있습니다. 이러한 자격 증명을 받는 방법은 두 가지입니다. 첫 번째 방법은 AWS 서비스 내에 액세스 키를 저장한 다음 최종 사용자에게 서비스에서 해당 특정 값을 가져올 수 있는 명시적 IAM 액세스 권한을 부여하는 것입니다. 액세스 키 저장 메커니즘의 두 가지 예로는 [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) 또는 [AWS SSM 파라미터 스토어](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html)를 사용하는 경우를 들 수 있습니다. 두 번째 방법은 WorkSpaces 애플리케이션 자격 증명 공급자를 사용하여 연결된 역할의 액세스 키에 액세스하는 것입니다. 자격 증명 공급자를 호출하고 액세스 키와 비밀 키의 출력을 파싱하여 이 작업을 수행할 수 있습니다. PowerShell 내에서 이 작업을 수행하는 방법의 예는 다음과 같습니다.

```
$CMD = 'C:\Program Files\Amazon\Photon\PhotonRoleCredentialProvider\PhotonRoleCredentialProvider.exe'
$role = 'Machine'

$output = & $CMD --role=$role
$parsed = $output | ConvertFrom-Json

$access_key = $parsed.AccessKeyId
$secret_key = $parsed.SecretAccessKey
$session_token = $parsed.SessionToken
```

### WorkSpaces Applications S3 버킷 보호
<a name="protecting-appstream-bucket"></a>

WorkSpaces 애플리케이션 워크로드가 홈 폴더 및/또는 애플리케이션 지속성으로 구성된 경우 영구 데이터가 저장되는 Amazon S3 버킷을 무단 액세스 또는 우발적 삭제로부터 보호하는 것이 가장 좋습니다. 첫 번째 보호 계층은 Amazon S3 버킷 정책을 추가하여 [실수로 버킷을 삭제하지 않도록 하는 것입니다](https://docs.aws.amazon.com/appstream2/latest/developerguide/s3-iam-policy.html#s3-iam-policy-delete). 두 번째 보호 계층은 최소 권한 원칙에 부합하는 버킷 정책을 추가하는 것입니다. [필요한 당사자에게만 버킷 액세스를 허용](https://docs.aws.amazon.com/appstream2/latest/developerguide/s3-iam-policy.html#s3-iam-policy-restricted-access)함으로써 원칙을 준수할 수 있습니다.