Last week on the Cloud Clinic we talked about what bad things can happen to your cloud when technical people have all the wrong access to your cloud assets. We’re talking costs running amok, instable work environment that are prone to environment drift and that cause your development to slow down to a crawl, and risk for mistakes that should not be possible to make. Those and more issues we list in that episode. Check it out: Establishing and monitoring access to different environments (part 1 of 2)
Now, let’s talk about the remedy! What do you do to avoid all the many problems that come from technical people having wrong access to the cloud?
Read on below and find out in this week’s episode!
The Cloud Clinic is a series on the #AzureEnablementShow where we focus on answering caller questions about using the cloud. It is difficult to start out right, and it is difficult to stay on an optimal path in the cloud journey. "I thought the cloud would be better than this, but I have some questions!" This is the show where you can have Your question answered! Please reach out to me on social channels, or comment here, or on YouTube, and we might be answering Your Cloud Clinic Question next!
Establishing and monitoring access to different environments (part 2)
Please enjoy this episode on YouTube:
[https://www.youtube.com/watch?v=8DckLrOulzA]
Here is the episode on Microsoft Learn:
[https://learn.microsoft.com/en-us/shows/azure-enablement/the-cloud-clinic-establishing-and-monitoring-access-to-different-environments-part-2]
There are two remedies to consider: Role Based Access Control and Privileged Identity Management. The former is what the Japanese call “kata”. It’s just good form. The latter is a bit tricker to manage, but when well rolled out, it empowers your organisation so very much!
Role Based Access Control (RBAC)
The way you grant someone, or something (a system) access to resources in Azure is by means of Role Based Access Control (RBAC). The thing about this is that RBAC data is stored in Azure, while identities of the people accessing the cloud are stored in Azure Active Directory (AAD). This leads to inconsistent access that is difficult to manage in Azure.
What I propose you do instead is take advantage of the AAD for what it is good at – users and group membership. The AD has “security groups” that are used to group users together to grant them access to something. You put users as members in the group, and then you grant the group, which is just another AD object just like a user identity, access to the intended system!
This means, in Azure, you will see only groups having access. You can create and maintain these as standard groups and standard access using automation, and you can easily automatically audit these groups. This makes your cloud access management cleaner!
Back in your AAD, to grant a person access to a system in Azure is as easy as making them a member of the right security group. AD is GREAT with auditing and managing who is a member of what group. This is what the AD is built for!
The outcome is that you now play the strength of each system, rather than ending up in this very uncomfortable split that gives you an inevitable pain in the groin! 
But wait, theres’s more!
Use the AAD security group owner to delegate membership
To let group leaders in your projects, self-manage who are members in their teams, and consequently who has access to the systems in Azure they oversee, you can delegate ownership of AAD security groups to them!
Regular users in the AAD do not necessarily have the right to add or remove members from security groups. This means they must ask someone else to set up access, say when a new team member joins the team, or revoke access when one leaves. The access administrator role in AAD has this privilege, but that creates an inconvenient bottleneck and leads to an access request granting system that is not very quick and agile.
Instead, what you should do is consider granting security group owner privileges to your team leads. They will then be able to manage membership of the security group themselves! This affords them a limited right to decide who is in the team and so have access to the Azure resources. This little trick is so very valuable it should come in gold!
Privileged Identity Management (PIM) is the next level of access control
Privileged Identity Management is a premium Active Directory feature that allows you to preconfigure access that can be activated only when needed. The tough bits here are two. One is that you need to pay for the AAD P2 license. But again, trust the doctor, it is well worth the money if used properly. Two is that you must invest some effort into fully adopting the feature into your organisation.
It is a bit tricky to configure PIM and that’s why I see organisations struggling to adopt it. You should start with a POC for PIM, if you will, and enable it for one team all the way. Then you take those experiences to learn how to roll out in your company all the way!
PIM means, as alluded above, that you configure access as the potential to have access, but the user does not really have access right now. It is just-in-time activated by the user. The main power here is that, if a user does not have access to a system, they cannot inadvertently make mistakes and modify that system by accident.
Use multi-factor authentication to further strengthen security
Another great combination here is MFA, or Multi-Factor Authentication. This is a standard feature that means you must use your phone or similar in conjunction with your password to authenticate. It is a great security addon that almost entirely removes the risk of credentials being stolen.
That plus other AAD features such as geofencing which blocks sign-ins from users that “all of a sudden” are attempting to gain access from Russia och China when they were in the office five minutes ago.
Manager approval is another method for controlling access to production
Activation of your access using PIM can be set up in such a way that you have to give written justification for the elevation of privileges. You can have the process that a work item must be related to why the user needs access, and this may be audited after the fact.
For additional security, again a risk of bottlenecks, you can also activate manager approval for users’ PIM activations. Just make sure you don’t have that activated for the support team that would need to phone a manager in the middle of the night on a weekend to grant access during maybe a critical security incident. That’s not going to sit well with upper management. Use this power only where it makes sense, and make sure more than one manager can be on call to grant access!
Don’t forget to audit access and review if a person still needs that extra access
Having limited access also provides useful audit logs so that you can determine who had access to certain environments at specific times. Any time a person accesses a system in Azure it is audited in the Activity Log. Same goes for any time a user elevates access using PIM, and the AAD also audits when users are added to or removed from security groups. Feed all this data into your SEIM system and have it analysed there, for example using Azure sentinel, which is purposefully built for exactly this type of auditing and security management.
Summary
There are so very many things you can do to have a proper access control, and which brings you so many benefits in terms of saving time and money, and in mitigating risk of data loss and thwarting attacks. Use proper RBAC with AAD security groups and consider PIM! You will not regret that investment, because you end up saving a ton!
References:
Comments are closed.