Least privilege is a critical security principle that restricts what users (and hackers who may steal their credentials) can do. Under least privilege, IT restricts the access rights of end users and IT itself to only what is absolutely necessary to do their jobs. This minimizes the risks of user error or malfeasance threatening your security.
More and more Microsoft 365 is the platform that defines the rights of end users and admins, so a disciplined approach to least privilege for M365 rights is essential. Unfortunately, such an approach is too rarely followed, Microsoft argues. “Most security-related training courses and documentation discuss the implementation of a principle of least privilege, yet organizations rarely follow it. The principle is simple, and the impact of applying it correctly greatly increases your security and reduces your risk. The principle states that all users should log on with a user account that has the absolute minimum permissions necessary to complete the current task and nothing more. Doing so provides protection against malicious code, among other attacks. This principle applies to computers and the users of those computers,” Microsoft said.
But the benefits of least privilege are profound, the Microsoft 365 creator believes. “One reason this principle works so well is that it forces you to do some internal research. For example, you must determine the access privileges that a computer or user really needs, and then implement them. For many organizations, this task might initially seem like a great deal of work; however, it is an essential step to successfully secure your network environment.”
Least privilege is arguably more important for IT, which wields tremendous power and has deep access, than for ordinary end users. “You should grant all domain administrator users their domain privileges under the concept of least privilege. For example, if an administrator logs on with a privileged account and inadvertently runs a virus program, the virus has administrative access to the local computer and to the entire domain. If the administrator had instead logged on with a non-privileged (non-administrative) account, the virus’s scope of damage would only be the local computer because it runs as a local computer user,” Microsoft said.
Microsoft 365 privilege management makes the difference between a safe environment, and one riddled with holes. Here are three M365 least privilege best practices:
The best way to do all this is to partition the M365 tenant into Virtual Tenants containing limited data pools. Then you can delegate fine-grained admin privileges to selected users who can only act in limited ways on limited objects within limited data pools. Unfortunately, this isn’t possible in the native Microsoft M365 Admin Center console.
Microsoft 365 veterans think their admin identities are secure if they have Role-Based Access Control (RBAC) – their killer security feature. But not all RBAC is created equal, and even the best RBAC is no match for Functional Access Control (FAC) – the true security killer feature.
Today’s smart M365 IT pros no longer focus on ‘roles’ in administration anymore – such as being the Exchange person who spends the day creating mailboxes and adding people to distribution lists. M365 admins instead perform FUNCTIONS across the entire cloud stack, which is quite complex. This can include adding a user, setting the password, and granting them a license. Then an admin may add them to a mailbox, to distribution lists, or Microsoft Teams channels, pre-initialize their OneDrive, set policies for devices, and so on. These are not ROLES – these are FUNCTIONS.
These various functions are not easily defined into a particular role. Instead, CoreView can break what IT or even non-IT professionals need to do into functions that then can be combined into what a user’s job actually entails.
RBAC is a way to APPROACH Least Privilege Access, while FAC is a way to ACHIEVE it. Unfortunately, Least Privilege is not well implemented in the Microsoft world because the roles are too broad and there is no concept of FAC. Again, not to toot our horn too much, but CoreView does a much better job at this because our Role-Based Access Model is actually functionally based. It is based on check marks where you check off the functions you want to grant rather than broad roles.
Functional Access Control is simply more granular and fits today’s IT workstyle better.
“CoreView’s FAC is check box-based. IT can give someone the ability to forward email addresses by clicking two boxes. It is automatically scoped, which is hard to do in the Microsoft world without creating a custom role and creating a custom scope – and frankly, nobody does that,” Matt Smith, CoreView solution architect pointed out. “I can also give somebody at the help desk the ability to forward email for people who are on long-term leave in the accounting department. Boom. We are done.”
One use case is for a desktop deployment person putting software on PCs that may have been locked on Friday at 5:00 PM. They need the ability to unlock the PC to reset the password, install the OneDrive agent and make sure that it is working. In that case, that person could request that ability to change the password and set the OneDrive settings.
CoreView offers deep Microsoft 365-specific security protection, governance, and compliance. Learn how we help with a personalized CoreView demo.
