The main goal of this post is to suggest a design approach for the establishment of a controlled environment in the public cloud. The design is based on AWS VPC, VPC Peering and 40Cloud Security Gateways, but it can be ported to similar environments with small modifications only. It is not my intent to state that there is only a single approach, but rather to suggest a design that is available, tested and can be implemented easily. Nevertheless, I welcome any thoughts, suggestions or comments regarding this post.
Moving the operational workload to public clouds is becoming a matter of “how”, as opposed to a matter of “if”. Many organizations acknowledge the fact that the public cloud is maturing, and are now asking how it can be leveraged for a more complex operational workload.
In many cases, moving operational workloads requires more control over network access and connectivity than public clouds offer today. Controlling access on a network level is a challenge – even within the traditional enterprise environment. Basically, it requires that network-level policy enforcement (restricting protocols, ports and IP addresses) will be triggered by network access events and associated identity resources, such as users and groups.
In this post, I’m going to suggest a more comprehensive design for building a controlled environment. The design is based on several requests that we’ve had in recent months from various customers. In this design I’ll be using AWS VPC, VPC peering and the 40Cloud Security Gateways. Once established, this design can be also extended to integrate with on-premise infrastructure and cross-region, cross-cloud deployments. Note that for quick and easy installation of the 40Cloud solution, use the 40Cloud AMIs available on the AWS Marketplace.
AWS Elements in Use
AWS VPC – Organizations have several deployment possibilities when adopting Amazon Web Services, one being Amazon Virtual Private Cloud (VPC). This option is used to deploy into a virtual network similar to one used in private data centers. The virtual network may be defined by the organization’s IT personnel. An added benefit is the scalability that is realized when using AWS infrastructure.
VPC Peering – Since peering is relatively a new feature in the AWS environment, I’m providing some additional information on peering capabilities and limitations. Virtual Private Cloud Peering builds on top of your AWS VPC deployment. It routes traffic between the peer VPCs using private IP addresses within the same account or belonging to another account. Since traffic is enabled through separate VPCs, mutual acceptance between VPCs is required, and there are also specific restrictions one must be aware of.
Security Groups – This is a hypervisor-level firewall controlling access to cloud instances. Security groups are configurable by the AWS user, using the AWS service console as well as AWS APIs.
Use Case – Access Controlled VPC
In many cases, organizations require spanning across multiple VPCs within the same region for its own purposes. For example, the development and test teams might be using different VPCs while staging, whereas the production team has their own VPC as well.
Employee access to all VPCs must be controlled – meaning that the organization’s employee must not be allowed to access a resource that the employee has not been granted permission for. For example, a development engineer shouldn’t have access to the production environment. In addition, access should be granted on per-instance and port levels. For example, an engineer might be granted SSH access to a specific instance that was allocated for him/her, but may not access any other port or instances in the same region.
Using additional layers of security (like SSH keys) is possible, but the primary layer must be based on identity and linked to the organization’s identity infrastructure. For example, if a user is removed from the identity infrastructure, he/she will no longer have access to any of the resources.
Challenges and Limitations of AWS VPC
Some limitations of the AWS VPC:
- Security Groups are IP-based and not identity-based. In general, identity is loosely coupled with IP addresses. In many cases, this coupling is not unique or strongly associated. So using static IP addresses as a mechanism to enforce identity-based access is going to be somewhere between challenging and impossible.
- AWS VPC doesn’t support road warrior VPN connections (Ad-hoc user-based VPN access) and doesn’t support IP-based policy mechanisms over IPSec connections.
- Security Groups don’t work across AWS VPCs.
Some Limitations regarding VPC peering:
- VPC peering is possible only within the same region.
- VPC peering can’t handle overlapping IP addresses – so peers’ CIDR blocks must be mutually excluded.
- Peering is not transitive – meaning that if A and B are peers and B and C are peers, A and C are NOT peers unless explicitly specified.
- Traffic forwarding is only limited to the local network – forwarding traffic not destined for the peer’s local network will not work.
- Security groups are not supported across peers. Therefore, rules must be specified at the IP Address level.
The Solution Design
The Idea behind the design is pretty straightforward. We use a single VPC for the common IT infrastructure, and add “satellite VPCs” as needed. The “IT VPC” will provide common IT services (identity, logging, etc.) via VPC peering (if VPC peering isn’t employed then a VPN can be used). Each VPC has an Access Gateway (GW) for user VPN access or for interconnection of corporate resources. User-based policies are associated with identity and are enforced at the GW level.
- VPC planning – The design is based on a single VPC (IT VPC) that provides IT services to all other VPCs via a peering connection. The services can be identity infrastructure, logging, SIEM, etc. All other VPCs are dedicated to specific business environments – Development VPC, Testing VPC, etc.
- VPC Access control – The VPC environment is accessed through 40Cloud Security Gateways. A single GW is setup within the VPC and has an EIP. Users wishing to access a resource within the VPC should establish a VPN connection to the GW and be authenticated by it. Once the ad-hoc VPN tunnel is established, the user can directly access the resources inside the VPC via the VPN tunnel.
- The 40Cloud Security GWs communicate with the identity infrastructure residing within the “IT VPC” (e.g. Active Directory servers) whenever employee authentication is required, allowing identity to be managed centrally.
- The 40Cloud Security GWs are also capable of enforcing per-user policies. For example, user ‘x’ can access resource ‘y’ via TCP ports a, b and c.
- Separation of company functions (into different VPCs) while allowing secure communication (using VPC-peering) with the common IT systems (on the IT-VPC)
- Resources are never directly associated with a public IP and are therefore never exposed directly to the public Internet.
- A GW can be launched on demand, allowing total isolation in case no access is needed in an ongoing manner.
- Access policies are enforced on a per user basis (i.e. based on identity and not IP address)
- Identity is managed centrally
This concludes our VPC peering use case, If you have any questions or comments please don’t hesitate to reach out to us. Of course, if you like to test 40Cloud by yourself just register for our 30-day trial.
– Amir Naftali