Xaccess Quick Start
For enabling Xaccess for an instance, we recommend that you use a pilot deployment strategy. Choose pilot user assets and users for active usage and feedback. Ensure that you provide the Xaccess Endpoint app User guide to help users during their initial days of Xaccess usage.
We recommend that you go through the FAQs before planning to enable Xaccess. For help related to concepts and tasks related to Xaccess, use Xaccess documentation. To enable Xaccess for an instance, you must be the Instance Admin for the instance.
This Quick Start topic assumes that you are enabling Xaccess on an instance/network that is currently using Xshield policy protection for application workloads ( with the Microsegmentation agent). Xaccess is also built to enforce Zero Trust-based access to application workloads by their IP segments or L2 domains.
Onboard pilot user assets
Install Xshield agents (type = User Access) on the user assets that must be managed. Agents can be installed from the UI or CLI and also at scale for Windows assets. Upon successful agent installation, the Xaccess Endpoint app is installed on the asset. Users use the app for user identity-based access to applications hosted in the Xaccess private network.
Use a preferred Onboarding mode to register the assets with the instance. The Onboarding mode (for the instance) helps you control how and when user assets are registered and how much manual effort is needed during onboarding.
Also, see the Xshield-supported user asset OSes and Xaccess Interoperability with third-party Security solutions on Windows assets before you plan to onboard assets.
Onboard CT Connectors
| CT Connectors are Ubuntu-based software appliances deployed in the customer premises (private data center or AWS or Azure cloud). After being deployed, CT Connectors must be registered to the apt Xshield instance from the UI. Connectors are built for high throughput and easy management. Use the Xaccess Onboarding Wizard to deploy and register the first CT Connector to the instance. For subsequent Connectors, they must be deployed and explicitly registered to the instance using their Instance IDs. Active CT Connectors in an Xshield instance are always connected to multiple CT Brokers deployed across multiple AWS regions in the ColorTokens Secure Cloud. The CT Broker cluster is an AWS VPC peered cluster of CT Brokers that extend connectivity to the private on-premises or cloud applications via the Connectors. |
|
Onboard pilot user-identities
| Onboarding user identities from an IdP or AD is a mandatory step in the Xaccess Onboarding wizard. The Xaccess user directory can be built with integrations with multiple SAML-based IdPs such as Azure AD and JumpCloud, or with an AD. Use IdP-native or AD-native features such as Dynamic grouping and SCIM for quicker user provisioning and Multi-Factor Authentication (MFA) and Password policies to harden user authentication. User identities and the IdP/AD Groups and Departments are listed on the Xaccess > Users & Groups page. |
|
Group users and user assets
In Xshield, a group of user assets equates to an Endpoint group and groups of users (by their identities) equate to IdP/AD Groups and Departments or Xshield User groups. Xshield User groups are supergroups of IdP/AD Groups or Departments.
Xshield policies are simulated and enforced on Xshield groups. Also, traffic visualization features such as Visualizer work based on groups. So, create effective Endpoint groups by criteria such as user identities, IdP/AD Groups or Departments, User groups, and user asset attributes.
Build policies and configure Xaccess settings
Xaccess policies to application workloads and network resources (domains and IP subnets) can be built in multiple ways - Policy Builder and custom Access policies. Policy Builder can help you build policies incrementally with Xshield-protected workloads (policies enforced on workloads) and protected workloads without Xshield agents (policies enforced on CT Brokers). Use Auto Quarantine templates to filter out vulnerable Remote endpoints and block their access automatically.
Xaccess usage for an instance can be tuned from the Xaccess Settings page. Some settings include IPsec VPN pools for user assets, idle logout duration, and level of access (disable Zero Trust-based access for remote users and allow access to all protected workloads).
Monitor users and user assets from the Xaccess Dashboard and using Visualizer, Flow Explorer, Dashboard, and Alerts features of Xshield.
Plan for scalability
Some of the milestones before scaling and extending Xaccess to more users are effective Xaccess policies, Auto Quarantine policies, and Xaccess settings, and adding an adequate number of CT Connectors to cater to the scale of users accessing the protected application workloads, and hardening user authentication with IdP-native or AD-native features.
We recommend that you use the TOP CONNECTORS BY RESOURCE UTILIZATION widget on the Xaccess Dashboard as an indicator to add more Connectors. Contact ColorTokens Customer Support for recommendations and CT Broker regions details.
Onboard remaining (actual) users
After you have ensured sufficient scalability for Xaccess to remote users and built and enforced effective policies to application workloads, consider adding the actual remote users to the Xaccess user directory. This may need you to increase the number of users in the IdP/AD Groups and Departments. In Xshield, use a preferred Onboarding mode if you haven't used it to onboard pilot user assets and edit Endpoint groups to add more users, groups, or departments. With enforced policies, the relevant policies are automatically enforced for the new actual remote users.
Use Scope tags to scope the administration of user assets to specific Asset Managers for your instance.