4 Security Tips for Your Amazon WorkSpaces Deployments


Mar 17, 2021

4 ways to secure data, networks, and devices across your Amazon WorkSpaces.

Key Takeaways: 

  • Amazon WorkSpaces leverages cryptography to protect data in transit.
  • Creating security groups or applying a host-based firewall may be required to protect a WorkSpaces network interface. 
  • You can encrypt the root and/or user volume of WorkSpaces. 
  • Access controls let you determine which devices are authorized to access WorkSpaces. 
  • Amazon WorkSpaces is a great solution for achieving CMMC Level 3 certification.

Security is key for businesses that use Amazon WorkSpaces, and the shared responsibility model calls for businesses using AWS to be responsible for the security of their side of the arrangement. Fortunately, there are many things you can do to maximize security across your WorkSpaces. 

Here are four security best practices to apply across your WorkSpaces deployments. 

1. Encryption in transit

WorkSpaces uses cryptography to protect data in transit. It uses a desktop client application that communicates with Amazon for updates and registration using HTTPS.

To verify data authenticity, the desktop client sends credentials to an authentication gateway. Meanwhile, the communication between the desktop client and authentication gateway leverages HTTPS. If the authentication is successful, the authentication gateway returns an OAuth 2.0 token to the desktop client via the same HTTPS connection.

Once the authentication gateway receives the client’s credentials, it submits an authentication request to AWS Directory Service. Communication between the authentication gateway to AWS Directory Service takes place over HTTPS. This ensures no user credentials are transmitted in plaintext.

During authentication, Active Directory Connector uses the Kerberos network authentication protocol to establish authenticated communication with on-premises AD. No user credentials are transmitted in plaintext. 

Following the delivery of the OAuth 2.0 token from the authentication gateway, the desktop client queries WorkSpaces services using HTTPS. The client uses the OAuth 2.0 token to verify its authenticity. It next receives the endpoint information of the WorkSpaces streaming gateway.

At this point, the desktop client requests to open a PCoIP session with the streaming gateway. This session utilizes AES-256 encryption and a PCoIP port for communication control. The streaming gateway then requests user-specific WorkSpaces information from the WorkSpaces service over HTTPS. It also receives the ticket granting ticket (TGT) user authentication token from the client and launches a Windows login on the WorkSpace. which initiates an authentication request to the configured AWS Directory Service using standard Kerberos authentication.

PCoIP streaming begins following a successful WorkSpace login. The streaming connection uses AES 128- and 256-bit ciphers for encryption. It defaults to 128-bit, but you can change this to 256-bit by using PCoIP-specific Active Directory Group Policy settings for Windows WorkSpaces or the pcoip-agent.conf file for Amazon Linux WorkSpaces.

2. Network interfaces

Each WorkSpace has a primary and management network interface. 

The primary network interface provides connectivity to resources inside an Amazon Virtual Private Cloud (VPC). These resources can include access to AWS Directory Service, the internet, and a corporate network. 

You can attach security groups to a primary network interface. To do so effectively, you should differentiate security groups based on the scope of your WorkSpaces deployment. 

There are two types of security groups for a primary network interface: WorkSpaces and Elastic Network Interface (ENI). 

A default WorkSpaces security group is created for AWS Directory Service. It is automatically attached to a WorkSpace that belongs to a specific directory. You can modify the rules of a WorkSpaces security group. Also, you can change a default WorkSpaces security group attached to an AWS Directory Service by changing the WorkSpaces security group association.

Comparatively, you can use different AWS management tools to control ENI security groups. To locate the ENI, search for the WorkSpace IP address in the WorkSpaces page in the Amazon WorkSpaces console. Then, use that IP address as a filter to find the corresponding ENI. After you locate the ENI, you can manage it through security groups. 

Unlike a primary network interface, you cannot use security groups to control a management interface. Instead, you can apply a host-based firewall to a WorkSpace to block interface ports or control access to it.

If you add host-based firewall rules to a management interface, keep a few ports open. This ensures that your WorkSpaces service can manage the health and accessibility to your WorkSpace. 

3. Encrypted WorkSpaces

You can encrypt the root and/or user volume of WorkSpaces. With WorkSpaces, the following data can be encrypted: 

  • Data stored at rest
  • Disk I/O to the volume
  • Snapshots created from encrypted volumes 

Encryption should be defined when a WorkSpace is created. You can only encrypt WorkSpaces volumes at launch: following launch, you cannot change their encryption status. 

To encrypt a new WorkSpace, choose the Encrypted WorkSpaces option from either the Amazon WorkSpaces console or AWS Command Line Interface (CLI). Or you can use the Amazon WorkSpaces API when you launch a new WorkSpace.

WorkSpaces uses a customer master key (CMK) from AWS Key Management Service (AWS KMS) to encrypt volumes. A default AWS KMS CMK is created when a WorkSpace is launched. You can also create a customer-managed CMK to use with encrypted WorkSpaces. 

4. Access controls 

You can determine which devices can access WorkSpaces. Access to WorkSpaces can be allowed exclusively from macOS and Windows PCs that obtain digital certificates. You can also authorize or prevent access for iOS, Android, Chrome OS, Linux, and zero clients, along with the WorkSpaces Web Access client. 

If there are limitations for corporate data access from trusted devices, you can restrict WorkSpaces access to trusted devices with valid certificates. In these instances, WorkSpaces uses certificate-based authentication to determine if a device is trusted. If the WorkSpaces client application cannot verify that a device is trusted, it blocks any user attempts to log in or reconnect from the device.

Maintain security across your WorkSpaces

The aforementioned options can help you optimize security across your WorkSpaces. To get the most value out of AWS, you may also want to work with an Amazon Managed Service Partner like CloudHesive

CloudHesive can offer expert tips, guidance, and recommendations to help you secure your WorkSpaces. Contact us today to learn more.

Related Blogs

  • A woman wearing a phone headset sits at a computer looking at the screen while apparently talking to a customer. On the screen is a larger background window with information, and a small pop-out window." alt="">
    Extend the Amazon Connect Contact Control Panel With CTI Actions

    The Amazon Connect Computer Telephony Integration (CTI) Adapter for Salesforce lets users leverage CTI Actions to extend their Contact Control Panel (CCP).  Key takeaways: The Amazon Connect CTI...

    Learn More
  • A penguin on a white computer vector graphic represents an Amazon Linux WorkSpace." alt="">
    How to Manage Amazon Linux WorkSpaces at Scale

    Discover how integrating Amazon WorkSpaces with AWS OpsWorks for Chef Automate can simplify the management of Amazon Linux WorkSpaces at scale Key Takeaways: Amazon Web Services, like Amazon...

    Learn More
  • " alt="">
    New! Disable Rollback for AWS CloudFormation

    AWS’ native Infrastructure as Code (IaC) service, CloudFormation has a new feature named “Disable Rollback”. Disable Rollback works exactly as it sounds and as easily as it sounds. If, during...

    Learn More