Application, API & M365 Data-Protection Architecture

Application, API & M365 Data-Protection Architecture — Full Guide

Tier navigation. Last-mile recall: 01-Cheat-Sheet · Understand-once concepts: 02-High-ROI-Explanations · Cross-reference, dates & licensing index: 99-Appendix

Prerequisite units: Secure Networking & Edge Protection (WAF / Front Door / Application Gateway plumbing, TLS to applications) · Data, Storage & Key Management (Key Vault, encryption, data classification) · Posture, Governance, Multicloud & Compliance (Defender for Cloud, its DevOps connector, and its secure score).

This unit references the WAF/Front Door/Application Gateway plumbing (taught in networking), Key Vault/encryption/data-at-rest (taught in the data unit), and Defender for Cloud posture including its DevOps connector and its secure score (taught in the posture unit). It does not re-teach those — it consumes them at the application altitude.

Part A — Azure API Management security (AZ-500 operate + SC-100 design)

A.1 Why APIM is a security control

APIM is a managed reverse-proxy gateway. It decouples API consumers from backends and lets you enforce authentication, authorization, throttling, transformation, and content validation at the edge, before requests touch backend services. The exam treats it both ways: AZ-500 wants the specific policies/settings that harden it; SC-100 wants you to place it in an end-to-end design and justify the choice.

A.2 Inbound authentication and authorization

Two OAuth-validation policies, applied at the gateway before forwarding to the backend:

• validate-jwt — generic. Enforces existence and validity of a JWT from any OIDC provider. Configure <issuers>, <audiences> (at least one audience required), <required-claims>, and signing keys (via <openid-config> pointing at the provider’s .well-known/openid-configuration, which APIM caches roughly hourly). It auto-checks signature and expiry.
• validate-azure-ad-token — preferred when the issuer is Microsoft Entra ID. Entra-aware, less boilerplate; specify tenant-id and allowed client-application-ids.

Scenario decision tree:

• Backend can speak OAuth → validate the token at the gateway, optionally forward it (or exchange it via send-request/managed identity) to the backend.
• Backend is legacy and can’t do OAuth → validate the token at APIM (issuer + audience minimum), then secure the gateway→backend hop separately (mTLS or APIM managed identity). The audience/scope of the token is between the caller and the APIM gateway.
• Org wants a standardized front-end authorization regardless of mixed backends → converge all front-end auth on OAuth at APIM.

A.3 Subscription keys and products

APIs are published through products; a product can require a subscription. Callers then present a subscription key (Ocp-Apim-Subscription-Key header). Subscription keys are pre-shared secrets — weaker than OAuth, with no built-in expiry/rotation (a key A / key B pair you rotate manually) — so best practice is OAuth plus subscription keys for per-consumer identification, auditing, and throttling. Do not use open products (products that don’t require a subscription). Require subscription approval and review requests.

A.4 Backend (gateway→origin) protection

• mTLS to backend — natively supported by API Management; the backend trusts only APIM’s client certificate.
• APIM managed identity to backend (authentication-managed-identity) — a system- or user-assigned identity obtains a token for the backend; no stored secret.
• Network isolation — deploy APIM with a Private Endpoint or in a VNet in internal mode so backends and the gateway aren’t publicly reachable (note: some isolation modes require Standard v2 / Premium tiers).

A.5 Secrets, certificates, named values

• Store secrets as named values marked “secret”, or integrate named values with Azure Key Vault (centralized rotation/revocation), authenticating to the vault with APIM’s managed identity.
• Never store secrets in plaintext named values, policy files, or source control.

A.6 Defense-in-depth policies (offload to the gateway)

• validate-client-certificate for front-end mTLS — set validate-revocation, validate-trust, validate-not-before, validate-not-after all to true.
• ip-filter — restrict caller IPs using an allowlist (not a blocklist).
• Content validation — validate-content (JSON/XML schema, max size), validate-headers, validate-graphql-request (max-size/max-depth for GraphQL).
• set-header — strip response headers that leak implementation detail; disable API tracing in production (it exposes sensitive request data).
• TLS hygiene — disable TLS 1.0/1.1 and weak ciphers; accept HTTPS/WSS only; enforce/audit with Azure Policy.
• CORS — never use wildcard *; explicitly allowlist origins.
• Policy structure — always inherit parent policies via the <base> tag; treat policy changes with SDL rigor (policies run with a privileged view of API traffic).
• Defender for APIs (a Microsoft Defender for Cloud plan) — runtime API threat detection, security insights, and recommendations.

