If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
If you would like to read the other parts in this article series please go to:
- Amazon WorkSpaces: Your Desktop in the AWS Cloud (Part 1)
- Amazon WorkSpaces: Your Desktop in the AWS Cloud (Part 2)
Introduction
In Part 1 of this series of articles, I provided an overview of the need for persistent desktops in the cloud, the differences between the two ways to implement that – VDI and DaaS – and some of the concerns and issues surrounding Desktop as a Service. Then I began to delve into Amazon’s WorkSpaces desktop service and as we continue the discussion, I’ll take a look at various aspects of how it works, what it costs and how to deploy and use it. Then in Part 2 I delved into an examination of the different plans, licensing issues, and provisioning for AWS WorkSpaces.
Now here in Part 3, we’re going to start looking at some other factors that are important in selecting a DaaS provider, all of which have to do with security. We’ll provide a brief overview of the cloud security dilemma and how it applies to DaaS in general, then we’ll talk about login security, identity and authentication, controlling and limiting user access and software security.
The cloud security dilemma
Security is always a consideration when facing the “to the cloud or not to the cloud” choice. Data breaches have become so commonplace that they’re almost not even “news” anymore, but they continue to dominate the headlines; a study from the Ponemon Institute found that more than 40% of companies experienced some type of breach in 2014, and this included big names such as Morgan Chase, Home Depot and of course the infamous Target case.
Organizations are terrified of being the next victim (and the loss of customers that can result from the bad publicity). Data leaks can occur in many different ways and employees who access sensitive data on their desktops present one attack vector. While virtual desktops have security advantages, they can bring new challenges. This is where the DaaS provider you choose can make a difference.
In search of a secure WorkSpace
In looking at the security of a DaaS solution, the questions that you want to ask and the features that you want to look for are similar to those you must consider with any cloud service. A secure DaaS implementation hinges on a number of factors:
- Secure logon to the service: user authentication must be strong in order to prevent unauthorized users from accessing desktops where they can access sensitive information.
- Reliable identity services: regardless of the strength of the authentication protocols, authentication is built on the foundation of identity, so the identity database itself must be secure.
- Encryption: when the entire desktop is being delivered to the user over the Internet, it should be encrypted to prevent interception by unauthorized persons.
- Effective key management: the keys used to encrypt the virtual drives on which the desktop “lives” must be protected.
- Physical security: the servers in the provider’s datacenter where the applications actually run have to be secured from access by unauthorized or malicious persons, both internal and external.
AWS WorkSpaces security
With AWS WorkSpaces, Amazon implements a number of different security mechanisms in an effort to address the above issues.
Log-in security
WorkSpaces admins can choose from a few different ways to allow their users to log onto the WorkSpaces desktops. The simplest is to have users create credentials (user name and password) of their choice after you provision their desktops. Most medium to large (and many small) organizations will already have an Active Directory deployment and you can integrate WorkSpaces with your Active Directory domain to make it easy for users – they sign in with their familiar AD credentials.
Identity and authentication
Users can log on with credentials stored in a directory that’s maintained and managed by Amazon on their servers, or with AD credentials, depending on how WorkSpaces has been configured. Active Directory is, of course, the standard identity repository on Windows-based networks and this is true as well for Amazon’s cloud-based services that are integrated with an organization that has integrated its on-premises AD with AWS.
You can integrate WorkSpaces with your RADIUS server if you have one. Amazon added this feature in August of 2014 and Microsoft RADIUS servers are supported, along with others. For redundancy and high availability, you can set it up to use multiple RADIUS servers, with or without a load balancer.
Admins configure the RADIUS integration through the WorkSpaces admin console (in the Directories section) and there’s no extra cost. You’ll need to configure the IP address(es) for your RADIUS server(s) or load balancer, the port your RADIUS server uses, a shared secret, and select the protocol you set up for your RADIUS endpoints. You can also configure server timeout in seconds and maximum number of retries to connect to the RADIUS server (up to 10).
To log in, users provide their AD user name and password and then enter a one-time passcode generated by a hardware or software token, giving the protection of multifactor authentication (MFA).
When using MFA, you can use either hardware or software tokens with Amazon’s MFA. Google Authenticator is a popular software based solution. If your RADIUS server is running on Linux, you can use a Pluggable Authentication Module (PAM) library to enable the use of Google Auth. MFA works for users who access WorkSpaces through client devices running Windows, Mac OS X, Chrome OS, iOS, Android or Kindle OS.
Controlling user access
You can limit the access that your users have to applications and other resources from their WorkSpaces.
It’s easy to keep a user from accessing his/her WorkSpace if the person leaves the company or for some other reason needs to be blocked permanently or temporarily; you simply disable the account in whichever directory is storing the user identities (your Active Directory if you’ve integrated AD with WorkSpaces or the Amazon directory service if you haven’t).
Note that Amazon Identity and Access Management (IAM) users are not given access to WorkSpaces resources by default. You probably already know that IAM is a means for allowing and denying permissions to resources via policies that can be attached to individual users, groups, or the resources themselves.
You would have to make a policy in IAM that grants the specific users permission to create and manage resources for WorkSpaces and EC2. Then you need to attach the policy to whichever users (or groups of users) you want to be able to access the WorkSpaces resources.
Amazon provides in their documentation a sample policy statement that can be used to grant permission to perform all WorkSpaces tasks for IAM users. You’ll find that sample script, along with more information on specifying WorkSpaces resources in IAM policies, on the AWS web site.
You can also control and limit access to network resources (including resources that reside on the Internet) from WorkSpaces by using VPC security groups. You might remember that VPC security groups behave sort of like virtual firewalls, because they control the inbound and outbound traffic to AWS virtual private clouds.
WorkSpaces will create a security group that’s assigned to all of the WorkSpaces you have provisioned to users in your directory. You can also create additional security groups, through the WorkSpaces console. If you’re going to want to allow Internet access from WorkSpaces, you need to assign a public IP address, and you need to set this up before you provision the WorkSpaces because it will only apply to those that are created after you enable this setting. If you already have WorkSpaces provisioned, it is possible to manually assign those WorkSpaces an Elastic IP address. Here are the instructions on how to do that.
Software Security
As all IT professionals know, one of the most important aspects of computer and network security is the patching of vulnerabilities in the software as quickly as possible, before their existence becomes widely known and attackers seize the opportunity to exploit them. WorkSpaces desktops are running popular applications on a popular client operating system and so security updates are just as important for these virtual desktops as they are for any network client.
Amazon gives you, as the WorkSpaces admin, control over the installation of security patches on the users’ WorkSpaces. This can be done through the Windows Update service that’s built into all modern versions of Windows, and Windows Update is turned on by default on all new WorkSpaces. If you prefer, however, you can use a patch management solution of your own choice, both to update Windows and Microsoft applications and to update third party apps.
Another “must have” for best security is anti-virus/anti-malware and you can install your favorite AV/AM software on the users’ WorkSpaces just as you install them on Windows client computers on your premises. You get Trend Micro AV as part of the package if you purchase one of the WorkSpaces “Plus” bundles (Value Plus, Standard Plus or Performance Plus), along with the Microsoft Office applications.
Summary
Security can make or break Desktop as a Service, both figuratively and literally. In this, Part 3 of our series on Amazon WorkSpaces, we looked at some of the security mechanisms that Amazon implements to protect users’ desktops that are delivered through their DaaS offering. Although we are wrapping up the series with this installment, this isn’t the whole story. Another very important aspect of security is encryption and how it works with WorkSpaces. I’ll be addressing that in the future in another article that will be published on the WindowsNetworking.com site, so stay tuned over there if you’re interested in “the rest of the story.”
If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
If you would like to read the other parts in this article series please go to:
What is recommend to restrict workspaces from access outside corp IP address subnets ? AWS has already confirmed along with several Identity providers this is not possible at this time . Thoughts ?
you setup the route table in the VPC that host your Workspace instance.