Data Access, Private Connectivity, and Secrets

Goal

The previous sections brought the request to a runtime. The runtime still needs to reach data, APIs, caches, storage, identity providers, and configuration. This is where web designs often become risky because a connection string can look like a data access plan.

It is not.

The durable idea is:

A web request is only as safe as the data and secret paths behind it.

The Short Version

Secure data access combines identity, authorization, network reachability, name resolution, secret handling, logging, and operational ownership.

A web application may depend on:

• relational databases;

• document databases;

• caches;

• object storage;

• search indexes;

• identity providers;

• internal APIs;

• payment, notification, or partner systems;

• secret and configuration stores.

Each dependency should be visible in the architecture because it affects latency, security, failure behavior, cost, and blast radius.

The Safe Access Path

Use this provider-neutral model:

Web runtime
  -> Workload identity
  -> Secret/config provider
  -> Private or controlled network path
  -> Data/API dependency

The model separates several responsibilities that are often blended together:

Private connectivity can reduce exposure, but it does not replace authorization. A private path says something about where traffic can travel. It does not prove the caller should be allowed to read or change data.

Data Dependencies on the Request Path

Not every data dependency has the same importance.

For a storefront, product details may be required to render a product page. Personalized recommendations may be useful but optional. Cart state may be required for checkout. Analytics writes may be able to happen after the response. A payment authorization may be required before confirming an order. A notification template may not be required before returning the order confirmation.

Classify dependencies by request impact:

This keeps the request path honest. It also helps the team avoid making user experience depend on every back-office or analytics system.

Secrets and Configuration

Secrets are values that should not be casually stored in source code, build logs, deployment scripts, or broad application configuration. Examples include passwords, API keys, certificates, signing keys, tokens, and some connection strings.

A good secret design answers:

• Where is the secret stored?

• Who or what can read it?

• How is access logged?

• How is rotation handled?

• What breaks when it changes?

• How is exposure detected and contained?

The best secret is often the one the application does not need to store. Workload identity can reduce the number of stored credentials by letting the runtime authenticate as itself to supported services.

Private Connectivity and DNS

Private connectivity is useful when a database, storage account, API, vault, or other dependency should not be broadly exposed through public network paths.

Private access adds responsibilities:

• network routing;

• subnet and endpoint placement;

• firewall or service access rules;

• DNS resolution;

• approval workflow where applicable;

• troubleshooting paths;

• monitoring of connection failures.

DNS deserves special attention. Applications usually call dependencies by name. If the name does not resolve to the expected private endpoint, the application may fail or use a path the design did not intend.

Private connectivity should therefore be treated as a designed access path, not just a checkbox.

Example: Storefront Data Access

A storefront might use several dependencies:

Web runtime
  -> Product catalog read model
  -> Cart store
  -> Customer profile API
  -> Payment session API
  -> Object storage for images and documents
  -> Secret/config provider

The product page may degrade if recommendations are unavailable, but it may not work if the catalog read model is unavailable. Checkout may need payment authorization before confirmation, but notification and analytics can continue later. Uploaded documents may need object storage immediately, but back-office review can happen asynchronously.

This gives the design a more precise reliability shape than "the app connects to a database."

Blast Radius

Data access choices affect blast radius. If the web runtime has broad write access to many data stores, one application bug or credential exposure can affect a large part of the system. If every dependency is public by default, network exposure grows. If one shared database holds unrelated domain data, a schema change or performance problem can affect many capabilities.

Limit blast radius by narrowing permissions, separating critical dependencies, making private access intentional, monitoring denied access, and keeping ownership clear.

Common Mistakes

• Putting credentials in application settings without lifecycle or rotation ownership.

• Making databases publicly reachable because it is simpler during development.

• Ignoring DNS and routing behavior for private access.

• Treating all data dependencies as equally critical to the user response.

• Assuming private connectivity replaces authentication and authorization.

• Hiding caches, search indexes, document storage, and external APIs behind a generic database box.

If Someone Asks You

What should I consider when connecting a web application to data services?

A good answer is:

Treat data access as an identity, authorization, network, secret, DNS, monitoring, and ownership path. Identify which dependencies are on the user request path, which can degrade, and which belong in follow-up flows. Use workload identity where possible, store unavoidable secrets in a controlled secret store, use private connectivity when exposure must be reduced, and monitor both access failures and dependency health.

What to Remember

Data access is part of the request path and part of the security boundary.

Questions to Check Your Understanding

1. Why should data dependencies be visible in the web architecture diagram?

2. What responsibilities come with private connectivity?

3. Why is secret handling part of architecture rather than only implementation?

4. Why does private access not replace authorization?