I'm developing a simple SaaS application that includes a Web App, an Azure SQL Database, and a few Azure Functions. It also interacts with some external APIs like SendGrid. I always thought Azure's infrastructure was secure enough, considering that the App Service only has necessary ports open and the SQL Database is limited to my IP address for public access. However, a 'security expert' suggested that I should deploy everything within a VNet and place the SQL server in a separate subnet without public access. My first question is, will this actually enhance my security more than my current setup? On top of that, since VNets and NSGs don't have charges, I know I'll need a VPN Gateway to maintain access to the SQL server, but the lowest tier (VpnGw1) costs about £105 a month, which I'd prefer not to add to my expenses. Is there a more affordable option to achieve similar security? Lastly, is there anything critical I might be overlooking? I have a decent grasp of networking, but I'm feeling a bit out of my depth here.
2 Answers
Honestly, using a VNet isn’t really necessary for a simple setup like yours. If you've got one app and one database in the same Azure account, more complex networking is overkill. VNets come into play when you're managing multiple apps or need tighter networking controls.
To clarify, following best practices for securing your web app and Azure SQL Database should suffice without requiring a VNet.
Okay, maybe I oversimplified my situation. I actually do have multiple apps and databases in the same account, but they don’t interact with each other and I’m a solo developer, so team access isn’t a concern.
If you want to keep things straightforward while enhancing your security, consider these steps:
- Limit access to your services where you can. For instance, if your App Service communicates solely with a specific SQL instance, you should restrict SQL access to just the outgoing IPs from that App Service. This can be tricky with PaaS, but some Azure services are capable of being recognized as trusted.
- Always implement authentication between your services and infrastructure. Even if you have a public endpoint for your SQL, you'll need this for accessing it securely.
- Use Managed Identity to grant access between Azure services. If your services can utilize Managed Identities, they may be treated as trusted, enabling access to resources without relying on public endpoints.
- Deploy an Application Gateway with Web Application Firewall (WAF) features. This adds a layer of abstraction between end users and your App Services, and helps with things like scaling and upgrades. Keep in mind, though, that WAF does add to your costs.
I have to disagree; routing a DB connection through an internal VNet is definitely more secure than accessing it through a public endpoint. While you can limit exposure using firewalls, it won't protect you against potential DDoS attacks. You can consider Azure’s DDoS protection, but that can get pricey.
If you’d rather not deal with VNets but still seek robust protection, there’s a newer service that integrates with Private Link called Azure Network Security Perimeter which could be worthwhile.