Azure cloud security best practices for beginners
The security that protects a beginner's Azure account is boring and high-impact — and it is nothing like the tooling the ads sell you.
New to cloud? CAMPUX is a free, build-first course. Start here →
The five things that protect a beginner's Azure account are dull and free: turn on MFA for every account, give people the least access that works, stop putting secrets in code, keep storage and databases off the public internet, and switch on the free Secure Score in Defender for Cloud. That list stops almost every real attack a small account sees — no exotic tooling required.
I have watched more beginner Azure accounts get burned than I can count, and the cause is never something clever. Nobody gets hit by a nation-state zero-day on their first storage account. They get hit because MFA was off and a password leaked, or because a connection string sat in a public GitHub repo, or because a storage container was set to "anonymous read" for five minutes to make a demo work and then forgotten. The fixes are equally unglamorous. This is the whole list, grounded in the one idea that makes sense of all of it.
Start with who owns what
Before any checklist, one concept: the shared-responsibility model. Microsoft secures the things underneath you — the physical datacenter, the hypervisor, the network fabric, the host operating system of the managed services. You secure the things you put on top — your data, your identities, your access rules, your network exposure, your keys. Microsoft will never leak your storage account for you. You will, if you configure it wrong.
Everything below is in your half of that split. That is deliberate. There is no point worrying about the datacenter's locks when your own front door is propped open. So the whole list is the set of doors that are yours to close.
The cloud provider secures the cloud. You secure what you run in it. Every practice here is on your side of that line — which is exactly the side a certification tests you on and an interviewer expects you to have actually configured, not just recognized on a multiple-choice question.
The checklist, at a glance
Here is the whole thing in one place: the practice, the specific attack it kills, and where in Azure you set it. Read it, then take the paragraphs below for the why and the one-line how.
| Practice | Risk it kills | Where in Azure |
|---|---|---|
| MFA on every account | Stolen / reused passwords — the #1 cause of account takeover | Microsoft Entra ID → Security → per-user MFA or a Conditional Access policy |
| Conditional Access | Logins from impossible locations, unmanaged devices, legacy protocols | Entra ID → Protection → Conditional Access |
| Least-privilege RBAC | One compromised account able to delete or read everything | Subscription / resource group → Access control (IAM) → role assignments |
| Managed identities | Keys and connection strings living in code and config | Resource → Identity → System-assigned, then grant it an RBAC role |
| No public storage / DB by default | Anonymous internet reads of your data | Storage account → Networking + "allow blob anonymous access" = off |
| NSGs + private endpoints | Databases and VMs exposed to the whole internet | Virtual network → NSG rules; resource → Private endpoint |
| Key Vault for secrets | Leaked API keys in Git history | Azure Key Vault → Secrets, read at runtime via managed identity |
| Logging & monitoring on | A breach you never notice until it is far too late | Azure Monitor + diagnostic settings → Log Analytics workspace |
| Budget alert (as breach signal) | Crypto-mining on a hijacked account draining your card | Cost Management → Budgets → alert at a low threshold |
1. MFA on everything, starting with you
What: require a second factor — an authenticator app, ideally — on every sign-in, especially the admin account. Why: the overwhelming majority of account compromises are just stolen or reused passwords, and MFA stops nearly all of them cold. It is the highest return of anything on this list and it is free. How: in Microsoft Entra ID, enable a Conditional Access policy requiring MFA for all users, or turn on security defaults if you want the one-click version.
If you do exactly one thing after reading this, do this one. No other control matters if an attacker can simply log in as you.
2. Conditional Access — MFA with judgment
What: policies that decide when to demand MFA or block a login based on signals — location, device, risk. Why: it lets you block the obviously-bad (sign-ins from a country you have never been to, ancient protocols that skip MFA entirely) without punishing normal use. How: Entra ID → Protection → Conditional Access, start with a policy that blocks legacy authentication and requires MFA for admins. Identity is the real perimeter in cloud, which is why the tenant, subscription, and groups class comes so early — get the structure right and access rules become obvious.
The perimeter is not the network anymore. It is the identity. Guard the login and you have guarded most of the account.
3. Least-privilege RBAC — stop handing out Owner
What: give each person and app the smallest role that lets them do their job, scoped to the smallest slice of the account. Why: the beginner reflex is to assign Owner or Contributor at the subscription level to make the error go away. Then one phished account can delete or exfiltrate everything. Scoped roles turn a full breach into a contained one. How: on the resource group or resource, use Access control (IAM) to assign a specific built-in role — Reader, Storage Blob Data Reader, whatever fits — at the narrowest scope that works.
This is the practice most people nod at and never do, and it is the single biggest gap between "I passed AZ-104" and "I can be trusted with production." The RBAC and Azure Policy class walks the full model; the short version is that "read-only to one storage account" is a real answer and "Owner on the subscription" almost never is.
4. Managed identities instead of stored keys
What: give your app its own Azure identity so it authenticates to other Azure services with no key at all. Why: a key you never store is a key that can never leak. Managed identities remove the entire class of "connection string in code" mistakes. How: turn on a system-assigned identity on your App Service or VM, then grant that identity an RBAC role on the resource it needs. Azure rotates the credential for you.
This is worth understanding properly because it is genuinely a beginner superpower — the fix that deletes a whole category of risk rather than mitigating it. The service principals and managed identity class is the one to sit with.
5. Nothing public by default
What: storage accounts, databases, and admin ports closed to the open internet unless there is a deliberate reason. Why: automated scanners find a newly-public storage container or an open database port in minutes, not days. "Allow anonymous blob access" is off by default now for good reason — leave it off. How: on the storage account, keep public network access disabled or restricted to selected networks, and confirm anonymous access is off. On databases, never leave the "allow all Azure services" or 0.0.0.0 firewall rule in place.
6. Keep the network tight — NSGs and private endpoints
What: network security groups to filter traffic, and private endpoints so a service is reachable only from inside your virtual network. Why: defense in depth — even if a credential leaks, an attacker still has to be inside your network to reach the resource. How: attach NSG rules to your subnets that allow only the ports you need, and add a private endpoint to your storage or database so its public endpoint disappears entirely. The virtual networks and subnets class covers the layout; the rule of thumb is that a database should almost never have a public IP.
7. Secrets in Key Vault, not in Git
What: for the secrets you genuinely must hold — third-party API keys, tokens — store them in Azure Key Vault and read them at runtime. Why: a key committed to a repo lives in Git history forever, and bots scrape public repos for exactly this. It is one of the most common ways a beginner account gets drained. How: put the secret in Key Vault, give your app's managed identity the "Key Vault Secrets User" role, and fetch it at startup. Nothing sensitive touches the codebase.
MFA first, this afternoon. Then a budget alert (five minutes, catches disaster). Then walk your RBAC assignments and remove every Owner you do not need. Then turn on Defender for Cloud's free tier and let Secure Score hand you the rest of the list, ranked. You do not have to do all nine at once — you have to start at the top.
8. Turn on logging before you need it
What: diagnostic logs flowing to a Log Analytics workspace, and the free tier of Microsoft Defender for Cloud giving you a Secure Score. Why: you cannot investigate a breach you never recorded, and Secure Score turns "am I secure?" into a ranked to-do list with a number that goes up as you fix things. How: enable diagnostic settings on your key resources pointed at a Log Analytics workspace, and open Defender for Cloud — the foundational tier is on by default and free. Work the recommendations top-down.
9. A budget alert is a breach detector
What: a cost budget with an alert at a low threshold. Why: the first visible sign of a compromised small account is usually the bill, not a security alert. Attackers hijack accounts to spin up expensive GPU VMs and mine cryptocurrency, and a budget alert can catch that within hours instead of at month-end when the damage is done. How: Cost Management → Budgets → set one a little above your expected spend, alert at 50 and 90 percent. The cost management class treats this as the finance tool it is; treat it also as security telemetry.
Own the gap
Here is the uncomfortable part. Every item on this list appears on the AZ-500 and AZ-104 objectives. You can pass the exam by recognizing "use a managed identity" as the correct answer among four choices. The job is entirely different: it asks whether you have ever clicked into a resource, enabled the identity, granted it the scoped role, and watched the app authenticate with no key. Certified means you know the word. Hired means you have done the thing.
None of these are hard. They are a portal blade and a few minutes each. The reason accounts still get breached is not that the controls are difficult — it is that "I will secure it later" is the most expensive sentence in cloud. Do the boring list. It is the whole game at this level.
Common questions
What is the single most important Azure security setting for a beginner?
Multi-factor authentication on every account, starting with the admin. Most account compromises are stolen or reused passwords, and MFA stops nearly all of them. It is free, it takes minutes, and no other control matters if an attacker can just log in as you. Turn it on before you do anything else.
Is Microsoft Defender for Cloud free?
The foundational tier is free and on by default. It gives you Secure Score, security recommendations, and an inventory of misconfigurations across your subscription at no cost. The paid plans add threat detection per resource type and are billed per resource per hour. For a beginner, start with the free tier and work your Secure Score up before paying for anything.
How do I keep secrets out of my code in Azure?
Two moves. First, prefer managed identities so your app gets an Azure identity and never holds a key at all. Second, for the secrets you genuinely must store — third-party API keys, connection strings — put them in Azure Key Vault and read them at runtime, never in the repo. A leaked key in Git history is one of the most common ways beginner accounts get drained.
Why is a budget alert a security control?
Because the first visible sign of a compromised Azure account is usually a bill, not an alert. Attackers spin up expensive VMs to mine cryptocurrency, and a budget alert set at a low threshold can catch that within hours instead of at the end of the month. Cost anomaly detection is, in practice, breach detection for a small account.