보안

이 섹션에서는 Amazon WorkSpaces 서비스를 사용할 때 암호화를 사용하여 데이터를 보호하는 방법을 설명합니다. 전송 중 및 저장 시 암호화와 보안 그룹을 사용하여 네트워크 액세스를 보호하는 방법에 대해 설명합니다 WorkSpaces. 또한 이 섹션에서는 신뢰할 수 있는 장치 및 IP 액세스 제어 그룹을 사용하여 최종 장치 액세스를 제어하는 방법에 대한 정보를 제공합니다. WorkSpaces

AWS Directory Service의 인증 (MFA 지원 포함) 에 대한 추가 정보는 이 섹션에서 확인할 수 있습니다.

전송 중 암호화

WorkSpaces Amazon은 암호화를 사용하여 다양한 통신 단계 (전송 중) 에서 기밀을 보호하고 저장 데이터 (암호화) 도 보호합니다. WorkSpaces WorkSpaces Amazon이 전송 중에 사용하는 암호화의 각 단계 프로세스는 다음 섹션에 설명되어 있습니다.

저장 중 암호화에 대한 자세한 내용은 이 문서의 암호화된 WorkSpaces 섹션을 참조하십시오.

등록 및 업데이트

데스크톱 클라이언트 애플리케이션은 HTTPS를 사용하여 Amazon과 통신하여 업데이트 및 등록을 요청합니다.

인증 단계

데스크톱 클라이언트는 인증 게이트웨이에 자격 증명을 전송하여 인증을 시작합니다. 데스크톱 클라이언트와 인증 게이트웨이 간의 통신은 HTTPS를 사용합니다. 이 단계가 끝나면 인증에 성공하면 인증 게이트웨이는 동일한 HTTPS 연결을 통해 데스크톱 클라이언트에 OAuth 2.0 토큰을 반환합니다.

참고

데스크톱 클라이언트 애플리케이션은 포트 443 (HTTPS) 트래픽, 업데이트, 등록 및 인증을 위한 프록시 서버 사용을 지원합니다.

클라이언트로부터 자격 증명을 받은 후 인증 게이트웨이는 AWS Directory Service에 인증 요청을 보냅니다. 인증 게이트웨이에서 AWS Directory Service로의 통신은 HTTPS를 통해 이루어지므로 사용자 자격 증명이 일반 텍스트로 전송되지 않습니다.

인증 — 액티브 디렉터리 커넥터 (ADC)

AD Connector는 Kerberos를 사용하여 온-프레미스 AD와 인증된 통신을 설정하므로 LDAP에 바인딩하고 후속 LDAP 쿼리를 실행할 수 있습니다. ADC의 클라이언트측 LDAPS 지원을 통해 Microsoft AD와 애플리케이션 간의 쿼리를 암호화할 수도 있습니다. AWS 클라이언트측 LDAPS 기능을 구현하기 전에 클라이언트측 LDAPS의 사전 요구 사항을 검토하십시오.

AWS 디렉터리 서비스는 TLS를 통한 LDAP도 지원합니다. 사용자 자격 증명은 언제라도 일반 텍스트로 전송되지 않습니다. 보안을 강화하기 위해 VPN 연결을 사용하여 WorkSpaces VPC를 온프레미스 네트워크 (AD가 있는 네트워크) 에 연결할 수 있습니다. AWS 하드웨어 VPN 연결을 사용하는 경우 고객은 AES-128 또는 AES-256 대칭 암호화 키를 사용하는 표준 IPSEC (인터넷 키 교환 (IKE) 및 IPSEC SA), 무결성 해시의 경우 SHA-1 또는 SHA-256, 완벽한 순방향 보안 (PFS) 을 사용하는 DH 그룹 (1단계는 2,14-18, 22, 23 및 24, 2단계는 1,2,5, 14-18, 22, 23, 24) 을 사용하여 전송 중 암호화를 설정할 수 있습니다..

브로커 스테이지

(인증에 성공한 경우 인증 게이트웨이에서) OAuth 2.0 토큰을 수신한 후 데스크톱 클라이언트는 HTTPS를 사용하여 Amazon WorkSpaces 서비스 (브로커 연결 관리자) 를 쿼리합니다. 데스크톱 클라이언트는 OAuth 2.0 토큰을 전송하여 스스로를 인증하고, 그 결과 클라이언트는 스트리밍 게이트웨이의 엔드포인트 정보를 수신합니다. WorkSpaces

스트리밍 스테이지

데스크톱 클라이언트가 OAuth 2.0 토큰을 사용하여 스트리밍 게이트웨이를 사용하여 PCoIP 세션을 열도록 요청합니다. 이 세션은 AES-256 암호화되며 PCoIP 포트를 통신 제어 (4172/TCP) 에 사용합니다.

