Private Link Doesn’t Stop Exfiltration. It Just Changes the Route

Tue, 16 Jun 2026 00:00:00 +1000

You can disable public network access, tighten internet egress, and still leave a perfectly usable path for data to leave the workload.

That is the trap with Private Link. It reduces one kind of exposure while making another kind of path feel safe by default. Once a service is reachable over a Private Endpoint, it starts behaving like trusted internal plumbing. In a lot of estates, that trust arrives long before anybody has defined whether the path should exist, who should own it, or how broadly it should resolve.

That is why this post treats Private Endpoints as part of the internal attack surface, not as a security boundary.

The practical question is not whether the traffic stays private.

It is whether the trust relationship created by that private path is explicit, constrained, and observable enough to rely on.

The Mental Model

The common assumption is familiar:

“If the service has no public endpoint and is only reachable over Private Endpoint, then exfiltration risk is largely removed.”

That sounds neat on a slide. It breaks in real estates.

Private Endpoint does not mean data cannot leave. It means data can leave through a path that now looks internal, often carries less scrutiny, and is easier to describe as “approved” without proving what that approval actually covers.

The more useful mental model is this:

A Private Endpoint is a trust edge.

It is not just a private IP for a platform service. It is a decision to make a managed service reachable from a specific network context under a specific name-resolution model, with all the downstream service behaviour and authorisation complexity that implies.

That should change how you design, deploy, and operate. You should review a new Private Endpoint the way you would review any new trust relationship, not the way you would review a harmless network attachment.

How It Really Works

Private Link gives your workload a private network path to a supported Azure platform service. DNS resolution typically steers the client to the Private Endpoint IP, and the Azure fabric carries the traffic to the target service.

That changes the shape of the path, but not the need to govern it.

A Private Endpoint by itself does not grant meaningful data access. The service behind it still enforces its own authentication and authorisation model. That matters, because the real exfiltration risk appears when three things combine:

private reachability
broad or inherited name resolution
service permissions that allow data use, storage, or onward movement

That combination is where an unexamined data path emerges.

So the real issue is not “Private Link secretly bypasses all security”. It does not.

The issue is that many teams govern the endpoint object, but not the trust relationship around it:

which workloads can resolve the name
which subnets can reach the interface
which identities can use the service meaningfully
which service instance sits behind the endpoint
which downstream service behaviours are now in scope

That is the operational gap. The platform gives you private transport. It does not tell you whether the resulting path should be trusted.

A lot of Azure estates now have strong language around “no public access” and “private-only service consumption”. Both can be sensible controls. But they often create an unhelpful shortcut in architecture reviews:

public endpoint disabled
Private Endpoint deployed
issue considered solved

It is not solved. It has moved.

If a workload can privately reach a storage account, database, or messaging service and has the service-level permissions to use it, then you already have a sanctioned outbound data path. The fact that the packet did not hit the public internet does not make that path harmless.

This is where the trust-edge model matters. A Private Endpoint should not be assessed as “more secure networking” in the abstract. It should be assessed as a concrete relationship between:

a source workload
a resolution path
a destination service
a set of service permissions
a trust boundary

If one of those is undefined, the path is probably being trusted implicitly.

DNS Is Where Trust Quietly Expands

In many Azure estates, the most important policy decision behind a Private Endpoint is not the endpoint itself.

It is which networks are allowed to resolve the name.

This is one of the easiest places for accidental trust expansion to happen. A Private Endpoint may be created for one application or subnet, but the corresponding private DNS zone is often linked far more broadly than the original use case required. Once that happens, reachability stops being a narrow application decision and starts becoming a platform-wide convenience feature.

That changes something important operationally.

A service that was supposed to be privately reachable by one workload can become resolvable by many workloads. If network paths and service permissions also line up, you have quietly widened the set of systems that can use that service as a data path.

That is not a DNS hygiene problem. It is an architecture problem with DNS symptoms.

