Azure Architecture Guide

CH21-04: Security and Identity

Goal

Help readers connect security and identity concerns to Azure solution options, useful patterns, trade-offs, and decision prompts.

The Short Version

Security design starts with identity, least privilege, protected secrets, controlled access paths, and visible risk.

In Azure, security is not only a network boundary or a security product. A strong design proves who or what is calling, limits what that caller can do, protects secrets and keys, reduces unnecessary exposure, records sensitive actions, and routes risk signals to accountable owners.

Concern

The workload must authenticate callers, authorize actions, protect secrets and data, reduce attack surface, and provide evidence of control.

Typical Symptoms

  • Shared credentials appear in code, configuration, or pipelines.

  • Users or services have broader permissions than needed.

  • Secrets have no rotation or access review.

  • Applications trust network location instead of identity and authorization.

  • Security monitoring exists but is disconnected from workload ownership.

Azure Solution Options

  • Microsoft Entra ID for identity and authentication.

  • Azure RBAC for authorization at Azure scopes.

  • Managed identities for workload access to Azure resources.

  • Azure Key Vault for secrets, keys, and certificates.

  • Private networking and edge protection where exposure must be reduced.

  • Microsoft Defender for Cloud for posture management and protection signals.

  • Microsoft Sentinel for security information and event management where needed.

Useful Patterns

  • Federated Identity.

  • Valet Key where limited delegated access is appropriate.

  • Gateway Offloading for shared edge concerns.

  • Sidecar or ambassador concepts where security functions need separation.

Trade-Offs

  • Stronger isolation improves control but can increase operational friction.

  • Centralized security controls improve consistency but must not block accountable delivery.

  • Managed identities reduce secret handling but still require precise permissions.

  • Security monitoring creates value only when alerts are actionable and owned.

Decision Prompt

Who or what is accessing this resource, what should they be allowed to do, and how will misuse or drift be detected?

Common Mistakes

  • Confusing authentication with authorization.

  • Treating Key Vault as a fix for overly broad access.

  • Giving agents, services, or pipelines owner-level permissions by default.

  • Designing security controls without incident ownership.

If Someone Asks You

How do you approach security and identity in Azure architecture?

I start with identity and authorization. Users, services, pipelines, and agents should authenticate through the right identity system and receive least-privilege access. I use managed identities where possible, Key Vault for secrets that must exist, private access and edge controls where exposure must be reduced, and Defender for Cloud, Sentinel, logs, and reviews to keep risk visible and owned.

What You Should Remember

Prove identity, grant least privilege, protect secrets, reduce exposure, and make risk visible.

Questions to Check Your Understanding

  1. How are authentication and authorization different?

  2. Why do managed identities still require access design?

  3. Why is monitoring not a replacement for least privilege?