Private Access with Explicit Egress and Exfiltration Guardrails

Thu, 12 Nov 2026 00:00:00 +1100

The application reads from private Storage. The dependency works, the endpoint has a private address, and the public-access setting has been reviewed.

One question is still unanswered: where else can this workload write?

The earlier Private Link exfiltration article explains why private access is still a trust relationship. Here we put that argument to work: constrain one unwanted destination operation without breaking the approved dependency.

I would test both sides of that decision. Can the workload still read where it should? Can it still write where it should not? “Private-only” does not answer either question on its own.

The Mental Model

A destination-bound operation needs more context than a private IP.

Name the service instance and operation first. Then record the subresource, resolver, route and principal that make it work. “Access to Storage” is too broad to test usefully.

For the illustrative exercise, account A holds synthetic objects the application should read. Account B is another author-owned destination the application should not write to. Both use Blob on supported general-purpose v2 Storage accounts. That gives us a safe comparison without sending data to a third party.

flowchart LR W[Application workload] --> D[Source DNS context] D --> A[Approved Blob endpoint] D --> B[Controlled unapproved endpoint] I[Effective service authority] --> A I --> B C[Network and service controls] --> T[Repeatable operation tests] A --> T B --> T T --> R[Residual and recovery record]

Keep the conclusion as specific as the test: this source, this identity, these operations and destinations. The exercise cannot establish that no data can leave the organization.

How It Really Works

Preserve the service name and inspect resolution

Microsoft documents that Storage applications keep the normal service connection string and authorization mechanisms when using Private Endpoints. Do not replace the application endpoint with the privatelink subdomain as a shortcut.

From the source workload, inspect the normal Blob name and TCP reachability:

1
2
3
4
5


$account = "<approved-lab-storage-account>"
$serviceName = "$account.blob.core.windows.net"
Resolve-DnsName -Name $serviceName -ErrorAction Stop
Test-NetConnection -ComputerName $serviceName -Port 443 `
 -InformationLevel Detailed

The checks explain resolution and TCP connectivity; they do not authenticate to Storage or perform the data operation. Inspect TcpTestSucceeded explicitly and retain the resolver context and timestamp. If DNS fails, investigate it. Substituting a cached address would change the experiment while hiding the failure.

Repeat resolution for B and the separately approved recovery context. A central resolver may make the name visible to more workloads than intended. That is worth investigating, but a resolvable name is not yet a writable destination.

Separate public and private access

Creating a Storage Private Endpoint does not automatically block the public endpoint. Microsoft’s documentation treats public endpoint access controls separately; the Storage firewall governs public access rather than granting the private path’s data permission.

Inspect actual public network settings and authorized private connection state. Test the public endpoint from a separately declared public context, not from a resolver that transparently sends the same hostname to a private IP.

NSP does not turn this into a universal private-operation boundary. Current documentation allows Private Endpoint traffic without explicit NSP access rules. Similarly, AVNM documentation states security admin rules do not apply to Private Endpoints. Choose and verify the relevant supported source/path controls instead of assuming either product closes the private path.

Test the operation the finding represents

Use a precreated synthetic object and the declared workload test principal for an approved read. If the unintended consequence is a write, baseline and post-change tests must actually exercise a harmless synthetic write against B, not substitute a TCP check.

The draft toolkit’s controlled-egress module provides the worksheet:

Case	Intended post-change result	Evidence to retain
Workload reads synthetic object from A	Success	Principal, request ID, service result, resolver and path context
Workload writes synthetic object to B	Rejected at the chosen boundary	Service/network error and corroborating control evidence
Declared public context accesses protected endpoint	Result matches public-access claim	Public resolution, source context and service result
Source sends telemetry and permits authorized recovery access	Success	Ingestion/access evidence, not only configuration
Approved downstream service behavior	Explicitly allowed or out of scope	Owner, operation and residual-risk statement

If B was not reachable and writable before the change, the test cannot demonstrate removal of that operation. It can establish a current boundary only within the declared conditions.

Real-World Impact

The review can now move past “Private Endpoint deployed.” The engineer has two results to defend: the dependency survived, and the unwanted operation was constrained.

Choose which layer should reject the operation

If the workload never needs authority over B, removing its data permission may be a direct remediation. If many identities can reach an unwanted destination set, supported network restrictions might also reduce opportunity.

Using both layers may be sensible. Just keep their claims separate. A network failure cannot tell you whether the role change worked, and an authorization denial cannot tell you whether traffic followed the inspection route. Otherwise the team can approve two changes using evidence for only one.

Pay for the constraint you can operate

Central egress inspection, narrower DNS links and destination inventories create ongoing work. TLS inspection can add certificate and troubleshooting overhead. Destination-specific permissions can increase application onboarding effort.

I would accept those costs where they constrain a high-consequence path. I would not hide them behind “private is more secure.” The owner needs to know what happens when a destination changes, a certificate expires or the application acquires another dependency.

Gotchas and Edge Cases

A failed request is tempting evidence when you want the fix to be finished. These cases are the reason to ask one more question before accepting it.

A timeout can mimic containment

Broken DNS, routing, credentials or a stopped destination can all produce a failed operation. Require the approved positive control and control-attributed rejection before claiming a deliberate path break.

Storage subresources are not interchangeable

Blob, DFS, Files and other service endpoints have different requirements. Microsoft documents that Data Lake Storage operations can require both DFS and Blob endpoints. This illustrative exercise is Blob-only; expanding it requires a revised test matrix and current service documentation.

Service-side movement can extend the boundary

An approved write can feed replication, export or a downstream consumer. Do not infer that a workload egress control constrains every subsequent service-side operation. Record the onward behavior as allowed, constrained, unknown or explicitly outside the test.

Recovery can use another path

A responder may need a different source, principal or regional dependency. Test the actual authorized recovery operation separately. A diagram that preserves a management arrow is not evidence that responders can use it.

Best Practices

Start with a small destination/operation matrix. Keep source, principal and resolver comparable between baseline and post-change tests, use fresh sessions, and record any deliberate differences.

Assumptions and evidence boundary

The exercise uses synthetic data and author-owned destinations; it has not been run as an Azure lab. Before execution, record the supported Storage account and Blob subresource; actual Azure cloud/region; DNS resolver and zone-link model; Private Endpoint network-policy/routing configuration if path filtering is used; public-access settings; Firewall tier/rule schema where applicable; CLI and service API versions; scoped data permissions; and available diagnostic categories/tables. ARM read access is not permission to perform the data test.

Keep resource configuration, documented behavior and observed operation results in separate evidence fields. That lets the reviewer see what the platform promises and what the test actually established.

I would not approve the blocked write if the same change breaks the approved read, telemetry or recovery operation. Stop rollout when a required positive control fails. If rollback reopens B, record that residual plainly: service restored, remediation unfinished.

🍺

Brewed Insight: Private-access assurance is destination and operation assurance. Prove what still works, what no longer works, and what happens after the first service accepts the data.

Egress on Brewed in the Cloud by Chris Hailes