5 Best Practices to Secure Your Azure Resources

Originally published by CrowdStrike.

Cloud computing has become the backbone for modern businesses due to its scalability, flexibility and cost-efficiency. As organizations choose cloud service providers to power their technological transformations, they must also properly secure their cloud environments to protect sensitive data, maintain privacy and comply with stringent regulatory requirements.

Today’s organizations face the complex challenge of outpacing cloud-based threats. Adversaries continue to set their sights on the expansive surface of cloud environments, as evidenced by the 75% increase in cloud intrusions in 2023 recorded in the CrowdStrike 2024 Global Threat Report. This growth in adversary activity highlights the need for organizations to understand how to protect their cloud environment and workloads.

In light of the frequent breaches of Microsoft’s infrastructure, organizations using Microsoft Azure should take proactive steps to mitigate potential risk. Microsoft’s solutions can be complex, difficult to maintain and configure, and prone to vulnerabilities. It’s the responsibility of organizations using Azure to ensure their cloud environments are properly configured and protected.

This blog outlines best practices for securing Azure resources to ensure that your cloud infrastructure is fortified against emerging and increasingly sophisticated cyber threats.

Best Practice #1: Require Multifactor Authentication (MFA) and Restrict Access to Source IP Addresses for Both Console and CLI Access

In traditional IT architecture, the security perimeter was clearly defined by the presence of physical network firewalls and endpoint protections, which served as the first line of defense against unauthorized access. In cloud-based environments, this traditional architecture has evolved to include identity, which encompasses user credentials and access management.

This shift amplifies the risk of brute-force attacks or the compromise of user credentials. Particularly in Microsoft environments, the complexity of the identity security framework and inability to consistently apply conditional access policies across the customer estate introduce additional risk. Navigating Microsoft’s security solutions can be daunting, with multiple agents to manage and an array of licenses offering varying levels of protection. The lack of real-time protection and inability to trigger MFA directly through a domain controller further amplify risk.

Adversaries who manage to procure valid credentials, especially by taking advantage of weak identity security practices, can masquerade as legitimate users. This unauthorized access becomes even more dangerous if the compromised account has elevated privileges. Adversaries can use these accounts to establish persistence and perform data exfiltration, intellectual property theft or other malicious activity that can have devastating impacts on an organization’s operations, reputation and bottom line.

To avoid this, organizations should:

• Use conditional access: Implement conditional access policies and designate trusted locations.
• Require MFA: Enforce rules for session times, establish strong password policies and mandate periodic password changes.
• Monitor MFA connections: Verify that MFA connections originate from a trusted source or IP range. For services that cannot utilize managed identities for Azure resources and must rely on static API keys, a critical best practice is to restrict usage to safe IP addresses when MFA is not an option. However, it’s crucial to understand that broadly trusting IPs from your data centers and offices does not constitute a safe practice. Despite the network location, MFA should always be mandated for all human users to ensure maximum security.

Best Practice #2: Use Caution When Provisioning Elevated Privileges

Privileged accounts have elevated permissions, allowing them to perform tasks or operations that a standard user would not be able to perform. These may include accessing sensitive resources or making critical changes to a system or network. Accounts provisioned with more privileges than needed are appealing to adversaries, driving both the likelihood of compromise and the risk of damage.

Adversaries often target privileged Azure identities to establish persistence, move laterally and steal data. While high privileges are necessary for IT and systems administrators to accomplish routine tasks, weak security policies on account provisioning can dramatically overexpose an organization to risk. These privileges should be tightly controlled and monitored, and only provisioned when strictly necessary after a security process has been defined and implemented.

Service accounts add to these challenges. Their limitations represent a troublesome area for Microsoft — for example, the difficulty in discovering and tracking Active Directory-based service accounts and poor visibility into these accounts’ behavior.

To help prevent adversaries’ abuse of privileged accounts, organizations should:

• Reduce the quantity of privileged users: Only grant privileged role assignments to a limited number of users. Overprovisioning is common and is often done by default by the application.
• Follow the principle of least privilege: Individuals should only be granted the minimum permissions necessary to perform their required tasks. Regular reviews should be scheduled with a view to downgrading privileges where the need no longer exists.
• Control access: Restrict cloud access to only trusted IP addresses and services that are genuinely required.
• Ensure that privileged accounts are cloud-only: Azure privileged accounts should be cloud-only (not synced to a domain), they should require MFA and they should not be used for daily tasks such as email or web browsing.

Best Practice #3: Utilize Key Vaults or a Secrets Management Solution to Store Sensitive Credentials

