Unlocking IBM i Security: A Guide to Protecting Your Goldmine

In today’s data-driven landscape, businesses rely heavily on digital operations, and the threat to production data has never been more ominous.

But have you ever noticed….,

The threats to production data are multiplying, morphing, and growing in sophistication.

But the actual question is that….,

Are you prepared to defend your data fortress? 

Come let us find out….

Object Level Security

IBMi is well known for its reliable, scalable, flexible, and secure systems, as well as the rapid development of its interfaces and system architecture. The IBMi platform has always been focused on improving the processing cycle, providing users with a large choice of APIs to accomplish their tasks, and supporting integration with various open-source languages.

This makes the IBMi system stand out from the other systems. System security is based on three objectives:

●      Confidentiality: Restricting data access to unauthorized users
●      Integrity: Restricting unauthorized users from manipulating data.
●      Availability: Protection against destruction of data.

It always depends upon the amount and criticality of the data, which gives us a better idea of how to secure the objects and environments.

To effectively implement and manage these security measures, consider leveraging IBM i consultancy services. Experienced consultants can provide expert guidance on:

• Assessing your current security posture: Identifying potential vulnerabilities and areas for improvement.
• Designing and implementing robust security controls: Including access control, encryption, and auditing.
• Developing and maintaining security policies and procedures.
• Ensuring compliance with industry standards and regulations.

The following questions can help us choose the best secure environment for our systems if we plan to implement security features:

● Is there a company policy on the security standards?

● Do the auditors require a minimum standard level of security?

● How critical is the data to our business?

● What are the company security requirements for the future?

The IBMi systems are used by a wide range of customers, and so are its security features. One of the factors that affect the utilization of these systems is object security. We need to understand these features to get the most out of these systems.”

Authorities Can be Granted on multiple levels. Let us look at them:

Private Authorities

Objects will only be accessible and usable by individual or group profiles with these permissions.

Authorities can be given or revoked by one of the listed commands –

• GRTOBJAUT (Grant Object Authority)
• RVKOBJAUT (Revoke Object Authority)
• EDTOBJAUT (Edit Object Authority)

As shown in the figure, these can be further classified into Object authorities and Data Authorities.

Object Authorities

1. *OBJOPR : Object Operation Authority authorizes the use of an object. This lets the user view the object’s description, regardless of the object’s type; but cannot access data or run the program without appropriate data authority.
2. *OBJMGT : With the Object Management Authority, the user can remove and rename objects, change their attributes, and grant or revoke the authority of other user profiles to the object. It is a superset of the object authorities *OBJALTER and *OBJREF.
3. *OBJEXISTS : Object Existence Authority lets the user delete, save, restore the object, and transfer ownership of the object.
4. *AUTLMGT : Authorization List Management applies to only authorization lists. This authority lets you add and remove user’s authorities to an authorization list.
5. *OBJALTER : Object Alter authority authorizes the user to add, clear, reorganize, and initialize database file members and to alter the attributes of database files (SQL tables/physical files or logical files). Besides adding and removing triggers, it can also change the attributes of tables, files, and SQL packages.
6. *OBJREF : Object Reference authority lets the user specify a database file or table as the parent file in a referential constraint.

Tips On Object Authorities

1. If you do not want a user to have *OBJALTER or *OBJREF authority, you must revoke not only *OBJMGT but also *OBJALTER and *OBJREF
2. You should restrict *OBJMGT and *OBJEXIST authorities to the object’s owner, to reduce the risk of the thing being improperly used or accidentally

3. *OBJALTER and *OBJREF apply primarily to database files.

4. If you want to grant a database administrator or programmer *OBJMGT authority, you can grant only *OBJALTER authority to limit the user to database-specific functions.

5. *OBJREF should only be granted to the database administrator or programmer responsible for enforcing referential integrity constraints.

Data Authorities

It applies to all object types and is as follows:

• *READ : Enables users to read and retrieve data and entries.
• *ADD : Enables user to insert a new data record or entry.
• *UPD : Enables users to modify existing data and entries.
• *DLT : Enables the user to delete and remove data and entries.
• *EXECUTE : Enables user to locate an object in a library or directory; and execute a program, a service program, or an SQL package.

Tips For Data Authorities

• The *EXECUTE authority allows you to search the contents of a library or directory. To access an object, you need not only authority over the object itself but also *EXECUTE authority over the library or directory where it resides.
• Data authorities also apply to objects that do not have contents.

E.g., to submit a job that uses a JOBD, you need *OBJOPR, *READ, and *EXECUTE authorities to that JOBD.

Authority Interconnection

Having authority in a library does not give you authority over the files within it. You need authority to both object and library, to access that object.