A Typical Exfiltration Pattern Without the Hype

We do not need to get into malware behaviour or offensive detail to see the design issue.

A common pattern looks like this:

an application subnet can resolve a private service name
the subnet can reach the Private Endpoint
the workload has valid service credentials or managed identity access
the destination service is treated as inherently safe because it has no public endpoint
the path is not reviewed as an outbound trust relationship

At that point, the environment has not eliminated outbound data movement. It has created a low-friction private route for it.

The most common examples are not exotic:

Private storage as an internal sink

A private-only storage account can become an internal drop location simply because it is reachable, resolvable, and writable from more places than intended.

East-adjacent movement across landing zones

A workload in one application trust zone may be able to write data to a private service hosted in another platform, subscription, or spoke. The traffic stays private, but the trust boundary crossing is real.

Service-mediated onward movement

The first hop may be private, but once data lands in the service, downstream platform behaviours matter. Export, replication, integration, or secondary consumers may extend the effective data path well beyond the source workload’s original boundary.

The mistake is not using these services. The mistake is reviewing only the transport path and ignoring what the service is now allowed to do in the broader design.

Visualising the Problem

flowchart LR A[Source workload] --> B[Private DNS resolution] B --> C[Private Endpoint] C --> D[Azure PaaS service] D --> E[Data written or staged] D --> F[Service-side downstream behaviour] D --> G[Consumer in another trust zone] H[Shared DNS zone links] --> B I[Service permissions] --> D style C fill:#d9edf7,stroke:#31708f style D fill:#fcf8e3,stroke:#8a6d3b style E fill:#f2dede,stroke:#a94442 style F fill:#f2dede,stroke:#a94442 style G fill:#f2dede,stroke:#a94442 style H fill:#f5f5f5,stroke:#666666 style I fill:#f5f5f5,stroke:#666666

The useful takeaway here is that the Private Endpoint is not the whole story. The meaningful risk sits in the combination of resolution scope, network reachability, service authorisation, and downstream service behaviour.

Disabling public access is often the right move. It removes a class of exposure cleanly.

But there is a difference between reducing exposure and controlling data paths.

“No public endpoint” can create false confidence because it sounds like a complete answer. In practice, it often just shifts scrutiny away from the remaining path. The service is now considered private, the traffic looks internal, and the path gets less attention precisely because it appears more controlled.

That is how unmanaged trust grows in mature environments:

the path is real
the path is approved in principle
the scope of that approval is unclear
visibility is fragmented
ownership is diluted across networking, platform, and application teams

The end state is not a dramatic security failure. It is something more common and more dangerous: a private data path that nobody is actively governing.

How This Changes Design, Deployment, and Operations

This is the practical anchor.

Design

Treat each Private Endpoint as a trust-edge decision.

Do not stop at “the app needs private access to Storage”. Define:

which workload needs it
which exact service instance it should reach
which networks should resolve the name
which trust boundaries are being crossed
which downstream service behaviours are acceptable
which cases are explicitly out of scope

That changes design because you stop modelling Private Endpoints as generic network plumbing and start modelling them as approved service relationships.

Deployment

Treat creation of a Private Endpoint as introduction of a new sanctioned private data path.

That means the deployment is not complete when the resource exists. It is complete when the trust conditions around it are also understood:

source scope
DNS scope
destination ownership
expected service use
reviewability

If those are missing, the deployment is technically correct but architecturally incomplete.

Operations

Review Private Endpoints the way you would review long-lived firewall rules or peering relationships: as objects that outlast the project that created them.

That changes operations because your questions become sharper:

which workloads can resolve this service name today
which trust zones can reach this endpoint now
does the destination still have a valid owner
would anybody notice if a workload started using this path differently
does the current DNS linkage still match the original design intent

That is far more useful than simply counting how many Private Endpoints exist.

Governance Query Example

For this kind of article, deployment syntax is not the interesting artefact. The harder problem is whether the estate can identify Private Endpoints that have become unmanaged trust relationships.

