Azure Security Best Practices

Since Azure offers more than 100 different services, and each service boasts a plethora of literature on how it should be properly configured, navigating security best practices for Azure can seem hopelessly daunting. To make things easier, we’ve assembled this document to illustrate how security best practices can be implemented on some of the most common Azure services.

This article organizes the best practices for managing Azure security in five categories as summarized in the table below: 

Security Category	Examples of covered topics
Identity and Access Control	Azure Active Directory (AD) and AD Domain Services
Data	Data types and key management
Database	Access management, auditing, and threat detection
Backup, Business Continuity, and Disaster recovery	VM, storage, and backup policies
Networks	Network design, VPN, and IP Scheming

Best Practices for Identity and Access Control

Azure AD

Azure AD is a cloud-based IAM (Identity and Access control) service. It establishes access to allocated resources through authentication and authorization. Standard Azure AD is a free tier service that comes along with O365 or Azure and can also be used to login to thousands of other SaaS-based applications. Some of the best practices on how to configure and secure Azure AD are given below:

Check Microsoft Secure Score

Microsoft Security Center is a free service provided with every O365 or Azure account. Login to your O365 tenant as an admin to access Security Center. Security Center provides an overall score on the security posture which includes, but is not limited to, settings for Azure AD to help improve the security. For more information on Secure Score, visit the Microsoft Secure Score web page.

Adopt a Zero Trust Approach Whenever Possible

The Zero Trust approach is normally used when data security is paramount. There are some general guidelines on how to approach Zero-Trust security. 

Zero Trust runs on the approach, malicious until proven otherwise. Every user, device, and process is deemed malicious unless proven safe, secure, authenticated, and authorized. 

Another important rule of a Zero Trust model is the principle of least privilege (POLP). Every user, which also includes the administrator, will only have access and control to the resources required to complete the task. For more details on Zero Trust, consult the website What is Zero Trust Security? by Check Point.

Enable Azure Security Defaults or Set Up MFA Separately

Azure security defaults are a set of security settings that already have best practices configured to view most of the organization. It’s a great place to start for most organizations and includes all the important security configurations. MFA is one of the many configurations included in the security default. If an organization wants to set up a security policy that is different from the security defaults, it should make sure that MFA is set up. 

Perform Regular Auditing

Azure AD comes with a reporting feature that allows organizations to view sign-in activity, application usage, administrative change, or any other changes that might impact sensitive resources. 

Use Attack Simulator MS Security Center also comes with an attack simulator which, as the name suggests, simulates a phishing attack. It does that by either sending an email to all the users with a phishing link and checking how many users fall for it or by sending a doc or pdf message with a warning. 

Configure Conditional Access to Setup Access Variables

Conditional Access is one of the features in Azure AD which puts conditions on authentication based on different parameters. These could be a user, device, location, certificates, and more. Conditional Access can make your environment more secure without a lot of user impact. 

Azure AD Domain Services

Azure AD Domain Services has nothing in common with Azure AD or a standard Domain Controller. It is a completely separate service provided for a completely different deployment scenario. It’s important not to confuse one with the other. 

Azure AD Domain Services is a managed service by Azure that provides a Domain Controller in the cloud with the ability to accept modern authentication, unlike a standard Windows-based DC. An Azure AD DS integrates with Azure AD during its creation to import all the users and their credentials into its directory. Since this is a managed service and not a local DC with full functionality, it does have its limitations. 

1. Even though desktops and servers can be connected to Azure AD DS, direct visibility is required. This means, your desktop or server should be able to resolve Azure AD DS, unlike Azure AD which is available everywhere. This should never be used as a replacement for standard on-prem DC. 
2. Azure AD DS is a read-only copy of your Azure AD. All the users and devices are copied over during deployment, but any changes made on Azure AD DS aren’t written back to Azure AD. 
3. There is no domain admin in Azure AD DS since it’s managed by Microsoft. Any application integrated with Azure AD DS that requires a domain admin will not work. 

Best Practices for Data Security

Types of Data

There are two statesof data in data security: Data at rest and data in motion or transit. A different set of policies and security measures are taken depending on the state of the data. 

1. Data at rest is the static data that exists on storage media. There are two different approaches to protect data at rest. 

• Restricting access to the data. 
• Encryption. 

You can visit this link to find more on how to protect data at rest.

2. Data in transit is the data being transferred from various users, components, devices, processes, and programs to each other. The only way to ensure the security of data in transit is encryption. There are many ways to encrypt data in transit, for example, transport-layer encryption, server or cloud-side encryption, wire encryption, etc. 

Key Management 

