A huge number of Internet-accessible systems are protected by the principle of connect, then authenticate. This includes VPNs, web applications, databases, Windows Servers with RDP endpoints exposed, and more.
Having a “private” system which is publicly-accessible means that connecting parties must connect before they can authenticate, an approach which means your private system is one phishing email, brute-force attempt or zero-day vulnerability away from being breached.
Enclave is a new way to protect private systems. It reverses the connect-then-authenticate paradigm to cloak private systems so they are invisible to the public Internet, with entirely closed ingress firewalls, and discoverable only by other systems which have first authenticated and met the specific trust requirements for access. To anyone else, your private systems simply don’t exist.
Zero trust, zero fuss
Let’s face it, zero trust is complicated, even to get started on the journey.
One of the goals of Enclave is to let you quickly create private connectivity without needing to expose anything on the public Internet, where the rules of who can talk to what, when, and for how long are defined entirely by policies based on business rules.
We believe Administrators shouldn’t have to understand access control lists or network security groups on the firewalls (no open ports, they can stay closed), and no more managing IP addresses, proxies, routers, switches, NAT or secret keys.
For example, Administrators can define an Enclave policy similar to “devs can access the test environment”, and Enclave takes care of the rest, regardless of what physical network the developer is on, and whether the test environment is on-prem, in the cloud, or an IoT device.
Enclave groups systems using “tags”; e.g. “devs”, “test-environment”, “server”, “payroll”, and so on; you can use whatever tags you like that best represent your business or security categories.
Tags are then combined into Policies to define access and connectivity. Enclave is default-deny, so Administrators can effortlessly craft precision access across the organisation regardless of what network each system is on, without needing to install appliances or proxy servers or opening firewall ports to the Internet.
Organisations are more than their perimeter
Applying perimeter-based solutions like VPN and Software Defined Perimeter (SDP) only addresses part of an organisation’s complexity; specifically remote access, the north-south traffic pattern. Once remote access traffic has arrived at the perimeter, the internal network can still be a complex web of tooling and configuration that tries to segment and route network traffic to its intended destination, which often then tends to cross to the east-west traffic pattern inside the organisation, and can often be several more firewall and VPN hops away from the original entry point.
With Enclave, stop thinking about network perimeters, or this office network and that cloud environment. By defining a Zero Trust Overlay Network using Enclave, segmented however you wish, the distinction between north-south and east-west traffic patterns, location and bearer all become completely irrelevant, transforming the network from a blocker to an agile and dynamic enabler.
With Enclave, you define what connectivity you want, rather than how that connectivity happens. We take care of the rest.
Direct, encrypted, universal connectivity
Solutions like VPNs and SDP inevitably route your traffic eventually through some form of concentrator, so you end up being limited by the capacity of that component, both in terms of available bandwidth, and how many users it can handle at any given moment.
Enclave creates fully audited peer-to-peer and end-to-end encrypted tunnels (to which we never hold the private keys, so we have no access to the data) and so is able to always utilise the best network route and all available network capacity between two points, without any bottlenecks.
Enclave is deployed as agent-based software on user devices or servers, and adds a new network adapter to transparently create the Enclave Zero Trust Overlay Network. To applications and software on the device, Enclave is simply another network which can route web, RDP, SSH, database, SMB, and any other protocol that runs on top of IP, forming an entirely private network with universal protocol support.
Example use case 1 – Secure access for developers to development environments
Developers often need access to development environments hosted in the office, the company cloud environment, or a testing lab. Getting developers appropriate (and secure) access can be complicated, and slow down development while they wait.
With Enclave, install the Enclave Agent on the developer’s machine, and on any systems they need access to (without any other network changes); whether that’s a MSSQL database server running on Windows, a pod in a Kubernetes cluster running on EKS, or an IoT Raspberry Pi plugged into a sensor in the office.
Tag each system appropriately, then define the policy in Enclave that your users need, e.g. `developers` can access `test-db`, and that’s it, they can get on with their work.
When the developer access is no longer needed, or they shouldn’t have that access anymore, just disable the policy and the access is instantly terminated.
Example use case 2 – Multi-cloud connectivity
If you have to interoperate between systems sitting in both AWS and Azure (for example), at the moment you probably have to navigate the myriad of (expensive) ways to set up private connectivity between VPCs in different clouds.
Why bother? If you stop worrying about the boundaries between clouds, and treat everything as a single Enclave Network, you don’t need any other glue to securely and privately connect multi-cloud or multi-region resources together.
Simply install the Enclave Agent on your systems in AWS and Azure, define the policies in the Enclave Portal (or via our Terraform provider) and those systems will feel like they’re sitting in the same VPC.