# Agilicus AnyX Configuration Security - Link: https://www.agilicus.com/white-papers/agilicus-anyx-configuration-security/ - Published: 2024-09-20T02:18:47+00:00 - Author: Don Bowman ![configuration-security](https://www.agilicus.com/www/385d7f88-configuration-security- 1024x1024.avif) # Agilicus AnyX Configuration Security ## Introduction Agilicus AnyX is part of a [Defence in Depth](https://www.agilicus.com/blog/defence-in-depth/) strategy. It also uses this same strategy internally, providing multiple layers of protection for all critical information and assets. ![Wastewater Remote Operations and Asset Management](https://www.agilicus.com/www/ 30c74c34-wastewater-remote-operations-and-asset-management.svg) 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: 1. 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) 2. No authentication-sensitive information is kept (no passwords) 3. 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](https://en.wikipedia.org/wiki/Universally_unique_identifier)) to prevent reversing, to allow “the right to be forgotten” while maintaining audit integrity 4. Strong systems security surrounding the Agilicus AnyX cloud 5. Agilicus AnyX does not hold any customer data at rest in its system: no files ### **Defence In Dept**h 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 ![identity-venn](https://www.agilicus.com/www/7531b7ba-identity-venn.png) The architecture of Agilicus AnyX is such that there are three primary locations of configuration: 1. Customer and Partner Identity Providers (e.g. Microsoft Entra, Okta, Google Workplace) 2. Agilicus Connector (on customer premise) 3. 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. ![Agilicus AnyX WSTunnel and WireGuard configuration diagram, illustrating secure remote access and data exchange bypassing firewalls.](https://www.agilicus.com/www/ cb4460b9-wireguard-wstunnel.svg) 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](https://agilicus.com/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 ### Related Topics [Industrial Zero-Trust Micro-Segmentation](https://www.agilicus.com/white-papers/zero-trust-microsegmentation/) [Multi-Factor Authentication On The Internal Network](https://www.agilicus.com/white-papers/multi-factor-authentication-on-the-internal-network/) [Authentication Audit](https://www.agilicus.com/anyx-guide/authentication-audit/) [Local SIEM: Audit Destinations](https://www.agilicus.com/anyx-guide/audit-destination/) [Authentication Rules](https://www.agilicus.com/anyx-guide/authentication-rules/) [Azure Active Directory (Entra)](https://www.agilicus.com/anyx-guide/azure-active-directory/) [Identity](https://www.agilicus.com/anyx-guide/identity-and-authentication/) & [Authentication](https://www.agilicus.com/anyx-guide/identity-and-authentication/) [Methods](https://www.agilicus.com/anyx-guide/identity-and-authentication/) 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. BOOK A MEETING 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. [BOOK A MEETING](https://www.agilicus.com/book-calendar-meeting/) ![Agilicus AnyX platform logo, horizontal orientation.](https://www.agilicus.com/ www/9f758437-agilicus-logo-horizonta.svg) info@agilicus.com, +1 ‪519 953-4332‬ 300-87 King St W, Kitchener, ON, Canada. N2G 1A7 [⌊partner⌉⌊partner⌉[