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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Updated about 1 month ago