Starting of a new series on Azure security concepts
/introduction
Security in the cloud is much different than what we know of the OnPrem world. Traditional network security was built on the idea of a perimeter. Simply said, if you are inside a network, you’re trusted. If you’re outside, you’re not.
That model made sense before when the enterprise data center and user sat in the same building behind a firewall and other security features.
The cloud breaks this concept entirely. Users work from anywhere, applications talk to other applications across the internet. As I have told my clients before, Identity is the new perimeter – not network locations. This is where Zero Trust comes in.
/what is zero trust?
Never trust, always verify.
Zero Trust is the new security strategy and goal, this is thrown around everywhere nowadays but what is that exactly? It is not a product or a service you can deploy in Azure per-se, it is an approach in designing and implementing its three security principles:
- Verify explicitly -> Always authenticate and authorize
- Least Privilege access -> Give the User the least permissions needed for the job task needed to be done, for only as long as it’s needed
- Assume Breach -> Verify end-to-end, create visibility, improve defense, minimize the blast radius
Instead of believing that everything is safe behind the corporate Firewall, this model assumes breach and verifies each request as thought it came from a compromised network. It does not matter from where these requests come from or what resources it wants to get access to, this model teach us to “never trust, always verify“.
/least privilege – the core of zero trust
If Zero Trust is the Goal, Least Privilege is on of the most important principles. It means, as shortly teased above, every Identity – whether human, service principal or a Microsoft managed identity – should have the minimum permissions assigned that is needed to do its job, and nothing more than that.
Why does this matter? Consider what could happen when such an identity is compromised. If that Identity had Contributor access assigned on a management level, an attacker could do almost anything under that management group: they could spin up resources to generate atrocious costs for your company, potentially steal all your data hosted under that management group/subscription or simply delete all and everything there.
Now if that identity only had “read only” access, the damage is still there – especially hurting the Confidentiality part of the CIA Triad (another security term) – but at least its contained.
We also, like assume Breach, limit the blast radius when something goes wrong, and unfortunately something always goes wrong – that’s Murphy’s law.
/implement zero trust & least privilege in Azure
Lets look at some Azure specifics, what kind of tools they have to put these principles into practice. Here I have compiled the important ones.
/azure RBAC – role based access control
RBAC is the core service used in Azure to enforce least privilege, it is the foundation of access control. Every action we do in Azure, from starting a VM or deleting resources, is controlled by the given role through RBAC.
How it works: A role assignment always has 3 needed points. A security principal (user, group, service principal etc.), a role definition (what its allowed to do) and a scope (on what level can the role do something).
Some built in roles to know which you will encounter mostly:
| Role | What it can do |
| Owner | – Grants full access to manage all resources – Assign roles in Azure RBAC |
| Contributor | – Grants full access to manage all resources – Can’t assign roles in Azure RBAC |
| Reader | – View all resources |
| Role Based Access Control Administrator | – Manage user access to resources – Assign roles in Azure RBAC – Can assign themselves Owner role (or others) – Can’t manage access using other ways like Azure Policy |
| User Access Administrator | – Manage user access to resources – Assign roles in Azure RBAC – Can assign themselves Owner role (or others) |
//best practices
The best practices for RBAC is usually;
1. assign on resource group scope and when possible no on a higher level like subscriptions or even management group.
2. Create your own custom roles, rather than relying on the built-in role like contributor which could have too much power.
3. Avoid assigning the roles to individual users – assign it to groups so access is managed centrally.
4. Regularly review the role assignments to ensure nothing is out the ordinary and to remove what is no longer needed. (access reviews in P2 or EntraID Governance license)
//example
Giving a developer read-only access to a specific resource group
Scope: /subscriptions/<sub-id>/resourceGroups/rg-dev-app
Principal: [email protected] (Entra group)
Role: ReaderThis means the team can see resources and configurations in that resource group, but cannot modify anything in it.
/privilege identity management (PIM)
RBAC from before handles standing access – meaning permissions are always active. For some sensitive roles like lets say Owner or Security Admin, those standing access are very risky, it would be wise to limit the time those roles were usable. This is where the resource PIM comes in.
PIM (Entra ID P2 or Entra ID Governance licenses needed) allows you to configure just-in-time (JIT) access to those risky permissions. It makes those roles eligible, rather than permanent. The user can request activation of those roles when they need it, for a limited time frame The acceptance of those requested roles is also behind the requirement of needing an approval (by a person) and possibly MFA.
Why does this matter in the context of Zero Trust? PIM is a practice that falls under the least privilege principle. Access is only granted when needed and most importantly automatically expires after the time you have set.
Even if an Identity is compromised, the attacker does not have a standing/persistent elevated access to exploit – nor is he able to get the elevated rights because the requirements of approval + MFA is configured.
//key PIM concepts
Eligible assignment -> The user can activate a “risky” / high elevated role on demand, but does not hold it permanently.
Active assignment -> The role is active, either assigned permanently or activated through PIM.
Activation settings -> You can require MFA, a justification, and/or approval from another entity before activation goes through.
Activation duration -> Access is limited to the set amount of time only, after that it has to be requested again.
//best practices
Best practices for PIM, for a role like Contributor on a production subscription would be;
1. make it an eligible assignment for certain administrators.
2. set MFA to be required for elevated permissions.
3. user requesting permissions must give a business justification reason.
4. 2 hour max duration set for eligible role.
5. approval required, usually by the owner of the resource.
/conditional access
Conditional access is the instance in Azure that sits in front of authorization and evaluates whether a sign-in should be allowed, or challenge the sign-in with additional verification. It is the service that enforces the principal of “verify explicitly“.
Instead of simply checking username and password, conditional access has the power to evaluate signals as:
– Who is signing in (user, role, group)
– What are they trying to get access to (application, resource)
– Where are they signing in from (location, IP range)
– What device they are using (compliant or managed devices?)
– What risk level EntraID has detected (sign-in risk, user risk -> evaluated by Azure themselves and practically not able to look up)
Based on the signals above, you define policies that block, grant or require additional controls like these:
///example
Users: All users
Cloud apps: Microsoft Azure Management
Conditions: Any location
Grant: Require multi-factor authenticationThe example above is used for anyone that is trying to access the Azure portal, cli or powershell must complete MFA – doesn’t matter from where the request comes from or on what network they’re on.
/managed identities
A common practice, which is a very bad one, is to store a service principals secret in an app’s configuration or environment variables. Secrets can be leaked, forgotten or often never rotated which makes them weaker by time -> creates overhead of rotation policies.
Managed identities solves this by giving an Azure resource like VM, App Service etc. an identity in EntraID that Azure manages entirely on their end. There are no credentials to store, rotate or accidentally committed into a Git repository.
There are two types of managed identities:
- System-assigned -> Created by the resource and therefore tied to the life cycle of the created resource (think like Virtual Machines).
- User-assigned -> Created by an administrator in EntraID, not tied to any resource which means that it can be assigned to one or many resources.
//example
An example use case from a real project of mine is; we used service principals for our Azure DevOps pipelines to deploy resources or read a statefile from a storage account. These service principals were created manually and we had to store the key in Azure Key Vault, it needed to check the credentials every time we wanted to push something into our infrastructure.
These secrets were managed by us, we initially set up these identities with passwords, so naturally we were responsible of rotating that password every time the policy of that specific company saw fit – lets say every 3 months. So every three months, someone had to manually rotate that secret or create a solution to make the rotation automatic.
After careful consideration, we created a managed identity (it was in public preview by that time), which has a “built-in” key rotation, the credentials and secrets were entirely managed by Microsoft. We essentially removed the manual work of rotating the secret, not only that but we didn’t have to think about it anymore from that day on. This removed the need for storing the secret inside our Azure Key Vault.
/putting it together
Zero Trust is not only just a checkbox – it is a mindset applied layer by layer (layered defense or defense in depth – possible future post). In Azure, the combination of these tools build a strong foundation.
To recap:
| Principles | Azure Tool |
| Verify Explicitly | Conditional Access |
| Least Privilege | Role Based Access Control Privileged Identity Management Managed Identities |
| Assume Breach | Audit logs, Defender for Cloud (coming in later parts) |
None of these work in isolation, the goal is to layer these controls so that a single failure like a compromised account, a misconfigured policy or an overlooked role assignment, does as little damage as possible -> reducing the blast radius.
/further Topics
These are just the tip of the iceberg when it comes to security measurements in the realm of Azure. Things like network level controls, threat detection, defender for cloud, audit logging, azure policies etc.
I will make sure to cover these in a future post.
Have a great day/week!