A surprising amount of digital information is unintentionally stored in public-facing locations that can be accessed by adversaries and then weaponized against an organization. Public code repositories, version control systems or other repositories used by developers can have a high risk of exposing live access keys, which authenticate a trusted user into a cloud service. Exposed access keys allow adversaries to pose as legitimate users and bypass authentication mechanisms into cloud services.

Adversaries can use access keys, along with metadata and formatting clues, to identify specifics about an environment. Exposed access keys can also be acquired from code snippets, copied from a repository where they are exposed or pulled from compromised systems or logs. Private source code repositories can be compromised, leading to theft of these API keys.

Stolen credentials, whether they’re console usernames and passwords or API key IDs and secret IDs, play an essential role in many incidents. This is evident in the latest Microsoft breach by Russian state actors, which stole cryptographic secrets such as passwords, certificates and authentication keys during the attack. This incident raises a significant concern: If Microsoft, using its own technology and expertise in the environment it owns, struggles to remain secure, how can Microsoft customers confidently protect their own assets?

To protect against this, security teams should ask themselves:

• Where do we store access keys?
• Where are our access keys embedded?
• How often do we rotate our access keys?

Having a dedicated secrets management solution to protect and enforce granular access to specific secrets makes it difficult for an adversary or insider threat to steal credentials.

Important note: Proceed with extreme caution when tying administrative or highly privileged access to the key vaults to SSO. If your SSO is subverted through weak MFA management, all of your credentials could be instantly stolen by a threat actor impersonating an existing or new/newly privileged user. Hardware tokens and strong credential reset management is a must for these applications.

Best Practice #4: Don’t Allow Unrestricted Outbound Access to the Internet

One of the most common cloud misconfigurations we see is unrestricted outbound access. This allows for unrestricted communications from internal assets, opening the door for outbound adversary communications and data exfiltration.

Also described as free network egress, unrestricted outbound access is a misconfiguration in which Azure cloud resources like containers, hosts and functions are allowed to communicate externally to any server on the internet with limited controls or oversight. This can be a default misconfiguration, and security teams often have to collaborate with IT or DevOps teams to address it. Because developers or system owners don’t always have full knowledge of the various external services that a workload might depend on — and because they might be accustomed to having unrestricted outbound access in their other work environments — some organizations battle with trying to close this loophole.

Adversaries can exploit this wherever untrusted data is processed by a workload. For example, an adversary may attempt to compromise the underlying software processing web requests, queued messages or uploaded files using remote code execution. This is then followed by payload retrieval or establishing a reverse shell. If outbound access is not permitted, they cannot retrieve the payload and attacks cannot be completed. However, once an initial code execution attack is successful, the adversary has full execution control in the environment.

To address this, organizations can:

• Configure rules and settings: Define cloud rules to securely control and filter outbound traffic, with provisioned security groups serving as an additional layer of protection.
• Apply the principle of least privilege: Grant outbound access only to resources or services where it is explicitly required.
• Control access: Limit cloud access exclusively to trusted IP addresses and services that are genuinely necessary.
• Add security through a proxy layer: Utilize proxy server tiers to introduce an additional layer of security and depth.

Best Practice #5: Scan Continuously for Shadow IT Resources

It is common for organizations to have IT assets and processes running in Azure tenants that the security teams do not know about. There have been incidents in which threat actors have compromised Azure resources that were unauthorized or were supposed to have been decommissioned. Both nation-state and eCrime adversaries thrive in these environments, where logging and visibility are typically poor and audit/change control is often nonexistent.

Some recommendations to address shadow IT resources include:

• Implement continuous scanning: Deploy tools and processes to continuously scan for unauthorized or unknown IT resources within Azure environments, ensuring all assets are accounted for and monitored.
• Establish robust asset management: Adopt a comprehensive cloud asset management solution that can identify, track and manage all IT assets to prevent unauthorized access and use, enhancing overall security posture. This includes Azure enterprise applications and service principals along with their associated privileges and credentials.
• Enhance incident response: Strengthen incident response strategies by integrating asset management insights, enabling quick identification and remediation of compromised or rogue assets. These may include unauthorized virtual machines used for activities like crypto mining and enterprise apps and service principals used or repurposed to exfiltrate databases, file shares and internal documentation and email.

Additional Resources

• Find out about cyberattacks targeting the cloud in the CrowdStrike 2023 Cloud Risk Report.
• Learn about common cloud misconfigurations and find out how to minimize the adversaries’ opportunities to exploit them in this eBook: Seven Easily Exploited Cloud Misconfigurations.