3a77b44a featured anyx admin conceptszero trust architecture

Zero trust architecture

CONTACT

Agilicus AnyX implements a zero trust architecture: no device, user, or network is trusted by default. Every access request is authenticated and authorised individually, regardless of where the request comes from.

The practical consequences for an administrator are:

  • your resources have no inbound ports and are not discoverable from the internet;
  • users are identified by who they are, not by where they connect from;
  • access decisions are made per request, against policy, in real time; and
  • every decision and every session is recorded for audit.

Theory of operation

The platform relies on a few moving parts:

  • a CNAME at your own domain that points at the Agilicus service, so the platform can serve content under a name you control;
  • connectors that run outbound from your site to the Agilicus cloud;
  • an identity-aware proxy in the cloud that terminates user sessions, applies policy, and forwards traffic over the outbound-only tunnel; and
  • identity providers that authenticate your users.
%%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "primaryColor": "#e8f1fb", "primaryBorderColor": "#1f4e79", "primaryTextColor": "#111111", "lineColor": "#4a4a4a", "secondaryColor": "#f5f5f5", "fontFamily": "Inter, sans-serif"}} }%%
flowchart LR
    subgraph Internet
        U[User]
        IDP[Identity provider<br/>Google, Microsoft, etc.]
    end
    subgraph Cloud["Agilicus cloud"]
        AP[Identity-aware proxy]
        AP2[Authorisation engine]
    end
    subgraph Site["Your site"]
        C[Connector]
        R1[Web application]
        R2[Database]
        R3[Desktop]
    end
    U -->|HTTPS via CNAME| AP
    U -->|sign in| IDP
    IDP -->|verification| AP
    AP --> AP2
    AP2 -->|allowed| C
    C -->|outbound-only tunnel| AP
    C --> R1
    C --> R2
    C --> R3

Notice the direction of the arrows: the connector reaches out to the cloud. Nothing reaches in. This is what removes the need for inbound port forwarding, port forwarding rules, and public internet exposure.

The CNAME and your domain

Your organisation is given a domain name (for example org.agilicus.com) and you point a CNAME record at it from a name you control. Users then access the platform and resources through that name. This matters because:

  • it gives you a stable, branded entry point;
  • TLS certificates are issued for your name;
  • the platform can host resources on subpaths of your domain; and
  • it lets you move the underlying infrastructure without changing the name users rely on.

Outbound-only connectors

A connector is a small piece of software installed on your side of the network (on a virtual machine, a container, a router, or an embedded device). It maintains one or more outbound connections to the Agilicus cloud. The cloud never initiates connections to you. This design means:

  • your firewalls do not need inbound rules for the platform;
  • resources behind the connector are invisible to the public internet; and
  • the connector works on almost any network, including carrier-grade network address translation.

See Connectors for deployment options and management.

The identity-aware proxy

The identity-aware proxy is the component in the cloud that:

  1. terminates the user’s HTTPS session;
  2. authenticates the user (directly or through an identity provider);
  3. enforces multi-factor authentication when policy requires it;
  4. evaluates authorisation for the specific resource being requested;
  5. applies any firewall and geolocation rules; and
  6. forwards the request to the correct connector, which reaches the resource.

Because each request passes through this proxy, the platform can apply per-user, per-resource policy and record exactly what happened.

%%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "primaryColor": "#e8f1fb", "primaryBorderColor": "#1f4e79", "primaryTextColor": "#111111", "lineColor": "#4a4a4a", "secondaryColor": "#f5f5f5", "fontFamily": "Inter, sans-serif"}} }%%
stateDiagram-v2
    [*] --> Authenticated: user signs in
    Authenticated --> Authorised: policy allows resource
    Authenticated --> Denied: policy denies resource
    Authorised --> Forwarded: routed to connector
    Forwarded --> Served: connector reaches resource
    Served --> Audit: request recorded
    Denied --> Audit: denial recorded
    Audit --> [*]

Security properties

  • Encryption in transit. All traffic uses HTTPS with TLS 1.3. Nothing is sent in the clear.
  • Identity over network. Access is granted to the person, not to the network segment they happen to be on.
  • Least privilege. You can grant read-only or very narrow access to a single application, down to a specific role within it.
  • No attack surface. With no inbound ports, there is nothing for an attacker to scan or connect to.
  • Full audit trail. Every request, decision, and session is logged and can be sent to your own log destination.

Further reading

Web guide