Threat Tribunal

Who and What Can Access Each Service

Zero Trust means checking every request instead of trusting it because of where it came from. The ability to connect, a person's sign-in and the identity used by an application answer different security questions and must be checked separately.

  • Use managed identities for applications instead of storing keys or connection strings.
  • Give each role access only to the service, operation and environment it needs.
  • Check permission again in every service that receives a request instead of trusting the caller or AI model.
  • Treat incoming public access, service administration and access to stored data as separate controls.
  • 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 Application Identity Can Access Too Many Parts of the System

Critical See where this finding applies on the diagrams: managed-identity edges · CP2 managed-identity edges
Business summary
A broadly privileged application identity allows one compromised service to become a stepping stone into settings, processing and data systems that should remain separate.
Assessment profile
Ease of attack
Requires compromise of one workloadOne application identity holds broad permissions across ingress, configuration, processing and data services.
Impact
Cross-zone access and privilege escalation
  • A compromise in one application could spread into parts of the system with different levels of trust.
  • It could expose administration, credentials, personally identifiable information (PII) and other protected customer data.
Detection difficulty
Visible in role-assignment review across services
  • List every Entra ID role assignment.
  • List permissions to stored data in Storage, Cosmos DB and App Configuration.
  • List reachable services and the effective access available to each application identity.
Pattern
Example least-privilege pattern
Expected fix Verification
  1. Expected fix Give each application service its own managed identity do not share identities or reusable credentials.
    Verification Each application service must complete its approved function through its own managed identity
  2. Expected fix Scope each Azure role to the smallest resource and set of operations the service needs
    Verification Each identity must be denied resources, configuration values and data assigned to another service
  3. Expected fix Prevent one service identity from reading another service's App Configuration values, secrets or customer data
    Verification The deployed configuration must contain no reusable credential that substitutes for the managed identity
  4. Expected fix Restrict network paths between services with different trust levels
    Verification Network tests must block service paths outside the approved trust boundary
  5. Expected fix Review role assignments regularly and alert on unexpected privilege changes
    Verification An unexpected role assignment must be detected by the access review or alerting control

Related illustrative findings: frontend configuration access; public network paths.

Illustrative only - not an engagement finding

The Public Web App Can Read Private Backend Settings

High See where this finding applies on the diagrams: App Configuration edges · CP2 managed-identity edges
Business summary
The public web app should expose the least information and authority. Private backend settings in that app can turn a web compromise into access to more privileged services.
Assessment profile
Ease of attack
Requires frontend identity compromiseA public-facing web workload can read configuration values intended only for APIs, workers or data services.
Impact
Backend credentials and service discovery
  • A compromise of the public web app could reveal private service addresses.
  • It could reveal reusable credentials or access details for more privileged services.
Detection difficulty
Visible in a review of who can read which configuration
  • Review App Configuration roles and key prefixes.
  • Review Key Vault secret references.
  • Review the effective values available to the web app's identity.
Pattern
Example configuration-separation pattern
Expected fix Verification
  1. Expected fix Treat every value delivered to the browser as public information
    Verification The browser bundle and runtime configuration must contain only the approved public-setting allowlist
  2. Expected fix Publish only an explicit allowlist of browser-safe settings
    Verification A planted secret, private backend setting or Key Vault path must fail the build or startup check
  3. Expected fix Give the web workload its own limited App Configuration area and identity
    Verification The web workload's identity must be denied every private backend setting and secret path
  4. Expected fix Remove access to private backend settings, Key Vault secret paths and reusable credentials
    Verification The browser must be unable to retrieve a backend-only setting through an application endpoint
  5. Expected fix Make the build or startup fail when an unapproved setting would be exposed to the browser
    Verification The application must continue to operate using only its explicitly approved public settings

Related illustrative findings: workload identity scope; shared application secrets.

Illustrative only - not an engagement finding

Supporting Services Still Accept Unnecessary Public Connections

Medium See where this finding applies on the diagrams: data and configuration zone · private-connectivity perimeter [target]
Business summary
Every unnecessary public connection creates another route that must be defended continuously and makes the system more dependent on sign-in and firewall settings remaining correct.
Assessment profile
Ease of attack
Depends on a valid identity or keyData, configuration or build services still accept public connections even though only known applications need access.
Impact
Expanded reachability and attack surface
  • Extra connection paths give attackers more routes to test.
  • They increase reliance on identity and firewall settings remaining perfect.
Detection difficulty
Visible in public-network exposure review
  • Inspect public-network settings, firewall rules and private endpoints across Storage, Cosmos DB, App Configuration and Container Registry.
  • Inspect name resolution and documented exceptions.
Pattern
Example private-connectivity pattern
Expected fix Verification
  1. Expected fix Use private endpoints for Storage, Cosmos DB and App Configuration, and explicitly disable their public network access
    Verification Connections from an external test location must fail for Storage, Cosmos DB, App Configuration and internal Container Apps
  2. Expected fix Keep backend Container Apps on internal ingress expose only the web entry point that users require.
    Verification Approved private workloads must continue to connect through private endpoints and private DNS
  3. Expected fix Configure private DNS and network rules so approved workloads use the private paths
    Verification Only the intended web entry point may remain publicly reachable
  4. Expected fix Deny unnecessary outbound traffic from application workloads
    Verification An unapproved outbound destination must fail at the network boundary
  5. Expected fix Give every required public exception a named owner, narrow scope, documented purpose and expiry condition
    Verification Every permitted public exception must show an owner, purpose, narrow scope and expiry date
  6. Expected fix Use deployment policy to prevent an expired or unapproved public path from returning
    Verification Deployment policy must reject an expired or unapproved public path

Related illustrative findings: workload identity scope; untrusted worker destinations.