What about security?

Mar 6, 2020

Security is paramount, and VirtualZ ensures that users cannot gain additional privileges or access as a result of our redirection process. All work VirtualZ does on behalf of a user is done in that user’s security context, limiting the user to only the resources they’ve been properly permitted to. This is true on both source and target systems, as we automatically capture and propagate the user’s identity to all target systems where their work runs.

Typically, permission checking is performed on the source system so that the target doesn’t have to be strictly synchronized with the source. We recommend doing security checks on the source to ensure that the user doesn’t get different access than they normally expect. However, optionally, VirtualZ can be configured to perform security checking on the target system as well, giving you the ability to have the target’s security policy override the source. This is sometimes important when a system with strict access controls accepts work from a system with weaker controls.

In order to propagate user identity, the user’s account must exist on both source and target systems. Details like their password and so forth need not be synchronized between source and target, but the account does need to exist, and VirtualZ needs to be authorized to submit work on behalf of this user via the “BPX.DAEMON” resource. If the user account does not exist or VirtualZ is not authorized to submit work on this user’s behalf, the user’s job will fail.

VirtualZ also provides a variety of built-in security controls:

  1. A global “VZC” permission check allows you to control VirtualZ access on a user-by-user basis. If enabled, users need permission to run jobs that trigger the VirtualZ redirection process. In addition, since the security system’s audit data can record these access attempts, then can be used to report on overall VirtualZ usage.
  2. The “VZCNODE” permission check allows you to control who can submit work that targets a specific system for execution. If the user doesn’t have access to run work on a particular target system, VirtualZ will select another node if any are defined.
  3. A VirtualZ “identity mapping” feature allows you to map the user’s identity to a different identity when desired. As described above, normally VirtualZ propagates the user identity from source to target, but if you wish to have the user run under a different identity on the target, that can be done using this feature. This is helpful in cloud settings where it might be desirable to map users to roles, rather than require all users to be defined on the target system.

VirtualZ is fully compatible with IBM RACF, CA ACF2 and CA Top Secret.