info@nimbus.expert
Background
I’m mostly a developer focused azure architect. In my recent activities, I have been confronted with a lot of policies, compliance, and security in-depth requirements. I like to think that I have a security-first mindset, but as it turns out, I was missing some pieces of the puzzle. In my journey to look to understand and solve the requirements, I found some aspects interesting to share. I hope you find them useful.
Most Azure services are highly secured and highly available by default. The design rationale behind services like ‘app services’ are to be as versatile and easy to use as possible. Whether you’re deploying python applications or .net core apps, you can use the one app service with some configuration changes. It’s also nice of Microsoft to make sure that others can’t access what we run or configure in terms of settings. In terms of identity, we’re covered by Azure (if we don’t mess up configuration).
It doesn't end with configuration settings and identity security. Microsoft won't make a one-stop service that solves all requirements in one go. Nor should it. It would be a spectacularly one-sided service. The remaining subject is network configuration. And a lot can be done there to really secure your services and backends without going to systems like Service Fabric or AKS. I’ll be walking you through the networking aspects and the consequences for us developers.
This post is the first in a series of post to help make sense of the compliance and security-in-depth world that you need to understand to run services in Azure the right way.
Setting the scene
Let’s keep things nice and simple to start:
We want to run a website! Choose App services for running the website, SQL database for the data storage. And finally: key vault for some secret storage. Yup. We’re secure. From a developer perspective, if you’re not leaking any credentials or other types of secrets in your app settings files, SQL scripts or deployment pipeline, you’re already doing more than some.
The question is: will this pass compliance checks?
For those of you who are not that familiar with compliance checks, there are many different aspects to think about. To name a few: GDPR compliance, network security requirements, secret storage requirements, identity access management requirements. If you want to get an idea of what compliance requirements might look like: check out the requirements for the Flemish Government (in Dutch).
It turns out we can do better. The code running in the app service is still vulnerable to many types of attacks and can cause unwanted security issues. In all steps of the SDLC there are possible vulnerabilities: during development time, in source control, issues brought up by the CB process, runtime security and the list goes on. Here again, we have a few paths to consider:
- Secure the development pipeline end-to-end
- Do security scans on your dependencies,
- Do code quality scanning for both code and security issues,
- Secure your build environment,
- Secure your deployment environment
- Harden (secure) the network
- Use least privilege principles
- ...
This post is about the networking aspect of hosting services. The other listed bullets involve setting up things like SonarQube, WhiteSource scanner, OWASP ZAP scanner, … and a great many other tools. As I mentioned, we’ll be focussing on the infrastructure side of things. Let’s leave the well-known-dev-cycle path and go the infra path.
Let's start with the beginning: how to secure incoming requests to the web server, and what kind of security does it provide? Enter the WAF, or Web Application Firewall
WAF? Wait A Few? Oh. Web Application Firewall.
In short: WAF's are an L7 security component. … L7? L7 from the OSI model is the application layer part of the OSI model. Being in the Application layer means that we’re outside the realm of standards that are widely adopted. We’re in our own application/system world with the runtimes that we’re creating on our own.
This in turn means that whatever we put in our network, it must be able to understand the ingress (or incoming) side of the traffic going into the app service. It must be able to decrypt the TLS-encrypted packages and figure out if the incoming payload is a malicious payload for the application or not. The flow then becomes something like this:
It's important to understand that WAF's work on an HTTP payload level. To evaluate the request being safe or not, it will use a set of rules. These rules can be a great many things. An example can be: does the request hold any SQL-injection-like code? If yes, block the request. Meaning that, even if you’ve missed something in your development process, your infrastructure now protects you.
Good stuff! Does it sound like something your CISO might want to put in front of your web services? I think so! The appliance name we’re looking for is a WAF. Or Web Application Firewall. WAF’s have that nice capability of inspecting traffic and declaring it valid or not.
In Azure, the native WAF to use is the Application Gateway (AppGw). The Azure Application Gateway is primarily not a WAF, it’s a reverse proxy (RP) that has WAF capabilities. If enabled.
RP’s allow us to do things like redirecting and rewriting traffic to other endpoints and configure conditional forwarding for HTTP(S) traffic. It’s a versatile tool that offers many capabilities for managing data flows and securing the backend process. Simply by adding the AppGw into the ingress flow of requests, you will be on your way to answer a lot of the compliance and security requirements. These requirements are forcing us to hide services off from the public and involve more infrastructure services.
The result in azure looks like this:
Look at these links if you want to learn how to set up an Application Gateway with WAF enabled, or want to know more about the rules the AppGW offers in Azure:
https://docs.microsoft.com/en-us/azure/application-gateway/overview
Hope this helps!