To look for objects in a library, you need to have *OBJOPR authority to the library. To read descriptions of library objects, you must have *READ authority to the library. To add objects to a library, you must have *ADD authority to a library, etc.

You may not require *DLT authority to delete an object from the library. *USE authority is sufficient to delete an object from a library.

However, you should have *OBJEXIST authority to that object and *EXECUTE authority to that library where it resides, to delete it.

To prevent a user from accessing an object, you must grant that user *EXCLUDE authority to the object. To set the object’s access to “deny by default,” you would set the object’s *PUBLIC authority to *EXCLUDE.

Group Profiles

The purpose of group profiles is to grant specific authority to a particular group of users. To simplify the authority granting process, all individual sources are granted to a group profile, and user profiles are associated with that profile as GRPPRF (group profile).

Likewise, multiple profiles could be granted and restricted with some set of authorities as per need and assigned to user profiles as SUPGRPPRF (supplemental group profile). The system searches each profile listed in the group profile and supplemental group profile for a user profile until it finds enough authority to perform the task.

Consulting with IBMi Experts can help you optimize your group profile configurations. Our experienced professionals can:

• Analyze your current security setup: Identify potential inefficiencies and security risks.
• Recommend best practices for group profile design: Ensure optimal performance and maintainability.
• Assist with the implementation and testing of new group profile configurations.

The fewer groups the system must search for relevant authorities, the better the performance. The recent upgrades to IBMi systems mean that even if the system must search for appropriate authorities for a lot of groups and supplemental group profiles, there will be minimal difference in performance. 

System Value QCRTAUT

When you create a library and do not specify a CRTAUT value, the *SYSVAL default value causes the library to use the value found in the QCRTAUT system value. The default public authority of objects created in any library is set to *CHANGE as IBM ships the QCRTAUT system value set to *CHANGE.

In the current system environment where FTP/SFTP, ODBC, JDBC, and SQL transactions are mostly happening in systems either internally or via HTTPS server requests to the system, the public authority *CHANGE is not a wise choice of state.

Most programmers/administrators prefer to set the value as *USE, or even *EXCLUDE to limit public authority to new libraries and objects. *USE is the most appropriate public authority in today’s environment. The worst of choices is to set it at *ALL, as the newly created library and objects will have *PUBLIC authority as *ALL. Any user can do any kind of manipulation or even delete the objects under this value.

It is always better to leave the QCRTAUT value as *USE to leave the system library authorities as it is. Then, plan and use the CRTAUT attribute in library creation, to set a new set of authorities to be applied to newly created libraries and objects.

System value QCRTAUT does not affect objects created in directories. Also, Changing the QCRTAUT system value does not affect objects that already exist. A change to QCRTAUT affects only objects that are created after the system value is changed.

Authorization List and its application

Objects associated with an application are secured with this management tool.

For example, new objects created within an application like Warehouse management must have the same access authority as existing objects. The authorization list is the best way to apply for it.

1. To create an authorization list to secure an object, use the CRTAUTL
2. Then, run the EDTAUTL command to grant a set of authorities to selected users or group profiles.
3. The next step is to associate all the application-specific objects and libraries to that authorization list by specifying their name in the AUTL parameter on the GRTOBJAUT
4. Last, you can set each file’s *PUBLIC authority to come from the authorization list by specifying *AUTL in the AUT parameter on GRTOBJAUT.

Advantages Of Authorization List

A user profile’s private authorities supersede any authority the user has to an authorization list. You can still grant and revoke private authorities to an object using the GRTOBJAUT, RVKOBJAUT, and EDTOBJAUT commands.

Let us check a quick comparison between the Authorization list and the group profile

Authorization List	Group Profile
Secures and helps you manage access to multiple objects that need the same authority settings.	Helps you manage multiple user profiles that need the same access and capabilities.
Let each profile have a different authority to the authorization list.	Gives all users in the group the same authority.
An object can be secured by only one authorization list.	A profile can be a member of multiple group profiles.

Based on the scenarios, and the sensitivity and criticality of business data, each system can be customized with the best-suited object security from features in IBMi.

The goal is always to protect the data from unwanted and unintentional interventions.

Conclusion

The threats to production data are ever evolving, and the consequences of data breaches can be severe. Businesses must take a proactive approach to safeguarding their digital assets. This involves a combination of robust technical measures, employee training, and a culture of security awareness. To ensure comprehensive and ongoing data protection, consider leveraging IBM i Support services. Our expert team can:

• Proactively monitor for and respond to security threats.
• Provide timely security updates and patches.
• Assist with incident response and recovery.
• Offer guidance on best practices for data security.

By prioritizing data security, organizations can protect their production data, maintain their integrity, and build trust with customers in an increasingly data-driven world. Remember, in the realm of data security, it is not a question of “if” but “when” a threat will emerge, so be prepared.