Agilicus AnyX Configuration Security
Introduction
Agilicus AnyX is part of a Defence in Depth strategy. It also uses this same strategy internally, providing multiple layers of protection for all critical information and assets.
There are three primary information areas:
- control plane: configuration, setup
- data plane: network connectivity
- overlay plane: secure user to resource access
The data plane is protected using tools such as strong encryption, geographical IP firewalls. The overlay plane is protected using a very precise firewall, with fine-grained audit, allowing very tight segmentation and control on a per user<->resource basis. In this document we discuss the control plane, configuration, what data exists, what controls exist to protect it, and what risks are involved.
At a high level, the protections are:
- Key information is in sole custodial control (meaning Agilicus has neither physical nor logical access to it) of the customer on their premise (encryption keys, firewall authentication and authorisation logic)
- No authentication-sensitive information is kept (no passwords)
- User sensitive information is primarily defined out of scope (this is a architectural decision of Agilicus, we have chosen to use existing single-sign-on exclusively, rather than allowing local users at all, thus all information is kept in the Identity Provider), with the remainder kept for audit purposes stored as a one-way Globally Unique ID (GUID) to prevent reversing, to allow “the right to be forgotten” while maintaining audit integrity
- Strong systems security surrounding the Agilicus AnyX cloud
- Agilicus AnyX does not hold any customer data at rest in its system: no files
Defence In Depth
The Defence in Depth consists of:
- full immutable audit
- defining out of scope data not required (e.g. authentication, passwords, user management provided by Microsoft Entra)
- user information stored via non-reversible GUUID (audit, permission assigning) allowing ‘right to be forgotten’ coupled with data integrity
- defining to end-customer custodial control sensitive information (e.g. certificates, encryption keys)
- defining as out-of-scope any end customer data (e.g. files)
- strongly encrypting all configuration data in motion and at rest
- strong API security for all access
Configuration Data Types and Locations
The architecture of Agilicus AnyX is such that there are three primary locations of configuration:
- Customer and Partner Identity Providers (e.g. Microsoft Entra, Okta, Google Workplace)
- Agilicus Connector (on customer premise)
- Agilicus AnyX cloud
All users are authenticated against an Identity Provider using Single Sign-On: there are no passwords stored in Agilicus AnyX (neither encrypted nor clear text). There is no ‘trust’ from the Identity Provider to Agilicus AnyX: Agilicus cannot modify or extract information other than the OpenID Connect ‘profile’ scope (user name, user email), thus a theoretical breach cannot flow upwards. The Agilicus AnyX ‘users’ model has a linkage to the identity provider.
The Agilicus Connector stores encryption keys and certificates on a per resource basis. Encryption is thus formed from the user to the Connector. The Connector runs within the customers network, with no inbound-API to fetch this information.
Each connector has its own encryption keys, stored in the local machines keyring or TPM if available. Thus gaining local control of one connector does not breach the others. The connector has no durable stored information other than certificate information and its local service account for fetching new configuration. There is no inbound connectivity to the connector, no open ports.
As you can see from above, the Identity Provider and Connector are both outside the scope of the Agilicus AnyX cloud. The Connector maintains its information within the custodial control of the Customer. This leaves the AnyX Cloud configuration to discuss.
Inside the AnyX cloud configuration data is kept within a consensus-based scale-out relational database, giving resilience to any node failures. Information is backed up to Google Cloud Storage using Customer Managed Encryption Keys. Thus neither the live information, nor the backup, is readable by anyone other than Agilicus.
Inside the configuration API is a set of data types (for detailed information see Agilicus API). This information relates to the configuration of network paths and authorisation rules (e.g. who can do what). The system is multi-tenant, and, there is segregated control on a per organisation basis.
Information that could be breached includes:
- internal IP/port of a resource
- list of which users or groups have access
- external host names assigned to the resources
No ‘sensitive’ information is present (e.g. internal passwords, external passwords, software version information).
There is a complete immutable audit trail kept for all configuration API read/write operations, including assigning of permissions, authentication, and access. The audit trail can be forwarded in real-time to a customer-supplied SIEM as desired.
The overall Agilicus AnyX system is maintained within Google Cloud on Kubernetes. 100% of connectivity is encrypted using TLS 1.3. All actions are authenticated via single-sign-on with multi-factor, all storage is encrypted with customer managed encryption keys.
Summary and Conclusions
Agilicus AnyX uses a Defence In Depth architecture on all three planes:
- control plane
- data plane
- overlay plane
No sensitive information is stored, under any circumstance.
Get In Touch
Ready To Learn More?
Agilicus AnyX Zero Trust enables any user, on any device, secure connectivity to any resource they need—without a client or VPN. Whether that resource is a web application, a programmable logic controller, or a building management system, Agilicus can secure it with multi-factor authentication while keeping the user experience simple with single sign-on.
info@agilicus.com, +1 519 953-4332
300-87 King St W, Kitchener, ON, Canada. N2G 1A7
info@partner.com, +1 555 555-5555
1 Main Street, Townsville, ON, Canada. POST-CODE