Securing Access to Your Applications

Ensuring the confidentiality, integrity, and availability of applications and data hosted on cloud platforms such as Microsoft Azure is crucial in today’s digital age.

In this chapter, we will explore various Azure security tools and capabilities that can be employed to design a secure environment for your applications. By leveraging these features, you can effectively protect your applications from unauthorized access and potential security threats.

Specifically, we will look at the following areas:

• Designing for security
• Securing traffic
• Securing keys and secrets
• Using managed identities

Technical requirements

This chapter will use the Azure portal (https://portal.azure.com) throughout for the examples. You will also need Visual Studio for Windows installed. The code examples for this chapter can be found in this book’s GitHub repository at https://github.com/PacktPublishing/Azure-Architecture-Explained.

Designing for security

Azure provides a range of tools to help us ensure our systems are secure. Some of these tools, such as Azure Key Vault, are independent services to be consumed as part of our solution. Other tools are component-specific, such as an Azure SQL Server’s firewall or threat protection capabilities.

In many cases, some options may seem to be duplicated or overlap in services – this isn’t by accident. When designing cloud applications, we often want to deploy and combine multiple tools that seem to serve the same purpose, or at the very least provide additional layers.

This multi-layered approach is called defense in depth and is an important subject in cloud platforms such as Azure. This concept essentially states that we should expect one or more of our security measures to fail – and then design additional measures to compensate when they do.

It may seem odd to assume something will fail – after all, years of system design...

Securing traffic

Securing traffic at the network level is often a given in an on-premises network. When you create systems in a corporate network, they will usually be secure by default. In other words, anything you deploy would be inside your network and to expose it to the internet, you would need to specifically allow traffic out through a firewall.

In contrast, within Azure, many services are often public by default, and if you wanted to secure them so that they’re internal, only would you need to configure this aspect.

Important note

Many applications, even those built for internal use only, are often exposed and consumed over the internet (for example, a SaaS product). Zero trust is a common pattern that means we control access to applications via identity and conditional access policies that are applied to end devices to control access rather than firewalls.

Therefore, you may think that any form of network-level security is no longer relevant – however...

Securing keys and secrets

Securing your applications against network-level attacks is often the first line of defense. With the additional capabilities of a WAF, you can readily protect against many forms of attacks and issues in your code.

But not all attacks come head-on. Most attacks are usually through insider threats – either maliciously or accidentally. What we mean by this is that, if we think back to Mark Twain’s proverb, it’s those that seek to get around the front door that often cause the biggest problems.

Therefore, we need to think about attack vectors other than a direct one over the network. If our network is secure, and our frontend is secure, we must consider how the backend can be exploited.

From a network point of view, this is quite difficult; if an attacker has found a way around these controls, the next level of protection is usually authentication. Because the asset we want to protect is our data, we must consider strategies to protect...

Using managed identities

Many resources in Azure can have identities attached to them, and we can use those identities to provide access to other Azure services without the need for passwords and usernames.

Managed identities are a special type of account called a service principal, and as they are managed, it means we never have to see the details – Azure just manages them for us.

Managed identities are arguably the most secure method of providing access between components as we never have to record sensitive passwords anywhere.

When we created our SQL Server, we chose Use both SQL and Azure AD Authentication. The AD part is important when using managed identities because, under the hood, they are just Active Directory accounts.

We also need to enable our web app with an identity, which we did in the previous section when we set up the Key Vault. Therefore, all we need to do now is grant access to that account to SQL Server. We must do that by using T-SQL commands...

Summary

In this chapter, we looked at why we need to think about our application architecture in terms of securing access, and which tools can help us achieve this.

We looked at using a layered network approach to securely lock down our backend data by employing tools such as VNet integration, SQL firewalls, Azure Firewall, Azure Application Gateway, and Azure Front Door.

We then looked at securing the connection strings to our databases, why we need to do this, and, again, the different options, such as Azure Key Vault and managed identities.

In the next chapter, we will look at how to control what users can do within Azure using its built-in governance tools.