Azure Key Management Solution lets you manage cryptographic keys used for encryption. These keys are used by cloud applications and services. Keys are stored in secure vaults which are encrypted and can only be accessed by applications and programs that require these cryptographic keys. This also prevents writing these keys in programs and applications, reducing their exposure to any malicious activity. More information on key vaults can be found here

Database

Database Access Management

Depending on the use case, a database might be exposed to the internet. A lot of databases have to be made accessible over the internet for everyone to access the required data. This presents a significant risk since everyone has access to the database and could potentially access records they aren’t authorized for or worse, destroy the data. Database access management is critical for every database, whether internet-facing or not. With an internet-facing database, it just becomes even more essential to deploy security measures to keep the database secure. All the mainstream databases come with access management functionality which can block any unauthorized use. It’s also very important to set the correct network rules for access management. 

Management access for a database can be configured to use a different port. It’s recommended to have a DMZ between the database and the outside world. This will filter all the incoming requests through the firewall before they get to the database. 

Authentication

SQL comes in two authentication modes. 

1. Windows-Based Authentication: 
   With Windows authentication, server admin credentials are accepted to log in to the database. They could either be local or domain administrative credentials. This is set up at the time of configuring the database. 
   
2. Mixed mode: 
   Mixed modeincludes both Windows Authentication and SQL server authentication. SQL Server authentication is a set of credentials set up at the time of SQL installation. ixed mode is highly recommended. In case of a disaster recovery or domain failure, SQL server credentials might be the only way to access the database since windows credentials might not work as it’s running on a different server or domain. 

Azure SQL 

Azure SQL is a managed database instance that is running the required SQL flavor without the underlying operating system. It’s a standalone database that can be created on Azure and connected to different servers and applications the same way as standard SQL running on any Server OS. Azure SQL uses Azure AD for authentication. Securing Azure AD ultimately secures Azure SQL. Common best practices for Azure SQL include:             

Encryption

Azure SQL gives the ability to enable Transparent Data Encryption (TDE) which encrypts all the data at rest. This also applies to backups and transition log files. TDE is enabled by default for all the newer instances of Azure SQL but has to be enabled for the older ones.

You should  leave this enabled or enable it for older Azure SQL instances. Microsoft has a detailed article on TDE which can be found here.

Auditing

Enabling auditing of Azure SQL provides tracking and logging of SQL events. Auditing is disabled by default and needs to be enabled under Azure SQL database settings. Auditing helps in understanding database activities and staying on top of any compliance. It’s important to note that database auditing helps in achieving most regulatory compliance but doesn’t necessarily guarantee it. 

Feature and Threat Detection

Azure SQL comes equipped with threat detection. Advanced threat detection is not available by default or part of the standard Azure SQL instance. It is enabled through MS Defender for SQL which is a paid service. Azure Defender for SQL can be extremely useful depending on the use case and how critical the database is. For any databases with a lot of internet-facing activity, threat detection is essential. It automatically detects and nullifies any malicious activity which might harm the database or compromise its integrity. It will also send out alerts to all the required administrators. 

BCDR design and best practices

3-2-1 Backup strategy is a well-established baseline for any backup solution. It requires 3 copies of the data. One is the production copy and the rest is backup. It also wants to use multiple forms of storage. This is to ensure that the data remains safe even if one form of storage medium goes down. Typically, organizations following this methodology will have tape drives as a secondary backup medium. And lastly, have a backup copy offsite. This ensures your data is safe if the entire site or region goes down. Azure provides a comprehensive Backup, Business Continuity, and Disaster recovery solution. A BCDR design can vary greatly on needs and requirements. Some of the most important things to consider are as follows:

Virtual Machines

Azure Backup is the go-to solution for most organizations. It’s a standard backup with basic retention policies which can backup a VM once every day at a time set up by the administrator. These backups can then be used to either restore an entire VM or have the backup attached in form of a drive for file recovery. 

For a more comprehensive backup solution, Azure offers DRaaS (Disaster Recovery as a Service). VMs are continuously replicated to a pair region. In case of a disaster, the replicated VMs in the paired region are used as primary VMs. Once the outage is over, the primary region syncs up all the changes made on the secondary region during the ongoing disaster and switches back to the default primary region. 

Best practices for Azure Storage

Azure storage has many different options to meet any storage requirements. When it comes to backup, two main options when creating a storage account are:

1. Local Redundant Storage (LRS): 
   All the data stored in the LRS account only have redundant copies in the same data center. LRS is the least expensive option and is widely used for Virtual Desktops and Servers that aren’t mission-critical or require High Availability. 
   
