Now that your Azure Environment is effectively and properly structured, as noted in our previous post, we come across a slippery slope that must be avoided. Now that it has been created, it needs to be secured. It has become second nature to use a seatbelt, lock doors and assure the area is clear when entering or exiting a vehicle, and we must direct that line of thinking when it comes to employing technology.
With each wave of technological upgrades and updates, gone are the days where you had to physically be in a specific location at a certain time with a unique key or key code. Now, identity and conditional access are your firewall. This new learned route consists of steps you can take to secure your Azure environment.
Step 1: Enable multifactor authentication (MFA) in Azure AD for your administrators as soon as they step foot in your Azure subscription. If you have not done that, this single, important step that does not require much time to implement, can save for mounds of trouble in the future. This prevents your password from being the only thing that prevents another person from taking advantage of your Azure environment.
It seems pretty simple when you say it like that – just because burglars can bust through a window doesn’t mean you’ll stop locking your doors, correct? Lock away your Azure environment before leaving it vulnerable to hackers, phishers and other bad actors.
Step 2: Use Azure Privileged Access Management as an additional measure. The best practice for accounts looks like this: you have your lower-level email account – that is how you log in, use email and experience normal life. Second, you have your administrator account. Once you log in with your email account and you’re seeking to do an action that is administrator-related, you then request access with Azure Privileged Access Management.
It is very easy to configure conditional access for an owner or administrator. This ensures that, even though I am logged in as myself, an administrator, I have to do something to use those elevated rights, and at that, specific admin rights – not just all of them at once. This straightforward process ensures a more secure approach in your Azure environment.
Step 3: Enable conditional access and secure the environment by confirming that not only are you the correct person with rights having the correct MFAs, but that you also are on a healthy device. There are two ways to accomplish this and here is the break-down: if you are using SCCM, enable conditional access with co-management using Intune. Or, go to Modern Device Management with Intune – they will do the same thing. Using either of those steps, you can tie right into conditional access and ask: “Am I on a healthy device that I own?”
Here’s a scenario: someone obtains your administrator credentials halfway across the world. What stops that person from getting into your Azure subscription? Nothing – unless you have MFA or conditional access enabled for device compliance and that you’re on a corporate device.
Let’s think about those two things: that is going to be a much more secure environment because there are many more steps that a person has to go through to be able to access your environment if you do indeed have those enabled.
Step 4: Make sure your applications have consistent RBAC applied. You can force that with blueprints and policies. The blueprints feature can force policy to ensure that you have RBAC applied on the application groups so that the right people talk to the right people; so that the right application owners get into those resource groups and can use them, but that they can’t just go to someone else’s to start using theirs.
The main goal there is you should almost never need to be an owner of the subscription – almost never. Subscription owners only need to exist to do really high-level things, and although too often I see it deployed that way, that is not something we need.