Azure & Entra ID Hardening

Cloud Fast, Cloud Tight

Cloud environments change rapidly. That's why security here must be standard and automated.

For Azure & Entra ID Hardening, automation is leading: guardrails in code, least privilege, and continuous drift control.

This way you maintain speed in the cloud, without security depending on manual luck.

Immediate measures (15 minutes)

• Implement IAM least privilege and enforcing guardrails per account/project.
• Use secret management with rotation instead of static credentials.
• Require CI/CD and IaC controls for deployment to production.

Why this matters

The core of Azure & Entra ID Hardening is risk reduction in practice. Technical context supports the choice of measures, but implementation and assurance are central.

Defense measures

Conditional Access

Conditional Access is the most important defense layer in Entra ID. A well-configured Conditional Access policy makes many of the attacks in this chapter impossible or significantly harder.

Essential policies:

# Audit: retrieve all Conditional Access policies
az rest --method GET \
    --uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" | \
    python3 -c "
import sys,json
policies = json.load(sys.stdin).get('value',[])
for p in policies:
    state = p.get('state','unknown')
    name = p.get('displayName','')
    print(f'[{state.upper():8}] {name}')
"

Privileged Identity Management (PIM)

PIM implements just-in-time privileged access: roles are not permanently assigned, but must be activated when needed. Activation requires a justification and can require MFA and approval.

PIM reduces the attack surface by: - Fewer permanently active Global Admins - Time-bound role activation (max 8 hours default) - Audit trail of role activation - MFA requirement on activation (even if the session already has MFA)

Workload Identity Federation

Workload Identity Federation is the successor to client secrets for app registrations. Instead of a secret that can be stolen, it uses a federated trust relationship with an external identity provider. No secret, no risk of secret leakage.

# Check if there are still apps with client secrets (that should be migrated)
az ad app list --query "[?passwordCredentials[0]!=null].{App:displayName,Created:passwordCredentials[0].startDateTime,Expires:passwordCredentials[0].endDateTime}" -o table

Additional Recommendations

Reference table

In the next chapter, we leave the Azure world and enter Google's territory -- a place where everything revolves around projects, service accounts, and the inexhaustible trust that Google has in its own infrastructure. Spoiler: that trust is not always justified.