Secure Your Database for an Internet Facing Application in the Cloud
Data breaching is a top of mind security concern. However database security is often deployed incorrectly, and creates security & financial risks for companies that we are working for.
I have seen many Internet facing applications are deployed using this model:
Issues with this design:
1) No Segmentation, mixing Internet facing application and database in the same VPC
2) No firewall/IDPS
3) Private Subnet is exposed to Public Subnet without any protection
We all like to use models that work without reinventing the wheel. Here is a secure datacenter reference architecture has been around for decades:
Translating this model into a cloud environment, the design below did exactly the same thing: Takes application flow into consideration, creates different layers, and secures application and database with Firewall/IDPS. The diagram is for AWS, and is the same for other cloud environment (Azure, GCP, OCI and etc.) using Aviatrix Multi-Cloud Network Architecture.
4 key concepts we have applied to this design:
Service Insertion: Placement of Firewalls & IDPS. As we all know “cloud” is pretty flat, it’s different than our traditional physical datacenter. We don't have wires to unplug & plug to add a firewall, hence service insertion function is a must have in a virtual cloud world.
Policy: Policy should not be just on the firewalls with allow/deny statements. We need to understand how our application works, and who needs to talk to whom. For example, a web load-balancer, should never talk to database server directly. Route policy, Security Group policy and Network Access policy should all be taken into consideration.
Network Segmentation: By defining multiple segments, we can build a much flexible and tighter policy. It can be a safety net to help preventing some unintentional mistakes, like sometimes our policy on firewalls is too loose. It should be your first line of defense.
Keep Private Subnet Private: Private subnet by definition is a subnet that does not have default route to IGW (Internet Gateway). It might still have a NAT gateway, or VGW to reach outside (the Internet) via routing. Keep your critical resources secure by not providing a path to outside is the key. For example, your database, should anyone reach it directly from outside, or should it initiate a connection directly to the Internet? I think you already know the answer: That’s a big NO. Therefore, your application & DB servers should have no EIP, on a subnet with no IGW, no NAT gateway, no default route that can lead to the Internet (preferably NO Default Route).