- Azure AD without on-prem Windows Active Directory? - Mon, Oct 25 2021
- An overview of Azure security - Mon, Mar 29 2021
- An introduction to Azure AD administrative units - Wed, Jan 6 2021
Azure has a large number of security services, and for good reason. Everything in Azure has security built in; it makes the product more robust against threats and bad actors. It also makes it challenging to identify the best way to secure resources in your environment.
Before we get to specific security options in Azure, it will help to understand the delineation of responsibilities when you move to Azure. Microsoft publishes the shared responsibility model to outline the responsibilities of Microsoft and the customer based on service type.
The shared responsibility model
One benefit of moving to a cloud service is that much of the management overhead is the cloud provider's responsibility, allowing the IT team to focus on tasks that add value to your business or organization. Not all cloud services are created equally, and the management responsibility can vary depending on the service. Microsoft uses the shared responsibility model to illustrate where security responsibilities fall with different service types, hosted on-premises or in Azure. The illustration below outlines the services and the responsibilities for different service types.
Shared responsibility model
Customers are responsible for information and data, devices such as mobile and PCs, and account information. This does not change if the data is in a Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), or on-premises.
The responsibility changes based on the service type. Identities and directory infrastructure, applications, network controls, and operating systems all have a different mix of responsibilities between the customer and Microsoft. Microsoft takes responsibility for maintaining networking, applications, and operating systems for SaaS services such as the Office 365 products. However, the responsibility falls to the customer with IaaS services, such as virtual networking and Azure Virtual Machines. Network security, patching, and application updates are the customer's responsibility with IaaS services.
The physical infrastructure, such as data centers, physical networking, and hosts, is the cloud provider's responsibility for all hosted services. No matter what type of service is moved to Azure, they all have the advantage of abstracting the physical infrastructure away from the service.
The delineation between Microsoft's responsibility and the customer's is important to understand, especially when securing the environment. An assumption that Microsoft keeps OSs up to date with patching or safeguards the virtual network in an IaaS model is false and could expose an organization to security vulnerabilities. Likewise, identifying the customer's part in securing PaaS services should be a step taken early in implementation.
Azure Security Center
Microsoft has many tools and services available to secure Azure; it has so many, in fact, that it can be difficult to get started. An excellent first step is with the Azure Security Center (ASC). The ASC is a security management system designed to enhance the security posture of your cloud deployments. ASC can also extend to your on-premises environment.
The Security Center Overview page provides highlights of the status of the Azure resources in the environment. At the top of the page is a list of the subscriptions, resources, and recommendations for those resources. It also lists a security score, insights, and recommended controls for the environment.
Azure Security Center overview
The security score provides a numerical score for the tenant and a breakdown score for each subscription. Navigating to each subscription shows a list of recommendations in order of strength of impact on the environment. The recommendations are an easy way to start improving security posture. Microsoft lists the control, point value, and steps to implement the control. In some cases, there is even a "Quick Fix" option to implement the remedy from the Security Center.
Azure Security Center controls
If you are starting with Azure security or looking for ways to reduce vulnerabilities, ASC is a good place to start. The score-based recommendations provide an easy way to quickly identify and reduce vulnerabilities based on Microsoft's best practices for cloud environments. ASC is not limited to Azure; on-premises servers or servers hosted in non-Azure clouds can be included as well.
Multi-factor authentication
One of the most recommended security configurations is multi-factor authentication (MFA). Traditional authentication uses a single factor, such as a known secret or password. MFA adds additional authentication requirements, including something we have, such as a token or an authentication application, or something we are, such as a fingerprint reader.
Enabling MFA is one step that will significantly improve an organization's security posture by protecting against weak or stolen passwords. It's so important that Microsoft now enables a set of security defaults, including MFA for all users, on new tenants.
Security defaults
Azure security defaults are a set of security best practices enabled on new Azure tenants and easily enabled on existing tenants. Enabling security defaults will require all users to register for Azure AD MFA. It requires MFA for admin tasks and requires users to pass an MFA challenge when necessary, such as accessing Office 365 services from a new device or application.
Enable security defaults
Enable security defaults
The Security defaults setting is available to all tiers of Azure AD, including the free tier. The drawback is the lack of granular control with the service. It can be enabled or disabled across the tenant with no option to adjust settings. For advanced MFA configuration, an organization should use Conditional Access policies.
Conditional Access policies
A Conditional Access policy is a set of "if this, then that"-style rules to apply conditions when users log into an Azure tenant. For example, a policy can be set to enforce MFA for all users except when they log in from a known location, such as the corporate office, or from a trusted device, such as a domain-joined computer.
New Conditional Access policy
Conditional Access policies provide granularity beyond the Security Defaults option, providing greater flexibility in how they're applied. Conditional Access policies require an Azure AD Premium P1 or P2 license.
Principle of least privilege
The principle of least privilege states that the assignment of permissions and access to systems is limited to only what is needed to perform routine, authorized activity. Azure has several options to support this principle by restricting elevated access to the scope and rights required for a given task. The following is a list of the Azure services that support the principle of least privilege.
Role-based access control
In Azure, a role defines actions that can be performed on Azure objects. Activities, such as read, write, and delete, are included in a role definition. The actions available for a role definition depend on the type of resource it's applied to. For example, the Network Contributor role only applies to network-based resources, and a Storage Account Contributor defines actions available on storage accounts.
Azure uses the concepts of security principals to define objects that access Azure resources. A security principal can be a user, a group, a service principal, or a managed identity. Users are granted roles in Azure through scopes. A scope defines the realm of management. The four scopes available in Azure include Management Groups, Subscriptions, Resource Groups, and Resources.
Azure RBAC scope
The combination of security principal, role, and scope create the foundation for role-based access control, or RBAC. With RBAC, permissions can be set to the minimum required to manage objects in a specific Azure scope.
Administrative units
In Azure AD, roles allow administrators to manage users, groups, service principals, and managed identities. For some organizations, there may be a need to restrict the scope of users and groups to which an administrator has rights. For example, if the help desk gets the rights to manage users' passwords in Azure AD, they can manage all users' passwords by default.
Some organizations run autonomous business units and require separations for management roles. In this type of environment, the ability to administer users and groups should be limited to the given region. Administrative units facilitate this by providing a container for users and groups that set an administrative boundary for management tasks. In the previous example, all regional users are added to an administrative unit, and the help desk is given password management rights to it. An administrative unit sets an administrative boundary for users and groups in Azure AD.
Privileged identity management
While RBAC roles and administrative units work together to limit the scope and level of access, privileged identify management (PIM) takes elevated access further by limiting how elevated privileges are applied to the duration of those privileges. Without PIM, user administrators or subscription contributors are granted those rights until the role is removed.
With PIM, users are set as eligible for a role assignment. Before they can leverage the management permissions, they need to activate the role. The activation process can be as simple as a time-bound granting of elevated rights or a more complex workflow that requires MFA, an approval process, and documented justification.
With PIM, an audit history tracks privilege elevation and an access review process to ensure that users eligible for elevated permissions still need the administrative roles. Users set as eligible for PIM, PIM approvers, or access reviewers require an Azure AD Premium P2 license.
Just-in-time virtual machine access
As specified by the shared responsibility model, virtual machines running in Azure are the customer's responsibility to secure. It is necessary to provide remote access to these virtual machines over RDP or SSH ports, depending on the OS. Opening these management ports can present a security risk. Just-in-time (JIT) virtual machine access limits the risk exposure with a policy-driven workflow that dynamically opens ports for a specified duration.
Virtual machines can be enabled for JIT access in ASC on the Azure Defender dashboard.
Just in time VM access
Users request access to the virtual machine, and the ports are dynamically opened to the users based on approved source IP addresses. The user's access to virtual machines with JIT VM is logged, providing auditing and reporting on virtual machine access.
Azure AD Identity Protection
Protecting a user's Azure AD identity is essential to the security of any organization. Azure AD Identity Protection automates the detection and response to identity-based risks. It provides an exportable history of risks that can be used for further analysis should an identity-based risk occur.
One common scenario is tracking the user's login location. It is not unusual for a user to log in from two different IP addresses in the same city. However, if the user logs in from a city thousands of miles away over a short time, that would be unusual and trigger a risk event. This is the type of event that Identity Protection can alert on and build automation to mitigate the risk.
The risk detection types included with Identity Protection are:
- Anonymous IP address
- Atypical travel
- Malware-linked IP address
- Unfamiliar sign-in properties
- Leaked credentials
- Azure AD threat intelligence
The Identify Protection portal includes three main sections: Protect, Report, and Notify.
Identity Protection sections
The policy options under the Protect section provide a way to automate a response to risk events. For example, a policy can be set to block access or enforce an MFA prompt if a risky sign-in is detected for a user. The policy streamlines the process by automating the requirement for an MFA prompt or an account block.
Sign in risk remediation policy
The features available in Identity Protection depend on the Azure AD license.
Azure Sentinel
Azure Sentinel is a security information event management (SIEM) and security orchestration automation response (SOAR) solution hosted in Azure. Azure Sentinel leverages Microsoft's analytics and AI technology to investigate and detect threats. It uses built-in orchestration and automation tasks to respond to the incident if a threat is detected.
Sentinel process overview
Azure Sentinel has built-in connectors to Azure and Microsoft 365 data sources, including Office 365, Azure AD, Microsoft Defender, and others. There are also connectors for non-Microsoft solutions and the ability to leverage syslog or REST API to connect a data source to Azure Sentinel.
Once the data is collected, it is processed to detect threats and correlate alerts into incidents. Incidents are further investigated with machine learning and advanced analytics to minimize false positives. Responses to threats are automated with security orchestrations. These are built-in or custom playbooks that leverage Azure Logic Apps to automate the response to common threats.
Azure Sentinel is priced at the Log Analytics data ingestion rate. The amount of data ingested and the retention time factor into the price of the solution.
Subscribe to 4sysops newsletter!
Conclusion
Security is critically important with IT infrastructure. The tools and security principles listed above encompass multiple Azure and Azure AD services. They provide a methodology with the shared security model and principle of least privileges and tools that support that methodology, such as RBAC, administrative units, and PIM. Tools such as Azure AD Identity Protection and Azure Sentinel take this protection further by automating the detection and response to common threats. All steps are critical to securing your Azure environment.