2. Zone Redundant Storage (ZRS): 
   ZRS replicates all data in a ZRS account to three different availability zones in the primary region. An availability-zones is a separate data center and in no way dependent on any other region or availability zone for any of the critical datacenter requirements (power, connectivity, cooling, etc.) The cost of ZRS depends on the availability zones and how often and the amount of data that is replicated across regions. On average it’s almost twice as expensive as LRS. This is why ZRS is only used when High Availability and Durability are paramount. 

This article Azure Storage Replication Explained by Netapp wonderfully illustrates different replication technologies in Azure.

Backup Policies

Backup policies differ from organization to organization. These policies control what to backup, how often to backup, where to store the backup and most importantly, if a backup of the backup is required to ensure there is no single point of failure with backups. 

Depending on what you’re backing up, these policies can dramatically change. Here is a list of best practices that can be applied to almost all the workloads:

1. Always run backup out of office hours or at the time of least activity. Running backups is disk and network-intensive. This can take a toll on the performance and users working during the backup schedule will experience performance degradation. 
2. Make sure the backup schedule does not collide with any other company-wide scheduled activities. Some organizations like to restart their desktops every night. Running backups during a restart activity would be disastrous. Similarly, running a backup during another backup activity could result in backup failure for both. Most backups for windows systems use windows, native readers. If a backup is already running, these readers might already be engaged resulting in a backup failure. 
3. Most organizations would find it useful to have weekly, monthly, and yearly backup copies. With the increase in sophisticated ransomware, which usually stays undetected in the system for months before they start encrypting files, it’s very important to retain old backups. Retaining daily backups for a year can be very expensive so a single monthly or yearly backup will ensure you have a backup far back in the past to beat ransomware that is configured for delay tactic.  

Best practices for designing and securing Azure network

Network design

Like almost everything else in azure, Network design is largely dependent on the use case. There is no single network architecture that will fit all requirements but there are some universal design principles that all designs should follow. 

1. The address space for your on-premise network should not be the same or overlap the address space on your azure. This might not be a problem straight away but if you ever need to establish communication between the two using a VPN, it would all fall apart. 
2. Virtual Networks or VNets are not usable address spaces on their own. They need subnets carved out of the available VNet space. It’s a good idea to create large VNets and have many different subnets created out of one. You should also leave plenty of room to grow. 
3. Large VNets are easy to manage instead of many smaller ones. One large VNet can have many small subnets instead of many different smaller VNets. 
4. Network Security Groups (NSG) are like a firewall for your VNets. An NSG can be attached to an entire VNet, subnet, or a single NIC (Network Interface Card). This will allow you to create inbound and outbound rules for NSG and whatever it’s attached to.

VPN

Azure provides many different flavors of VPN. It’s important to understand each one and use the correct VPN for the job. The best way to select the type of VPN is to determine the following: 

1. How many endpoints is it connecting to?
2. How many users are simultaneously going to connect to it? 
3. Are all the users present at the same location or scattered? 
4. How much bandwidth will be consumed daily and what would be the approx. peak load? 
5. What’s the average acceptable latency over the VPN? 

Each of these questions is very important in determining what kind of VPN you should choose. Each type of VPN is further divided by SKUs which determine different properties of the VPN, for example, the maximum number of concurrent users a VPN support or what’s the maximum bandwidth of the SKU, etc.

IP scheming and Public IP

IP scheming is a very important design aspect and should ideally be done pre-deployment. IP scheme can help in identifying a particular resource just by looking at its IP address. IP Scheme is also good for logical partition of certain resources for ease in management. 

Most importantly, IP scheming helps ensure that each device has the IP from the correct VNet and Subnet. Different VNet and Subnets might have different NCGs assigned to them which determine the inbound and outbound rules. This is especially important when dealing with a large number of devices where access security is paramount and the network is set up according to the POP. 

Public IP allows our machines and apps to be visible over the internet. It’s a unique IP address that distinguishes whatever resource it’s assigned to from everything else. In Azure, a Public IP address can be assigned to the same NIC you have running an IPv4 or IPv6 address. Following best practices should always be adhered to when setting up a Public IP

1. Always block port 3389 which is the remote desktop port. 
2. Use load balancers or DMZ for sensitive infrastructure instead of directly assigning a Public IP
3. Use NGS to control the ingress and egress traffic from the Public IP
4. Only ever open the required port on the public interface and select the origination IP, Location, or any other identifier in the port rules wherever possible. 

Conclusion

The essential security best practices for managing Azure services can be organized in five categories: Identity and access control, data, database, business continuity and disaster recovery, and networks. There are over a hundred Azure services with their own distinctive considerations for security management but the ones presented in this article provide a solid starting foundation for any computing environment hosted in Azure.