Azure Security: Best Practices and Guidance

Microsoft Azure is one of the leading cloud providers in the world. Its breadth of services and tight integration with the Microsoft ecosystem makes it ideal for many enterprise workloads. As a result, Azure has become a staple of many modern digital environments, and, for many organizations, Azure security is a critical aspect of maintaining a strong security posture.

Azure offers basic best practice security features for free. Its integration with Azure Active Directory (AD) and other identity providers helps to manage users and their access easily. However, default settings and security features alone aren’t always enough. This article will explain seven essential Azure security best practices that can help teams get the most out of the platform while reducing the risk of a breach. 

Summary of Azure security best practices

The table below summarizes the Azure security best practices this article will explore in more detail.  

Azure security best practices: #1 Understand shared responsibility and audit resource access

Security is a shared responsibility between cloud providers and customers. Understand the division of duties for various services that are being used. Compare those duties across different XaaS (Iaas, PaaS, FaaS, CaaS, DBaaS, etc.) models, then design the solution based on how much responsibility IT teams can take up. For example, if an IaaS, like Azure VM, is used for hosting a web server, then applying security patches becomes the customer’s responsibility, not Azure’s. Instead, if a PaaS, like Azure App Service, is used Azure manages patching and other OS and infra-level upgrades, while customers are responsible only for the application and other configurations. Comparing a service’s value against security operations overhead is a good starting point when choosing a service.

Processes, tools, and technology become crucial while dealing with security at scale. Processes like change management, approval workflows, and just-in-time access must be in place before moving to production. Additionally, operations teams must be efficient and well-versed in these processes.

As part of these processes, if there are any requirements for access to resources, then the requirements must be vetted properly. Operations teams must be trained to question every access request and avoid giving any access until a valid business justification is provided. 

Administrators should always use security groups to manage resource access, and Azure AD access reviews should govern memberships. Access reviews help with regular attestations of group memberships, reducing the risk of unnecessary access. 

Regularly review security group membership to ensure that accounts that no longer require access, particularly those with high privileges, are removed. You can conduct the audit manually or through automated processes with Azure AD access reviews. Make auditing a recurring activity that happens at least annually.

Azure security best practices: #2 Implement the principle of least privilege using RBAC

Scope the access requirement and give the user or the app just enough access. Say no to future scoped requests like “I don’t need it right now, but I’ll need it in the future” or uncertain requests like “I might need it.” It’s better to start with lower privileges, and increase the access based on the feedback, than providing elevated privileges unnecessarily. 

Azure offers built-in service and operation-specific roles. Suppose a resource group contains a Virtual Machine and a Key Vault, and a VM admin needs to read keys and secrets from the Key Vault. In that case, assign the Virtual Machine Contributor role on the VM and the Key Vault Secrets User role on the Key Vault for the user. Virtual Machine Contributor lets an identity create and manage a VM, and Key Vault Secrets User enables an identity to read secret contents. This is a good way to avoid granting access at a higher scope, like a resource group, while ensuring the user has the required permissions.

Now let’s say we don’t want to manage two different roles, and we want the VM admin to only do OS patching on VMs. We can address this requirement by creating a custom role with granular permissions. This way, we can ensure that the principle of least privilege is implemented at the role and operation level. The screenshot below provides an example of a custom role definition.

A custom role which can read keys and secrets from Key Vault, and can perform patching on VMs.

After creation of the role, it can be assigned to an identity just like built-in roles.

Azure security best practices: #3 Avoid misconfigurations by enforcing security policies

Policies help define what makes a resource compliant. Policy tools continuously assess resource configurations against the compliant configuration to detect and prevent drift from the organization’s standards. 

Azure’s native policy management tool is Azure Policy. It evaluates all Azure resources under the specified scope against the policy definition. A policy definition contains conditions that need to be fulfilled for a resource to be compliant and the consequence if the resource is not compliant, called the “effect”. For example, a definition in plain English would sound like “If the location of a storage account is set to anything except North Europe, don’t create it”, or “If Azure SQL is open to the public network, flag it as non-compliant”. Creating policy definitions and assigning them to required scopes ensures misconfigurations are flagged and remediated proactively.

However, Azure Policy is only useful for defining policies related to the Azure cloud. For organizations that need multi-cloud support, Paladin Cloud is an excellent alternative for policy management. It is free, open-source, and supports multi-cloud architectures. It supports policy management, security monitoring, and reporting. Additionally, Paladin Cloud offers more policy scope flexibility than Azure Policy. Policies can be scoped to a group of resources (“asset groups”) sharing the same tags or by the user.

