IBM Workload Scheduler for z/OS Security with RACF & IBM zSecure

IBM Systems & IBM Security
© 2018 IBM Corporation
IBM zSystems
IT Service Management
IBM Workload Scheduler for z/OS
Security
with RACF & IBM zSecure
Domenico (Nico) Chillemi
IBM Executive IT Specialist
nicochillemi@it.ibm.com
Best Practices

zSystems & zSecurity
Ciao 
IBM Mainframe
50 years old
Strong
Batch
experience
IBM Academy of Technology
z Platform Initiatives Leader
zChampion
2
IBM Workload Scheduler
RACF & zSecure
zStorage Rocket Tools
System Automation
Log Analytics Tools

zSecure components
RACF commands
RACF db
SMF
RACF
zSecure Admin
zSecure
Alert
zSecure
Audit
z/OS + UNIX + DB2 + CICS + IMS configuration info
z/OS
DB2
CICS
S
A
F
zSecure Visual
zSecure CICS
Toolkit
zSecure Command Verifier
SIEM
Other

IBM Workload Scheduler for z/OS components
Info Mgmt
IWS for
z/OS/ES
A
Monitoring
ALLSYSTEMSCITY1 CITY2
CITY
3
ISPF
Z/OS Domain
IWS z/OS
Agents
IBM
Workload
Console
Websphere
Application
Server
IWS Distributed
zCentric Agents
IWS z/OS
Engine
Sysplex
MAS
DASD
XCF
FTP

Main IWSz concepts and objects
 Database
– Batch applications
– Workstations
– Calendars
 Plans
– Long Term Plan
– Current Plan
 Run Cycles
 JOBs
 Generic Operations
 Commands
 JOBLOGs
 .....

IBM Workload Scheduler for z/OS - What to consider for protection
 IWSz data sets
– This can be done just protecting all data sets needed to IWSz address spaces to start
 Subsystem (Controller/Tracker/Server) USERID
– Any IWSz address space needs to be associated with a user, which can be the same for
more than one subsystem
– This user has to be registered in the STARTED RACF class
 IWSz Subsystems
– Any direct access to IWSz or also via any kind of interface (Console, API, etc...) can be
prevented or authorized through the APPL RACF Class
 IWSz Objects
– Any access to AD, CP, or also for example to specific IWSz jobs, can be prevented or
authorized
 IWSz Commands
– One or more typical IWSz commands can be prevented or authorized
6

IWSz - What to consider for protection (RACF)
 IWSz data sets
ADDSD IWS.V9R3.** UACC(N) OWNER(NICO)
PERMIT IWS.V9R3.** ACC(ALTER) ID(IWSUSER AdminGrup)
 Subsystem (Controller/Tracker) USERID
ADDUSER IWSSTC DFLTGRP(Admin) OWNER(NICO) NOPASSWORD ....
RDEF STARTED IWS*.* STDATA( USER(IWSSTC) .....)
PERMIT IWS.V9R3.** ACC(ALTER) ID(IWSSTC)
 IWSz Subsystems
RDEF APPL IWS9 UACC(N) OWNER(NICO)
PERMIT IWS9 CLASS(APPL) ACC(R) ID(.......)
7

IWSz - What to consider for protection (zSecure)
8

Protect IWSz Objects with RACF
9
 One dedicated RACF Class, already defined in RACF
– IBMOPC dedicated RACF Class
• Automatically activated
• We can have others dedicated, to be defined to RACF
– Activated in IWSz with the AUTHDEF initialization statement
 Other RACF classes can be defined in RACF
– Dynamically or via job
 Two protection levels
– IWSz Fixed Resources (AD, WS, LT, CP, ...)
• All activated if IBMOPC activated both in RACF and in AUTHDEF
– IWSz Subresources (Specific objects inside each resource)
• Only those specified in the AUTHDEF initialization statement are activated

IBM Workload Scheduler for z/OS Parameters Example
 IWSz PARMLIB
– IWSz Fixed Resources
AUTHDEF CLASS(IBMOPC)
– IWSz Subresources
SUBRESOURCES(AD.ADNAME,
AD.OWNER,
WS.WSNAME,
LT.ADNAME,
CP.JOBNAME,
JS.JOBNAME,
.....)
RACF
Resource
ADA.**
ADO.**
CPJ.**

Fixed Resources protection (1st level)
 Application Description, Current Plan, JS, etc...
RDEF IBMOPC (AD) UACC(N)
RDEF IBMOPC (CP) UACC(N)
RDEF IBMOPC (JS) UACC(N)
…
PERMIT AD CLASS(IBMOPC) ACC(U) ID(Admin)
PERMIT CP CLASS(IBMOPC) ACC(U) ID(Admin)
PERMIT JS CLASS(IBMOPC) ACC(U) ID(Admin)
…
PERMIT AD CLASS(IBMOPC) ACC(U) ID(Grup1)
PERMIT CP CLASS(IBMOPC) ACC(U) ID(Grup1 Grup2)
PERMIT JS CLASS(IBMOPC) ACC(U) ID(Grup1 Grup2 Grup3)
11

Subresources protection (2nd level)
 Specific applications, specific jobs, etc...
– Applications by owner-name
RDEF IBMOPC (ADO.NIC*) UACC(N)
PERMIT ADO.NIC* CLASS(IBMOPC) ACC(U) ID(Admin)
– Long term plan objects by application-name
RDEF IBMOPC (LTA.APPL1*) UACC(N)
PERMIT LTA.APPL1* CLASS(IBMOPC) ACC(U) ID(Grup1)
– Current plan objects by job-name
RDEF IBMOPC (CPJ.J01*) UACC(N)
PERMIT CPJ.J01* CLASS(IBMOPC) ACC(U) ID(Grup1 Grup2)
– JS objects by job-name
RDEF IBMOPC (JSJ.J01*) UACC(N)
PERMIT JSJ.J01* CLASS(IBMOPC) ACC(U) ID(Grup3)
12

zSecure – Fixed Resources and Subresources
13

Enhanced Security in Workload Automation for z/OS
(last IWSz 9.3 SPE)
Value Solution
 More granularity in security
access help guarantee product
stability
 Secure actions, in addition to
data
 Security access can now be
controlled at any level, from
object level down to action level

AUTHDEF
COMMAND1(J,ARC,…)
SUBRESOURCES(CP.ADDOPER,
CP.COMMAND1)
RACF Commands
RDEF IBMOPC CP.ADDOPER
PERMIT CP.ADDOPER ID(JASON) ACCESS(UPDATE)
CLASS(IBMOPC)
Fixed
resource
Subresource &
RACF resource
name
Description
CP CP.ADD Add workload (occurrences or operations)
CP.MODIFY Modify attributes
CP.DELETE Delete workload (occurrences or
operations)
CP.COMMANDx Line commands
CP.ADDOPER Add operations
CP.DELOPER Delete operations
CP.MODOPER Modify operations
CP.ADDDEP Add dependencies
CP.DELDEP Delete dependencies
CP.MODDEP Modify dependencies
CP.MODOPSTAT Modify operation status
• Define actions as sub-resources in
AUTHDEF statement
• Use RACF commands to provide/deny
access to users
IWSz Security Enhancements
Occurrence Commands
• RG Remove from group
• DG Delete group
• CG Complete group
• C Complete an occurrence
• W Set waiting
• R Rerun
Operation Commands
 J Edit JCL (J command resource)
 MH, MR Manual Hold, Manual Release (MR, MH command
resources)
 NP, UN NOP,UN NOP (NP, UN command resources)
 K Kill (K command resource)
 EX Execute (EX command resource)
 JR/FJR JT, Fast path JR (JR command resource)
 SR/FSR SR, Fast path SR (SR command resource)
 SC/FSC SC, Fast path SC (SC command resource)
 SJR Simple Job Restart Execute (SJR command resource)
 R Reset Status (MODOPSTAT resource)
 BIND Bind operation (BND command resources)
 N Set NEXT logical status (MODOPSTAT resource)
 N-x Set specific status (MODOPSTAT resource)

Enhanced IWSz Security - Scenarios
Tim, the System
Administrator
Tim can now authorize Jason, the
Scheduler, to add operations to the
Current Plan.
In the same time, he can prevent him
from adding new occurrences.
Jason, the scheduler
Tim can secure a set of commands, creating new User
Profiles.
• He can authorize Jane to perform a recovery action, but prevent
her from editing a job
• He can authorize Jason to Complete and Rerun an existing
occurrence, but prevent him from adding new occurrences
Jane, the Application Developer
1 2

• Define the CP.ADD and CP.ADDOPER
subresources in the AUTHDEF
SUBRESOURCES(CP.ADD,CPADDOPER)
(AUTHDEF statement)
• Define them to RACF and give universal
NONE access by default
RDEF IBMOPC CP.ADD
RDEF IBMOPC CP.ADDOPER
• Give user Jason update access to the
CP.ADDOPER resource
PERMIT CP.ADDOPER ID(MARNIE)
ACCESS(UPDATE) CLASS(IBMOPC)
To allow Jane to perform “ARC” (Automatic Recovery)
and Jason to perform “C” (Complete occurrence) and “R”
(Rerun Occurrence) commands:
• Define the CP.COMMANDx subresources
in the AUTHDEF
AUTHDEF CLASSNAME(IBMOPC)
COMMAND1(ARC, C, R)
SUBRESOURCES(CP.COMMAND1)
• Define to RACF
RDEF IBMOPC CP.ADD
• Give Jane update access to
CP.COMMAND1
PERMIT CP.COMMAND1 ID(JANE)
ACCESS(UPDATE) CLASS(IBMOPC)
1
2
Enhanced IWSz Security - Scenarios

Subresources protection with the last IWSz 9.3 SPEs
 AUTHDEF in IWSz PARM
AUTHDEF CLASSNAME(IBMOPC) COMMAND1(ARC, C, R)
SUBRESOURCES(CP.COMMAND1)
 RACF RESOURCE DEFINITION
RDEF IBMOPC CP.COMMAND1
 PERMIT TO DEVELOPERS
PERMIT CP.COMMAND1 ID(Grup3) ACCESS(UPDATE) CLASS(IBMOPC)
18

IBM New Security Enhancements Parameters Example
 IWSz PARMLIB
SUBRESOURCES(CP.COMMAND1,
CP.COMMAND2,
.....)
COMMAND1(ARC, C, R)
COMMAND2(M, L)
...
RACF
Resource
CP.COMMAND1
CP.COMMAND2

Quick zSecure Scenario - IWSz 9.3 SPE example
20

zSecure Command Verifier and IWSz
 When acting on resources in RACF, often the SPECIAL
attribute is required
 Also in IWSz this can be a problem, since a SPECIAL user
can do much more
 With only RACF this problem is not solved
 zSecure Command Verifier allows to limit SPECIAL users
power
 IWSz can strongly benefit by this zSecure capability
21

zSecure Command Verifier in Action
22
RACF db mgr
TSO/ISPF
RACF
commands
+ output
zSecure Admin
Cmds RACF
commands
RACF
profiles
Command Verifier
EXIT
Policy
SMF

zSecure CV Best Practices examples with IWSz
 Suppose you would like to establish a IWSz RACF
compliance rule, saying that development people inside a
department can define only IWS Application Description
profiles for applications starting with TIV*.
 The objective is to prevent RACF accepting any IWS profile
creation, other than a IWS Application Description profile
matching the TIV* wildcard, issued by a user belonging to the
TIVCFG group.
 The first thing to do is to define the generic C4R profile saying
that TIVCFG cannot add IWS for zOS profiles
 This is done by adding the C4R.IBMOPC.ID.* profile to the
C4R class
23

24

25
YES
NO

Typical zSecure Command Verifier DEVOPS Scenario
with IBM Workload Scheduler for z/OS
 Suppose we need to establish IWSz RACF compliance rule, saying that:
– PAYROLL administrators can define IWSz resources, based on payroll batch
applications their teams are responsible for
• PAYROLL application developers can define only with IWSz applications they are responsible for
– REPORTING administrators can define IWSz resources, based on reporting batch
applications their teams are responsible for
• REPORTING application developers can define only IWSz applications they are responsible for
 There will be 3 types of figures in this scenario:
– RACF administrator
– PAYROLL administrator and REPORTING administrator
– PAYROLL developers and REPORTING developers
26

PAYROLL and REPORTING DEVOPS Scenarios
 RACFADM is the RACF Administrator
– Creates Command Verifier profiles to authorize PAYROLL and REPORTING administrators, with SPECIAL attribute, to
create only specific PAYROLL and REPORTING IWSz RACF profiles
 IWSPAYR is the IWSz Payroll Administrator
– Creates RACF profiles for different Payroll IWSz applications
 IWSREPT is the IWSz Reporting Administrator
– Creates RACF profiles for different Reporting IWSz applications
 IWSGPAY1 is the IWSz Payroll Application Developers 1 Team
– Users connected to this RACF group will be authorized to define only IWSz applications with names starting with PAYR1
 IWSGPAY2 is the IWSz Payroll Application Developers 2 Team
– Users connected to this RACF group will be authorized to define only IWSz applications with names starting with PAYR2
 IWSGRPT1 is the IWSz Reporting Application Developers A Team
– Users connected to this RACF group will be authorized to define only IWSz applications with names starting with REPTA
 IWSGRPTB is the IWSz Reporting Application Developers B Team
– Users connected to this RACF group will be authorized to define only IWSz applications with names starting with REPTB
27

Administrators work in this scenario
 RACFADM
– RDEF C4R C4R.IBMOPC.ID.** UACC(N) OWNER(RACFADM)
– RDEF C4R C4R.IBMOPC.ID.ADA.PAYR* UACC(N) OWNER(IWSPAYR)  1st line
– RDEF C4R C4R.IBMOPC.ID.ADA.REPT* UACC(N) OWNER(IWSREPT)  2nd line
 IWSPAYR
– RDEF IBMOPC ADA.PAYR1* UACC(N) OWNER(IWSPAYR)  matches (1st line)
– RDEF IBMOPC ADA.PAYR2* UACC(N) OWNER(IWSPAYR)  matches (1st line)
– PERMIT ADA.PAYR1* ACCESS(U) ID(IWSGPAY1) CLASS(IBMOPC)
– PERMIT ADA.PAYR2* ACCESS(U) ID(IWSGPAY2) CLASS(IBMOPC)
 IWSREPT
– RDEF IBMOPC ADA.REPTA* UACC(N) OWNER(IWSREPT)  matches (2nd line)
– RDEF IBMOPC ADA.REPTB* UACC(N) OWNER(IWSREPT)  matches (2nd line)
– PERMIT ADA.REPTA* ACCESS(U) ID(IWSGRPTA) CLASS(IBMOPC)
– PERMIT ADA.REPTB* ACCESS(U) ID(IWSGRPTB) CLASS(IBMOPC)
28

Results
 ITUSER01 is connected to IWSGPAY1
– ITUSER01 can access IBM Workload Scheduler for z/OS
• He/She can define/update PAYR1APPL001, PAYR1APPLXXX, ...
• He/She cannot define/update PAYR2APPZZZ, REPTAAPPKKK, BANKAPP1, ...
 ITUSER25 is connected to IWSGPAY2
• He/She can define/update PAYR2APPL001, PAYR2APPLXXX, ...
• He/She cannot define/update PAYR1APPZZZ, REPTBAPPKKK, BANKAPP1, ...
 ITUSER71 is connected to IWSGRPTA
• He/She can define/update REPTAAPPL001, REPTAAPPLXXX, ...
• He/She cannot define/update PAYR2APPZZZ, REPTBAPPKKK, BANKAPP1, ...
 ITUSER95 is connected to IWSGRPTB
• He/She can define/update REPTBAPPL001, REPTBAPPLXXX, ...
• He/She cannot define/update PAYR2APPZZZ, REPTAAPPKKK, BANKAPP1, ...
29

Command Verifier Scenario with new IWSz enhancements
 Suppose we need to establish IWSz RACF compliance rule, saying that:
– PAYROLL administrators can define IWSz command resources, based on payroll
batch applications their teams are responsible to test
• PAYROLL application testers can test only IWSz Payroll RERUN in the Current Plan
– REPORTING administrators can define IWSz resources, based on reporting
batch applications their teams are responsible to test
• REPORTING application testers can test only IWSz browse joblog in the Current Plan
 There will be 3 types of figures also in this scenario:
– RACF administrator
– PAYROLL administrator and REPORTING administrator
– PAYROLL testers and REPORTING testers
Note: We assume here that all appropriate Current Plan RACF protections have
been performed for both PAYROLL and REPORTING applications!
30

Testing (last IWSz enhancements) DEVOPS Scenarios
 RACFADM is the RACF Administrator
– Creates Command Verifier profiles to include PAYROLL and REPORTING commands
 IWSPAYR is the IWSz Payroll Administrator
– Creates RACF profiles for Payroll tester groups
 IWSREPT is the IWSz Reporting Administrator
– Creates RACF profiles for Reporting tester groups
 IWSGPAYT is the IWSz Payroll tester group
– Users connected to this RACF group can test only the RERUN (R) command related to PAYROLL
occurrences
 IWSGRPTT is the IWSz Reporting tester group
– Users connected to this RACF group can test only the BROWSE JOBLOG (L) command related to
PAYROLL occurrences
31

Enable R and L different commands in IWSZ
 IWSz PARMLIB
– AUTHDEF CLASS(IBMOPC)
SUBRESOURCES(CP.COMMAND5,
CP.COMMAND7)
COMMAND5(R)
COMMAND7(L)
 RACFADM
– RDEF C4R C4R.IBMOPC.ID.** UACC(N) OWNER(RACFADM)
– RDEF C4R C4R.IBMOPC.ID.CP.COMMAND5 UACC(N) OWNER(IWSPAYR)
– RDEF C4R C4R.IBMOPC.ID.CP.COMMAND7 UACC(N) OWNER(IWSREPT)
 IWSPAYR
– RDEF IBMOPC CP.COMMAND5 UACC(N) OWNER(IWSPAYR)
– PERMIT CP.COMMAND5 ACCESS(U) ID(IWSGPAYT) CLASS(IBMOPC)
 IWSREPT
– RDEF IBMOPC CP.COMMAND7 UACC(N) OWNER(IWSREPT)
– PERMIT CP.COMMAND7 ACCESS(U) ID(IWSGRPTT) CLASS(IBMOPC)
–32

Results
Considering that appropriate Current Plan RACF protections have been
done for both PAYROLL and REPORTING applications, we will get:
 ITUSER51 is connected to IWSGPAYT
• He/She can test the RERUN command on all PAYROLL occurrences
• He/She cannot test any other command
 ITUSER73 is connected to IWSGRPTT
• He/She can test the BROWSE JOBLOG command on all REPORTING occurrences
• He/She cannot test any other command
33

34
Thank You

IBM Workload Scheduler for z/OS Security with RACF & IBM zSecure

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to IBM Workload Scheduler for z/OS Security with RACF & IBM zSecure

Similar to IBM Workload Scheduler for z/OS Security with RACF & IBM zSecure (20)

Recently uploaded

Recently uploaded (20)

IBM Workload Scheduler for z/OS Security with RACF & IBM zSecure