On Sat, 23 Dec 2017, at 19:42, Jon Perryman wrote: > Naming conventions only go so far in securing departmental data because > of exceptions. For instance, there is departmental overlap such as > payroll and general ledger.
But if there's proper separation between production ids (which run the programs etc) and user departments (those who use the reports etc produced by the programs), there's still not a problem. You're right of course that some of the payroll & general ledger programs will have to access each other's files... but it's a known relationship, which gets coded into the security rules. And, yes, it'll change from time to time, as programs and needs change, but you don't just let any idiot change the rules. > As for "Production being executed by a user", forgive me if I implied > that. I was specifically saying production being executed by a > production user id. To clarify, I was saying that since you don't have > access, you must somehow get another user to execute your program. The > production user is only one method. If you wanted access thru someone, a > simpler method would be to ask a colleague to run your program to see if > they get the same results, error or any reason they encounter > occasionally. But... it wouldn't have mattered if I'd asked every colleague to run a copy of a production program; none of US had access. None of us - indeed no human user at all - could run a program under a production userid. > As for "production required actions", these are processes. Processes are > never 100%. An employee understands these processes and if motivated > enough will find where these processes fail. I do agree that collusion between people is a problem. But if people set out to find holes in processes that install programs, set up files etc... they're likely to be found out by the trail of RACF violations they leave behind them. Of course if no-one follows those up... > >I said 6. Most employee's have full control for their datasets and > > allow anyone to allocate and write them. > > Sorry, I said "allow" but meant "can allow" or better yet "can > authorize". Often, user's are allowed to change security rules on their > own datasets. I worked at an ACF2 site; is RACF different? ACF2 rules couldn't be changed by anyone except those whose job it was. Rules got changed only when change requests had been properly signed-off. Yes, I'm sure not every person who authorised such a change had a proper understanding of the impact... but the people who actually made the changes did understand what they were doing. As far as I remember changes were audited on the following day, by other people (working from compare listings of changed rules, I think). -- Jeremy Nicoll - my opinions are my own.