For example, by setting the tag Application=Atlas all the policy findings for the Atlas application in the Paladin Cloud ecosystem would be grouped. Now the Atlas team can focus their efforts on the systems they are responsible for instead of digging through the entire organization’s data.

Finding non-compliant configurations as early as possible in the Software Development Lifecycle (SDLC) is always a good idea. To do that, create or update the policies during development and deploy them to test subscriptions to understand their impact. 

The Azure Policy below shows an example of how to restrict the locations where resources can be deployed. This Policy as Code approach helps to enforce organizational standards and best practices. Paladin Cloud works with Azure Policy to detect whether your environments follow these best practices.

{
  "properties": {
    "displayName": "Allowed locations",
    "policyType": "BuiltIn", // Custom policy can also be created
    "mode": "Indexed",
    "description": "This policy enables you to restrict the locations your organization can specify when deploying resources. Use to enforce your geo-compliance requirements.",
    "metadata": {
      "version": "1.0.0",
      "category": "General"
    },
    // While assigning this policy, list of allowed locations can be specified as parameters.
    "parameters": {
      "listOfAllowedLocations": {
        "type": "Array",
        "metadata": {
          "description": "The list of locations that can be specified when deploying resources.",
          "strongType": "location",
          "displayName": "Allowed locations"
        }
      }
    },
    "policyRule": {
      // condition- if the location of the resource is not present in the parameter list
      "if":
          {
            "field": "location",
            "notIn": "[parameters('listOfAllowedLocations')]"
          }
      },
      "then": {
        "effect": "deny" //if the condition is met, the resource is marked as non-compliant and its creation is denied
      }
    }
  },
  "id": "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c",
  "type": "Microsoft.Authorization/policyDefinitions",
  "name": "e56962a6-4747-49cd-b67b-bf8b01975c4c"
}

JSON representation of an Azure Built-In Policy.

Azure security best practices: #4 Use data encryption

Leave no stone unturned when it comes to encryption. Missing encryption even at a single point could lead to data leaks. That’s why developers and security teams must have a good knowledge of architecture to identify places where encryption must be implemented, both in transit and at rest. 

Once identified, explore what Azure offers by default and what customization customers may need to do. Azure has an encryption solution for almost every scenario, including data in transit and at rest:

• At-rest data encryption examples – For Azure SQL databases, data files are by default encrypted using Transparent Data Encryption. Similarly, Storage Accounts are, by default, encrypted using Storage Service Encryption.
  
• In-transit data encryption examples – Azure manages encryption of data flowing across different data centers. Customers need to implement HTTPS to secure web traffic. Use encrypted channels for remote access, like RDP and SSH. For traffic between private networks, Azure VPN gateway helps with sending encrypted traffic between virtual networks and on-prem locations.

For on-prem to virtual network traffic, point-to-site and site-to-site VPNs use encrypted tunnels, making the connection secure automatically.

Encryption can happen either on the client side or the server side. In client-side encryption, developers and security teams can encrypt their data outside Azure and manage keys themselves. The data is encrypted before it reaches servers or the cloud. This gives the teams complete control over encryption methods while avoiding dependency on any cloud provider. However, there’s more area to cover in this case as the default encryption at various places is not there anymore.

Azure will ensure data is encrypted as soon as it reaches their network, hence offloading the overhead from customers in case of server-side encryption. Customers can still manage encryption keys or let Azure manage them. 

Azure security best practices: #5 Identify gaps in network security

Putting the best effort into locking down the network from public and other private networks is essential. Identify the entry points for a network and secure those points.

Wherever possible, place resources within a private network so they are not discoverable in any other network.

Use network security groups to deny unwanted traffic into the private network. Azure Firewall is an excellent option for advanced firewall capabilities like monitoring, threat intelligence, and L3-L7 policies.

Understanding the network exposure required by PaaS services is essential. Use IP allowlisting to restrict public network traffic. If no exposure to the public network is required, then traffic can be routed through the Microsoft backbone network using service endpoints and private endpoints. This ensures traffic flows through trusted channels and stays on Microsoft’s trusted network. 

The service needs to have a public IP in case of service endpoints, as the last hop to the service is to its public IP. If the public IP of the service needs to be disabled to make it more secure, use private endpoints for connectivity using private IP over a virtual network.

Difference between public and private connectivity with Storage Account as an example. (Source)

Azure security best practices: #6 Limit usage of credentials

Credentials could be of different types including passwords, secrets, certificates, access keys, and connection strings. Developers and security teams must know about the kinds of credentials being used and how they are managed, as they could act as an entry point for threat actors. 

