RE: System administration without production data access?

I used to be the tech support/system administrator at a small bank & finance
business; the internal auditors were paranoid (IMHO) about system security;
the activation of the system auditing journal allayed most of their fears
... plus the standard controls of profiles & passwords.  I made available to
them each month a database created from the audit journal - to my certain
knowledge, they NEVER analysed it.  Providing they have the ability to
accurately work out where to point the finger of blame when something goes
wrong, they are happy.

I'm sure that statistics would prove that the most serious system damage is
caused by employees with valid and appropriate user ids and passwords; the
damage does not have to be intentional to be serious - I have had a few
bloopers over the years, and fortunately the damage was not too costly.
Accidents and sabotage are all too easy even with tight controls.

A company's IT staff have a duty of care to their employers property, and
how seriously this trust is exercised will certainly have an effect on the
number and gravity of data loss/damage events.  On the other hand, the
management need to be in close touch with all their employees, particularly
those with 'power profiles' on the computer systems. I do not believe that
sabotage in this area is totally unpredictable, and some accidents too can
be avoided by being aware of over-confidence, over-tiredness etc among the
IT staff.

As a matter of course on my iSeries, I have at least two user profiles, one
with minimal authority for daily use, and one *SECOFR profile for only when
I need it.  When signed on with the *SECOFR profile I work at half-speed,
double checking EVERY command before I issue it - the iSeries can be very
unforgiving when you issue a valid but wrong command - there are very few
'Are you sure?' confirmations.

Good grief ... I'm waffling on ... shut up Jeff.

Kind regards,

Jeffrey E. Bull
OS400 Software Support Consultant

IBM Certified Systems Expert, iSeries Technical Solutions
IBM Certified Systems Specialist, AS/400 System Administration

*      +44 [0] 149 454 9533               swb.   +44 [0] 149 454 9400
mbl.     +44 [0] 786 750 4961               fax.    +44 [0] 149 454 9454
web.     http://www.itm-group.co.uk
 
ITM Group Ltd, Latimer Square, White Lion Road, Amersham, Buckinghamshire,
HP7 9JQ, United Kingdom


-----Original Message-----
From: Evan Harris [mailto:spanner@xxxxxxxxxx]
Sent: 02 February 2004 11:13
To: Midrange Systems Technical Discussion
Subject: Re: System administration without production data access?


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

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


________________________________________________________________________
This e-mail has been scanned for all viruses by ITM. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, 
email marketing@xxxxxxxxxxxxxxx
ITM - Managing Communication and Information through technology
Company registration number - 3783433
________________________________________________________________________


DISCLAIMER

Any opinions expressed in this email are those of the
individual and not necessarily the Company. This email
and any files transmitted with it, including replies and
forwarded copies (which may contain alterations) 
subsequently transmitted from the Company, are 
confidential and solely for the use of the intended recipient. If you are not 
the intended recipient or the 
person responsible for delivering to the intended recipient, 
be advised that you have received this email in error and
 that any use is strictly prohibited.

If you have received this email in error please notify the IT
manager by telephone on +44 (0)870 871 2233 or via 
email to Administrator@xxxxxxxxxxxxxxx, including a copy
of this message. Please then delete this email and 
destroy any copies of it.

________________________________________________________________________This 
e-mail has been scanned for all viruses by ITM. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, 
email marketing@xxxxxxxxxxxxxxx
ITM - Managing Communication and Information through technology
Company registration number - 
3783433________________________________________________________________________