Skip to main content

How zero trust access works

Customer Connect's security model is deny-by-default and identity-first. Two connectors can't communicate until you write an explicit policy linking them. There is no implicit trust based on network location, IP address, or firewall zone, and there's no path for lateral movement.

This page explains how that works in practice and why the building blocks are arranged the way they are.

The mental model​

Customer Connect organizes infrastructure into a small hierarchy:

A provider owns one or more customers. Each customer has locations. At each location run connectors, and each connector publishes one or more applications. Communication between connectors only happens when an access policy explicitly allows it (that's the dashed link in the diagram).

For the full vocabulary, see Key concepts.

What happens when a request reaches the network​

An access policy is not a configuration that runs after traffic; the policy decision happens before a single byte moves on the overlay.

If no access policy's rules match the requested source/destination pair, the request is denied. There is no "open by default" tier. Adding a new connector doesn't grant it any reachability until a policy includes it.

Why this prevents the common failure modes​

  • No lateral movement. Compromising a connector doesn't expose its peers. The compromised connector can only reach destinations the access policies already named, and you can shrink that set by editing or excluding from rules at any time.
  • No reliance on network position. Identity, not IP address, decides access. Moving a connector between clouds or behind a NAT doesn't change what it can reach; only its policies do.
  • No inbound exposure required. Connectors initiate outbound connections to the overlay. You don't have to open inbound firewall ports or assign public IPs for traffic to flow.

How the rule model expresses this​

An access policy's source and destination sides each carry a match rule: by connector model, by location, or by specific connectors, with optional exclusions that subtract from the matched set. This is how you express intent like:

  • "Every connector built from the internal-services model can reach every connector at the AWS us-east-1 location, except the staging-only ones."

The builder expands the rule into the concrete source/destination connector pairs before you save, so you see exactly which pairs the policy will authorize. See Build access policies for the workflow.

Scopes (provider vs customer)​

The same model applies at two levels of visibility:

  • A provider admin sees and can author policies across every customer's resources.
  • A customer admin sees only their own customer's resources and can only author policies within that scope.

This keeps multi-tenant blast radius contained: a customer admin cannot accidentally grant access across customer boundaries, and a provider admin can preview any customer's experience via the View as customer toggle without leaving the provider context.

What's next​