Using Your Security System › Security Profiles › Your Protection Profile Strategy

Your Protection Profile Strategy

Your protection profile strategy for using the CA Tape Encryption SAF Interface is to first decide which resources you want to protect and whether these resources are protected at the local (individual BESn subsystem), the global (all BES subsystems) level or a combination of both. Next, you should decide if all resources are to be protected by default or only a select few resources should be protected. Finally, you should select which data sets should be encrypted based upon security selection criteria.

The architecture of CA ACF2 protects all resources by default therefore global resource definitions and PERMIT processing is not supported. If you want to use PERMIT processing, you can define LOCAL pseudo-generic CA ACF2 rule sets that will effectively allow all functions to be enabled for all users.

The SAF Interface running under RACF or CA Top Secret uses a hierarchal model in determining security processing options and resource protection. The first checks are to determine the scope of control that has been implemented (PROTECT or PERMIT). PROTECT and PERMIT control statements allow you to set the scope or default level of resource protection. The second check is to determine the resource protection level that has been implemented (LOCAL or GLOBAL). All resources can be protected at either the LOCAL or GLOBAL level. The third check is to determine if the individual USERID, ACID, or LID has been granted either implicit or explicit access to the resource. Each of these terms are further explained in this chapter.

For CA Top Secret and IBM Security Server RACF, the security protection feature of CA Tape Encryption gives you a great deal of leeway to set up your security profiles in the manner most suited for your needs. The following points describe some of the possible configuration strategies:

• In some environments you might not require any of the SAF Interface features and continue to run on an open system without any protection. In this case, you do not need to define any of the CA@BES entities. If this is the case CA Tape Encryption will not issue any calls to determine user access to resources and will revert back to using the z/OS DFSMS data class definitions to manage tape encryption.
• In some environments, you might want to default to encrypting all tape data sets using a default encryption key. If this is the case only tape data set selection will be active, and with the exception of CA ACF2, no other resources will be protected.
• In your test environment you might want to implicitly allow all users access to all commands, keys, and utilities. In this scenario you would want to specify the PERMIT level of protection at either the global or local level.
• In most environments, you will want to use your security system to control a few important commands, keys, utilities, and permit most users of CA Tape Encryption to run all the other commands and use most of the keys and utilities. In this case, you can create global protection profiles that permit all users to run any command and use any key or utility on all BES subsystems. Then you can restrict the use of specific commands, keys and utilities by defining these important elements to the CA@BES resource class and permitting only specific users to access them. You can create these profiles at the global level to apply to all BES subsystems by specifying BES with no subsystem identifier, and at the local level to apply to each BES subsystem by specifying the subsystem identifier.

  Observe the following:

  • For CA Top Secret and IBM Security Server RACF, CA Tape Encryption will look first at profiles for the local BES subsystem to determine access permissions. If no profiles are found for a specific command, key, or utility, CA Tape Encryption looks at the global profiles for BES to determine access permissions and to determine default tape encryption processing.
  • For CA ACF2, CA Tape Encryption only supports local profile definitions. The lone exception is the default data set selection model, BES.DEFAULT.

  In most environments, you will want to set security profiles to control commands and keys on specific BES subsystems. In this case, you might have a primary BES subsystem (BES1), a failover BES subsystem (BES2), and a test BES subsystem (BES3). You would define the same security profiles to BES1 and BES2, but you most likely want less stringent security profiles for testing purposes on BES3. You can define commands, keys, and utilities to BES1 and BES2 and explicitly grant permissions for them on each subsystem. Then you might define a completely different set of security permissions for commands, keys, and utilities on BES3.

• In some environments, you might want to use your security system to harden access to all commands, keys, and utilities. In this case, you can create global protection profiles that prohibit all users from running any command, using any key, or running any eligible utility on any BES subsystem. Then, you can permit the use of specific commands, keys, and utilities by defining them to the security system and permitting only specific users to run these commands and use these keys or utilities. You can create these global profiles by specifying BES with no subsystem identifier, and for each BES subsystem by specifying the subsystem identifier.

Note: If you want to permit or protect specific commands, keys, or utilities, you must define them to the security system and then define the permissions. If you do not do this and you are running CA Top Secret, RACF, or using CA ACF2 pseudo-global profiles, CA Tape Encryption will default to implicitly allowing access to these resources.