Identity, Least Privilege and Network Exposure

Illustrative Findings Boundary

The severity-labelled scenarios below are newly authored fictional examples informed by the control domains assessed in this work. They do not reproduce or summarize any engagement finding, do not describe the reviewed environment, and do not indicate that any weakness was observed, confirmed, remediated or remains outstanding. Severity labels apply only to these examples and illustrate prioritization methodology.

Each example combines a plain-English business summary, a technical condition, potential impact, the evidence an assessment would seek, the expected control and a measurable way to check the fix.

Zero Trust requires explicit verification at every boundary. Network reachability, user sign-in and service identity answer different security questions and should be assessed separately.

Prefer managed workload identities over embedded connection material.
Scope roles to the smallest service, operation and environment that requires them.
Enforce authorization in downstream services instead of relying on a caller or model to make the decision.
Separate public ingress requirements from management-plane and data-plane access.
Record deliberate exceptions with an owner, expiry condition and verification step.

Fictional Security Examples

Illustrative Identity and Access Examples

Illustrative only - not an engagement finding

One Workload Identity Can Traverse Multiple Trust Zones

Critical See where this finding applies on the diagrams: managed-identity edges · CP2 managed-identity edges

Ease of Attack: Requires compromise of one workload
Impact: Cross-zone access and privilege escalation
Detection Difficulty: Visible in role-assignment review across services
Pattern: Example least-privilege pattern

Business Summary: A broadly privileged workload identity allows one compromised service to become a stepping stone into configuration, processing and data systems that should have separate trust boundaries.
Possible Weakness: One application identity holds broad permissions across ingress, configuration, processing and data services.
Potential Impact: A compromise in one workload could spread across trust zones and expose administration, credentials and sensitive data.
What an Assessment Verifies: List every Entra ID role assignment, the data-plane permissions on Storage, Cosmos DB and App Configuration, reachable services and the effective access available to each workload identity.
Expected Fix: Use a distinct Entra ID identity per workload, scope every role to the minimum operation and restrict network paths between trust zones.
How to Check the Fix: Each workload must complete its approved function while tests prove that it cannot read, change or administer resources assigned to another trust zone.

Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how identity configuration, role assignments and safe tests that confirm access is denied are reviewed together. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.

Example read-only role-assignment record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "properties.exampleControl"

Illustrative output: {"exampleControl":"enabled"}
```
Example infrastructure identity definition
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
```
if not policy.can_access(actor, record):
    raise Forbidden()
```
Example denied-access test output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```

Illustrative only - not an engagement finding

Frontend Workload Can Read Backend-Only Configuration

High See where this finding applies on the diagrams: App Configuration edges · CP2 managed-identity edges

Ease of Attack: Requires frontend identity compromise
Impact: Backend credentials and service discovery
Detection Difficulty: Visible in a review of who can read which configuration
Pattern: Example configuration-separation pattern

Business Summary: The public-facing layer should expose the least information and authority. Backend-only configuration in that layer can turn a web-tier compromise into access to more privileged services.
Possible Weakness: A public-facing web workload can read configuration values intended only for APIs, workers or data services.
Potential Impact: A frontend compromise could reveal backend destinations, reusable credentials or access material for more privileged services.
What an Assessment Verifies: Review App Configuration roles, key prefixes, Key Vault secret references and the effective values available to the web app's identity.
Expected Fix: Separate App Configuration scopes, remove backend access from the web app's identity and prefer managed identity over reusable credentials.
How to Check the Fix: The frontend identity must be denied every backend-only key and secret path while the web application continues to operate using only its explicitly approved configuration.

Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.

Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "properties.exampleControl"

Illustrative output: {"exampleControl":"enabled"}
```
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
```
if not policy.can_access(actor, record):
    raise Forbidden()
```
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```

Illustrative only - not an engagement finding

Supporting Services Retain Unnecessary Public Network Paths

Medium See where this finding applies on the diagrams: data and configuration zone · private-connectivity perimeter [target]

Ease of Attack: Depends on a valid identity or key
Impact: Expanded reachability and attack surface
Detection Difficulty: Visible in public-network exposure review
Pattern: Example private-connectivity pattern

Business Summary: Every unnecessary public endpoint creates another route that must be defended continuously and increases dependence on identity and firewall settings remaining correct.
Possible Weakness: Data, configuration or build services retain public endpoints even though only known application workloads need access.
Potential Impact: The additional network paths expand the attack surface and increase reliance on identity and firewall configuration remaining perfect.
What an Assessment Verifies: Inspect public-network settings, firewall rules and private endpoints across Storage, Cosmos DB, App Configuration and Container Registry, plus name resolution and documented exceptions.
Expected Fix: Prefer private connectivity to Storage, Cosmos DB and App Configuration, scope necessary public exceptions and give every exception an owner and expiry condition.
How to Check the Fix: Connections from an external test location must fail while approved private workloads continue to connect. Any permitted public exception must show an owner, purpose and expiry date.

Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "properties.exampleControl"

Illustrative output: {"exampleControl":"enabled"}
```
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
```
if not policy.can_access(actor, record):
    raise Forbidden()
```
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```

Azure Review · Control Domain 2 of 5 · Public Edition

Part of the two-report public security-review portfolio.

Report overview