Re: How to limit access to production data from non-production code?

From: Colin Butcher (colin_DOT.butcher_AT_at_xdelta_DOT.co_DOT.uk)
Date: 01/21/04 

Date: Wed, 21 Jan 2004 20:03:34 GMT

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 generally have three separate system environments - development, test
(sometimes an exact replica to avoid problems of scale) and production.
Having completely separate environments and systems helps you to think about
the software development / test / release process, especially the process of
delivering a software package to a target system.

If you make the process of delivery to the production environment fairly
difficult then it does help to reduce the problems introduced by the 'quick
hack' method. I find that it also helps if you make the process of hanging
the perpetrators of such misdeeds quite unpleasant and relatively public.
Tends to discourage others from following suit.

It all depends how mission-critical your systems are and how important you
job is to you.

In this case it sounds as if it's not hugely critical, so your approach may
be valid for cost reasons, but you do introduce a lot of effort and
associated costs for setting up the kind of environment you're thinking of.

Group logical name tables, application version specific logical name tables
and directory structures, rights identifiers, ACLs etc. seem like a way to
start. What about network access and proxy logins? How will you cope with
testing new OS and layered product versions if you don't have genuinely
separate environments? How will you cope with performance tuning the systems
to meet the changing needs of the application? And so on.

Seriously - please consider separate systems for separate functions. It's a
lot easier - and not so expensive if you use second-user hardware.

Also - to borrow an excellent quote from Larry - help for sorting out
complex problems afterwards is usually billed by the hour... 

-- 
Hope this helps, Colin.
colin DOT butcher AT xdelta DOT co DOT uk
Systems Archaeologist - Investigation & troubleshooting of older systems and
networks.

Relevant Pages

  • Re: Security around Solaris 10 zones
    ... trust relations between the automount daemon and the kernel ... >would you feel confident in putting them into sensistive production ... >development/test environments and less sensitive prod environs, ... to opinions held by my employer, Sun Microsystems. ...
    (comp.unix.solaris)
  • RE: BAM Excel live book
    ... We have various BizTalk environments setup, Development, ... User Acceptance Testing and Production ... We have Office XP installed only on our development server ... >>Is it possible to create BAM infrastructure using XML ...
    (microsoft.public.biztalk.general)
  • Re: How to limit access to production data from non-production code?
    ... Have separate development and production ... > Never mix development, test and production environments. ... I returned to the task in hand, deleting the database for the next task. ... underway, and the recovery time was bearable, the most recent backup was ...
    (comp.os.vms)
  • Application_Error Public event not being handled
    ... development machines but once in the production environment, it fails, ... The only difference between production and development environments is the ... In both environments we are using StateServer for Session ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Math in Table?
    ... Don't create a separate table for each production line. ... > scheduled pounds, pounds packed, labor hours, pounds per ... > or do I need for it to be done in a query or report ...
    (microsoft.public.access.tablesdbdesign)
Quantcast