As we have been building the Zero Trust platform at ScaleFT, we’ve kept a clean delineation between our control plane and our data plane. The data plane for our Zero Trust architecture is called the Access Fabric. The Access Fabric provides the core dataflow for authentication, authorization, and user sessions in ScaleFT.
The building blocks for Zero Trust start with making every session authenticated, authorized, and encrypted; consequently, support for these properties must be built in at an architectural level. All of these building blocks must be flexible as future factors and requirements change.
It’s a truism that to deliver security in the real world, you have to make it feel good, because if it feels bad, people will circumvent it. This means performance cannot be significantly impacted – in fact, it would be best to make the user experience even faster and less painful! While the control plane, our configuration API, is primarily used by administrators for configuration, the Access Fabric is the primary point of interaction we have with the users of ScaleFT, making it a crucial touch point for our user experience.
The facts behind authentication and authorization decisions are required by the data plane to make real time decisions. If an employee of a global organization is hired (or fired) in London, then, to make the correct authorization decision in Macau, the truths about the employee’s status, devices and roles must be present and consistent in Macau. From a security perspective, the consistency and availability of this data is of paramount importance. The requirement for high performance is fundamentally driven by the need for a fantastic user experience.
This means our Access Fabric is a globally distributed, low latency, authentication, authorization, encryption and connection broker engine. In a Zero Trust architecture these features can be provided by a single component, but in a legacy world, companies address these needs with some combination of a VPN, a CDN, a real time IPS and Active Directory.
Inside the ScaleFT Access Fabric
The inputs to the Access Fabric – device state, user attributes, session data, and access policies, are collected from various sources (the ScaleFT Platform, users’ laptops, a company’s Identity Provider, information from the access attempt itself), and then streamed in real-time into Authorization Engines that are distributed globally.
Similar to how traditional CDNs have points of presence, we distribute Access Fabric clusters across the world. In a traditional IT deployment, the user connecting to a VPN is not only entering a trusted network perimeter, but they are often connecting to a geographically distant point, which introduces unnecessary latency. Traditional centralized architectures are not only less secure, but they have poor performance properties.
The Access Gateway allows the Access Fabric to act as an intermediary between a User, their Device, and the Resource they are accessing. In ScaleFT, we use the identity of the machine and the user to authenticate a session. The facts about the user, device, and session are evaluated in accordance with one or more Access Policies associated with the target resource in order to produce an authorization decision.
If permitted, the client’s requests are forwarded to the destination. The Access Gateway component has the capacity to terminate HTTPS from a Client with modern TLS 1.2 ciphers. OIDC is used for authentication against the ScaleFT Platform, providing a stable API that abstracts over the identity provider complexity which can explode out to SAML, OpenID, Okta, and many others. To provide Authorization, the Access Gateway communicates with our Authorization Engine, using gRPC, to obtain a fast-expiring JWT attesting to a recent re-authorization decision. Even with expirations of only a few minutes, we also provide a mechanism to immediately invalidate previous authentication or authorization decisions. This is a streaming push mechanism, whose purpose is to improve upon the baseline multi-minute authorization expiration interval, allowing instantaneous revocation of sessions as soon as anything changes that should invalidate a user’s access.
If access is denied, the user is redirected to the Remediation Helper. This service translates the reason for denying a request into a human understandable message. Similar to Netflix’s Stethoscope project, we believe in user focused security, where education and culture is a critical component of security. Many factors which can cause access to be denied are correctable: a user can enable disk encryption, enable a host firewall, or apply important OS patches. The Remediation Helper exists to guide users through the specific workflows required to address these correctable factors.
Our team has been working hard to build these components, but they wouldn’t be possible without leveraging many open source projects. The three with the biggest impact on our architecture and development flow are Apache Kafka, the Go programing language, and gRPC.
The semantics of Apache Kafka provide a correct model for replicating streams of facts in a highly available, low latency way. We use Kafka topics to model the current state of polices and updates to those policies are correctly ordered and reduced with low latency.
Go’s surprising fitness for both client and server applications has allowed us to share common business logic around multiple highly distinct components and platforms. Despite some challenges with dependency management for large scale repositories, the productivity and battery-included attitude has made Go an indispensable member of our team.
gRPC is the youngest technology we built on top of, but it has quickly matured. The clear definition of services has helped our team collaborate with clear boundaries as our architecture (and “microservices”) has evolved
It’s been a long road to get here – we’ve been working on ScaleFT for more than 2 years. Many components of the Access Fabric have been in place for almost that long. Many of the technologies we are using were much less mature 2 years ago, but now provide a strong and stable core for our product. .
The Big Picture
The ScaleFT Access Fabric implements Zero Trust in a globally distributed way, solving structurally for the challenges of real time changes to user facts and policies. More is required within an organization to deploy Zero Trust, from software components such as device management and specific protocol integrations, to organizational concerns such as policy administration and even executive sponsorship.
In the details, everyone might deploy Zero Trust differently, but we believe in certain key mandates. You have to be globally distributed. You have to do this in real time. You have to support legacy tools, protocols, and workflows. User success is critical. We look at Google’s story of their journey to BeyondCorp as an outline of how one especially powerful and large company might do this. ScaleFT exists to provide a path to this architecture for everyone else.