Securing Your Cloud, Part 2: Locking Down Azure and Entra ID

This is part 2 of GRAYTECH.ONE's "Securing Your Cloud" series — practical hardening for the three big clouds. Part 1 covered GCP; part 3 covers AWS.

Azure's security story has a twist the other clouds don't: the tenant and the subscriptions are different kingdoms. Your identity layer (Entra ID — formerly Azure AD) controls who gets in everywhere, while each subscription holds the resources. Most small-team breaches in Azure land through the identity plane — a phishing'd global admin, a consented OAuth app, a guest account that never left — not through the resources themselves. So that's where the baseline starts.

1. Break glass, then shrink the crown

• Create two break-glass accounts — cloud-only (no federation), long unique passwords in a safe, excluded from conditional access. Test them quarterly. When your identity provider is the thing that's broken, these are the only keys that still work.
• Count your Global Admins. The healthy number for a small business is 2–3, all with phishing-resistant MFA (FIDO2 keys or platform authenticators — not SMS). Every extra global admin is a kingdom key.
• Use PIM (Privileged Identity Management) if you're on P2 licensing: admin roles become time-boxed activations with justification, instead of permanent standing access. This one change kills most privilege-abuse paths outright.

2. Conditional access is the real firewall

In Azure, network security groups matter less than the identity firewall. Baseline conditional access policies worth having on day one:

• Require MFA for all users — no exceptions for "service accounts" (they get managed identities instead)
• Block legacy authentication protocols — that's where password spray lives
• Block or heavily restrict sign-ins from anonymous proxy IPs and countries you don't operate in
• Require approved devices for administrative portals

3. OAuth consent — the quiet landmine

Azure's biggest under-appreciated risk: users can consent third-party apps to read mail, files, and calendars. One convincing phishing page ("Review permissions to continue") and an attacker has a persistent OAuth foothold that survives password resets.

• Admin console → Enterprise applications → Consent and permissions: set "Allow user consent for apps" to disabled, or gate it to verified publishers with limited scopes.
• Review Enterprise applications quarterly — anything unfamiliar gets its grants revoked.
• Watch sign-in logs for Consent to application events — that's the audit trail of new app grants.

4. Network and storage defaults

• Storage accounts: turn on "deny public access" at the subscription level and enable Defender for Storage. Public blob leaks are the Azure equivalent of the open S3 bucket — same story, different console.
• NSGs: default-deny inbound, allow by exception. Management ports (RDP 3389, SSH 22) get Azure Bastion or JIT (just-in-time) access — never a standing public rule.
• Virtual machines: if the team leaves, orphaned public IPs stay. Inventory public IPs monthly; every one needs an owner and a reason.

5. The Azure five-minute audit

1. Entra ID → Roles → Global Administrator: how many? Any without MFA? Both answers should be small.
2. Enterprise applications → sort by permissions: any app with Mail.Read, Files.Read.All, or Directory.Read.All you don't recognize?
3. Storage accounts → Networking: any with "Public network access = enabled"?
4. Sign-in logs → filter failures: password spray shows up as many failures across many usernames from one IP.
5. Subscriptions → check for guest accounts with elevated roles — contractors and ex-partners linger here.

Azure rewards teams that treat identity as the perimeter. Tenant hygiene is unglamorous, but it's where the actual attacks are — and it's the cheapest security you'll ever buy.