Security in the Cloud starts with Architecture

In today’s connected world the subject of security is perhaps the hot topic – at least when it goes wrong!  Unfortunately, many risk teams argue that security is often thought about too late – i.e., after a security incident has occurred and an application has been compromised.

To innovate we need to be able to build new solutions rapidly – using Agile frameworks there is much emphasis on getting out the MVP (Minimum Viable Product) as fast as possible and then iteratively building upon it every two weeks or so.

From a security perspective this creates big headaches – we need to ensure the MVP is solid, but then with every update we introduce the possibility of creating new vulnerabilities.

For many clouds vendors security in depth is an important paradigm to help solve these problems – we need to implement multiple layers of security controls so that if one area is compromised there are others that will stop an attack.

Some of these controls can grouped into the following areas.

• Network Security
• Encryption
• Authentication/Authorization
• Governance and Compliance

Also notice that these are all mainly around infrastructure, and because of this we need to ensure that they are considered right at the very start of a new solution.  Our solutions need to be secure by design, or to put it another way, security has to start with architecture – i.e., when we design solutions, we need to consider security in the first instance, and always have it in mind when addressing functional and non-functional requirements.

A very simple example of this is when building a simple Azure Web App that connects to an Azure SQL Database.  By default, web apps are built to expose public endpoints and the SQL Database has an option to Allow Azure services and resources access the server (i.e., our Web App).

This reduces the network scope to only Azure, but it includes every other customer using Azure – not just your own subscription or tenant.

We of course need a login and password to access the database (or we can used Managed Identities or AD Integration), but this only represents a single layer of protection.  We should be designing our solutions with greater depth.

One way to further secure the network is through Service Endpoints.  With Service Endpoints you can configure Azure SQL Database to only accept connections from a particular VNET, however for this to work you must enable VNET integration on the Web App itself.

Using VNET integration also allows you to use Network Security Groups on the web app as well, which means you can also control outbound communications.

Finally, the addition of an Application Gateway or Azure Front Door gives even further protection, but to fully realise this added security you must also specifically block all access to the Web App except from the Application Gateway or Front Door appliance.

The following diagram shows an example of how this might look.

This is just one example of how good architecture can ensure that your solutions are locked down more – but these options must be specifically chosen, they are not enabled or configured this way by default.  

Taking it to the next level you can build Azure Policies that would block or report on services that don’t align to your prescribed patterns, which grants greater control over your whole enterprise.If you would like to learn more about Azure architecture, and prepare yourself for the AZ-304 Microsoft Azure Architect Design exam, checkout my book on Amazon - Exam Ref AZ-304 Microsoft Azure Architect Design Certification and Beyond: Design secure and reliable solutions for the real world in Microsoft Azure