In the last two posts, we covered the security fundamentals to migrate to the Cloud and the 10 best practices to secure workloads. In this third post, we will talk about securing access to your AWS workloads.
To Live Happy, Live Hidden
In a traditional model, you need to somehow open your cloud infrastructure to allow users to access applications. It could be a VPN gateway or a Bastion host, and with it comes the responsibility of managing IP whitelists in Security Groups when applicable, or absorbing attacks when it is not.
To simplify these challenges and help companies move to a Zero Trust model of securing the application versus the network, Akamai has built Enterprise Application Access (EAA).
Let's look at how this can be achieved with EAA, using AWS as a Cloud origin.
It All Starts With a Connector
EAA's architecture requires at least one connector to be deployed and configured; we recommend to start with two for an active-active configuration per AWS region. They load-balance and fail-over automatically without additional equipment.
Connectors sit next to your applications, all you need is to allow them to dial-out to the Akamai Secure Edge Platform using TLS encrypted channels.
Isolate in Private Subnet
First rule of business with Enterprise Application Access: deploy EAA connectors private subnet, behind a NAT. You do not need Bastion or VPN gateway anymore!
Example of an EAA Connector running on AWS EC2
Just like with EAA Connectors, we strongly recommend to deploy your own EC2 instances in private subnets. Extend this principle to any AWS managed services: keep them within a private evironment.
EAA will allow you to configure - either from the Control Center or programmatically - Access Control List and restrictions such as geography, time of the day or IP address applying for each individual application. EAA supports web-application access and since not all productivity applications can run in a browser, you may need to provide access to TCP or UDP based applications: native SSH, Remote Desktop or access to database. Accessing a GIT repository, a RedShift cluster with PostgreSQL or Oracle Database with Toad is a breeze: install EAA Client, authenticate and AWS EC2 resources are immediately at your fingertips.
Segment With Security Groups, Curate Outgoing Internet Access
Unless communication between services / instances is required, the only Security Group you need is traffic to and from the EAA Connectors.
Example of security group inbound rule allowing only EAA Connectors
You may need to open a broader access, like outbound access global internet - it happens more often than not in a world of API in the cloud.
With such a setup, keep in mind if one of your application or system becomes exploited, it may start leaking data (over HTTP/S and even DNS!), or reach to remote command and control.
To avoid this catastrophic potentially scenario, consider not using AWS default DNS but rather use directly or indirectly Akamai Enterprise Threat Protector (ETP) directly or indirectly in your Cloud. ETP is designed to block threats before they do any damage. In AWS VPC configuration, create a custom DHCP Option Set to include a secure DNS servers using directly ETP, assign it to your VPCs.
Airlock at the Edge
Now everything is tidy in the Cloud, you need to configure the access for each application.
Users -- employees, partners, contractors -- will not directly touch your Cloud infrastructure, only the Akamai Edge Platform, and potentially a 3rd party identity provider.
Our unique identity aware solution allows us to insert extra services like WAN Acceleration (Ion, IP Accelerator), Web Application Firewall and DDoS protection with Kona Site Defender and state of the art bot detection with Bot Manager!
We hope this quick review will help you understand how to make your AWS workload access more productive and secure.
If you're interested to test it further, feel free to give us a try, we offer a 30-day free trial.