There needs to be a robust mechanism for storing and accessing the credentials. Azure Key Vault is the preferred service for storing credentials. Key Vault enforces encryption of stored data while giving granular access to the stored data in the form of access policies and role based access control. 

Ensure that MFA protects the accounts of people with access to sensitive resources. While MFA is a must for these privileged users and IT, MFA should be enforced for all users.

Renew credentials frequently. Azure PaaS, like storage accounts, Azure SQL, etc., have the option of rotating credentials on demand, hence making it useful at the time of remediation of a possible leak. If consumers of the PaaS are in the same tenant, consider using managed identities. Managed identities are identities that Microsoft manages in the Azure AD, and they can be attached to a resource, hence giving that resource an identity. The created identity can then be assigned the required roles in PaaS for consumption. 

Managed identity is preferred for using service principals wherever possible, as there is no risk and operational overhead of secrets and certificates. Behind the scenes, a managed identity is a service principal object in Azure AD. It is just that they are automatically managed, making our lives simpler.

To understand the different ways of using credentials, let’s take an example of a scenario and see the possible ways of accessing it while minimizing risks for different types of consumers.

A storage account’s blob data must have read-only access to: 

• A developer
• A CI/CD pipeline that contains a PowerShell script
• An Azure function

The best possible ways to read blob data while minimizing risk are:

1. Raise access requests through Privileged Identity Management (PIM) for Storage Blob Data Reader role. The credentials would be the developer’s Microsoft account password, and MFA protects the account. PIM would ensure that the access is temporary and goes through an approval process.
2. Create a service principal with a password-protected certificate as the credential having Storage Blob Data Reader role on the storage account. Store the certificate and its password in an Azure Key Vault, with the pipeline’s service connection having read-only access to the certificate and the password secret. No other entity should have access to the certificate and its password present in the Key Vault. The pipeline can automatically download the required certificate during its execution to access the required blob data. 
3. Enable system-assigned managed identity of the Azure function app. Azure creates and manages an identity of the resource in the Azure AD without involving any credential input. Give Storage Blob Data Reader role to the managed identity on the storage account. 

Azure security best practices: #7 Monitor cloud security posture

When there are many resources across multiple subscriptions, or even cloud providers monitoring which ones are non-compliant becomes critical. Missing out on the monitoring could lead to failure in compliance audits and, of course, increases the area for security attacks. Cloud security posture management (CSPM) comes to the rescue for such use cases. 

Tools that continuously scan resources for security issues are available, and they represent the scanned report in a comprehensive dashboard. The dashboard view makes it easy for security teams to have visibility of the cloud security posture of their organization. It makes the turnaround time for remediation quicker if any issues are identified.

Microsoft Defender for Cloud is a CSPM tool popular in the Azure ecosystem. It represents the organization’s security posture as a “secure score”. It also checks for compliance of resources against Microsoft Cloud Security Benchmark (MCSB). MCSB is built on top of the best cloud security principles. 

Defender for Cloud sends security alerts whenever it detects an incident on resources for which Defender for Cloud is enabled. It categorizes these incidents into levels of severity (high, medium, low), which helps security teams take action based on the severity of the incident. 

Security teams should have strategies to deal with each type of incident regardless of tools. Try to automate the incident handling wherever possible. For example, if an alert is triggered, the security team might want to automatically create a ServiceNow ticket or a GitHub issue to inform other teams to avoid collaboration efforts while keeping other teams in the loop and focusing on investigating and remediating the incident as quickly as possible.

Paladin Cloud has comparable capabilities to Defender for Cloud, with the added benefit of being extensible to third party plugins, such as vulnerability scanners. This allows enterprises to identify coverage gaps and verify security controls to increase their security efficacy. In the Paladin Cloud UI, the scope of the portal can be set to a specific asset group, which helps configure the UI to relevant data points for the security teams.  

Overview screen of Paladin Cloud UI. (Source)

Paladin Cloud offers a free open source product and a SaaS version with additional features.

Conclusion

Azure security best practices help organizations develop strategies that address three security use cases: continuous, proactive, and reactive. 

• Continuous – Monitor every component, and train people about processes.
• Proactive – Identify and fix existing vulnerabilities and potential threats that haven’t been reported yet.
• Reactive – If breached, respond in the best and quickest way possible. Engage technical and operations teams as soon as possible and isolate the breach.

Shifting security left and integrating it into the SDLC as soon as possible is essential to optimizing security posture. Integrating security throughout the SDLC builds a security-first culture and helps identify security flaws before they reach production.