Re: Securing the database from the DBA

[Hans Forbrich]

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? If not, then why not make the DBA a member of that group?

/Hans

[Joe]

Hans Forbrich <fo******@yahoo.netwrote in message news:<R8Adc.25679$J56.8600@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.

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.

--
Joe
http://www.cafeshops.com/joekaz
http://www.joekaz.net/

[Hans Forbrich]

Joe wrote:

Hans Forbrich <fo******@yahoo.netwrote in message
news:<R8Adc.25679$J56.8600@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