VitalSigns for IP, Security
Beginning with VIP 6.0, VIP security functions are now entrusted to the products designed for it—ACF2, RACF, and Top Secret. Responsibility for VIP security will no longer fall on VIP administrators. Instead, setting up VIP security is given to those normally responsible for security—the security group. z/OS security administrators can secure VIP and its system tools with the familiar SAF (Systems Authorization Facility) tools they’re already using.
This has been a requirement at several large shops and is considered necessary at many sites for auditory compliance. By externalizing the security interface, VIP leverages existing security and maintains an audit trail.
- The new VIP security interface leverages existing security. Group rules can be put in place such that when a new user is added to a group, he or she automatically has the proper access. This was not possible with the security interface in VIP versions prior to 6.0.
- VIP now uses SAF security and therefore supports the wildcarding that is possible within SAF-based security products (ACF2, Top Secret, and RACF). This also was not possible with VIP versions prior to 6.0.
- Access control over console commands, drop connection, and activate LU will take advantage of security that is already in place. These commands are now issued in the user’s context. Prior to VIP 6.0, those commands were issued under the context of the VIP Agent’s user ID. Executing in the user’s context further reduces any security changes, providing a better audit trail and more robust security.
- Security is now multi-layered. In addition to a first level of security restricting access to resources like the command tool, executing in the user’s context means that execution of the command itself is based on user’s access to the command—thus providing a second and more granular level of security.
- VIP can now be more granular in IP packet tracing than the TCPIP stack itself allows. VIP can allow/disallow tracing for a user or group by LPAR or sysplex even with a shared security database. This means, for example, that a development group could use tracing to help develop and debug an application, but they could be disallowed access to restricted production data.
- Tools that were not secured before VIP 6.0 are now secured: Remote Host, TN3270, and HTTP monitors. Securing these monitors allows sites to make sure that only authorized users are able to create, delete, alter, or initiate these monitors. This ability is important for sites wishing to roll out VIP beyond the systems programming staff to groups such as Help Desk, Operations, Level 1, etc.
- VIP security configuration is generally not high maintenance—once installed and implemented, the number of users tends to be fairly static.
- The move to complete reliance on SAF security is a widely requested enhancement to VIP. It is essential to our platform moving forward. Migration will be required for support of future operating system and to take advantage of features in future versions—7.0 for example, which is due out in beta in May 2008.