Re: System administration without production data access? -- MIDRANGE-L

Hi Loyd

This is one of my favourite topics; rest assured it can be done if you want to do it :) Personally I think its a good idea, but understand why often people resist it particularly in smaller shops.

The dedicated administrator could still be a programmer. Just have a dedicated administration profile on the production box. Turn on user auditing and audit the administration profile. I used to audit my own profile all the time as a matter of course; great for proving not only what I did do, but also what I didn't do; great for transparency; great for justifying anyone else with *ALLOBJ, command line or any unusual rights.

If required create an "emergency profile" with additional rights for programmers use in after hours situations that is logged and auditted as standard practise. Its useful to have a separate for emergency use only profile as it encourage people not to use it unless necessary.

As far as access to the data, I usually look to give the support people a normal user profile, that is an end user profile with inquiry rights or maybe some additional data input rights depending on what the person who authorised end users to data is comfortable with. The key here is that the programmer can get at data through a controlled and approved interface not a back door :)

It is imperative (in my opinion anyway) to consider the operations and administration in terms of an application to be audited and controlled and automated like any other. This helps reduce the "hands on" stuff to hackwork and aids in laying off at least some of the procedures.

PTF's and other operating systems are handled as change control items; write up a doc describing the change, log it, schedule it and do it as normal. What do you do now ?

Third party vendors is a tricky one. I usually take the line that if they can't explain it to me, or write down what has to be done so I can do it, then they don't understand the change well enough to be doing it themselves (this looks harsh even to me written down like that). I would expect that any required maintenance can be done in-house anyway, and anything else is a change control issue.

Even if the third party is to do it (or for those changes where it just makes sense to let a couple of developers log on and implement something due to the amount of work), I would expect that they advise me in advance, in detail, in writing what they are going to do, what their roll back plan is and that they use a profile that provides me with sufficient logging for me to establish/audit what they did.

Bakcups can be an in-house backup program, just document how it works and what the recovery plan is, no magic here. Consider it another application as discussed above.

Duplication of data to a test box is just a database population exercise; either restore the data from prod or keep a copy in a segregated library and refresh your test database as necessary.

Mostly (and I know I'll get screams about this) the problems with doing this are voiced by developers who don't want to change their ways. Yes, there are exceptions and special cases, and these are generally what gets dragged out as the reasons for not doing it, but keep in mind that they are the exceptions. If people need to keep logging on with QSECOFR rights to support the system then there is a more fundamental problem.

Hope this helps a bit.

Let the debate begin :)

Regards
Evan Harris

OK, I hear this all the time on the list: "Programmers should not have access
to production data (or even the production system)." This sounds great in
theory, but how does it work in practice? How is system administration handled
without "dedicated" system adminstrators versus developers? Assume a small
shop with two - three iSeries folks.
I can fill in some blanks, but what about others?
* Use source control to manage object moves from development to production.
* Use backup software such as Tivoli or BRMS.

How are the following handled in a "do not touch" production system?
* Applying PTFs or vendor software updates?
* Allowing third party vendors to "dial-in" and maintain their software?
* Duplication live production data for use in test/development, so the
development system feels "real"?

I've only worked in small shops thus far, but I understand the need for
segregated control. Our current internal auditors are clamoring for this, but
do not offer any advice on REAL system administration, only "you shouldn't be
able to do this, that, and those other things."

Thanks,
Loyd