Re: Securing the database from the DBA
From: Hans Forbrich <forbrich_at_yahoo.net>
Date: Fri, 09 Apr 2004 22:19:19 GMT
Message-ID: <HjFdc.27931$J56.15216_at_edtnps89>
>
> Systems need to be protected from anyone who should not have access to
> them. A security group probably only needs read-only access - access
> to the dictionary and audit trails, but not the application data.
>
>
> Separation of duties is one way of building checks and balances into
> the system. Having the DBA who maintains the database report into the
> security group (or the other way around) defeats that concept, so it's
> best to keep them as 2 distinct entities.
>
Date: Fri, 09 Apr 2004 22:19:19 GMT
Message-ID: <HjFdc.27931$J56.15216_at_edtnps89>
Joe wrote:
> Hans Forbrich <forbrich_at_yahoo.net> wrote in message
> news:<R8Adc.25679$J56.8600_at_edtnps89>...
>> Joe wrote: >> >> > We're in the same situation - trying to address the concerns of >> > Sarbanes-Oxley and FDA 21CFR Part 11. Like you said, it's a catch-22, >> > that you can't truly secure the database from the people who are >> > responsible for maintaining it. >> > >> >> Dumb question - does the system need to be protected from the security >> group?
>
> Systems need to be protected from anyone who should not have access to
> them. A security group probably only needs read-only access - access
> to the dictionary and audit trails, but not the application data.
>
For now <g>
>
>> If not, then why not make the DBA a member of that group?
>
> Separation of duties is one way of building checks and balances into
> the system. Having the DBA who maintains the database report into the
> security group (or the other way around) defeats that concept, so it's
> best to keep them as 2 distinct entities.
>
In which case monitor the s%!t out of the DBA's activities but let him/her do the bl$$dy job!
/H Received on Sat Apr 10 2004 - 00:19:19 CEST