A governance-oriented query is more useful than a create example because it tests whether your environment can answer basic architectural questions at scale.

The Azure Resource Graph query below looks for Private Endpoints and surfaces signals that deserve review:

missing ownership tags
missing business-purpose tags
the subnet hosting the endpoint
the target resource behind the connection

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


resources
| where type =~ 'microsoft.network/privateendpoints'
| extend peSubnetId = tostring(properties.subnet.id)
| extend connections = properties.privateLinkServiceConnections
| mv-expand conn = connections
| extend targetResourceId = tostring(conn.properties.privateLinkServiceId)
| project
 subscriptionId,
 resourceGroup,
 privateEndpoint = name,
 location,
 peSubnetId,
 targetResourceId,
 owner = tostring(tags.Owner),
 businessPurpose = tostring(tags.BusinessPurpose)
| extend ownerState = iif(isempty(owner), 'Missing', 'Present')
| extend purposeState = iif(isempty(businessPurpose), 'Missing', 'Present')
| order by ownerState desc, purposeState desc, subscriptionId asc

This does not prove exfiltration risk by itself, and it should not be oversold. What it does show is whether your estate can identify private service paths that lack even basic ownership and intent metadata.

That matters because unmanaged trust tends to appear before confirmed misuse does.

If your platform team cannot quickly answer who owns a Private Endpoint, why it exists, and which service it reaches, then your “private-only” posture is probably carrying more implicit trust than you think.

Indicators That the Data Path Is Being Trusted Implicitly

These are the signs I would look for in a real environment.

Private DNS zone links are broader than the application need

This is one of the strongest indicators that convenience has overtaken design intent.

Private Endpoints exist without clear ownership metadata

If the object is live but nobody clearly owns the path, it is already under-governed.

Shared services are reachable across multiple trust zones by default

That may be intentional, but it should be visible and explicitly defended, not inherited silently.

Architecture documents describe “private access” but not “approved data destinations”

That wording usually means the transport decision was reviewed but the data-path decision was not.

Public access is disabled and that is treated as the end of the conversation

This is the most common mental shortcut. It reduces one risk and masks another.

Gotchas & Edge Cases

Private reachability is not the same as authorised use

A workload still needs valid service-level permissions. The risk comes from the combination of path and permission, not from private transport alone.

DNS scope can widen faster than endpoint deployment

You can accidentally expand reachability through name resolution changes without creating any new Private Endpoint resources.

Cross-subscription does not mean cross-trust is understood

Administrative boundaries are not the same as trust boundaries. A private path into another team’s service is still a trust decision even if it lives inside the same tenant.

Service subresources matter

Different subresources can expose materially different capabilities. Reviewing access only at the service label level is often too coarse.

Best Practices

1. Review Private Endpoints as trust edges

Make this the default posture. If a new endpoint creates a new path to a managed service, it deserves trust-boundary review.

2. Keep DNS scope as narrow as the use case

Private resolution should be deliberate. Broad inherited zone links are one of the easiest ways to create accidental trust expansion.

3. Separate transport approval from data-path approval

A service being reachable privately does not automatically make it an approved destination for sensitive or high-value data.

4. Require ownership and business purpose for every Private Endpoint

If the relationship matters, it should be attributable. If it is not attributable, it should not be trusted by default.

5. Review by trust boundary, not just by subscription or VNet

The real question is who can now reach which service under which name and permissions, not which administrative container the resource lives in.

6. Assume private PaaS traffic is under-observed until proven otherwise

Do not assume your visibility model kept up with your connectivity model.

🍺

Brewed Insight: Private Link is very good at removing public exposure. That is exactly why it can hide bad assumptions so well. If the service is private, broadly resolvable, and meaningfully usable, then you do not have “no exfiltration path”. You have a trusted one.

Data Exfiltration on Brewed in the Cloud by Chris Hailes