Azure Security: Defender, Key Vault, Policy, and Private Access

Protect Identities and Privilege

Azure security combines identity controls, workload configuration, network isolation, data protection, policy, monitoring, and incident response.

Managed identities and Azure RBAC reduce stored credentials, Key Vault protects secrets and keys, Azure Policy evaluates configuration, and Defender for Cloud provides posture recommendations and workload protections.

A control is useful when its result can be verified: denied access, private resolution, rotated credentials, policy compliance, protected logs, or a rehearsed response.

Require strong authentication, use conditional access, minimize permanent privileged roles, and assign workload identities separately from deployment automation.

Use Privileged Identity Management for time-limited elevation where available.
Review application credentials and role assignments.
Maintain controlled emergency access accounts.

Protect Secrets, Keys, and Data

Store secrets and keys in Key Vault, authorize access through RBAC or the selected vault model, and use private endpoints where exposure requirements demand them.

Enable soft delete and purge protection for important vaults.
Rotate secrets and certificates before expiry.
Separate key administration from ordinary data access.

Enforce and Detect

Use Azure Policy initiatives to audit or deny unwanted configurations. Defender for Cloud, Activity Logs, resource logs, and Microsoft Sentinel can identify posture gaps and suspicious activity.

Assign findings to owners with remediation deadlines.
Aggregate logs before a compromised resource can erase local evidence.
Tune detections with documented exceptions.

Contain and Recover

Prepare procedures for disabling identities, isolating network interfaces, preserving evidence, rotating credentials, restoring data, and communicating an incident.

Pre-authorize an incident-response role and workflow.
Test isolation without destroying evidence.
Protect backups and security logs from the workload administrator path.

Responsibility and Control Mapping

Microsoft secures Azure facilities, physical infrastructure, and managed platform layers according to each service. Customers retain responsibility for identities, data, application code, configuration, and exposed operating-system layers. A virtual machine leaves guest patching and host configuration with the customer; App Service, Azure SQL, and Functions move different operations to Microsoft without assuming application authorization or data governance.

Map every security objective to a control, scope, owner, evidence, test frequency, and incident action. The Microsoft cloud security benchmark and Azure Well-Architected security guidance provide review domains, but the workload threat model determines which controls matter and how they are implemented.

Keep compliance evidence distinct from actual risk reduction. A Policy compliance result or Defender recommendation can identify configuration, but it does not prove business authorization, code security, recovery, or incident readiness. Validate controls from an unauthorized callers or attackers path.

Document responsibility per service layer.
Give every control an owner and evidence source.
Use benchmarks as inputs to a workload threat model.
Test outcomes rather than relying only on compliance status.

Identity Attack Paths

Require strong authentication for people, managed identity or federation for workloads, and time-bounded privileged activation. Review combined Entra and Azure privilege escalation: application consent, role assignment, managed-identity attachment, Key Vault access, pipeline control, Bicep deployment, extension execution, and the ability to change Conditional Access or Policy.

Separate daily, privileged, emergency, deployment, and runtime identities. Restrict subscription Owner, User Access Administrator, directory administrator, and app-consent roles. Monitor new credentials, federated subjects, role assignments, group changes, PIM activation, and emergency access use.

Run access reviews and remove inactive users, service principals, credentials, assignments, and consent grants. Preserve rare recovery permission only with a documented owner and exercise. Least privilege is a maintained lifecycle, not the first role chosen during resource creation.

Review privilege chains across directory and resources.
Separate deployment authority from runtime access.
Monitor role, consent, and credential changes.
Exercise rare emergency access before retaining it.

Key Vault and Data Controls

Use Key Vault for secrets, cryptographic keys, and certificates with separate RBAC for read, write, rotation, and purge. Prefer Azure RBAC for modern consistent authorization where the service design permits it, and do not mix access models casually. Enable and understand soft delete and purge protection so an attacker or mistake cannot immediately destroy recovery material.

Use managed identities, private endpoints or controlled firewall paths, diagnostic logs, rotation, expiration, and dependent-application refresh. A vault outage or deleted key can stop data recovery and application startup, so design redundancy and break-glass access from the workloads RTO. Customer-managed keys add control and key-availability responsibility.

Classify data and govern every copy: primary stores, snapshots, exports, logs, caches, queues, and backups. Encrypt transport and storage, but also narrow data roles and application object authorization. Encryption does not protect data from a principal legitimately permitted to decrypt it.

Separate secret use, management, and purge authority.
Protect vaults with recoverable deletion controls.
Test rotation and encrypted restore.
Inventory secondary copies and telemetry.

Policy and Defender Signals

Azure Policy audits, denies, modifies, or deploys supported resource configuration according to definition, initiative, assignment, and effect. Test deny and remediation before broad management-group rollout. A deploy-if-not-exists or modify assignment uses a managed identity with permissions that must be reviewed and monitored.

