4 Security Tips for Your Amazon WorkSpaces Deployments


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

  • Ensuring HIPAA compliance with Amazon Connect: A Guide for Healthcare SaaS Providers

    Healthcare IT – HIPAA Compliance Best Practices in Amazon Connect Healthcare application providers are responsible for ensuring systems protect patient data to comply with HIPAA regulations. HIPAA...

    Learn More
  • Ensuring Robust Security in Amazon Cloud Environments

    Amazon has the tools and CloudHesive has the expertise to keep your SaaS data safe.   Rock-solid security is crucial in all cloud environments, especially for SaaS platforms, which handle...

    Learn More
  • What You Need to Know about Cloud Security in the Generative AI Era

    Key Takeaways: Find out how generative AI is changing cloud security. Learn best practices for cloud security in the generative AI era.  Discover generative AI tools and techniques for enhancing and...

    Learn More