CH07-01: Security Selection Mental Model
Goal
Earlier chapters treated service selection as responsibility matching. Compute selection matched code to an operating boundary. Integration selection matched communication to a contract. Data selection matched information to shape, query pattern, consistency, and lifecycle.
Security selection works the same way, but the responsibility is a control objective. A control objective is the thing you are trying to protect, prove, detect, or recover from. The goal is not to enable a long list of security products. The goal is to understand which risk each control addresses and who will operate it after it is enabled.
The durable idea for this chapter is:
Security services should be chosen for the control objective they support.
The Short Version
The easy question is:
Which Azure security service should I use?
The better architecture question is:
What control objective am I trying to satisfy?
Security is not solved by one service because there is not one kind of risk. Identity risk is different from secret exposure. Public web exposure is different from private database access. Misconfiguration is different from active attack detection. Audit evidence is different from actual incident response.
Do not worry about memorizing every security product name immediately. Start with the jobs security controls perform:
flowchart TB
A["Identity and access<br/><small>Who or what can act?</small>"]
B["Secrets, keys, and certificates<br/><small>Which sensitive values need protection?</small>"]
C["Network and edge protection<br/><small>Which traffic paths need filtering or inspection?</small>"]
D["Posture and workload protection<br/><small>Where are misconfiguration and active risk appearing?</small>"]
E["Logging, analytics, response, and evidence<br/><small>How will teams detect, investigate, act, and prove control?</small>"]
A --> B --> C --> D --> EIf you can name the control objective, the service choice becomes much easier to explain.
Control Objectives Before Service Names
Azure has many security services because cloud security is layered. The same workload may need identity controls, secret controls, network controls, posture controls, detection controls, and evidence controls at the same time.
Use this first-pass map:
| Control Objective | What You Are Really Deciding | Azure Direction |
|---|---|---|
| Identity and access | Who or what is allowed to act, and at what scope? | Microsoft Entra ID, Azure RBAC, managed identities. |
| Secrets and keys | How are passwords, connection strings, keys, and certificates protected? | Azure Key Vault. |
| Network and edge protection | Which public and private traffic paths need filtering, inspection, or mitigation? | Azure Firewall, Web Application Firewall, DDoS Protection, private endpoints. |
| Posture and workload protection | How will teams find misconfiguration and workload risk? | Microsoft Defender for Cloud. |
| Detection, response, and evidence | How will teams collect signals, correlate incidents, automate response, and prove control? | Microsoft Sentinel and operational logging. |
This table is a vocabulary bridge, not a final design. A real architecture still needs scopes, routing, ownership, data classification, response paths, and cost decisions.
Why One Service Is Not Enough
Imagine a public customer API for a regulated company. Users authenticate before calling the API. The API runs in Azure and connects to a database with sensitive customer records. The platform team needs audit evidence. The security team needs visibility into suspicious activity. The application team needs to deploy without waiting for security engineers to approve every small change.
No single security service covers that whole story:
User and operator access need identity and authorization controls.
The API workload needs a safe way to authenticate to Azure services without storing credentials in code.
Database credentials, certificates, and keys need protected storage and scoped access.
Public entry points need application-layer protection and denial-of-service mitigation.
Private dependencies need reduced exposure and correct DNS and network paths.
Cloud resources need posture recommendations and workload protection signals.
Logs and alerts need correlation, investigation, response, and retained evidence.
The architecture is secure only when those controls reinforce each other. A firewall does not replace identity. A private endpoint does not replace authorization. A dashboard does not replace an incident owner. A compliance report does not prove that a team can respond under pressure.
A Practical Selection Flow
Start with these questions before choosing products:
| Question | Why It Matters |
|---|---|
| Who or what can access this resource? | Separates human identity, workload identity, and permission scope. |
| Where are secrets, keys, and certificates stored? | Prevents sensitive values from leaking through code, configuration, logs, or deployment scripts. |
| Which traffic paths are public, private, inspected, or blocked? | Connects security choices to networking and application entry points. |
| What misconfiguration or threat signals must be detected? | Turns posture and detection tools into action instead of noise. |
| Who owns alerts, exceptions, access reviews, and response? | Makes security controls operational instead of decorative. |
| What evidence must be retained? | Connects compliance to logs, policy state, access records, and incident history. |
| What cost and operational load can the workload justify? | Prevents overbuilding controls for low-risk experiments or underbuilding them for critical systems. |
These questions are deliberately plain. In architecture discussions, plain questions are often more useful than product vocabulary because they keep the team focused on risk and responsibility.
Example: Regulated Customer API
A regulated customer API stores sensitive records and exposes public endpoints for a web and mobile experience. It also calls internal systems and stores operational logs for audit.
A control-objective view might look like this:
| Need | Control Objective | Service Direction |
|---|---|---|
| Operators need production access only through approved groups. | Human identity and scoped authorization. | Microsoft Entra ID groups and Azure RBAC. |
| The API needs to access storage, Key Vault, or a database without embedded passwords. | Workload identity. | Managed identity. |
| Certificates and connection secrets must be protected and auditable. | Secret and key management. | Azure Key Vault. |
| Public HTTP traffic needs protection from common web attacks. | Application-layer edge protection. | Web Application Firewall. |
| Public resources need mitigation for volumetric attacks. | Denial-of-service protection. | DDoS Protection where the architecture requires enhanced protection. |
| Private data services should not be exposed directly to the internet. | Private service access. | Private endpoints and private DNS. |
| Misconfigured resources and workload threats must be visible. | Posture and workload protection. | Microsoft Defender for Cloud. |
| Security signals need correlation and response workflow. | SIEM, analytics, and response. | Microsoft Sentinel. |
Notice the shape of the answer. It does not start with a product shopping list. It starts with what the platform must control.
Common Mistakes
Enabling security services because they sound important, without naming the control objective.
Treating network controls as a replacement for identity, authorization, and application security.
Storing secrets in application configuration while assuming the rest of the architecture is secure.
Turning on alerts without assigning owners, escalation paths, and response expectations.
Confusing compliance evidence with actual security operations.
Assuming a higher secure score or a cleaner dashboard means the team is ready for an incident.
If Someone Asks You
How do you choose Azure security services?
A good answer is:
I start with the control objective. If the problem is who can act, I look at Microsoft Entra ID, Azure RBAC, and managed identities. If the problem is secrets, keys, or certificates, I look at Key Vault. If the problem is traffic exposure, I look at WAF, DDoS Protection, Azure Firewall, private endpoints, and routing. If the problem is posture or workload threat protection, I look at Defender for Cloud. If the problem is signal correlation, investigation, response, and evidence, I look at Sentinel and logging. Then I check ownership, cost, alert tuning, and response process.
What You Should Remember
Start with the risk and control objective, then choose the security service.
Questions to Check Your Understanding
Why is security not solved by one Azure service?
What is a control objective?
Why do ownership and response matter after security services are enabled?