Last month I covered security options for Microsoft 365 — both what you get in the basic SKUs and what the higher SKUs provide. This time around I’ll cover Microsoft Azure, both the Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS) services and what options you have to secure your cloud deployments. First, I’ll look at foundational services and technologies, and then move on to specific tools for different deployments.
Azure Resource Manager
It begins with Azure Resource Manager (ARM). Everything in Azure (except really old resources that were deployed years ago under the Azure Service Manager, ASM, model) is deployed using ARM. If you just click buttons in the portal to create a database, a virtual machine (VM) or a virtual network (vNet) an ARM template is created for you and that’s what’s deployed. But you can create your own templates for your business, or customize the available ones. Once you start doing that, however, you’ve got to think about how you’re going to manage secrets such as usernames and passwords for VMs, connection strings, certificates and so on. The solution is Azure Key Vault
Key Vault is the place to store all of your secrets — passwords, RSA keys and certificates, and so on (Figure 1). For ARM you then enable the vault to be used for deployments, and a Web site ARM template, for instance, will “fetch” the TLS certificate, SQL connection string and any other secrets when you’re deploying it.
There are two flavors of Key Vault: A1 Standard, which is software-based, or the P1 Premium tier, where the secrets are stored in a Hardware Security Model (HSM), currently Gemalto SafeNet Luna appliances. You can connect a Key Vault to a Certificate Authority (CA) account to automatically create certificates as required.
An often overlooked gem in Azure is Policy, where you can audit your resources (Figure 2). For instance, you can ensure that all of your SQL Databases have Transparent Data Encryption (TDE) enabled, and automatically remediate if they’re not, or deploy a VM extension to all your Windows VMs to ensure that the Administrators group only contain members you specify. You can also apply policies that limit what type of resources users can create and in which regions they can create them. These are examples of built-in policies, but you can also create your own, giving you a good path to governance and control over your company’s cloud deployments.
Role Based Access Security (RBAC) is the part of Azure where you control access to various resources. You can assign roles at the subscription and resource group level and even at the resource level (in very specific situations, it’s a bit like assigning permissions to a specific file in a folder, rather than at the folder level). You can also group multiple subscriptions into management groups (MGs), nest MGs to reflect your organizational hierarchy and assign RBAC permissions at various levels for governance.
RBAC is built around the concept of roles, with four main ones: Owner, Contributor, Reader and User Access Administrator, with more than 40 built in resource-specific roles such as VM Contributor or Monitoring Reader. You can also create your own custom roles. Assigning the correct permissions to resources in Azure is a cornerstone of controlling your security posture.
Azure Security Center is another no-brainer for security for all of Azure (and on-premises and other cloud resources, too, if you want). This is a one-stop place for evaluating the security compliance of your IaaS VMs, as well as your virtual networks, your identity configuration and your databases. Just like Microsoft 365 has a Secure Score that I looked at in the last column, Azure now has an overall score for your deployment, along with recommendations for actions that will improve your score (Figure 3). The score is broken down by areas such as Data & storage, Networking and so on. I really like Secure Score in Microsoft 365 and it’s no less useful here, although it’s a little less mature.
The addition of a score for your compliance with regulations is also welcome, although it’s only in preview at the time of this writing (Figure 4). PCI DSS 3.2, ISO 27001 and SOC TSP are covered.
One of the most important features that Security Center offers for VMs is Just-in-Time Access. If you don’t have a Site-to-Site VPN or ExpressRoute connection from on-premises to Azure, you have to access your Linux machines via SSH and your Windows machines via RDP to administer them. Rather than leaving that access on permanently for the automated scans of attackers and brute force attempts, those ports are closed until an administrator logs on to the Azure Portal, performs a Multi-Factor Authentication (MFA) and then the relevant port is opened for a set amount of time, perhaps an hour. This significantly lowers your attack surface.
Security Center also gives recommendations for your PaaS workloads such as Azure SQL Database, App Services, Blob storage accounts and virtual networks.
If you want to distribute TCP or UDP traffic to multiple endpoints in Azure (plus on-premises for high availability), the Load Balancer is the way to go. You can either use it as a public load balancer for traffic from the Internet or internally between subnets inside your virtual network. If on the other hand you have Web traffic that you need to distribute between nodes for scale and availability, you should look at the Application Gateway and its sister, Web Application Firewall.
Application Gateway (AG) is specifically for protecting Web resources, either in App Services or in VMs that you manage. Because AG operates at layer 7 it can be more specific and redirect traffic to a specific URL, for instance (/images to this server, /videos to this other one). It also support SSL termination and optionally you can enable the Web Application Firewall (WAF) part of AG. This will give you built-in protection against SQL injection and cross-side scripting, as well as the entire Open Web Application Security Project (OWASP) core rule set, either version 2.2.9 or 3.0. If a particular rule or group of rules aren’t applicable to your Web sites, you can disable them. WAF also integrates with Security Center.
Most resources in Azure either must be or can be deployed to a vNet. Within a vNet you can use subnets and Network Security Groups (NSGs), a software firewall to control traffic flow to and from resources. NSGs are part of Azure and don’t cost extra, but can be tricky to manage at scale. Another option is Azure Firewall, which is a managed firewall with cloud scalability that can be deployed in a hub network for centralized firewall traffic management. With Firewall you can control both incoming and outgoing traffic, including limiting outgoing traffic to a list of FQDNs.
Azure is always protecting all resources with DDOS protection, but if you need specific insight into malicious traffic targeted at your specific resources, the Standard SKU of DDOS Protection is the way to go. It even provides offsets on your bill for data transfer and application scale-out costs for documented DDOS attacks.
You may have heard of Microsoft’s new security information and event management (SIEM) play — Azure Sentinel — currently in public preview. Next month I’ll do a deep dive on Sentinel and how you can use it to further improve your Azure security posture.
I trust that this overview has given you pointers to the security controls you can use to improve the security posture of your cloud deployments.