Introduction
Does this seem too long and complicated? Just want to try PrivX? Go to Quick PrivX Setup. You can also run PrivX test drive!
What is PrivX
PrivX is a privileged-access-management solution for accessing remote systems. It is used to provide secure, audited access to cloud infrastructure, servers, network devices, different appliances and to operational technology systems.
PrivX enables zero-trust principles: Short-lived certificates may be used for authenticating to target systems, replacing passwords and other static credentials. Certificate-authentication support requires configuring the target systems to trust the PrivX certificate authority.
For target systems which are unable to support certificate authentication, PrivX also supports a full-featured secrets vault with an integrated password rotation solution.
How to Deploy
First, identify what systems (or targets) you'd like to access with PrivX. Where do you plan to deploy PrivX network-wise: is PrivX going to see the target systems, or are the target systems perhaps located in a separate, protected network?
- To reach targets in different networks, you may deploy PrivX Extenders to enable connectivity.
- To access web targets, you must deploy a PrivX Carrier and Web Proxy.
- For network-level access from workstations to target devices (PrivX OT), PrivX Routers must be deployed and integrated to the organisation VPN solution.
Deploying PrivX and PrivX components
Deploying PrivX Extender
Deploying PrivX Carrier and Web Proxy
Deploying PrivX router
You can install PrivX either via RPM packages to a compatible Linux system, or via container to Kubernetes. We have infrastructure-as-code examples about deploying PrivX to Amazon Web Services, and architecture blueprints for deploying to Azure and Google Cloud. Public cloud deployments can make full use of public cloud-managed services.
PrivX requires a PostgreSQL database and the application can be deployed to be highly available. To achieve high-availability in RPM installation, multiple PrivX nodes can be deployed behind a load balancer.
Roles and Role-Based Access Control
PrivX access and permission models are based around role-based access controls (RBAC).
To start, a role is created and associated with users. The association may be done automatically by mapping external or local users to roles using tags, identity provider group memberships or free-form LDAP filters. These are called mapped roles.
Roles can also be explicitly granted to specific users by administrators. Alternatively, users can request specific roles using workflow requests.
Managing workflows
Requesting and approving role memberships
All users' role memberships may contain context limitations such as source addresses or time of day. A user may belong to any number of roles.
Users' roles determine what targets (be those hosts, applications, networks, or secrets) they can access.
Granting access to hosts
Securely storing data
Roles' permissions specify which actions users may perform in PrivX - the permissions range from being able to administer the system, to being able to view audit trails.
Role permissions also determine what API clients are allowed to perform.
Granting permissions to users via roles
Role permissions
There are two types of users in PrivX: local users, and external users. External users can be imported from your existing identity sources such as Microsoft Active Directories, LDAP servers, OIDC providers, and even via SCIM.
At the import phase, based on user-group memberships, tags, or other attributes, the user can be automatically mapped to roles. Apart from local and SCIM users, users are kept only in-memory and synched periodically or on-demand. If a user originates from an external source, authentication for that user is also made against that specific external source.
Once logged in, the user’s group memberships and attributes are periodically checked against the identity provider and the role memberships are adjusted accordingly. If role memberships change in a way that disallows specific target connections, they are terminated automatically.
Importing External Hosts and PrivX Local Hosts
Just like users, hosts also come in two shapes: imported hosts and local hosts. Hosts can automatically be imported from cloud providers such as Amazon Web Services, Microsoft Azure, Google Cloud, or from virtualisation environments such as OpenStack. Hosts can also be pushed in to PrivX via SCIM by using our custom SCIM protocol extension.
In addition to this, it is possible to push hosts in via the PrivX API using PrivX API clients, enabling custom integrations to a wide range of CMDB solutions.
When importing hosts, the desired role access model can be expressed via cloud provider instance tags.
Script-Based Certificate-Authentication Setup
Onboarding Environment for PrivX Access
Certain authentication methods such as certificate-based authentication require target-system configuration. For example, with Linux hosts this may involve configuring Tectia or OpenSSH to trust the PrivX Certificate Authority. PrivX also supports ssh public key and password authentication, which do not require target-system configuration.
Supported Authentication Methods
Deployment Automation
Script-Based Certificate-Authentication Setup
Onboarding SSH target hosts to PrivX via Ansible
Onboarding SSH target hosts to PrivX via Chef
To access Windows target systems via virtual smartcard authentication, the Windows domain must be configured to trust the PrivX certificate authority. The alternative is to use password authentication against standalone Windows servers or domain members.
RDP Certificate Authentication
Target accounts can be shared accounts or user-specific accounts. Even with shared accounts, the access can be traced from the target system back to PrivX logs and individual users via certificate serial numbers.
Making Connections with PrivX
After your environment has been onboarded for PrivX access, connections can be made using the PrivX web user interface or via PrivX Bastions using native clients. Both proxied and bastioned connections can be audited. For native SSH connections, OIDC (Open ID Connect) login is also supported.
Connecting via the PrivX GUI
SSH Connections with Native Clients
RDP Connections with Native Clients
Database Connections with Native Clients
Session Recording
Machine-to-Machine Connections
Certificate based connection setup
External JWT Authentication
Integrations
All the actions performed via the PrivX web GUI can also be performed via the API by API clients with sufficient role permissions. SSH publishes API access SDKs for Golang and Python as well as a command-line client for performing actions against the PrivX instance.
API-Client Integration
PrivX CLI
Golang SDK
Python SDK
Monitoring
PrivX produces audit events of all user actions. The audit events can be seen through the Monitor tab in the GUI but they are also by default sent to syslog from which they can be exported to SIEM systems for further analysis, dashboarding, and alerts.
Viewing Audit Data
Audit Events Reference
Splunk integration
External Logging
Matching Certificate-Based-Login Messages
PrivX instances and microservices also publish a status REST end point with which system health can be monitored. The status is also visible under Monitor tab in the GUI.
System Lifecycle Management
As with any IT system, it is a good idea to have backup and restore processes in place and making sure that there's sufficient disk space available for log files and trail files.
Was this page helpful?