Zero Trust Architecture (ZTA) within LEXIS
The Classical approach to security
Lots of companies rely mostly on perimeter-based network security, building their network as a castle with defenses on the perimeter. However, this approach is not made to cope with current ways of working, if they involve – for example – remote connectivity or interfacing to cloud services. Such situations require opening access to internal resources/assets, and sooner or later are likely to allow an attacker to breach the perimeter and move on laterally.
LEXIS goes one step further
In the LEXIS project, we actively cope with the problem sketched above: The build-up of the LEXIS Cloud-HPC-Big Data platform has been accompanied by the development of a security concept following the “Security-By-Design” and “Zero-Trust” principles. A secure Zero-Trust Architecture (ZTA) has been implemented. This has an immediate impact on LEXIS data, compute, orchestration, portal and billing services, and also on the unified Identity and Access Management (IAM) solution within LEXIS. This solution, based on the Open-Source product “Keycloak”, is the most important component of the platform’s Authorisation and Authentication Infrastructure (LEXIS AAI). It allows for authentication based on tokens (following, e.g., the OpenID Connect standard).
ZTA concept and implementation in LEXIS services
The main idea of a Zero-Trust concept is to protect assets by minimizing access possibilities and by enforcing authentication and authorization for each access request. To give an easy example, services do not trust any other service or information source except the LEXIS AAI to check authorization for an actual access. Instead, all services verify the identity and permissions, talking to the IAM system with what they know about the user. Below, we focus on our unified, federated IAM/AAI solution and its relationships with the main LEXIS components, to showcase LEXIS as an example for how a Zero-Trust architecture can be implemented.
The figure illustrates these relationships. It indicates that all components such as LEXIS DDI, LEXIS Orchestration Infrastructure are communicating with the LEXIS AAI to:
- validate every access token (received, e.g., from another component) which contains the identity asking to act on or access a resource,
- check the component-specific permissions of such an identity, and to
- pass an access token to any other component they need to interact with.
The solution has been fine-tuned to allow any component to only retrieve directly relevant access permissions for an identity. As a concrete example, the LEXIS compute component checks the validity of an access token received through the API call (using an API call for token introspection), then it interacts with LEXIS AAI to request a specific access token for itself and information on compute access permissions for the identity in question (using an API call for getting user info).
A sound security architecture within LEXIS, beyond the ZTA
The LEXIS AAI with its IAM system deployment was designed as a unified component handling authorization and authorization in LEXIS, avoiding a fragile architecture with many small IAM solutions synchronizing with each other. With a federated cross-data centre deployment of Keycloak, a single point of failure is avoided. The LEXIS security architecture is not only focused on reliability and the zero-trust principle, but also implements further relevant good practices, such as limiting authorizations to a viable minimum (principle of least privilege), and proper firewalling and monitoring of network and service components.
Further information about Zero-Trust Architecture:
