The question this week in the Cloud Clinic is a very interesting one and one that I see a lot of companies are struggling with and suffering the consequences of not managing optimally!

Too many people have too much access to production, and now our security team is saying this is not compliant and it has to change! In fact, this question is such a doozie that first we will answer – “why is it such a problem if too many people have too much access”. I mean of course other than it not being considered compliant. What problems emanate from incorrect access?

Next week we will delve into how to approach a sounder access control – so don’t for get to join us for that!

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 1)

Please enjoy this episode on YouTube:

[https://www.youtube.com/watch?v=KmmHrNNZdEw]

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-1]

It is unfortunately almost always the case that security is fixed when there is a security problem, rather than planned as a first-class concern to avoid a problem happening in the first place. Don’t wait until something bad happens before thinking about security! Make sure you plan for the right access control from the beginning to avoid a slew of negative consequences if you don’t!

What happens when you grant too much access?

You might need to live up to a certain security and compliance standard, because your customers require it. This means you can lose customers or fail to gain new ones if your business is not living up to your customers’ requirements. Sort if a consequence by proxy. This can really hurt in the wallet area.
If a person has the wrong access, mistakes can occur. It is like inviting the inevitable opportunity for human error. It is also very disrespectful to your employees to put them in the position where they can make bad mistakes, if that situation can be technically avoided, or at least very much mitigated!
When you have too much access, you also tend to become careless with such things as leaving test resources around. Because it seems to you that does not really matter, right? You can create those resources, so why not just leave them lying around. Again, this is a slippery and costly slope. There is power in the psychology of “running a tight ship”. When employees feel empowered and like things they do matter and are important, they will behave more responsibly too!

How do companies get into this position?

A big problem is that the person who owns the application security responsibility can often be an administrator with a very busy schedule. They do not want to be bothered by the technical people time and again for them to do repetitive technical administration. Instead, they will grant the technical people “all the access” so that they go away and do technical things. Problem is. Now they have too much access!

Use automation to change testing and production environments-never grant individual access

Technically humans “never” have access to production! Only automation may touch production! When that does not fully fill the need, and a human does need to “enter production”, they should be granted minimal access, just-in-time to do the task, and that access should be automatically revoked again.

For development and sometimes test environments, it is more okay to grant more access to “people”. DO still consider granting appropriate access levels. For example – everyone can have Read access. The web developers are “Contributors” on the web resources, but not the databases. The database maintainers have Contributor access to the databases, but not the web apps. I realize I am oversimplifying here, but you get the drift. Consider gravitating to security groups with appropriate access control, rather than lazily granting everyone on the team “all the access”. You’ll thank me later. Winking smile

Privileged Identity Management (PIM) is a huge area of focus which is wonderful to work with once you have set it up. Reality is that it can be tricky to set it up. The rewards are worth it though. What you get is the situation where your team members are eligible for access, but they don’t have access all the time. When they need access, they can activate their access and make the changes they need to make. Apart from this being very secure and compliant – which is an awesome bonus, the main benefit here is that people who need to activate access to environments to make changes, tend to think more about why they are doing what they are doing, rather than “just doing it”. Word of caution though – the proverbial thumb screws of being required to activate access every time you make a change can become quite annoying. You should use PIM only where you need it the most. For example, in production and test environments that you want to limit “fiddling” in.

Also have a watch at the next episode that talks about what to do to avoid the problems described in this episode: Establishing and monitoring access to different environments (part 2 of 2).

References: