It’s not uncommon when supporting growing businesses, for roles and standards to be put in place. Standards make life easy for the business to interact with IT, as well as making IT services much easier to fulfill. I’m a meticulous person. I believe the world is plainly black-and-white. Regarding roles, each user of job title should have identical access. Lower levels of support (and sometimes end-users) should be empowered with permissions to resolve known issues once documented. Setting up good RBAC is vital to easily onboarding new users, identifying times to promote or expand the team, and eliminating security risks.
Gathering Data on Roles
First off, gather a report of all AD groups each person is a member of. Fortunately, Microsoft lets you download role assignments.
Afterward, compare this to a list of users and their job titles. To be safe, I’d generate a report from your HRIS system if you do not integrate it with Azure.
Here comes the fun part. You (or your designated spreadsheet monkey) get to tally up a count of which job titles have access to respective resources.
Implementing RBAC
If you don’t have one already, make a new group and custom role for each job title. When setting up the custom role, you can also use PIM, or privileged Identity Management. This means that to perform an administrative action, the user has to request (and audit) the access, making it easily monitored and preventing accidental changes.
Next, look at your non-production resources. Ideally, you’ll have a subscription for this. Consult your security team for the level of least privilege your organization desires. I would assign no higher than “Contributor” level on the subscription, since owners can delegate permissions, and that defeats the point of RBAC.
Unless your security team says otherwise or when using managed identities, you shouldn’t assign access to individual resources.
For your production subscriptions, do the same, but using the custom role. This will make any changes to production “privileged”, so they’ll have to be deliberately planned and audited.
Elevating Privileges
Elevating privileges is simple. You can type “PIM” in the Azure portal and be brought to Privileged Identity Management. Select the role, and press Activate. This will either give you the access requested, or reach out to the respective approver.
It’s a good idea to set up regular Access Reviews to see what roles are getting used the most. When your logs contain frequent requests to the same resource, maybe a process can be modified, or the role widened. If a process is known and repeatable, it should be handed off to an automation account or to lower levels of support. If someone is essentially breaking the glass because their user account is neutered, it’s a good opportunity to determine if access need to be more open.
One-off Roles
“But what if someone needs access to a confidential or short-term project?” This can be done in Entitlement Management using Access Packages. This is a great opportunity for evaluating whether you should promote someone, or for granting limited access upon request. If you end up giving an entire team an access package, the team should probably just have more access.
How do roles help?
Roles prevent the micromanagement of granular access, which snowballs when things shift from on-prem to the cloud. If you are assigning permissions outside of the role, this could be a great way to evaluate whether someone is ready for more responsibility. Alternatively, you may see someone who is wearing three or four hats and is getting paid to wear one. Having this access on a group level makes it much easier for security team to create policies and enforce least-privilege. If you aren’t using an HRIS integration, it will likely save you from copying user accounts to ensure no permissions are left behind.
RBAC is straightforward, but can make your onboarding feel smooth while removing potential blockers to operations.