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:

• Azure docs Application Gateway overview
• Azure docs architecture center about Application Gateway
• Application gateway OWASP supported ruleset documentation

Hope this helps!