And often enough, when we think we are protecting ourselves, we
are struggling against our rescuer.
- Marilynne Robinson, Gilead
Like any other element connected to Internet, AWS instances are exposed to various attack vectors every day. The primary reason is that many AWS users allow the individual instances to be publicly addressable from anywhere on the Internet by trading off security to favor convenience. It enables, for instance, the Dev and Ops personnel easy access to every asset to load and test software.
How would you shield the AWS assets from unauthorized access and other attacks? Security group is a great defense instrument. You take a stock of all the IP addresses from where your VPC will be accessed and build security groups that allow access from those locations (deny by default; accept only from known set). This works pretty well, but as your workforce expands and turns global, flexible, and mobile, security group administration becomes inconvenient. Adding to this, imagine the situation when you have AWS resources spread across multiple regions. Since each region operates independently, the security group upkeep nightmare multiplies.
Bastion host is a commonly used method to protect individual instances from the attack vectors. You basically introduce one more hop (where you can insert custom authorization mechanisms) and keep the AWS instances in the internal network (VPC). Cons: the bastion host adds one more step for access and can be cumbersome operationally.
Private connectivity to AWS
The past sections concentrated on secure access to individual AWS instances. Integration of enterprise IT with AWS frequently calls for internal services (such as a corporate web site, wiki, source control) to be hosted securely on AWS. That requires privately (and securely) connecting the enterprise with AWS at the network level.
A private network with AWS provides the best of the worlds:
- It is secure,
- Managing security groups is simpler,
- You can seamlessly deploy enterprise applications on AWS.
There are a few technologies available today to implement private connectivity to AWS:
- Hardware virtual private gateway
- Software appliance based VPN, such as OpenVPN
- AWS direct connect
- Provider cloud connect, such as AT&T Netbond and Verizon SCI
You can find more information on this AWS guide.
At Sproute, we believe that the extension of an enterprise private network to AWS should be a really simple operation and should just work. Not surprisingly, we think our approach for AWS connectivity is a great solution. We came up with a few metrics while evaluating the various approaches - here is a summary:
We struggled through many of the same techniques while working with our AWS resources. Now, we are happily dogfooding SPAN.