With the increasing threat of data theft, either through hacking attempts, DDoS attacks, data interception during transit, or defects in code that provide backdoors to sensitive data, the reality of the world today is that businesses need to be more proactive in securing proprietary data.
With the trend of businesses moving their operations more and more to the cloud, this need for data security is paramount. Simply creating an instance within the cloud does not mean that data is secure unless significant steps are taken by leveraging Virtual Private Clouds.
Even then, assuming the services that are available will completely meet the security needs of the business is an invitation for disaster. If data is compromised, the road to recovery is a long and painful process which, unfortunately, is not always successful.
The ClearScale Solution
One mobile payment company was very much aware of this risk. With data centers located around the world, this company had volumes of sensitive customer payment data that had to be stored and accessed in a way that allowed them to be Payment Card Industry (PCI) compliant. With these challenges in their mind, they engaged with ClearScale, an AWS Certified Premier Partner, to design a fully secure Virtual Private Cloud (VPC) to provide complete security and redundancy of the customer data while still allowing low latency transfer of data between their global locations.
The Approach — Hub and Spoke Topology Deployed by Terraform
Because of how the client had a tiered application structure to support a plethora of customers, applications needed to be grouped and ultimately placed within one of six different VPC locations. However, because the client had a need to use ELK services to collect, parse, and store data logs the challenge for ClearScale was to design a solution that kept the applications isolated within the VPCs but accessible to ELK from a holistic perspective. As such, to maintain the highest level of security while still having specialized VPCs, a Star Topology approach was required. This topology in a Local Area Network (LAN) sense allows the VPCs to remain separated, but tied together in that information can be passed between them and a centralized hub. This hub and spoke approach allows for the entire system to remain viable even if one of the spokes fail.
ClearScale isolated each segregated application tier with security groups and then deployed those across multiple subnets and Availability Zones (AZ). By creating API endpoints in each VPC, ClearScale could then route traffic to the VPC internally. With the exception of the Bastion host and the load balancers for routing external traffic to the VPC, all servers were placed within private subnets for added security.
With a bit of engineering expertise and effort, ClearScale leveraged AWS VPN Connections to configure a peer with on-premise data centers as well as other VPCs in different Availability Zones. AWS Direct Connect was implemented in order to provide low-latency connections to U.S. and India deployments. A centralized Management VPC hub (including a back-up for disaster recovery purposes) that has been configured with LibreSWAN for IPSec connectivity to the spoke VPCs allows for overarching management of the entire hub and spoke topology. Although most communication occurs between the spoke VPCs and the hub, the spoke VPCs can also contact each other through an AWS EC2 Hub instance as needed.
To support existing deployments for the client, ClearScale spent considerable time developing Terraform modules to aid in the deployment of key infrastructure. The first, called the Spoke Module, instantiates a Virtual Private Gateway for a given spoke VPC and the subsequent VPN connection to the hub server. The second, called the Hub Module, creates the AWS EC2 instance configured in the Hub role. Once created, Ruby scripts are used to set up the LibreSWAN IPSec tunnels using VTI support and then the BGPD daemon shares information about the tunnel routes with the VPN Gateways and other hub instances. The scripts determine which VPN connections are available utilizing AWS APIs by querying a customer gateway that has the same Elastic IP address as the primary Hub server. Once it finds a match, it establishes the VPN connection needed to then configure on the Hub server. To manage all of the routing, ClearScale opted to use VTI interfaces instead of IPSec policies as they were supported by LibreSWAN.
As the architecture diagram above indicates, the Green demonstrates how each hub module was resourced by different Terraform module instances. Each module can be created many times, much like a Class is used in a variety of different program languages; it is instantiated as it is needed and does not cause conflict with other instances that are already in existence. The blue above indicates spoke modules that were created by other Terraform modules.
The hub modules create EC2 instances with various roles along with a Bastion host and VPN hub. The hub creates the Customer Gateway with each AWS Region, not within the VPC. This is done because the gateway is shared between a few different application VPCs; otherwise, creating the gateway within the spoke creates existence conflicts that prevent proper communication. The hub then creates IPSec tunnels to other hub instances based on specific tags that are identified and then to VPN connections which are linked to the customer gateway.
Within the spoke modules, VPN Gateways are created for the VPC and a VPN connection is made for each Customer Gateway which is then linked with the VPN Gateway. Coupled with the effort done by the hub modules, one customer gateway can be shared with many VPN connections, and a single VPN gateway can be shared with many VPN connections.
The hub instance propagates a VPN gateway of connected spoke VPCs in each route table within the spoke VPC. Because of a limitation in Terraform, data resources are unable to be returned which, ideally, would be used with the VPN Gateways and associated route propagation resources. Since the volume of route tables are extensive, having to update all of the various route tables in each spoke VPN would be resource intensive, so ClearScale had to use an alternative solution to accomplish this goal due in large part to the many relationships inherent to the schema that was needed for this project.
The Resulting Benefits
Ultimately, the security solution ClearScale designed and deployed in the AWS Virtual Private Cloud allowed the client to provide a higher level of security and isolation for its customer base while providing greater availability, redundancy, and integration into existing data centers. Because AWS VPC allows for the provisioning of isolated sections within the cloud to instantiate and launch AWS resources, customers can build a truly secure virtual network. ClearScale’s approach to this project also allowed the client to control all areas of the network deployment while restricting access and adding additional layers of privacy and security.
Using redundant AWS VPN connections, AWS VPC coupled with LibreSWAN allowed connectivity to the client data centers and made them dedicated VPC spokes. The solution also allowed for greater control of the applications the client used internally by isolating servers that were not required to process requests from outside sources directly. With Security Groups and Network Access Control Lists (NACL) enabled, VPC instances were further protected by only allowing traffic from specific IP address sources, ports, and protocols.
The complexity of this ongoing project allowed ClearScale to demonstrate that bringing third-party solutions, like Terraform, to bear on a hub and spoke topology increased the viability of a truly secure environment. Combined with added layers of security and communication, ClearScale gave the client the tools necessary to prove beyond a doubt that they could meet any rigid PCI compliance bar.
Get in touch today to speak with a cloud expert and discuss how we can help: