We all think about the obvious and standard governance that we need around AutoSys. Note 5 verizon root. Well at least I hope we all do. First I will mention some of the most common practises to ensure governance and security. I am sure there is probably quite a degree of disagreement on this, I am in no way suggesting this it the ultimate list.
The permission based
Autocalasc is the utility that helps maintain the calendars in Autosys Syntax. Administer Extended Calendar. 3 Administer Cycle. 4 List all Calendars. Autosys run every 2 hours Autosys run every 2 hours. Step 3: Give option 5 (Preview an Extended Calendar). Step 4: Paste the calendar name. Step 5: Now you can view the preview an Extended calendar. Create Calendar In Autosys Of Holidays Autosys Run Calendar. 2–35 iv User Guide. Days to NOT Run Through a Custom Calendar. This guide is for users responsible for defining jobs to Unicenter.
- Read only access to Production
- Read only access to Staging/PreProduction
- Full access in Test and Development
- Execute access for Operations in Production and Staging/PreProduction
- Possibly full access for the AutoSys support team accross the board
The Controls based
- Restrict who can have jobs run as root or Administrator
- Restrict who can run jobs on specific servers
- Who can promote job to which environment
Now for the bit that I am not sure people consider or think about, again this is my view, some people/sites might actually be doing/considering all of the below. If anyone is doing it then I would like to hear their thought and how they are doing it.
There is one really big weakness that I have been pondering when it comes to governance and controls around AutoSys this being with regard to promotion of jobs from one environment to another.
Generally when a job is promoted from Development/Test to UAT/Staging/PreProduction or UAT/Staging/PreProduction to Production the following checks are normally done:
- Valid or correct Production owner
- Valid or correct Production Server
- Valid std_in/std_out paths
- Valid job naming standards
- Valid or correct calendars or scheduling criteria
- Valid or correct dependencies
All those will ensure we have a fairly stable and compliant Production environment, but the one aspect I believe is not being checked and is possibly more important than the above is the actual Command.
Why is it important?
- How do we know what the command does?
- How do we know it is not malicious?
- Is it safe?
- Is it fraudulant?
- Does it provide someone with non standard or not allowed access to data or systems?
I am sure the list of why it is important is much longer than the points I have made.
So that leads to the question, Why are we not doing enough validation on the command being executed by the AutoSys job?
Autosys Extended Calendar Definition
Well the simplest and possibly truest answer is that it is difficult, thus easier to just ignore and trust most people are honest etc.
What should we do about it?
Autosys Extended Calendar Conditions
I believe that we should work at finding a solution to enable us to validate the commands being executed by the AutoSys jobs. One thing I can tell you is that is will not be easy and it will depend a lot on the individual organisation and the controls and level of standardisation with each organisation.
Hendry
Comments are closed.