The goal is to assign application security to a group then add the group to the user's definition. When a person transfers then you add and deleted groups to the user while the user keeps access to personal datasets.
On Fri, Aug 4, 2023, 15:51 Steve Thompson <[email protected]> wrote: > Don't know if TSS implements groups. But with groups, I can have > access to certain DSNs read only, others update|delete|create. I > can have access to console commands from TSO, but not have logon > access to CICS. Just as examples. > > Having to change TSO IDs is problematic because one loses access > to their private data sets... (tools you wrote for making > ISPF/Roscoe or whatever better...). > > So role based using group definitions that give one authority > until they don't need it (or can't justify it), is what I think > you mean and need. > > Steve Thompson > > On 8/4/2023 4:25 PM, Wayne Bickerdike wrote: > > To implement this would require systems that implement application > > security. The idea that a systems programmer of any type would be able to > > perpetrate fraud is a stretch. > > > > I had access to everything mainframe (RACF, CICS, z/OS) in a top secret > > installation. I wouldn't be able to place a purchase order but I could > nuke > > any dataset. I was also too damn busy doing my job to compromise the > > systems. > > > > The worst case is where staff inherit privileges as they change roles. > That > > was a problem. Makes a case for role based security. Change roles > New > > role based ID. > > > > On Fri, Aug 4, 2023 at 11:34 PM Michael Babcock <[email protected]> > > wrote: > > > >> I ran across this in a CICS security admin book (which should also apply > >> to z/OS sysprogs): > >> > >> Roles and separation of duties > >> > >> A key security principle is the separation of duties between > >> different users so that no one person has sufficient access privilege to > >> perpetrate damaging fraud. *This configuration is required by various > >> audit regulations such as the United States Federal Law known as the > >> Sarbanes-Oxley Act of 2002 > >> < > >> > https://www.ibm.com/links?url=https%3A%2F%2Fwww.govinfo.gov%2Fcontent%2Fpkg%2FPLAW-107publ204%2Fpdf%2FPLAW-107publ204.pdf > >>> .* > >> An example of this separation of duties, is that someone with the > >> role of CICS System Programmer must not also have the role of RACF > >> Security Administrator. > >> > >> > >> Does anyone know exactly which section of SOX it's referring to? > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to [email protected] with the message: INFO IBM-MAIN > >> > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