A.7 The APIM hardening table (recall)

A.8 OWASP API Top 10 mapping (SC-100-style reasoning)

“Security misconfiguration” → correct gateway TLS, validate-jwt/validate-azure-ad-token before backend, no wildcard CORS, private endpoint/internal VNet, named values + Key Vault, products require subscription. This is the kind of design-justification SC-100 expects: you state a requirement, then map it to the concrete APIM control that satisfies it.

Part B — WAF and web-workload security (SC-100 design; mechanics in secure-networking)

This unit owns two objectives — Design solutions that secure applications by using Azure Web Application Firewall (WAF) and Specify security requirements for web workloads. The WAF configuration mechanics and Front Door / Application Gateway networking are in Secure Networking & Edge Protection; here you reason at the application layer.

• Placement choice: WAF on Azure Front Door = global edge (CDN, global scale, edge DDoS) for internet-facing apps; WAF on Application Gateway = regional L7 near the backend. Teach which + the OWASP angle here.
• Managed rules = OWASP Core Rule Set (CRS) — covers the OWASP Top 10 (SQLi, XSS, etc.).
• Custom rules — rate limiting, geo-filtering, IP allow/block; bot protection rulesets for credential stuffing / scraping.
• Mode — Detection first (log, tune false positives), then Prevention (enforce/block).
• Web workload requirements (the “specify requirements” objective): TLS in transit, WAF in front, backend reachable only from the WAF tier (service tags / Private Link), managed identity to the data tier, secrets in Key Vault, logging/diagnostics for non-repudiation.

Part C — Application security lifecycle (SC-100 design)

Four objectives — full lifecycle strategy, standards for the dev process, threat modeling, mapping technologies to requirements — plus portfolio posture evaluation.

C.1 Evaluate an existing application portfolio

Inventory applications, classify business criticality, and identify which are business-critical (the ones to threat-model first). Assess each for exposure, identity model, data sensitivity, and existing controls. This produces the prioritized list that drives the rest of the lifecycle.

C.2 Threat modeling (design phase)

• Microsoft Threat Modeling Tool — a core element of the Microsoft Security Development Lifecycle (SDL), design-analysis-centered, usable by non-security experts; it draws data-flow diagrams across trust boundaries.
• STRIDE methodology — each threat class maps to a security property and candidate Azure mitigations:

• Make it a continuous discipline: revisit models as architecture evolves. The Microsoft cloud security benchmark (MCSB) control DS-1 (“Conduct threat modeling”) formalizes this, including modeling the CI/CD pipeline and artifacts, not just runtime.

C.3 SDL and DevSecOps standards

• Microsoft SDL = the body of secure-development practices (equivalent in spirit to OWASP SAMM). It defines secure design, secure-coding training, threat modeling, and verification.
• Shift-left DevSecOps — embed security early: SAST (Static Application Security Testing — analyzes source/bytecode without running it; catches injection / insecure design) and DAST (Dynamic — runtime testing).
• Tooling: GitHub Advanced Security (secret scanning, code scanning, dependency review) and Microsoft Defender for Cloud DevOps security (connects GitHub / Azure DevOps / GitLab).

C.4 Map technologies to requirements & workload identity

“Map technologies to application security requirements” is a translation exercise: requirement → Microsoft control. Example mappings:

Workload identity = managed identity is the canonical “app authenticates to Azure resources without secrets” answer. Its identity-side mechanics live in the identity unit; here it is consumed as the “app authenticates to Azure” control.

Part D — Defender for Office 365 (MDO) — email/collaboration (SC-100 design)

Layered email/collaboration protection above Exchange Online Protection (EOP) (the baseline anti-spam / anti-malware in every mailbox).