스트리밍 게이트웨이는 OAuth2.0 토큰을 사용하여 HTTPS를 통해 Amazon WorkSpaces 서비스에 사용자별 WorkSpaces 정보를 요청합니다.

또한 스트리밍 게이트웨이는 클라이언트로부터 TGT를 수신하고 (클라이언트 사용자 암호를 사용하여 암호화됨) Kerberos TGT 패스스루를 사용하여 게이트웨이는 사용자가 검색한 Kerberos TGT를 사용하여 에서 Windows 로그인을 시작합니다. WorkSpace

WorkSpace 그런 다음 표준 Kerberos 인증을 사용하여 구성된 AWS 디렉터리 서비스에 대한 인증 요청을 시작합니다.

성공적으로 로그인하면 WorkSpace PCoIP 스트리밍이 시작됩니다. 클라이언트는 포트 TCP 4172에서 연결을 시작하고 트래픽은 포트 UDP 4172에서 반환합니다. 또한 관리 인터페이스를 통한 스트리밍 게이트웨이와 WorkSpaces 데스크톱 간의 초기 연결은 UDP 55002를 통해 이루어집니다. (Amazon의 IP 주소 및 포트 요구 사항은 설명서를 참조하십시오 WorkSpaces. 초기 아웃바운드 UDP 포트는 55002입니다. 포트 4172 (TCP 및 UDP) 를 사용하는 스트리밍 연결은 AES 128비트 및 256비트 암호를 사용하여 암호화되지만 기본값은 128비트입니다. 고객은 WorkSpaces Windows용 PCoIP 전용 AD 그룹 정책 설정을 사용하거나 Amazon Linux용 pcoip-agent.conf 파일을 사용하여 이를 256비트로 적극적으로 변경할 수 있습니다. WorkSpaces WorkSpacesAmazon의 그룹 정책 관리에 대한 자세한 내용은 설명서를 참조하십시오.

네트워크 인터페이스

각 WorkSpace Amazon에는 기본 네트워크 인터페이스와 관리 네트워크 인터페이스라는 두 개의 네트워크 인터페이스가 있습니다.

기본 네트워크 인터페이스는 AWS Directory Service, 인터넷 및 고객 기업 네트워크에 대한 액세스와 같은 고객 VPC 내부의 리소스에 대한 연결을 제공합니다. 이 기본 네트워크 인터페이스에 보안 그룹을 연결할 수 있습니다. 개념적으로 이 ENI에 연결된 보안 그룹은 배포 범위에 따라 구분됩니다 ( WorkSpaces 보안 그룹 및 ENI 보안 그룹).

관리 네트워크 인터페이스

보안 그룹을 통해 관리 네트워크 인터페이스를 제어할 수는 없지만 고객은 호스트 기반 방화벽을 사용하여 포트를 차단하거나 액세스를 WorkSpaces 제어할 수 있습니다. 관리 네트워크 인터페이스에는 제한을 적용하지 않는 것이 좋습니다. 고객이 이 인터페이스를 관리하기 위해 호스트 기반 방화벽 규칙을 추가하기로 결정한 경우 Amazon WorkSpaces 서비스가 해당 인터페이스의 상태 및 접근성을 관리할 수 있도록 포트 몇 개를 열어야 합니다. WorkSpace 자세한 내용은 Amazon Workspaces 관리 안내서의 네트워크 인터페이스를 참조하십시오.

WorkSpaces 보안 그룹

기본 보안 그룹은 AWS Directory Service별로 생성되며 WorkSpaces 해당 특정 디렉터리에 속하는 모든 그룹에 자동으로 연결됩니다.

Amazon은 다른 많은 AWS 서비스와 WorkSpaces 마찬가지로 보안 그룹을 사용합니다. WorkSpaces Amazon은 사용자가 WorkSpaces 서비스에 디렉터리를 등록할 때 두 개의 AWS 보안 그룹을 생성합니다. 하나는 디렉터리 컨트롤러 디렉터리ID_Controllers용이고 다른 하나는 디렉터리 ID_WorkspacesMembers 디렉터리에 있는 디렉터리용입니다 WorkSpaces . 이 보안 그룹 중 어느 것도 삭제하지 마십시오. 그렇지 않으면 보안이 손상될 수 있습니다. WorkSpaces 기본적으로 WorkSpaces 구성원 보안 그룹의 이그레스는 0.0.0.0/0까지 열려 있습니다. 디렉터리에 기본 WorkSpaces 보안 그룹을 추가할 수 있습니다. 새 보안 그룹을 WorkSpaces 디렉터리에 연결하면 새로 WorkSpaces 시작하거나 WorkSpaces 재구축한 기존 보안 그룹에 새 보안 그룹이 생깁니다. 이 새 기본 보안 그룹을 WorkSpaces 재구축하지 않고 기존 보안 그룹에 추가할 수도 있습니다. 여러 보안 그룹을 WorkSpaces 디렉터리에 연결하는 경우 각 보안 그룹의 규칙을 단일 규칙 세트로 WorkSpaces 집계하십시오. 보안 그룹 규칙은 가능한 한 응축하는 것이 좋습니다. 보안 그룹에 대한 자세한 내용은 Amazon VPC 사용 설명서의 VPC용 보안 그룹을 참조하십시오.

WorkSpaces 디렉터리 또는 기존 WorkSpace 디렉터리에 보안 그룹을 추가하는 방법에 대한 자세한 내용은 관리 안내서를 참조하십시오. WorkSpaces

일부 고객은 WorkSpaces 트래픽이 유출할 수 있는 포트와 목적지를 제한하고자 합니다. 에서 들어오는 송신 트래픽을 제한하려면 서비스 통신에 필요한 특정 포트를 그대로 두어야 합니다. 그렇지 않으면 사용자가 해당 포트에 로그인할 수 없습니다. WorkSpaces WorkSpaces

WorkSpaces 로그인하는 WorkSpace 동안 고객 VPC의 ENI (엘라스틱 네트워크 인터페이스) 를 활용하여 도메인 컨트롤러와 통신합니다. 사용자가 WorkSpaces 성공적으로 로그인할 수 있도록 하려면 다음 포트가 _WorkspacesMembers 보안 그룹의 도메인 컨트롤러를 포함하는 CIDR 범위 또는 도메인 컨트롤러에 액세스할 수 있도록 허용해야 합니다.

• TCP/UDP 53 - DNS

• TCP/UDP 88 - Kerberos 인증

• TCP/UDP 389 — LDAP

• TCP/UDP 445 - SMB

• TCP 3268-3269 - 글로벌 카탈로그

• TCP/UDP 464 - 케르베로스 비밀번호 변경

• TCP 139 - Netlogon

• UDP 137-138 - Netlogon

• UDP 123 - NTP

• TCP/UDP 49152-65535 RPC용 임시 포트

다른 애플리케이션, 인터넷 또는 기타 위치에 WorkSpaces 액세스해야 하는 경우 _WorkspacesMembers 보안 그룹 내에서 CIDR 표기법으로 해당 포트 및 대상을 허용해야 합니다. 이러한 포트와 대상을 추가하지 않으면 위에 나열된 포트 외에는 접속할 수 없습니다. WorkSpaces 마지막으로 고려할 사항은 기본적으로 새 보안 그룹에는 인바운드 규칙이 없다는 것입니다. 따라서 보안 그룹에 인바운드 규칙을 추가하기 전에는 또 다른 호스트에서 시작하여 인스턴스로 가는 인바운드 트래픽이 허용되지 않습니다. 위 단계는 에서 나가는 것을 제한하거나 액세스 권한이 있어야 하는 리소스 WorkSpaces 또는 CIDR 범위로만 수신 규칙을 잠그려는 경우에만 필요합니다.

참고

새로 연결된 보안 그룹은 수정 후 WorkSpaces 생성되거나 재구축되는 그룹에만 연결됩니다.

ENI 보안 그룹

기본 네트워크 인터페이스는 일반 ENI이므로 다양한 AWS 관리 도구를 사용하여 관리할 수 있습니다. 자세한 내용은 엘라스틱 네트워크 인터페이스를 참조하십시오. Amazon WorkSpaces 콘솔 WorkSpaces 페이지에서 WorkSpace IP 주소로 이동한 다음, 해당 IP 주소를 필터로 사용하여 (Amazon EC2 콘솔의 네트워크 인터페이스 섹션에서) 해당 ENI를 찾습니다.

ENI를 찾으면 보안 그룹에서 직접 관리할 수 있습니다. 기본 네트워크 인터페이스에 보안 그룹을 수동으로 할당할 때는 WorkSpaces Amazon의 포트 요구 사항을 고려하십시오. 자세한 내용은 Amazon Workspaces 관리 안내서의 네트워크 인터페이스를 참조하십시오.

그림 21: WorkSpaces MFA가 활성화된 클라이언트

네트워크 액세스 제어 목록(ACL)

또 다른 방화벽 관리가 복잡해짐에 따라 네트워크 ACL은 매우 복잡한 배포에 일반적으로 사용되며 일반적으로 모범 사례로 사용되지는 않습니다. 네트워크 ACL은 VPC의 서브넷에 연결되므로 OSI 모델의 계층 3 (네트워크) 에 기능이 집중됩니다. Amazon은 디렉터리 서비스를 기반으로 WorkSpaces 설계되었으므로 두 개의 서브넷을 정의해야 합니다. 네트워크 ACL은 디렉터리 서비스와는 별도로 관리되며, 네트워크 ACL은 WorkSpaces '할당된 서브넷 중 하나에만 할당될 수 있을 가능성이 큽니다.

상태 비저장 방화벽이 필요한 경우 네트워크 ACL은 보안을 위한 모범 사례입니다. 네트워크 ACL에서 기본 설정을 초과하여 변경한 모든 내용은 서브넷별로 유효성을 검사하는 것이 가장 좋습니다. 네트워크 ACL이 의도한 대로 작동하지 않는 경우 VPC 흐름 로그를 사용하여 트래픽을 분석해 보십시오.

AWS 네트워크 방화벽

AWS Network Firewall은 기본 보안 그룹 및 네트워크 ACL이 제공하는 것 이상의 기능을 제공하지만 비용이 듭니다. HTTPS 기반 웹 사이트를 위한 서버 이름 검사 (SNI), 침입 탐지 및 방지, 도메인 이름에 대한 허용 및 거부 목록 등 네트워크 연결과 관련된 보안을 강화할 수 있는 기능을 요구하는 고객들은 이에 대한 대체 방화벽을 찾아야 했습니다. AWS Marketplace 이러한 방화벽의 배포가 복잡하기 때문에 표준 EUC 관리자의 숙련도를 넘어서는 문제가 발생했습니다. AWS Network Firewall은 레이어 3에서 7까지의 보호를 지원하는 동시에 기본 AWS 환경을 제공합니다. 조직에 EUC AWS 네트워크 보호를 모두 적용할 수 있는 다른 수단 (클라우드로 전송할 수 있는 타사 방화벽에 대한 기존 온프레미스 라이선스 또는 방화벽을 관리하는 별도의 팀 제외) 이 없는 경우 Network Firewall을 NAT Gateway와 함께 사용하는 것이 좋습니다. NAT 게이트웨이는 AWS 네트워크 방화벽과 함께 무료로 제공됩니다.

AWS Network Firewall 배포는 기존 EUC 설계를 중심으로 설계되었습니다. 단일 VPC 설계에서는 방화벽 엔드포인트용 서브넷과 별도의 인터넷 송신 라우팅 고려 사항을 포함하는 간소화된 아키텍처를 구현할 수 있는 반면, 다중 VPC 설계는 방화벽 및 Transit Gateway 엔드포인트가 있는 통합 검사 VPC의 이점을 크게 누릴 수 있습니다.

설계 시나리오

시나리오 1: 기본 인스턴스 잠금

기본 WorkSpaces 보안 그룹은 인바운드 트래픽을 허용하지 않습니다. 보안 그룹은 기본적으로 거부되고 스테이트풀이기 때문입니다. 즉, WorkSpaces 인스턴스 자체의 보안을 강화하기 위해 추가로 구성해야 할 구성이 없습니다. 모든 트래픽을 허용하는 아웃바운드 규칙과 사용 사례에 적합한지 고려해 보세요. 예를 들어 LDAP의 경우 389, LDAP의 경우 636, SMB의 경우 445 등과 같이 포트 사용 사례에 맞는 특정 IP 범위 및 모든 주소로 포트 443으로 향하는 모든 아웃바운드 트래픽을 거부하는 것이 가장 좋습니다. 하지만 환경의 복잡성으로 인해 여러 규칙이 필요하므로 네트워크 ACL 또는 방화벽 어플라이언스를 통해 더 잘 서비스될 수 있습니다.

시나리오 2: 인바운드 예외

일정한 요구 사항은 아니지만 네트워크 트래픽이 인바운드로 시작되는 경우가 있을 수 있습니다. WorkSpaces 예를 들어 WorkSpaces 클라이언트가 연결할 수 없는 경우 인스턴스를 분류하려면 대체 원격 연결이 필요합니다. 이러한 경우에는 고객 ENI의 보안 그룹에 인바운드 TCP 3389를 일시적으로 활성화하는 것이 가장 좋습니다. WorkSpace

또 다른 시나리오는 중앙 집중식 인스턴스에서 시작되는 인벤토리 또는 자동화 기능을 위한 명령을 수행하는 조직 스크립트입니다. 인바운드의 특정 중앙 집중식 인스턴스로부터 해당 포트의 트래픽을 보호하는 것은 영구적으로 구성할 수 있지만 계정 내 여러 배포에 적용할 수 있으므로 디렉터리 구성에 연결된 추가 보안 그룹에서 이 작업을 수행하는 것이 가장 좋습니다. AWS

마지막으로, 일부 네트워크 트래픽은 상태 저장 기반이 아니므로 인바운드 예외에 임시 포트를 지정해야 합니다. 쿼리와 스크립트가 실패하는 경우 연결 실패의 근본 원인을 파악하면서 최소한 일시적으로 임시 포트를 허용하는 것이 좋습니다.

시나리오 3: 단일 VPC 검사

단순화된 배포 WorkSpaces (예: 확장 계획이 없는 단일 VPC) 에는 검사를 위해 별도의 VPC가 필요하지 않으므로 VPC 피어링을 통해 다른 VPC와의 연결을 단순화할 수 있습니다. 그러나 해당 엔드포인트에 대한 라우팅과 IGW (Internet Gateway) 이그레스 라우팅을 구성하여 방화벽 엔드포인트에 대해 별도의 서브넷을 생성해야 합니다. 그렇지 않으면 구성하지 않아도 됩니다. 모든 서브넷이 VPC CIDR 블록 전체를 사용하는 경우 기존 배포에 사용 가능한 IP 공간이 없을 수 있습니다. 이러한 경우에는 배포가 이미 초기 설계 이상으로 확장되었으므로 시나리오 4가 더 유용할 수 있습니다.

시나리오 4: 중앙 집중식 검사

AWS 네트워크 방화벽의 스테이트풀 및 스테이트리스 규칙의 관리를 단순화하므로 한 AWS 지역에 여러 EUC를 배포할 때 선호되는 경우가 많습니다. 기존 VPC 피어는 Transit Gateway로 대체됩니다. 이 설계에서는 Transit Gateway 첨부 파일과 해당 첨부 파일을 통해서만 구성할 수 있는 검사 라우팅을 사용해야 하기 때문입니다. 이 구성에도 더 높은 수준의 제어가 적용되므로 기본 환경을 넘어서는 보안이 가능합니다. WorkSpaces

그림 22: Transit Gateway 첨부 파일을 사용하는 샘플 아키텍처

암호화됨 WorkSpaces

각 WorkSpace Amazon에는 루트 볼륨 (Windows의 경우 C: 드라이브 WorkSpaces, Amazon Linux의 경우 루트 WorkSpaces) 및 사용자 볼륨 (Windows의 경우 D: 드라이브 WorkSpaces, Amazon Linux의 경우 /home) 이 제공됩니다. WorkSpaces 암호화된 WorkSpaces 기능을 사용하면 볼륨 하나 또는 둘 모두를 암호화할 수 있습니다.

무엇을 암호화하나요?

저장된 데이터, 볼륨에 대한 디스크 입력/출력 (I/O), 암호화된 볼륨에서 생성된 스냅샷은 모두 암호화됩니다.

암호화는 언제 이루어지나요?

시작 (생성) 시 a에 대한 암호화를 WorkSpace 지정해야 WorkSpace 합니다. WorkSpaces 볼륨은 시작 시에만 암호화할 수 있습니다. 실행 후에는 볼륨 암호화 상태를 변경할 수 없습니다. 다음 그림은 새 버전을 출시할 때 암호화를 선택할 수 있는 Amazon WorkSpaces 콘솔 페이지를 보여줍니다 WorkSpace.

그림 23: 루트 볼륨 암호화 WorkSpace

새 WorkSpace 암호화는 어떻게 이루어지나요?

고객은 Amazon WorkSpaces 콘솔에서 또는 AWS CLI 고객이 새 앱을 시작할 때 Amazon WorkSpaces API를 사용하여 암호화 WorkSpaces 옵션을 선택할 수 WorkSpace 있습니다.

Amazon은 볼륨을 암호화하기 위해 CMK from AWS Key Management Service () AWS KMS 을 WorkSpaces 사용합니다. 기본 AWS KMS CMK는 지역에서 처음 실행될 WorkSpace 때 생성됩니다. (CMK에는 지역 범위가 있습니다.)

고객은 암호화된 상태로 사용할 고객 관리형 CMK를 만들 수도 있습니다. WorkSpaces CMK는 Amazon WorkSpaces 서비스가 각 볼륨을 암호화하는 데 사용하는 데이터 키를 암호화하는 데 사용됩니다. WorkSpace (엄밀히 말하면 볼륨을 암호화하는 것은 Amazon EBS입니다.) 현재 CMK 한도는 리소스 할당량을 참조하십시오. AWS KMS

참고

암호화된 이미지에서 사용자 지정 이미지를 생성하는 WorkSpace 것은 지원되지 않습니다. 또한 루트 볼륨 암호화가 활성화된 상태에서 WorkSpaces 시작한 경우 프로비저닝하는 데 최대 1시간이 걸릴 수 있습니다.

WorkSpaces 암호화 프로세스에 대한 자세한 설명은 Amazon의 WorkSpaces 사용 방법을 참조하십시오 AWS KMS. WorkSpace 암호화에 대한 요청이 올바르게 처리되도록 CMK 사용을 모니터링하는 방법을 고려해 보십시오. AWS KMS 키 및 데이터 키에 대한 추가 정보는 페이지를 참조하십시오. AWS KMS

액세스 제어 옵션 및 신뢰할 수 있는 장치

WorkSpaces Amazon은 액세스할 수 있는 클라이언트 디바이스를 관리할 수 있는 옵션을 고객에게 제공합니다 WorkSpaces. 고객은 신뢰할 수 있는 디바이스에만 WorkSpaces 액세스를 제한할 수 있습니다. macOS 및 Microsoft Windows PC에서 디지털 인증서를 사용하여 액세스를 WorkSpaces 허용할 수 있습니다. 또한 iOS, 안드로이드, 크롬 OS, 리눅스, 제로 클라이언트 및 WorkSpaces 웹 액세스 클라이언트에 대한 액세스를 허용하거나 차단할 수 있습니다. 이러한 기능을 통해 보안 태세를 더욱 개선할 수 있습니다.

새로운 배포에서는 사용자가 Windows, macOS, iOS, Android, ChromeOS 및 Zero Client의 WorkSpaces 클라이언트에서 액세스할 수 있도록 액세스 제어 옵션을 사용할 수 있습니다. 웹 액세스 또는 Linux WorkSpaces 클라이언트를 사용한 액세스는 새 WorkSpaces 배포에서 기본적으로 활성화되지 않으므로 활성화해야 합니다.

신뢰할 수 있는 장치 (관리 대상 장치라고도 함) 에서 회사 데이터에 액세스하는 데 제한이 있는 경우 유효한 인증서가 있는 신뢰할 수 있는 장치로만 WorkSpaces 액세스를 제한할 수 있습니다. 이 기능을 활성화하면 Amazon은 인증서 기반 인증을 WorkSpaces 사용하여 디바이스를 신뢰할 수 있는지 확인합니다. WorkSpaces 클라이언트 애플리케이션이 디바이스를 신뢰할 수 있는지 확인할 수 없는 경우 디바이스에서 로그인하거나 다시 연결하려는 시도를 차단합니다.

신뢰할 수 있는 장치 지원은 다음 클라이언트에 제공됩니다.

• WorkSpaces 안드로이드 및 안드로이드 호환 크롬 OS 기기에서 실행되는 구글 플레이의 Amazon Android 클라이언트 앱

• WorkSpaces macOS 디바이스에서 실행되는 Amazon macOS 클라이언트 앱

• WorkSpaces 윈도우 디바이스에서 실행되는 Amazon Windows 클라이언트 앱

액세스할 WorkSpaces 수 있는 디바이스를 제어하는 방법에 대한 자세한 내용은 신뢰할 수 있는 디바이스에 WorkSpaces 대한 액세스 제한을 참조하십시오.

참고

신뢰할 수 있는 디바이스의 인증서는 Amazon WorkSpaces 윈도우, macOS 및 Android 클라이언트에만 적용됩니다. 이 기능은 Amazon WorkSpaces Web Access 클라이언트 또는 Teradici PCoIP 소프트웨어 및 모바일 클라이언트, Teradici PCoIP 제로 클라이언트, RDP 클라이언트 및 원격 데스크톱 애플리케이션을 포함하되 이에 국한되지 않는 타사 클라이언트에는 적용되지 않습니다.

IP 액세스 제어 그룹

고객은 IP 주소 기반 제어 그룹을 사용하여 신뢰할 수 있는 IP 주소 그룹을 정의 및 관리하고, 사용자가 신뢰할 수 있는 네트워크에 연결된 WorkSpaces 경우에만 해당 그룹에 액세스하도록 허용할 수 있습니다. 이 기능을 통해 고객은 보안 상태를 보다 효과적으로 제어할 수 있습니다.

WorkSpaces 디렉토리 수준에서 IP 접근제어 그룹을 추가할 수 있습니다. 두 가지 방법으로 IP 접근제어 그룹을 사용할 수 있습니다.

• IP 접근제어 페이지 — WorkSpaces 관리 콘솔에서 IP 접근제어 페이지에 IP 접근제어 그룹을 생성할 수 있습니다. 액세스할 수 있는 IP 주소 또는 IP 범위를 입력하여 이러한 그룹에 규칙을 추가할 WorkSpaces 수 있습니다. 그런 다음 업데이트 세부 정보 페이지의 디렉터리에 이러한 그룹을 추가할 수 있습니다.

• Workspace WorkSpaces API — API를 사용하여 그룹을 생성, 삭제 및 확인하고, 액세스 규칙을 생성 또는 삭제하거나, 디렉터리에 그룹을 추가 및 제거할 수 있습니다.

Amazon WorkSpaces 암호화 프로세스에서 IP 액세스 제어 그룹을 사용하는 방법에 대한 자세한 설명은 사용자를 위한 IP 액세스 제어 그룹을 참조하십시오 WorkSpaces.

Amazon을 사용한 모니터링 또는 로깅 CloudWatch

네트워크, 서버 및 로그 모니터링은 모든 인프라의 필수적인 부분입니다. Amazon을 배포하는 고객은 배포, 특히 개인의 전반적인 상태 및 연결 상태를 WorkSpaces 모니터링해야 합니다. WorkSpaces

에 대한 아마존 CloudWatch 메트릭스 WorkSpaces

CloudWatch 에 대한 WorkSpaces 지표는 관리자에게 개인의 전반적인 상태 및 연결 상태에 대한 추가 통찰력을 제공하도록 설계되었습니다 WorkSpaces. 지표는 지정된 디렉터리 내의 조직 내에서 사용할 수 있거나 전체 WorkSpaces 조직에 대해 집계하여 사용할 수 있습니다. WorkSpace

모든 지표와 마찬가지로 이러한 CloudWatch CloudWatch 지표는 AWS Management Console (다음 그림 참조) 에서 보고, API를 통해 액세스하고, CloudWatch 경보 및 타사 도구를 통해 모니터링할 수 있습니다.

그림 24: CloudWatch 지표: ConnectionAttempt / ConnectionFailure

기본적으로 다음 지표가 활성화되며 추가 비용 없이 사용할 수 있습니다.

• 사용 가능 - WorkSpaces 상태 확인에 대한 응답이 이 지표에 포함됩니다.

• 비정상 상태 — 동일한 상태 확인에 응답하지 WorkSpaces 않는 비정상은 이 지표에 포함됩니다.

• ConnectionAttempt— a에 대한 연결 시도 횟수. WorkSpace

• ConnectionSuccess— 성공한 연결 시도 횟수.

• ConnectionFailure— 실패한 연결 시도 횟수.

• SessionLaunchTime— 세션을 시작하는 데 걸린 시간 (클라이언트가 측정한 시간). WorkSpaces

• InSessionLatency— 클라이언트가 측정 및 WorkSpaces 보고한 WorkSpaces 클라이언트와 클라이언트 간의 왕복 소요 시간.

• SessionDisconnect— 사용자가 시작한 세션과 자동으로 종료된 세션 수.

또한 다음 그림과 같이 경보를 생성할 수 있습니다.

그림 25: WorkSpaces 연결 오류에 대한 CloudWatch 알람 생성

아마존 CloudWatch 이벤트 대상 WorkSpaces

Amazon CloudWatch Events의 이벤트는 보고, 검색하고, 다운로드하고, 보관하고, 분석하고, 로그인에 성공하면 응답하는 데 사용할 수 있습니다. WorkSpaces 이 서비스는 사용자 로그인에 대한 클라이언트 WAN IP 주소, 운영 체제, WorkSpaces ID 및 디렉터리 ID 정보를 모니터링할 수 있습니다. WorkSpaces 예를 들어 다음과 같은 목적으로 이벤트를 사용할 수 있습니다.

• 나중에 참조할 수 있도록 WorkSpaces 로그인 이벤트를 로그로 저장하거나 보관하고, 로그를 분석하여 패턴을 찾고, 해당 패턴을 기반으로 조치를 취하십시오.

• WAN IP 주소를 사용하여 사용자가 로그인하는 위치를 확인한 다음 정책을 사용하여 액세스 CloudWatch 이벤트 유형에 있는 액세스 기준에 맞는 파일 또는 WorkSpaces 데이터에만 사용자가 WorkSpaces 액세스하도록 허용하십시오.

• 정책 제어를 사용하여 권한이 없는 IP 주소에서 파일 및 애플리케이션에 대한 액세스를 차단합니다.

CloudWatch 이벤트 사용 방법에 대한 자세한 내용은 Amazon CloudWatch Events 사용 설명서를 참조하십시오. CloudWatch 이벤트에 대한 WorkSpaces 자세한 내용은 Cloudwatch 이벤트 WorkSpaces 사용 모니터링을 참조하십시오.

YubiKey 아마존 지원 WorkSpaces

추가 보안 계층을 추가하기 위해 고객은 다단계 인증으로 도구와 사이트를 보호하기로 선택하는 경우가 많습니다. 일부 고객은 YubiKey Yubico를 사용하여 이 작업을 수행하기로 선택합니다. WorkSpaces Amazon은 일회용 암호 (OTP) 와 FIDO U2F 인증 프로토콜을 모두 지원합니다. YubiKeys

Amazon은 WorkSpaces 현재 OTP 모드를 지원하며, 관리자나 최종 사용자가 OTP를 사용하기 위해 추가 단계를 거쳐야 할 필요는 없습니다. YubiKey 사용자는 이를 컴퓨터에 연결하고 키보드가 해당 영역 WorkSpace (특히 OTP를 입력해야 YubiKey 하는 필드) 에 초점을 맞췄는지 확인한 다음, 키보드의 금색 접점을 터치할 수 있습니다. YubiKey YubiKey 그러면 선택한 필드에 OTP가 자동으로 입력됩니다.

YubiKey 및 와 함께 FIDO U2F 모드를 WorkSpaces 활용하려면 추가 단계가 필요합니다. U2F 리디렉션을 활용하려면 다음과 같은 지원 YubiKey 모델 중 하나를 사용자에게 발급해야 합니다. WorkSpaces

• YubiKey 4

• YubiKey 5 NFC

• YubiKey 5 나노

• YubiKey 5C

• YubiKey 5C 나노

• YubiKey 5 NFC

U2F용 USB 리디렉션을 활성화하려면 YubiKey

기본적으로 PCoIP에는 USB 리디렉션이 비활성화되어 있습니다 WorkSpaces. U2F 모드를 사용하려면 이를 사용하도록 설정해야 합니다. YubiKeys

1. PCoIP (32비트) 용 최신 WorkSpaces 그룹 정책 관리 템플릿 또는 PCoIP (64비트) 용 WorkSpaces 그룹 정책 관리 템플릿을 설치했는지 확인하십시오.

2. 디렉터리 관리 WorkSpace 또는 디렉터리에 연결된 Amazon EC2 인스턴스에서 그룹 정책 관리 도구 (gpmc.msc) 를 열고 PCoIP 세션 변수로 이동합니다. WorkSpaces

3. 사용자가 설정을 재정의하도록 허용하려면 재정의 가능한 관리자 기본값을 선택합니다. 그렇지 않으면 [재정의할 수 없는 관리자 기본값] 을 선택합니다.

4. PCoIP 세션에서 USB 활성화/비활성화 설정을 엽니다.

5. 활성화됨을 선택한 다음 확인을 선택합니다.

6. PCoIP USB 허용되는 디바이스 규칙 및 허용되지 않는 디바이스 규칙 구성 설정을 엽니다.

7. 활성화됨을 선택하고 USB 권한 부여 테이블 입력(규칙 최대 10개)에서 USB 디바이스 허용 목록 규칙을 구성합니다.

   1. 권한 부여 규칙 - 110500407. 이 값은 제공업체 ID(VID)와 제품 ID(PID)의 조합입니다. VID/PID 조합의 형식은 다음과 같습니다. 여기서 는 1xxxxyyyy 16진수 형식의 xxxx VID이고 는 16진수 형식의 PID입니다. yyyy 이 예시에서 1050은 VID이고 0407은 PID입니다. USB 값에 대한 자세한 내용은 USB ID 값을 참조하십시오. YubiKey YubiKey

8. USB 인증 테이블 입력 (최대 10개 규칙) 에서 USB 장치 차단 목록 규칙을 구성합니다.

   1. 권한 미부여 규칙의 경우 빈 문자열을 설정합니다. 인증 목록에 있는 USB 디바이스만 허용한다는 뜻입니다.

      참고

      최대 10개의 USB 권한 부여 규칙과 최대 10개의 USB 권한 미부여 규칙을 정의할 수 있습니다. 세로 막대(|) 문자를 사용하여 여러 규칙을 구분합니다. 권한 부여/권한 부여 규칙에 대한 자세한 내용은 Windows용 Teradici PCoIP 표준 에이전트를 참조하십시오.

9. 확인을 선택합니다.

10. 그룹 정책 설정 변경은 해당 세션의 다음 그룹 정책 업데이트 이후 및 세션이 다시 시작된 후에 적용됩니다. WorkSpace WorkSpace 그룹 정책 변경 사항을 적용하려면 다음 중 하나를 수행합니다.

    1. 를 재부팅합니다 WorkSpace (Amazon WorkSpaces 콘솔에서 를 선택한 다음 작업 WorkSpace, 재부팅을 선택합니다 WorkSpaces).

    2. 관리 명령 프롬프트에서 gpupdate /force를 입력합니다.

11. 설정이 적용된 후에는 USB 디바이스 규칙 설정을 통해 제한을 WorkSpaces 구성하지 않는 한 지원되는 모든 USB 디바이스를 리디렉션할 수 있습니다.

U2F용 USB 리디렉션을 활성화한 후에는 Fido의 YubiKey U2F 모드를 사용할 수 YubiKey 있습니다.