CH07-06: Security Choice Scenario

Goal

This chapter started with one idea: choose security services by control objective, not by product name. Now we will apply that idea to a realistic design.

The scenario is a regulated customer platform. It hosts public APIs, stores sensitive customer records, integrates with internal systems, and needs evidence for audit. Security teams need visibility and response workflow, but they cannot become the deployment owner for every workload team.

The durable idea for this section is:

A secure Azure design combines controls around identity, secrets, traffic paths, posture, detection, response, and evidence.

Scenario

A financial services company is building a customer platform in Azure.

The platform includes:

• Public APIs used by web and mobile applications.

• Sensitive customer records in managed data services.

• Internal integrations with existing enterprise systems.

• Application teams that deploy frequently.

• Central security, compliance, and platform teams.

• Audit requirements for access, configuration, logging, and incident response.

The business wants fast delivery, but the security requirements are serious:

• Protect human and workload identities.

• Avoid storing secrets in code or plain configuration.

• Reduce public exposure for data services.

• Protect public entry points from common web attacks and availability attacks.

• Inspect or control important traffic paths.

• Detect misconfiguration and suspicious activity.

• Retain useful evidence for audits and investigations.

• Define owners before incidents happen.

This is exactly where a control-objective model helps.

Translate Requirements Into Controls

Start by translating each requirement into a security job:

This table gives the team an explainable starting point. It also prevents an unhelpful answer like, "Use every security service."

Layered Architecture View

A high-level security view could look like this:

flowchart TB
    A["Users and clients"]
    B["Public edge<br/><small>WAF and DDoS protection</small>"]
    C["API workload<br/><small>Managed hosting or container service</small>"]
    D["Managed identity<br/><small>Workload authentication</small>"]
    E["Key Vault<br/><small>Secrets, keys, certificates</small>"]
    F["Private endpoint<br/><small>Private data service access</small>"]
    G["Internal integrations<br/><small>Controlled routes and firewall where needed</small>"]
    H["Defender for Cloud<br/><small>Posture and workload protection</small>"]
    I["Sentinel<br/><small>Analytics, incidents, playbooks, evidence</small>"]

    A --> B --> C
    C --> D
    D --> E
    C --> F
    C --> G
    C --> H
    B --> I
    E --> I
    F --> I
    G --> I
    H --> I

The diagram is intentionally layered. It is not saying every packet must pass through every box. It is showing where each control objective lives.

Identity and Secrets Design

For human access, the platform uses Microsoft Entra ID groups and Azure RBAC assignments. Production access is group-based and scoped by role. Application teams can deploy through approved automation, while direct production modification is limited. Emergency access exists, but it is logged, reviewed, and separated from normal daily work.

For workload access, the APIs and background jobs use managed identities wherever supported. The workload identity receives only the permissions it needs. For example, the API may read a certificate or secret from Key Vault and connect to a data service using Microsoft Entra authentication where the target service supports it.

Key Vault stores secrets, keys, and certificates that cannot be eliminated. Access is narrow. Secret rotation and certificate renewal are assigned to owners. Key Vault logs are retained and sent to the monitoring or security operations path.

The design principle is simple: people, workloads, and automation should not share broad credentials.

Traffic Protection Design

The public API entry point uses a service that can apply Web Application Firewall policy. WAF helps reduce risk from common HTTP-layer attacks and gives the team logs for blocked or suspicious requests.

For internet-facing resources where availability risk is high, the team evaluates DDoS Protection. This is a business and architecture decision: public exposure, expected traffic, regulatory impact, outage cost, and response needs all matter.

The API reaches sensitive data services through private endpoints. Private DNS is designed so service names resolve to private addresses from the workload network. Public network access is restricted where the service and architecture support it.

Selected network paths route through Azure Firewall. For example, outbound internet access from workload subnets may be controlled centrally, and traffic between workload spokes and shared services may be inspected where the risk justifies the complexity.

The key is placement. WAF protects HTTP application entry. DDoS Protection protects availability of public resources. Azure Firewall controls selected network paths. Private endpoints reduce public exposure for dependencies.

Posture, Detection, and Response Design

Defender for Cloud is used to assess cloud posture and surface workload protection recommendations or alerts. The platform team uses it to understand whether subscriptions, resources, and workload services follow expected security baselines.

Sentinel collects signals that matter for investigation: identity activity, Azure activity logs, WAF logs, firewall logs, Key Vault access logs, selected application logs, and relevant Defender for Cloud alerts. Analytics rules group related activity into incidents. Playbooks automate trusted response steps, such as opening a ticket, enriching an incident, notifying an owner, or disabling a known-bad path when the team has approved that automation.

The team avoids collecting logs blindly. Each log source has a reason:

Detection without ownership is theater. The platform defines who owns each incident type before production.

Evidence and Ownership

For audit, the company needs more than screenshots. It needs evidence produced by normal operation:

• RBAC assignments and access reviews show who had access.

• Policy and posture records show which guardrails and recommendations were active.

• Key Vault logs show access to sensitive material.

• WAF, firewall, and DDoS telemetry show traffic events and response context.

• Sentinel incidents show investigation and response history.

• Change records show approved configuration changes and exceptions.

Ownership is split deliberately:

This gives security teams visibility without making them the bottleneck for every deployment.

Common Mistakes

• Designing security as a list of enabled services instead of a control model.

• Protecting the edge while leaving workload identities over-permissioned.

• Sending logs to security tools without response owners.

• Treating Key Vault as enough while broad access remains.

• Forgetting that security services must align with governance, networking, compute, integration, and data choices.

• Collecting evidence only when an audit is near instead of as part of normal operations.

If Someone Asks You

How would you choose Azure security services for a regulated customer platform?

A good answer is:

I would translate the requirements into control objectives. For identity and access, I would use Microsoft Entra ID, Azure RBAC, and managed identities. For secrets, keys, and certificates, I would use Key Vault with narrow access and rotation planning. For public traffic, I would use WAF and evaluate DDoS Protection. For private dependencies, I would use private endpoints and private DNS. For selected network paths, I would use Azure Firewall where inspection and control justify the operational cost. For posture and workload risk, I would use Defender for Cloud. For SIEM, correlation, investigation, automation, response, and evidence, I would use Sentinel with clear owners and retention decisions.

What You Should Remember

Security architecture is layered responsibility placement, not a product checklist.

Questions to Check Your Understanding

1. Which controls in the scenario protect identity and secrets?

2. Which controls protect traffic paths?

3. Which controls help detect, investigate, and prove security posture?