CH08-04: Data Access, Private Endpoints, and Secrets

Goal

The previous sections brought traffic to the application and chose a runtime for the web or API layer. Now the runtime needs to reach data: subscription records, documents, user preferences, sessions, payments, configuration, certificates, and other dependencies.

This is where many designs become risky. A connection string is not a data access architecture. Secure data access combines identity, authorization, secret handling, network reachability, DNS, logging, and operational ownership.

The durable idea is:

Data access in a web architecture is a security and operations design, not only a connection string.

The Short Version

A web application usually needs one or more data services. A customer portal may use Azure SQL Database for relational subscription records, Azure Blob Storage for uploaded documents, and Key Vault for secrets, keys, or certificates.

The architecture should answer:

• Which identity does the application use when it calls Azure services?

• Which permissions does that identity receive?

• Which values must be treated as secrets?

• Which dependencies can be reached publicly, and which should be reachable only through private networking?

• Which private DNS records are required for private endpoint access?

• Which logs show successful access, denied access, suspicious access, and dependency failure?

Private endpoints are important, but they are only one part of the design. A private endpoint gives a supported Azure service a private IP address in a virtual network, so traffic can reach that service through private network paths. It does not prove the caller is allowed to read customer data. Authorization still matters.

The Secure Access Path

Think of data access as a path with identity and network controls working together:

flowchart LR
    R["Web/API runtime<br/><small>App Service or Container Apps</small>"]
    I["Managed identity<br/><small>Workload identity in Entra ID</small>"]
    K["Key Vault<br/><small>Secrets, keys, certificates</small>"]
    P["Private endpoint<br/><small>Private IP for Azure service</small>"]
    DNS["Private DNS<br/><small>Name resolves to private IP</small>"]
    D["Data service<br/><small>Azure SQL or Storage</small>"]
    L["Logs & alerts"]

    R --> I
    I --> K
    R --> DNS --> P --> D
    I --> D
    K --> L
    D --> L

This diagram separates two ideas that are often blended together:

• Identity decides who or what the application is when it calls a service.

• Network reachability decides which network path can reach the service endpoint.

A strong design usually needs both.

Managed Identities

A managed identity gives an Azure resource an identity in Microsoft Entra ID. Instead of storing a password or client secret inside the application, the application can use its managed identity to request access to supported Azure resources.

For a web application, this can reduce credential risk. The application can authenticate as itself when reading from Key Vault, accessing Storage, or calling other Azure services that support identity-based access.

Managed identity does not mean "allow everything." The identity still needs carefully scoped permissions. If the application only needs to read one secret, it should not receive broad administrative access. If it only needs to read from a storage container, it should not receive account-wide ownership unless there is a clear reason.

Key Vault and Secret Handling

Key Vault is Azure's service for centrally managing secrets, keys, and certificates. In web application architecture, it is commonly used for values that should not be hard-coded into application code or casually copied into deployment scripts.

Examples include:

• Database credentials when identity-based access is not available or not yet adopted.

• API keys for external providers.

• Certificates used by the application.

• Encryption keys or signing keys where the design requires centralized key management.

Application settings can reference configuration values, but secrets need lifecycle design. Ask who can read them, who can rotate them, how rotation is tested, how access is logged, and what happens when a secret is exposed.

The best secret is often the one you do not store. Managed identity can remove many stored credentials from the application path.

Private Endpoints and Private DNS

A private endpoint maps a supported Azure service to a private IP address inside a virtual network. This is useful when a database, storage account, or vault should not be exposed through public network paths.

Private endpoints usually introduce a DNS responsibility. The application still calls a service name such as a database or storage endpoint. With private DNS configured correctly, that name resolves to the private IP address instead of the public endpoint.

If private DNS is missing or misconfigured, the application may fail to connect, or worse, may accidentally use a public path when the design expected private access.

Private access also does not replace service authorization. A database still needs authentication, users or roles, firewall rules or network controls, auditing, and application-level authorization. Blob Storage still needs proper access control, container permissions, and logging. Key Vault still needs access control and monitoring.

Data Access Responsibility Map

The exact service configuration changes by dependency. The model stays consistent.

Example: Portal to Azure SQL

Imagine the customer portal from earlier. The web API runs on App Service and stores subscription data in Azure SQL Database. The team wants the database reachable only through private access from the workload network.

A first-pass access model might be:

App Service API
  -> Uses managed identity where supported
  -> Reads required secret or certificate from Key Vault
  -> Connects to Azure SQL through private endpoint
  -> Resolves database name through private DNS
  -> Emits dependency failures and authentication failures to monitoring

This design still needs details. The team must configure virtual network integration for the runtime where required, create the private endpoint, configure private DNS, restrict public network access according to the policy, assign least-privilege database access, and monitor failed logins and dependency latency.

The important point is that the data path is intentional. The application is not simply carrying a connection string and hoping the network is safe.

Common Mistakes

• Storing secrets in application settings without rotation, ownership, or access review.

• Adding private endpoints but forgetting private DNS.

• Assuming private network access replaces least privilege, database permissions, or application authorization.

• Giving the application identity broad owner-level permissions because it is convenient during development.

• Locking down public access before confirming the runtime has the private network path it needs.

• Monitoring application logs but ignoring data-service audit logs and denied access events.

If Someone Asks You

How should an Azure web application connect to data services securely?

A good answer is:

I design data access as an identity, network, secret, and monitoring path. The web runtime should use a managed identity where possible, store unavoidable secrets in Key Vault, use least-privilege authorization on the data service, use private endpoints and private DNS when the dependency should avoid public exposure, and emit logs and alerts for access failures, dependency latency, and suspicious activity. Private access helps, but it does not replace authorization.

What You Should Remember

Secure data access combines identity, authorization, secret handling, private reachability, DNS, and logs.

Questions to Check Your Understanding

1. What problem does managed identity reduce?

2. Why does private DNS matter with private endpoints?

3. What does private access not solve by itself?

4. Why should data-service logs be part of the web architecture?