Many corporations announce mergers frequently. Once the ink has dried on the deal, the integration plan begins to take shape. The immediate challenge of interconnection is tasked to IT so that application systems integration or data sharing can securely take place. Often the operations need to remain only partially integrated, as they operate within different data sovereignty laws and corporate polices. How do we do this securely when both organizations have existing AWS account footprints?
There are two solutions that come to mind:
- Use Firewalls in an Edge VPC on the AWS network edge with IDS/IPS to form a restricted/inspected VPN connection over the public Internet creating an External Secure Service Edge (SSE).
- Take advantage of existing transit gateways in both accounts to use the AWS backbone and inspect/restrict the traffic using IDS/IPS firewalls or other security appliances in an inspection VPC on both sides to form a "firewall sandwich" with gateway load balancers creating an Internal SSE.
Let’s break them down:
One new VPC is created and named the External SSE VPC using appliance mode with 2 IaaS firewall(s) with 2 ENIs in separate availability zones that are compatible with the existing enterprise FW footprint and management system. Four new subnets will be created (Private and Public) using 2 for each Availability Zone (AZ).
On the IaaS FW, one ENI would attach to the Public Subnet using a private IP that is in turn connected to a Network Load Balancer that has the Public IP from AWS. The second ENI on the firewall, will attach to the private subnet. The TGW will be attached to the External SSE VPC and have routes added for the private subnets on the other side of the tunnel at the external company pointed towards the Private Subnet ENI of the firewall. The traffic would then by processed by the FW via IDS/IPS and encrypted across the Internet via IPSec tunnel to the other company and go through the reverse process inbound on the other side.
The two companies TGW can be peered by sharing account information and the static routes set up in a new separate “External” routing table (RT) created on the TGW. This will attach the TGW’s the traffic between accounts. It must be noted that this solution does not cover overlapping IP ranges between the companies.
Similarly, this solution will also require a new VPC called Internal SSE VPC using appliance mode with two IaaS firewall(s) that are compatible with the existing enterprise FW footprint and management system. A gateway load balancer will be set up also within that Internal SSE VPC. Four Private subnets will be created and used.
Two Gateway Load Balancer endpoints (GWLBe) are set up within the same subnets as the firewalls in separate availability zones (AZ) within each region. Two additional subnets are created in the VPC. One subnet and routing table is for traffic inbound to Internal SSE inspection FWs from the external company via TGW attachment. The other subnet and routing table is for outbound traffic from the Internal SSE inspection FWs towards the internal and external peered accounts’ devices and services. This is associated to the “External” routing table on the TGW.
The TGW would then have a route in its “Internal” routing table for the other sides subnets or a 0.0.0.0/0 default route pointing at the Internal SSE VPC TGW attachment this will pass the traffic through to the GWLBe and on to FW IDS/IPS. The traffic is then inspected and sent back out to the GWLBe the traffic came in from and onto the associated TGW routing table “External” that has been peered earlier to the external company. The traffic will then arrive at the other company for the inbound equivalent for this processing, but in reverse and onwards to the destination.
The visibility provided by the firewalls via the management platforms allows for continuity with the rest of the enterprises’ security and firewall footprint to match their cloud footprint.
The Internal SSE solution only uses private IP traffic that is inspected to ensure each side is in control of what gets through with full visibility via two TGW routing tables and peering the TGWs across the AWS backbone forming an Internal SSE. It could also be expanded to form both Zero Trust Networking (ZTN) for all internal account east-west inter VPC, Ingress/Egress with Internet or Direct Connect (DX)/VPN remote site traffic.
The ConvergeOne Internal/External SSE solution is one of many creative AWS networking and security solutions available to our customers. Reach out to ConvergeOne to see how we can help you quickly design and deploy AWS Networking to integrate with your existing network and security requirements.