Azure Best Practices: Account and Identity Management
Identity and access management in the world of cloud computing is a critical challenge and needs to be handled diligently at both the management and the data levels. As a key player in public cloud computing, Microsoft Azure facilitates centralized identity management using Azure Active Directory (Azure AD). The process of securing an Azure deployment starts at the subscription level.
This can be expanded to the placement of resource groups, individual resources and their associated access permissions. Organizations that use Microsoft Active Directory Domain Services on-premises can integrate it easily with Azure AD to provide a seamless user access experience while implementing hybrid cloud architectures.
The benefit here is that users don't have to remember multiple credentials to access cloud native software as a service applications, or credentials hosted in on-premises data centers. Azure AD enables secure collaboration, single sign-on, and single-plane management capabilities that enhance your existing identity framework.
As with any other technology, Azure AD should also be configured for optimal use, especially for large-scale deployments. This blog will explore some of the most crucial best practices to ensure an effective Azure AD deployment.
What is Azure Active Directory (AD)?
Put simply, Azure AD is an enterprise class multi-tenant Identity-as-a-Service (IDaaS) offering which can be used for identity management of your applications, as well as your infrastructure. It is offered as a complete cloud-based SaaS solution, and all elements of security and high availability are integrated into the offering.
Azure platform-level access management can be performed only with accounts present in Azure AD. These accounts can be natively created in Azure AD, synchronized from an on-premises Windows Active Directory, or created as guest accounts for third-party collaborators using their public or corporate email IDs.
The first step in implementing an optimal security policy in Azure is the segregation of resources into logical containers like subscription and resource groups. The next step is a clearly defining who should be given access to what resources, and assigning levels of privileges or roles.
The most elementary best practice for Azure is providing the least required privileges to authorized users, thereby limiting them exclusively to the resources that they need to access or manage. For example, users in a development team may only require access to the Azure resources related to the project they are working on. The same access principle holds true for the subscription level, the resource-group level and the individual-resource level.
Azure AD Role-Based Access Control (RBAC)
Role-Based Access Control (RBAC) was one of the biggest changes in the Azure Resource Manager (ARM) architecture that replaced the classic Azure Service Management (ASM) model. The classic model offered a single co-administrator role – when assigned at subscription level, this co-admin role provided users full control for all resources in that subscription. There was no fine-grained access control at the resource level.
In contrast, RBAC comes with several predefined roles – both generic and resource-specific – which regulate the level of access for users assigned to that role. The following are the three basic built-in roles that can be used across all resource types:
- Owner: This role has full access at an assigned security-perimeter level, such as the subscription, resource-group or resource levels. Users assigned to the owner role can create, delete or modify resources. They can also delegate access to other users.
- Contributor: This role also has full access at the resource level. However, users assigned to this role cannot delegate access to other users.
- Reader: As the name indicates, users assigned to this role will only have read-only or view access to resources.
A fourth predefined role – dubbed the “User Access Administrator” – is important from an administrative perspective because it allows authorization management for Azure resources such as VMs, VNet, storage, Web apps, and Azure SQL DB.
There are additional built-in roles like virtual machine contributor, SQL server contributor, backup operator, etc. These roles target specific permissions for resources at any assigned scope. For example, if you want to assign backup administrator rights to manage Azure backup services, then a backup operator role can be assigned.
The administrator will be able to manage all day-to-day backup-related activities, but will not be able to delegate rights to other users, create new vaults, or remove existing backup data. It’s important to identify the level of access required for each user and assign the least permissive roles to perform their work. If none of the built-in roles meet your security requirements, you can also create custom RBAC roles with the necessary permission levels using Azure PowerShell, Azure CLI or Rest API.
Identity in the Azure Enterprise Scaffold
An Azure subscription is a basic vehicle to organize your resources within Azure. A subscription can also be used to organize billing – you receive individual bills for resource utilization associated with a subscription. Subscriptions are limited according to the number of resources. This is an important factor to keep in mind when designing Azure subscriptions for your enterprise.
The following are some additional factors that should considered when determining the scope of subscriptions:
- If there is a requirement to isolate line-of-business (LOB) applications for security or billing purposes, deployment in multiple subscriptions is recommended.
- When a business is spread across multiple geographies, it’s wise to isolate resources used for one region into separate subscriptions. Additionally, Azure policies can be implemented at the subscription level to restrict resource creation to specific geographies when compliance requirements like GDPR must be accommodated.
- When access restrictions are to be implemented at the environment level for applications –such as development, QA or production – these environments can be hosted in different subscriptions.
By default, access permissions assigned at the subscription level will be applied to all resources hosted in that subscription. Therefore, administrators should be cautious when assigning permissions at the subscription level.
It’s a good idea to deploy resources sharing the same lifecycle into the same resource group, because this acts as another security boundary within a subscription. For example, multiple applications associated within a business unit can be deployed in different resource groups within a subscription, and management-level access can be restricted to users working on specific applications.
If additional restrictions are required, access can also be assigned to individual resources within the resource group. This sort of access should be controlled using the relevant RBAC roles in Azure AD, as explained above. For example, a new member of a team need not have full access to all resources used by development team so access can be restricted to read-only within a resource group.
Hybrid Identity Management
Organizations adopting hybrid cloud architectures can integrate on-premises Active Directory with Azure AD. Authentication can be performed either by Azure AD or redirected to an active on-premises directory. Federation with an existing Azure Active Directory also enables a single sign-in (SSO) to your existing enterprise applications.
Workplace productivity applications included in the Office 365 bundle, as well as in Dynamics CRM, already use Azure AD for authentication. That way, users can have a seamless experience in which they use the same credentials to access cloud-based, as well as on-premises applications.
The Azure AD Connect tool is used to integrate an on-premises identity with Azure AD. The service consists of three main components: synchronization services, an optional Active Directory Federation Services (ADFS) component, and a monitoring component, called Azure AD Connect Health. Synchronization services ensures that on-premises identities are synchronized with those of Azure AD. By default the entire source domain is synchronized, but it can also be customized to synchronize specific organizational units (OU) according to an organization’s needs.
The ADFS component should be used in hybrid-cloud deployments that need features like single sign-on (SSO), AD sign-in policy enforcement or multi-factor authentication (MFA). The AD Connect Health component monitors the overall health of integrated identity infrastructure components (Active Directory servers, ADFS, AD Connect servers, etc.) so administrators can see the status directly from Azure Portal.
Identity Protection and Monitoring
Organizations with strict identity protection requirements can tap into additional Azure AD features, such as multi-factor authentication (MFA), Azure AD Identity Protection and Azure AD Privileged Identity Management.
Azure AD MFA helps to protect against identity theft by adding an additional layer of authentication compared to the typical password-based authentication approach. This additional authentication can be performed through several methods like SMS, voice call, the Microsoft Authenticator app, etc. One best practice widely followed by organizations involves enabling MFA for Azure administrators, so that only authorized personnel can manage resources hosted in Azure.
Azure AD Privileged Identity Management enables Just-in-Time administrative access to resources, so that the required access levels are assigned to users only for a predetermined amount of time. This feature is currently in preview phase and will be a great asset for the Azure identity and access management process, once it becomes available for general users.
Azure AD has advanced logging and reporting capabilities to monitor user sign-in activities and administrative activities like policy changes, user/app property updates, etc. Security logs in Azure AD flag potential identity theft by detecting risky sign-ins. It also has built-in intelligence to first detect if any user accounts are compromised, and then flag those accounts as risky users, for further investigation.
Finally, the biggest advantage for monitoring and management of identities in Azure AD is that it can be done directly from the Azure portal using native features without depending on any third-party tools.
The Whole Picture
Secure identity management using Azure AD is the cornerstone of any large-scale Azure deployment. Before the first resource is deployed, it’s important to have the identity management policies defined and implemented, to ensure a secure infrastructure from day one. The guidelines discussed in this blog will help you get started with an optimal implementation of an identity framework in Azure.
There’s a lot to learn about Azure, and many organizations lack the expertise or the bandwidth for their IT teams to learn and fully manage the entirety of their Azure cloud environments. That’s where a managed cloud service provider like Navisite can help offload such responsibilities, allowing your IT team to focus on the most critical elements that drive business success.
With more than 117+ Azure-certified experts, and as a Microsoft Gold Azure Expert MSP and Cloud Security Alliance member, along with a wealth of security and compliance expertise, Navisite can help fully assess your needs on Azure. We’ll help you understand what makes sense to deploy to Azure, then help you build and deploy Azure cloud solutions in keeping with prevailing best practices. We can also assess if the account and identity management services in Azure are sufficient to meet your needs, or if your organization can benefit from the additional layered services our Managed Security and Compliance portfolio.