• MDO Plan 1 — prevent & detect: Safe Attachments (sandbox detonation of attachments, including for SharePoint / OneDrive / Teams), Safe Links (time-of-click URL rewriting in email, Office clients, and Teams), anti-phishing policies with impersonation protection (user/domain impersonation, mailbox-intelligence / contact-graph, phishing thresholds), real-time detections, Tenant Allow/Block List, ZAP for Teams.
• MDO Plan 2 — everything in P1 plus investigate / respond / automate: Threat Explorer, Threat Trackers / campaign views, Automated Investigation and Response (AIR), Attack simulation training, priority account protection, advanced hunting and incident/alert investigation in Microsoft Defender XDR.
• Safe Documents is not in either MDO plan — it requires M365 A5 / the Microsoft Defender suite. (Classic distractor.)
• ZAP (zero-hour auto purge) retroactively removes malicious mail (and Teams messages) discovered after delivery.

Part E — Defender for Cloud Apps (MDCA) / CASB (SC-100 design)

MDCA is a Cloud Access Security Broker. Three deployment modes solve different problems:

1. Cloud Discovery (shadow IT): analyzes proxy/firewall traffic logs, or integrates with Microsoft Defender for Endpoint to see traffic beyond the corporate network. Scores apps from a catalog of ~31,000 apps against ~90 risk factors. Workflow: discover → assess risk → tag unsanctioned → block via firewall/proxy/MDE; alert via app discovery policies.
2. API connectors: connect sanctioned apps (M365 and third-party SaaS) for continuous monitoring — file policies, anomaly detection, app governance (OAuth app permissions / overprivileged-app hygiene), and governance actions (revoke sharing, quarantine, suspend user).
3. Conditional Access App Control (CAAC): a reverse proxy. You create a Conditional Access policy in Microsoft Entra ID that routes the session through MDCA, which then applies:
   • Access policies — real-time control over logins.
   • Session policies — real-time control over in-session activity: block download, force label-on-download, monitor, require step-up MFA on sensitive actions, control access from unmanaged devices / risky IPs.
   • It operates at the application level, not the file level (you can’t exclude individual files); it requires Entra CA integration.

Policy taxonomy: access (CA), session (CA), file (info protection), app discovery (shadow IT), malware detection (built-in threat), anomaly detection.

Integrations: Entra ID (CA + identity protection), Intune (device compliance), Defender for Endpoint (traffic-based discovery + endpoint governance), Purview (classification), Microsoft Sentinel (export Cloud Discovery logs for KQL hunting).

Part F — Microsoft Intune — device management (SC-100 design)

“Evaluate device management solutions that include Microsoft Intune.” Three policy types, and a crucial division of labor: Intune evaluates; Microsoft Entra Conditional Access enforces.

Key facts:

• Intune evaluates compliance; Microsoft Entra Conditional Access enforces it. The CA node is identical whether opened from Intune or Entra. CA requires Entra ID P1/P2 (app-based CA is also satisfied by EMS licensing).
• Device-based CA = compliant/enrolled device required (managed scenarios).
• App-based CA = managed app required (BYOD without enrolling the whole device).
• Mobile Threat Defense (MTD) risk can feed the compliance signal.

Part G — Microsoft Purview for M365 data (delta from data-storage-keyvault)

The data unit covers Azure data-plane encryption and classification generally; here we cover Purview as it governs Microsoft 365 content.

• Sensitivity labels — the cornerstone: classify content, apply encryption/visual marking, and (critically for Copilot) get cited in output. Support default labels, mandatory labeling, auto-labeling (E5), and container labels for Teams/Groups/SharePoint sites (E5).
• Data Loss Prevention (DLP) — identify, monitor, and protect sensitive items across M365 services and endpoints. Endpoint DLP (on Purview-onboarded Windows devices) can warn/block actions like pasting sensitive content into third-party generative-AI sites (e.g., pasting a credit-card number into ChatGPT in a browser).
• Content explorer — verify what’s labeled/classified.
• Insider Risk Management — detect/investigate/mitigate internal risks (IP theft, data leakage), with privacy controls (pseudonymization, RBAC).
• Retention policies — keep/delete obligations.
• Permissions interplay: content granting VIEW but not EXTRACT usage rights can’t be summarized by Copilot — a direct bridge to Part H.

Part H — Copilot for Microsoft 365 — data security & compliance (SC-100 design)

“Evaluate data security and compliance controls in Microsoft Copilot for Microsoft 365 services.”

Foundational behaviors:

• Copilot enforces each user’s existing permissions — it can only ground on content the user can already access.
• It honors Purview sensitivity labels and encryption; for files where the user lacks EXTRACT rights, Copilot won’t summarize (it can reference with a link).
• Generated content inherits the highest-priority sensitivity label from its source data.
• An advanced PowerShell setting for sensitivity labels can block Office apps from sending content to connected experiences, including Copilot.

Purview DLP for the “Microsoft 365 Copilot and Copilot Chat” location — three protections, two licensing tiers:

1. Restrict processing of sensitive prompts (by SIT) — blocks Copilot from responding when a prompt contains specified sensitive information types (credit card, SSN, passport, custom SITs). Available to ALL Copilot / Copilot Chat licenses.
2. Restrict files/emails with specific sensitivity labels from being processed (grounding/summarization) — labeled items still appear in citations, but their content isn’t used in the response. Requires M365 E5 / the Purview suite (E3 / business tiers don’t get this).
3. Restrict external web grounding when a prompt contains sensitive data (preview) — keeps SITs from being sent to external web search while still using permitted internal sources.

Auditing & coverage caveats: Copilot interactions are captured by Purview Audit (centralized logging objective links to the SecOps unit). Coverage caveats: emails supported on/after Jan 1, 2025; only files in SharePoint Online / OneDrive for Business; calendar invites not supported.

Part I — Microsoft Secure Score — and the classic trap (SC-100 design)

“Evaluate security posture for productivity and collaboration workloads by using metrics, including Microsoft Secure Score.”

Microsoft Secure Score lives at security.microsoft.com/securescore in the Microsoft Defender portal. It measures M365 / productivity & collaboration posture, organizing improvement actions into four groups:

• Identity (Entra accounts & roles)
• Device (Defender for Endpoint — “Secure Score for Devices”)
• Apps (email & cloud apps — Office 365 + Defender for Cloud Apps)
• Data (Microsoft Purview Information Protection)

It spans roughly 17 products (Entra ID, Defender for Endpoint, Defender for Identity, Defender for Office 365, Defender for Cloud Apps, Purview Information Protection, Exchange/SharePoint/Teams Online, GitHub, and third-party SaaS such as Salesforce, ServiceNow, Okta, Zoom), supports benchmark comparison with similar orgs, KPI tracking, and crediting non-Microsoft mitigations.

The classic SC-100 trap — two different Secure Scores

| | Microsoft Secure Score (THIS unit) | Microsoft Defender for Cloud Secure Score (posture unit) | |---|---|---| | Portal | security.microsoft.com/securescore (Defender portal) | Azure portal / Defender for Cloud | | Scope | Microsoft 365 / productivity & collaboration | Azure + AWS + GCP workloads | | Organized by | Identity / Device / Apps / Data | MCSB security controls (risk-based model adds asset criticality) | | Calculation | Improvement actions across M365 products | Built-in MCSB recommendations only |

They are different models with different math and values. Discriminator = the workload: if the scenario is about email/identity/collaboration/M365 posture → Microsoft Secure Score. If it’s about Azure/multicloud infrastructure posture → Defender for Cloud Secure Score (taught in the posture unit). Memorize the four groups (Identity / Device / Apps / Data) as the fingerprint of the M365 one.

Part J — The AZ-500 (operate) ↔ SC-100 (architect) relationship, made explicit

The takeaway: APIM is the single place this unit asks you to configure. Everything else is choose the right product, plan, mode, or policy and justify placement in a design. The reusable SC-100 decision tables: MDO P1 vs P2 (prevent vs prevent+respond/automate — AIR is the P2 marker), MDCA’s three modes (discovery / API connector / CAAC), Intune’s three policy types (compliance / configuration / MAM, with CA as the enforcement point), Copilot DLP’s two tiers (SIT-on-prompts = all licenses; label-blocking = E5), and the two Secure Scores (M365 vs Defender-for-Cloud).

Cross-references

• Cheat-sheet (recall): 01-Cheat-Sheet
• High-ROI (understand once): 02-High-ROI-Explanations
• Prereqs: Secure Networking & Edge Protection · Data, Storage & Key Management · Posture, Governance, Multicloud & Compliance
• Related: Identity, Access & Privileged Access (Conditional Access, managed/workload identity) · Security Operations (Defender XDR, Purview Audit centralized logging)
• Dates, licensing & exam index: 99-Appendix