2

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).

Reply Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
Like2 Follow
  • 2 Likes
  • 4 mths agoLast active
  • 28Views
  • 1 Following