IBM i job scheduling is about more than just running necessary jobs and workflows in the proper order. It’s also about ensuring that you have a separation of duties between IT personnel, provide audit and historical reporting on submitted jobs, and have an audit trail for scheduling activities. Properly securing your IBM i job scheduler is also crucial for compliance with laws and regulations, such as the Sarbanes-Oxley Act of 2002 (SOX). You need to consider all of these items when setting up your IBM i scheduling environment.
Who’s authorized to what?
User access to job scheduling functions should be authorized only to what the users need to do their jobs, nothing more; this is the concept of least authority. Separation of duties specifies that critical functions should be broken down into tasks, and each task should be performed by a different person so that no one person can game the system. Best practices specify that you should use least authority and separation of duties to secure your IBM i system. Compliance regulations such as SOX search for these items in an audit.
Implementing a strategy of separation of duties and least authority between programmers, IT management, and IT Operations for IBM i job scheduling will improve overall system security. Programmers can specify what applications and commands should be executed in a job stream and view scheduled jobs, but they shouldn’t have the ability to schedule jobs or kick off a job stream. IT Management should approve and authorize all job schedule adds, deletes, and changes. IT Operations should set up and maintain the job schedule, and kickoff job streams and workflows manually, as needed.
Each group has its own separate and special access, but… what’s the best way to implement that framework to secure your jobs?
A lack of security inside the native IBM i job scheduler
For IBM i job scheduling, shops can either use the native IBM i job scheduler or a third-party job IBM i scheduler, such as SEA’s absScheduler. The native job scheduling software is accessed through the Management Central Scheduler feature in the IBM Navigator for i Web application or the Work with Job Schedule Entries command (WRKJOBSCDE).
While the native scheduler offers job automation, it lacks job entry security features. You can’t control who schedules jobs, changes jobs, or submits jobs. If someone is able to reach the native scheduler, they can schedule jobs. The only real security available for the native IBM i job schedule lies in native IBM i operating system authorities. To keep unauthorized users from making changes within the Native scheduler, it’s necessary to take away their authorities to the native job scheduler environment.
The native job scheduler also doesn’t provide any audit reports indicating who entered, changed, or ran which job, which makes meeting audit requirements extremely difficult. To get the data you need for compliance, programmers will be required to write code to retrieve and analyze the job scheduler’s performance. This is an inefficient use of pricey programming time, especially when third-party IBM i schedulers typically offer built-in reporting.
Third-party job scheduler security
Third-party job scheduling software for the IBM i supports least authority and the separation of duties. It also provides the reporting needed for compliance and forensic research on scheduled jobs.
Third-party job schedulers typically allow you to limit what people do in the scheduler, enforcing least authority, and the separation of duties. Package security segregates scheduling duties by assigning roles to your users and giving each role individual authority to scheduler functions. You could create an IT Ops role that can schedule jobs and maintain the schedule. A programmer’s role could be limited to only viewing the job schedule in the production environment, while allowing programmers to be administrators in the test or QA environment. Using roles in this manner could allow programmers to test new job streams and workflows, while forbidding them from promoting those same changes to the production environment.
Third-party job schedulers can also provide auditing and reporting. Using a package’s auditing and reporting functions allow you to see who set up your scheduled jobs, when jobs ran, who made changes to job scheduler entries, and who ran jobs out of order. They enable you to produce compliance reporting without additional programming. Audit reporting and reporting dashboards can be used to track execution steps when an incident occurs within your scheduled jobs, which is useful for forensic research on running jobs.
The easiest way
Using third-party IBM i job scheduled is the easiest way to secure your job schedule, implement least authority and separation of duties, provide audit reporting, and review job history. As opposed to using the native IBM i job scheduler, third-party packages will provide the framework needed to secure your job scheduling environment properly.
If you’re using the native IBM i job scheduler, we encourage you to look at upgrading to a third-party IBM i job scheduling package for better security, auditability, and reporting.