By taking some additional actions, you can protect your replication environments from access by unauthorized users.
Use available product authority functions provided with Precisely products: If the Precisely product you are installing supports product-level security, use it. Product-level security can be turned on immediately after installing software by using commands shipped in License Manager.
When product-level security is turned on, user profiles must be authorized to a product before they can access its functions. You can control public authority access as well as access for individual or group user profiles. Then, only users that have security access to the product can use its functions. You can also further limit access to areas within the product, such as commands and displays.
For example, if you do not use product-level security, an unauthorized user could create a journal monitor within MIMIX. The user could then receive partial information about journal transactions from a journal to which the user is not authorized. Without product-level security, an unauthorized user could also use License Manager to delete an installation of a Precisely product.
For detailed information and examples, see Precisely-provided product-authority functions.
Modify authority to user profiles provided by Precisely: If your business environment requires, you can limit the special authorities given to user profiles associated with Precisely products. Be aware that you may also need to change object authority to other objects to ensure that the Precisely products have the necessary access to operate as expected.
Removing *ALLOBJ authority from the LAKEVIEW user profile will degrade performance for all install-related processes because of the overhead of additional operating system authority look-ups. Removing *ALLOBJ authority may also cause product upgrades to fail if the LAKEVIEW user profile lacks the authority necessary to use the objects needed for updates or product installation objects.
Removing *ALLOBJ authority from the MIMIXOWN user profile will degrade performance for all MIMIX processes because of the overhead of additional operating system authority look-ups. Removing *ALLOBJ authority may also cause files to go on hold and may cause failed requests if the MIMIXOWN user profile lacks the authority necessary to operate on the defined files and objects.
If you have an extreme business need to remove *ALLOBJ authority, you have these options:
For the LAKEVIEW user profile, explicitly grant authorization to the LAKEVIEW user profile for every stream file for software updates and all objects in each product installation library.
For the MIMIXOWN user profile, add the QSECOFR user profile as the primary group profile. Because of the *ALLOBJ authority inherited from the QSECOFR user profile, this allows the MIMIXOWN user profile to access any objects for which it is not explicitly excluded.
For the MIMIXOWN user profile, explicitly authorize every file and object used by the replication process on the source system and on the target system. For user journal-based replication, this includes every file, data area, data queue, or IFS object on the source system from which transactions will be replicated, every file on the target system that will receive replicated transactions, and any libraries to which the object replication process replicates a file and defines these objects for cooperative processing. For system journal-based replication, this includes every object on the source system that will be replicated, every library, folder, and directory (*LIB, *FLR, *DIR) on the target system that will receive replicated objects, and any library to which files are defined for cooperative processing.
If you change the authority level of the MIMIXOWN user profile, you must also explicitly authorize MIMIXOWN to the following:
All objects of any type that are being replicated by MIMIX or being audited by Precisely Audits within iTERA.
All objects of any type within an installation library which contains data groups that are enabled or disabled within iTERA when a roll swap occurs.
Any customized step programs and user created procedures for application group operations within MIMIX.
Access to files and temporary journaling environments used when copying or reorganizing active files within MIMIX.
All of the following items associated with switching the direction of replication for a data group-only MIMIX environment, using a model switch framework implementation or the MIMIX Switch Assistant:
-
Any customized user programs for the switch framework.
-
Any MIMIX libraries to be switched.
-
Any communications configuration to be switched.
-
Change authority (*CHANGE) to the output queues of user profiles submitting switching commands so that MIMIX can write to spooled files.
-
Any objects used by monitors which MIMIX uses for supporting functions. This includes the job scheduler, all objects that each monitor watches (such as journals and message queues), and to any interface exit programs, condition programs, and event programs called by each monitor.