Senior Solution Advisor – Cloud Secure Infrastructure, ACTS
Most people don’t think of IT as a threat, especially IT pros themselves. But they can be, since IT folks are simply people – good, bad, and in between. At the same time IT can make mistakes, and these can be another source of security woes.
Knowing this, smart enterprises take steps to secure their Microsoft 365 environment against the IT threat – whether through malfeasance, mistakes or neglect. And in fact these defenses are implemented by IT itself.
There’s another issue at hand. IT professionals with high level privileges are a hacker’s delight. If these accounts are cracked, cybercriminals can run rampant.
It All Starts With Least Privilege Access
For all these reasons, IT privileges should be defined, controlled, and restricted. This is the concept of Least Privilege Access, where IT only has the right to do what is absolutely necessary. In the case of Microsoft 365, global admins are at the top of the heap and without restrictions they can do anything anywhere across the tenant. There’s certainly a need for some global admins who can oversee and control the entire tenant. These are valued and trusted IT professionals. But not everyone needs or should have this generous level of privilege.
Least privilege is a broad term relating to how privileges are limited for the sake of security and IT efficiency. In Microsoft 365 there are two key approaches that help implement Least Privilege. These are Role-Based Access Control (RBAC) and Just-in-Time privileges.
If You Have More Than 2-4 Global Admins, You’re Doing it Wrong, Microsoft Says
The Center for Information Security (CIS) and Microsoft both believe that for the sake of security, you should have only 2-4 global administrators for each M365 tenant. Unfortunately, that is rarely the case – except in the smallest of shops.
ACTS sees this first hand. A recent ACTS M365 tenant assessment discovered 47 people with global administrator rights. Out of these, more than 10 were for employees that had left, or were accounts otherwise not actively used – but not deactivated.
These are exactly the types of accounts that need to be spotted and quickly deprovisioned. They represent a lingering attack point – ex-employee accounts still active – and with passwords still attached.
There’s one other troubling issue. Let’s assume all those 47 admin accounts were attached to people still working for the company. Does that mean you have 47 people with high-level accounts you actually trust? This speaks to the insider threat, which is why Least Privilege Access and limiting the number of Global Admins to 2-4 is so critical.
Doing Least-Privilege Access Right
Least Privilege Access is something best implemented with a methodology, rather than a scattered, ad hoc approach. So what does Microsoft suggest? “We identified those roles that absolutely required elevated access, but not all elevated-privilege accounts are created equal. Limiting the attack surface visible to potential aggressors depends not only on reducing the number of elevated-privilege accounts. It also relies on only providing elevated-privilege accounts with the least-privileged access needed to get their respective jobs done,” the company said. “This is the concept of least-privileged access: We only allow you access to a specific role to perform a specific activity within a specific amount of time from a secure device while logged in from a secure identity. Add the necessary access controls to remove the need for Global Administrator or Domain Administrator access. Just provide everyone with the access that they truly need. Build your applications, environments, and tools to use RBAC roles, and clearly define what each role can and can’t do.”
Get to Know RBAC
As you can see, RBAC is step one – arguably the most important step, in implementing Least Privilege. Luckily, there is a Microsoft-proven method to setting RBAC privileges. “We used a role-based access control (RBAC) model to establish which specific elevated-privilege roles were needed to perform the duties required within each line-of-business application in support of Microsoft operations. From there, we deduced a minimum number of accounts needed for each RBAC role and started the process of eliminating the excess accounts. Using the RBAC model, we went back and identified a variety of roles requiring elevated privileges in each environment,” Microsoft argued in its Improving Security by Protecting Elevated Privilege Accounts document.
Azure RBAC can also be used to secure service providers needing access to a client’s Azure environment, an approach supported by Microsoft’s Lighthouse security solution. “Limit access to your resources with role-based access control (RBAC), a granular access management system. Control permissions, including who has access, what actions they can take, and what areas they have access to. RBAC in Azure allows service providers to work autonomously while keeping your systems secure,” Microsoft argued in its Azure Role-Based Access Control overview.
Here are a few examples of Azure RBAC, according to Microsoft:
- “Allow one user to manage virtual machines in a subscription and another user to manage virtual networks
- Allow a DBA group to manage SQL databases in a subscription
- Allow a user to manage all resources in a resource group, such as virtual machines, websites, and subnets
- Allow an application to access all resources in a resource group”
RBAC creates roles for Azure and M365 rights, but Scope defines the range of the control. “Scope is the set of resources that the access applies to. When you assign a role, you can further limit the actions allowed by defining a scope. This is helpful if you want to make someone a Website Contributor, but only for one resource group,” Microsoft argued. “In Azure, you can specify a scope at four levels: management group, subscription, resource group, or resource,” Microsoft advised.
RBAC Rights Further Secured with Just-in-Time Access
Microsoft believes that every instance of elevated rights should be combined with JIT elevation – ending the old rule of persistent access. “It requires an extra step to get temporary secure access before performing elevated-privilege work. Setting persistent access to expire when it’s no longer necessary narrows your exposed attack surface,” Microsoft concluded.
Deeply Control Rights with Privileged Identity Management (PIM)
With Azure PIM, IT can tightly control how rights are released when working with external entities and partners, as Microsoft explained in its Azure Active Directory/Privileged Identity Management article. “That is why Azure has Privileged Identity Management (PIM) where you can put someone in a role that has these extremely elevated rights. But those rights are not turned on that account,” Microsoft explained. “Instead, the person has to ask the PIM, go into the portal and a request these rights. Then then their manager has to approve that request. When that request is approved, that account that account’s rights are escalated to those higher levels, but they’re also timeboxed. They only last at last for an hour, four hours, or one day — whatever the organization decides, and then that elevated access expires until they need it again.”
The same concept applies to Microsoft 365, and in this case uses a similar solution: Privileged Access Management (PAM). Here, IT or a person designated by IT is given just-in-time rights to perform a specific task on Microsoft 365. Again, this is all managed by Azure Active Directory, so Azure Active Directory is a massive control point and a massive vulnerability point, which is a great concern for Azure security.
Here are examples of time and approval roles that can be activated by PIM, Microsoft says.
- “Provide just-in-time privileged access to Azure AD and Azure resources
- Assign time-bound access to resources using start and end dates
- Require approval to activate privileged roles
- Enforce multi-factor authentication to activate any role
- Use justification to understand why users activate
- Get notifications when privileged roles are activated
- Conduct access reviews to ensure users still need roles
- Download audit history for internal or external audit”
(Shawn Pickett is Senior Cloud Solution Advisor with a focus on Cloud Secure Infrastructure hosted in Azure, AWS, and Google Cloud Platform. He is a Trusted IT Executive Advisor for ACTS Consulting clients across multiple verticals advising on Cloud Architecture/Deployment/Security, Disaster Recovery and Business Continuity, Application Hosting, Database Hosting, Cloud Operating Models and Cloud Economics.)