Re: How to limit access to production data from non-production code?
From: Nic Clews (sendspamhere_at_[127.0.0.1)
Date: 01/22/04
- Next message: Bob Koehler: "Re: How to do Bootable Image Backup ?"
- Previous message: Didier Morandi: "QANN=5D_First_Annual_VAXUS_Symposium_?= in Paris (French communiqué)"
- In reply to: Colin Butcher: "Re: How to limit access to production data from non-production code?"
- Next in thread: konabear: "Re: How to limit access to production data from non-production code?"
- Reply: konabear: "Re: How to limit access to production data from non-production code?"
- Reply: Peter Weaver: "Re: How to limit access to production data from non-production code?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 22 Jan 2004 13:26:38 +0000
Colin Butcher wrote:
>
> Larry's giving you sound advice. Have separate development and production
> systems. Ruthlessly enforce the separation.
>
> Have a representative test environment, using copies of real data if need
> be - maybe even use the process to test the restore of yesterday's
> production backup.
>
> Never mix development, test and production environments. If things can go
> wrong - they will, usually when you least expect it or can least tolerate
> it.
I've a war story I've not recounted publicly before now. Things got done
differently after this. It's a few years ago too, not here.
Whilst we had a production and a development system for the main
applications, the development system typically was a 'lesser' system,
lower powered, and more importantly less disk space.
This let to a problem, the development system did not have enough space
for all the required development. So, as you've probably guessed, the
live system was used to provide a development area, with some clever
repointing of logicals in the same way we segregated multiple production
environments. This involved remapping to different group tables, the
names remained the same.
So there I was, testing completed. I was distracted (support call). Then
I returned to the task in hand, deleting the database for the next task.
You guessed, the production database went.
deleted... deleted... deleted... file open by another user... deleted...
deleted...
Immediately I 'phoned the application manager/owner, told him what had
happened, the processes then started to fall in a heap, so we stopped
the application (usual stop procedure, forced exit, stop/id) then
decided how to recover.
Fortunately, the database had a journalling file on another data area,
so we recovered the data from the last good backup, and allowed the
database to roll itself forwards. Transactions are paired over a number
of hours and the manager reckoned he'd lost about 2 or 3 transactions,
(out of several thousand per day) which he manually adjusted for after
database reconciliation.
In this case I was extremely lucky, an understanding (but annoyed)
application owner, an application capable of withstanding and recovering
from the damage inflicted at it, no time critical processing was
underway, and the recovery time was bearable, the most recent backup was
"nearline" (on a "backup disk" and tape recovery wasn't required), the
missing transactions could be reconstructed manually from the "other" of
the pair with an assumption. I wasn't disciplined for the events as I'd
taken appropriate actions, but the events and causes were examined
independently, and procedures and a physical separation was achieved of
the two environments (extra necessary hardware, now with justification).
One of the things introduced was the usage of _different_ accounts,
rather than repointing logicals, using ACL's, and just using a single
(privileged) account. Using a single account to seamlessly switch was a
prime cause. Perhaps it may be easy to argue that multiple accounts per
number of users is a security risk, but security also means keeping data
safe from accidental loss or destruction.
-- Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences nclews at csc dot com
- Next message: Bob Koehler: "Re: How to do Bootable Image Backup ?"
- Previous message: Didier Morandi: "QANN=5D_First_Annual_VAXUS_Symposium_?= in Paris (French communiqué)"
- In reply to: Colin Butcher: "Re: How to limit access to production data from non-production code?"
- Next in thread: konabear: "Re: How to limit access to production data from non-production code?"
- Reply: konabear: "Re: How to limit access to production data from non-production code?"
- Reply: Peter Weaver: "Re: How to limit access to production data from non-production code?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
