Multi-Layer Security for your Azure Integration

Key Takeaways

Jan de Vries has been developing software for well over a decade. Currently, he is working at 4Dotnet as an Azure Software Architect/Developer. His focus is on highly developing performant and scalable solutions using the excellent services provided by the Microsoft Azure platform. Because of his expertise, he has been able to help multiple customers to bring their on-premises solutions to the cloud and guide them toward a better software development ecosystem.

What is multi-level security?

Security is often an afterthought. When designing and deploying solutions within Azure or any other cloud or maybe even on-prem, some interest must be taken into infrastructure and developer perspective. Every organization should apply multi-layer security in one form or another. The easiest part is just securing data repositories from the public internet. Because everything deployed to the cloud is public, probably nobody wants their SQL Server or File storage being out open to the internet. Azure has some security measures, like logging in with Active Directory or having Azure tokens, but organizations should take it a step further. Multi-level security doesn’t cost much, and users can bring it to the next level by adding gateways, firewalls, strict authorization, and authentication policies.

Different layers in multi-layer security

Layers are split into three layers, depending on how each user counts. The first one is securing data repositories by adding virtual networks to the environment and setting policies like only internal traffic or internal services can access this. Having the SQL server in a social network or the storage account in a virtual network, no one can access this aside from their services. That’s the first part, and then users can take it up another level by adding authentication authorization to services or software or adding some more Azure services to the environment like API management, application gateway, or front door. Once the user is done with this, they can add some more policies for API Management with the subscriptions.

Factors to be considered in the multi-layer security implementation

The factors depend on the organization and per project and how secure they need to be. In agriculture, it needs a different way of securing the environment than a banking organization. Suppose the scenario is to integrate with banks and the government. The government and the banks need to have a document saying that we can handle penetration testing, hacks, take a show day exploits, and know our data security. The agriculture sector doesn’t have these mandatory rules. The project with a government and a banking sector will have these things in place, and we have added stuff like application gateway, API management, and Azure firewall to ensure it is secure.

Domains that require multi-layer security

All domains should have at least the isolation of the data repository, SQL, and storage accounts. The banking, government, and insurance domains should have things like an application gateway or a front door added to the environment has some benefits compared to an Application Gateway because it’s a global service. If it is a global project, having a front door added to the solution might make sense. Its major downside is that it doesn’t have CNET integration support, but an application gateway has this support. The positioning of multi-layer security ultimately depends on the domain and scale of the business.