Create User Groups
User Groups in your VPAM server enable you to segment your internal users immediately after the user is created. This initially limits your internal user's access only to applications that their User Group has access to.
Initial Considerations
VPAM usually has two types of Internal Users:
-
System Administrators: A user that can see everything and do everything in the system
-
Standard User: Follows a Least Privileged Access design philosophy and are configured with User Groups and Custom Roles.
The primary function of a User Group is to establish which Application(s) Standard Users are allowed to see and interact with.
Configuring segmentation at a User Group level does not configure the permissions each User Group has. To configure permissions at a Role level, read the best practices on Segmenting Roles.
System Administrator do not belong to any User Groups or User Roles because they have full access to everything.
If you intend on having a single System Administrator that performs all duties in your VPAM server, then configuring User Groups might not be necessary and you can use the default PUBLIC User Group for the configurations that require a User Group.
Suggested Segmentations
Use any of the following recommendations to ensure you implement zero-trust access at the User Group level.
To follow these guides, you must be a System Administrator role or a user with User Group management permissions.
Your VPAM server has the built-in PUBLIC User Group. If you do not create User Groups prior to creating internal users, all users are included to the PUBLIC User Group.
If you are not delegating server management tasks to Standard Users, you can use the PUBLIC User Group as a placeholder, or as a User Group for Standard Users.
Imprivata recommends you create purposeful User Groups to implement zero-trust based access in your server and increase security.
Create User Groups based on the role you want to assign at a very high-level. For example: Support, Engineering, Customer Success, Application Owner, Legal, Regulatory. With this segmentation, you can map begin to grant access by role, limiting access and capabilities of your internal users.
Create User Groups based on which environment your internal users should have access to. For example: Development, Testing, or Production. With this segmentation, you can prevent developers and testers to access the production environment when they are building or testing features. You can also prevent your customer-facing teams to access work in progress.
Create User Groups based on the applications you have and which users should have access to them. Ensure each group is mapped to specific applications. With this segmentation, internal users can only access applications assigned to their User Group.
This recommendation works best if you assign one User Group to one application; otherwise, other strategies may provide more benefits to your workflows.
Create groups based on privilege, access, and authority to your VPAM server. For example: Public, Internal, Private, Privileged. With this segmentation, you can protect assets that require higher security.
Create groups based on the vendor that your internal users service. For example: Company Imaging, Payment Processor, Banking Support, Virtual Desktop, Agent Endpoint.
Recommendations
Ensure that you also read the following recommendations when implementing User Groups.
-
DO:
-
Mix different segmentation techniques to ensure granular access and zero-trust implementations.
-
Ensure User Groups are always purpose-driven.
-
Consider creating separate User Groups for Internal User Access, for Approvals, and for Managing Vendor Access.
-
Remember that an Internal User can be assigned to more than one User Group, so layering multiple User Groups may fit your internal organization structure better than aiming for single groups.
-
Continue configuring zero-trust at the Role-level.
Read the Roles documentation and the Segmenting Roles best practices. -
Create at least a rough draft of User Groups before proceeding onto User Roles.
User Groups act as a "first filter" and will affect several permissions inside a User Role.
-
-
DON'T:
-
Don't skip User Groups! Permissions inside User Roles are affected by User Groups, so tackle these first!
-
Don't feel like you have to create dozens or hundreds of User Groups.
Some few customers may need that level of granularity, but most do not -
Don't configure Internal User Groups for any external third-party users.
Third-Party Users are known as Vendors.
-
For example, imagine you have 10 internal users, but not all of them require access to the same applications. Their access requirements are the following:
| # | User | Access Requirements |
|---|---|---|
| 1 | Alex | Connection Access to Database Server |
| 2 | Jane | Connection Access to Database Server |
| 3 | Michael | Connection Access to Database Server |
| 4 | Diane | Connection Access to Database Server |
| 5 | Phil | Connection Access to Medical Imaging Devices |
| 6 | Erin | Connection Access to Medical Imaging Devices |
| 7 | Josh | Connection Access to Medical Imaging Devices |
| 8 | Betty | Connection Access to Network Infrastructure Devices |
| 9 | Charles | Connection Access to Network Infrastructure Devices |
| 10 | Patrice | Connection Access to Database Servers and Network Infrastructure |
In this example, you can create three User Groups, add each user to their corresponding group, and limit their access to your assets. The segmentation would be the following:
| User Group | Internal Users |
|---|---|
| Internal Access: Databases |
|
| Internal Access: Medical Imaging |
|
| Internal Access: Network Infrastructure |
|
Always remember to include the purpose of the User Group in its name. In our example, the naming enables us to quickly remember the purpose of the User Group.
Remember!
All your Internal Users must belong to at least one User Group, and an individual Internal User can belong to multiple User Groups.