Once I spun up a virtual machine in Sydney to get a recipe from the MasterChef Australia website due to the site being restricted to just Australia. I could do this because of cloud computing. It made it possible to do work from anywhere on Earth as long as both ends have an internet connection.
Because while connectivity around the globe is becoming better, faster, and more prevalent, data sovereignty is becoming a significant issue for organisations. Be it the intellectual property of MasterChef recipes or the personal (health) data of residents in a country staying within certain geographic boundaries. And this is what I’ll elaborate on.
I worked for a British customer connected closely with the United Kingdom National Health Service (NHS), the central government-funded medical and health care services all things health in the United Kingdom. This organisation has access to very sensitive data, which falls under Tier 3 data as defined by the Alan Turing Data Safe haven tiers (1).
These tiers, together with agreements and requirements from the NHS, the United Kingdom’s Government and third-party data providers can be distilled into a set-in-stone rule that any and all data within the customer’s Tier 3 is not allowed to leave the United Kingdom (UK).
In. Any. Way.
The environment has all its resources placed in the AWS EU-West-2 region so that all data, instances and all ingress and egress into this environment are located within the United Kingdom. Data in S3 buckets, Data Analysis on EC2 instances, and ingress/egress of Data via secured upload methods, all authenticated and authorized via an AWS Managed Active Directory and again, all safely within the EU-West-2 region.
For User Ingress, Amazon WorkSpaces is going to be used. Amazon WorkSpaces is a fully managed desktop virtualization service for Windows and Linux. The Workspaces will give access to a secured Windows environment using a remote desktop session via PC over IP (PCoIP) that meets all the requirements set by the customer and regulators. But, where all infrastructure required for this to work, from domain controllers to the WorkSpaces themselves are on British soil, there is no way to have checks in place to see if the users themselves are in the UK.
By default, any users that can fully authenticate against the environment can connect to this environment from anywhere in the world. Long live cloud computing! Except when you’re not allowed to have data leave the country. Because, when we say that data cannot leave in any way, this also means the data, as pixels, on a screen of an RDP session. This means that an authorized user that works on this data daily is not allowed to do so when they are at a conference in Norway, for example.
Let’s delve into how to solve this. How can we prevent users from logging into their Workspace when not in the UK? How do we create geo-restriction for a solution that does not have any?
First, we start by looking at the documentation and see how this solution works. (2)
Figure 1 – AWS Managed WorkSpaces using AWS Managed Active Directory
We see that the solution initiates the connection with authentication from the client, via the AWS-managed Auth/Session gateway to the Directory Service that is managing authentication. After that completes successfully, the workspace streaming is a setup that users can actively work through.
The entire flow is completely managed by Amazon Web Services (AWS). Users (or administrators, for that matter) cannot manipulate the stream of data at all. When the author’s streaming data is attempted to be redirected or streamed via third-party solutions, it breaks. This is a great design. We don’t want any man-in-the-middle attacks succeeding.
Only when the traffic has come through the AWS-managed parts and arrives at the customer’s VPC do we gain control of this traffic and can steer it using the standard methods like security groups, routing, and NACLs. But, at that point, any data we could use for geolocation purposes, like the user’s IP address, have been lost.
So, what can we do?
The Amazon WorkSpaces client has a Proxy Server option, but this only applies to the auth traffic. The moment the WorkSpaces client tries to set up the streaming connection, only a direct connection to AWS is accepted. So, setting up a proxy server behind some form of geo-restriction is not going to work.
Let’s look at the backend options within WorkSpaces. The two client-side options are:
- Trusted devices via certificates
- IP access control groups
The trusted devices only control what devices can log into the Workspace but with IP Access control we can control where a user can log in from.
Trying to find out how many IP addresses / IP ranges are in use within the UK (4), we come to the lofty sum of 85.000 CIDR ranges. That is a bit more than what Amazon WorkSpaces supports. Amazon WorkSpaces documentation describes (5) that only 250 IP rules can be added to an Amazon WorkSpaces instance.
This inspired me to develop a solution. As I love cloud computing and it allows me to, if something doesn’t exist, build it myself. So, the solution I designed looks as follows:
Figure 2 – High-level infrastructure design WorkSpaces geo-restriction
While Amazon WorkSpaces does not have geo-restriction, AWS Web Application Firewall (WAF) does! WAF cannot be directly connected to workspaces, but we can use the IP Access Control List.
So, the design is:
- An AWS WAF with a geographic match rule for the United Kingdom.
- An Application Load Balancer with the WAF attached.
- A Lambda that will validate the user and then set their home IP in WorkSpaces.
- An identity provider that has credentials for the user, in this case, Cognito.
Figure 3 – UML Workflow user experience
Users going to the URL of the Application Load Balancer will have their IP checked by the WAF. If this fails, the user will not even have the opportunity to log in. But if the user is within the UK, the user can then sign in with their credentials. When that succeeds, the AWS Lambda will add the user’s IP to the access control list and the user can then log into their workspace. This entire workflow is shown in figure 3.
Finally, returning to my initial paragraph: this solution is not foolproof. By bringing up a virtual machine in the right location or using a VPN, working around the geo-restriction is not incredibly difficult. But like all things security, you work in layers. The geo-restriction works together with the authentication mechanism to not only have a user in the right place but also know the correct information to reach the secured environment.
In conclusion, a thank you to Network 10 for planting the seed of my geo-restriction design and thank you for not having the recipe behind a login or else I would never have been able to eat this wonderful parsnip soup (6) my wife made.
Links:
- https://www.turing.ac.uk/research/research-projects/data-safe-havens-cloud
- https://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/scenario-3-standalone-isolated-deployment-using-aws-directory-service-in-the-aws-cloud.html
- https://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html#client-application-ports
- https://www.ip2location.com/free/visitor-blocker
- https://aws.amazon.com/workspaces/faqs/
- https://10play.com.au/masterchef/recipes/parsnip-soup-with-stilton-and-bacon-crumb/r190614fckou
This blog was originally published on https://helecloud.com/blog/geographic-restrictions-workspaces-finding-out-how-to-cook-parsnip-soup/ but has since then gone down due to Helecloud's acquisition.
Top comments (0)