Use Policy exemptions rather than invisible exclusions when a resource is mitigated or temporarily waived. Record category, reason, compensating control, owner, scope, and expiration. An expired exemption remains as a historical object but should no longer excuse noncompliance; monitor and close it.

Microsoft Defender for Cloud combines security posture recommendations and selected workload protection plans. Enable coverage intentionally per subscription and resource, route alerts to responders, and prioritize exploitable paths and critical data rather than chasing secure-score points alone. Verify recommendations against workload context before remediation.

Stage Policy effects before broad enforcement.
Restrict remediation identity permissions.
Give every exemption an expiry and compensating control.
Route Defender findings to accountable responders.

Workload and Network Protection

Expose only intentional entry points through Front Door, Application Gateway, API Management, or load balancers, and keep backends private where practical. Use NSGs, Firewall, WAF, DDoS Protection, private endpoints, and outbound controls for their specific layers. Do not assume a private address removes the need for identity and application authorization.

Patch VM images, containers, Functions and App Service dependencies, database clients, and platform versions through a tracked lifecycle. Defender vulnerability findings and registry scans require triage, rebuild, deployment, and closure evidence. Remove unsupported software before an urgent migration narrows testing time.

Validate input, business authorization, tenancy boundaries, SSRF protections, secrets, and dependency trust inside application code. Use workload identity with minimal data roles. Cloud configuration reduces exposure but cannot make an insecure endpoint safe.

Keep backends behind reviewed entry paths.
Control outbound traffic and private DNS.
Patch through reproducible artifacts.
Test object-level and tenant-level authorization.

Incident Containment Drill

Prepare Sentinel or another SIEM path, Defender alerts, Activity Log export, resource diagnostics, evidence storage, incident identities, network isolation, credential revocation, clean deployment, backup access, and communication before a compromise. Protect security workspaces and vaults from ordinary workload administrators.

For a suspected identity event, preserve sign-in and audit evidence, identify tokens and role paths, contain the principal, inspect persistence and application consent, rotate affected secrets, and validate downstream data access. For a workload event, isolate without destroying disks or volatile evidence when investigation requires it.

Exercise a compromised service principal, public storage change, suspicious VM, deleted vault secret, and encrypted restore. Record decision authority and recovery time. Feed findings into Policy, RBAC, detection, image, network, and runbook changes with owners rather than ending at an incident report.

Preserve evidence before destructive containment.
Pre-create narrow response identities.
Test secret revocation and clean redeployment.
Convert exercise findings into verified controls.

Exception and Evidence Lifecycle

Represent security exceptions through a Policy exemption, risk register, or another governed record rather than an undocumented exclusion. Record affected resource IDs, control intent, waiver or mitigation, business reason, approving owner, compensating controls, evidence, expiration, and the event that forces earlier review.

An expired Policy exemption stops being honored but remains visible as history. Alert before expiry and decide whether the resource becomes compliant, receives a new reviewed exception, or is retired. Do not renew automatically merely because remediation remains inconvenient.

Test the compensating control from the threat path. A private endpoint, additional alert, or manual review only mitigates risk when it actually blocks or detects the scenario. Reassess after network, identity, data classification, or service changes and attach the proof to the exception record.

Use governed exemptions instead of silent exclusions.
Require owner, expiry, and compensating evidence.
Test mitigation from an unauthorized path.
Preserve immutable review evidence for auditors and responders.
Close exceptions when the workload changes or retires.

Azure Security Examples

Azure Key Vault secret reference example

Store the secret in Key Vault and reference it from app configuration instead of copying secrets into App Service settings.

Azure Key Vault secret reference example

az keyvault secret set \
  --vault-name kv-tl-demo \
  --name DbPassword \
  --value "ChangeMe123!"
az webapp config appsettings set \
  --resource-group rg-cloud-lab \
  --name app-web-prod \
  --settings "DbPassword=@Microsoft.KeyVault(SecretUri=https://kv-tl-demo.vault.azure.net/secrets/DbPassword/)"

Secret references reduce credential sprawl in app configuration.
The app identity still needs permission to read the secret from Key Vault.

Contain a Key Vault Exposure

A secret is read by an unexpected workload identity.

Contain a Key Vault Exposure

Constraints: Audit evidence must be retained; dependent applications need a safe rotation sequence.
Decision: Disable the identity path, rotate the secret, update managed references, review role assignments, and preserve Key Vault diagnostics.
Verification: The old value and principal are rejected, approved workloads resolve the replacement, and the timeline is complete.
Failure test: Attempt access from the removed principal and confirm a logged authorization failure.

Output

Expected evidence: The old value and principal are rejected, approved workloads resolve the replacement, and the timeline is complete.

This is a worked engineering decision, so the result is operational evidence rather than terminal output.

Before you move on