In case you missed it, Aviatrix has just launched an era-defining feature to their Secure Cloud Networking solution – the Distributed Cloud Firewall.
There is a lot of amazing content out there on why this is so important:
https://aviatrix.com/distributed-cloud-firewall/
However, where I see amazing value for my customers is where we can actually use this to cut down on data transfer costs, LGFW (Last Gen Firewall) run costs, and operational overhead.
Let me tell you why.
A major requirement in the cloud is to securely control how different departments, systems, applications, etc, communicate with each other. This communication can be user access, API calls, or any other type of application calls required to make a business application or solution function.
Historically this has meant passing by centrally deployed security chokepoints. As workloads move to the cloud, pulling this traffic back to data centres for traffic inspection is detrimental to the application experience, often not programmatic therefore implying lengthy change controls and quite simply, a dated design in todays Cloud first world.
There is another way (not involving an escape pod), but let me take you there step by step.
Day 0 in the Cloud
A few facts on our environments above:
- Engineering was the first to the Cloud and chose AWS as their preferred CSP
- Manufacturing took advantage of some financial incentives following their M365 agreement to build their applications in Azure
- Sales chose GCP for some native tools that they considered superior in GCP
The consequences of the above design decisions become apparent when we need to connect these different business units together.
There are a number of challenges to this organic growth:
- High operational overhead
- Disparate architectures
- Increased downtime
- Lack of visibility
- Lack of consistent security in the cloud
- Security choke point on-premises
- Decreased agility
- Suboptimal cost model
Step 1 – Decrease operational overhead, increase visibility, increase agility, begin optimising cost
Here we add the Aviatrix Secure Cloud Networking solution to the mix.
Immediately, we get the following benefits:
- Consistent design
- No need to manage the Cloud Native constructs
- Consolidate skillsets
- Predictable traffic flow
- Full visibility
- Access to key troubleshooting tools
- Access to a suite of security features
- Offload physical circuits for inter-cloud connectivity
Step 2 – Slightly improve a suboptimal design 🙂
Those pesky firewalls shouldn’t remain on-premises.
Aviatrix has a solution called Firenet which will allow you to insert those LGFWs into the cloud to get 1 step closer to workloads.
This has been highly successful with our customers who had requirements to remain with an internally approved firewall vendor for all inspection requirements but wanted this to be deployed in the Cloud.
However, today, the reality has shifted.
If you think about it, “lift and shift” has been demonized as the fallback to moving applications to the cloud when they cannot be optimized appropriately. And that’s what we are essentially doing here.
So, whilst the below is possible, it’s no longer meeting application owners’ expectations:
Step 3 – Increase Security, Lower Cost
Time for the good stuff.
What’s different below?
That’s right: No bolted on firewall.
The firewall is baked into the network fabric, where it should be.
Let me explain how.
Identifying Cloud Assets when IP Addresses just won’t do
When you deploy workloads to the cloud, the concept of an IP Address as their single source of identity is no longer possible.
That’s why we identify workloads based on cloud metadata, such as tags.
As you will see in above, one of my Manufacturing machines was not tagged with the correct department. I have remediated that in Azure and checked again:
Creating a Policy
Let’s create a policy to block Engineering to Manufacturing flows over TCP port 80:
Let me walk you through the above:
- I verified that the VMs in both Engineering and Manufacturing have been correctly tagged.
- There are some automated HTTP and ICMP checks in both directions running so we can see the effect of our security policy
- We checked the Greenfield rule in place, allowing any to any reachability. Our deny policies will be inserted above this
- We deployed a deny rule, enforcing it and setting logging on
- We immediately saw that HTTP traffic in one direction was blocked. All other flows continued
How easy was that????
That is how easy it is to apply an East-West policy in the cloud with the Aviatrix Distributed Cloud Firewall.
In the next post, I’ll take this a step further by adding a policy for the Sales BU and showing you how to secure egress traffic to the internet. Spoiler alert: it includes URL filtering, malicious threat detection, IDS functionality, SSL decryption, all, once again, baked into the network fabric.
Thanks for reading.
