Best Practice for SQL Server security

Our database section is relatively new. The SQL Servers were setup
before our creation and the security is our first area of concern.
Currently, there is a .NET 1.1 COM layer that handles all database
access. It is using a single NT domain account with read/write to all
the databases and execute on the user stored procedures. From what I'm
told, all the business rules for applications (mostly web apps) are
handled in the COM layer.
Our section feels that this is not a secured model from a database
perspective. We want each application to have a unique login to SQL.
Each application would have read/write/execute on its main database as
it does currently, however data access to other databases would be
tightly controlled by the allowing only enough privileges to accomplish
the business objective.
We are hitting massive battles from a small section of our
application developers who insist that the current model is most
secure. Our stance is that we don't trust the middle tier because of
the amount of human coding involved and the lack of auditability on
database security. They have proposed a solution where each COM object
has it's own unique ID, but any application can call any COM object
with read/write/execute in any database - this is not acceptable to us.
My question is - what is the best practice? What are you doing for
security with a "trusted" middle-tier.Hi
http://vyaskn.tripod.com/sql_server...t_practices.htm --sec
urity
best practices
"PSPDBA" <DissendiumDBA@.gmail.com> wrote in message
news:1165926885.850901.28250@.n67g2000cwd.googlegroups.com...
> Our database section is relatively new. The SQL Servers were setup
> before our creation and the security is our first area of concern.
> Currently, there is a .NET 1.1 COM layer that handles all database
> access. It is using a single NT domain account with read/write to all
> the databases and execute on the user stored procedures. From what I'm
> told, all the business rules for applications (mostly web apps) are
> handled in the COM layer.
> Our section feels that this is not a secured model from a database
> perspective. We want each application to have a unique login to SQL.
> Each application would have read/write/execute on its main database as
> it does currently, however data access to other databases would be
> tightly controlled by the allowing only enough privileges to accomplish
> the business objective.
> We are hitting massive battles from a small section of our
> application developers who insist that the current model is most
> secure. Our stance is that we don't trust the middle tier because of
> the amount of human coding involved and the lack of auditability on
> database security. They have proposed a solution where each COM object
> has it's own unique ID, but any application can call any COM object
> with read/write/execute in any database - this is not acceptable to us.
> My question is - what is the best practice? What are you doing for
> security with a "trusted" middle-tier.
>|||Thanks, that document helps. I think I'm more looking for an overall
approach to security. Are there other DBAs out there that are fully
trusting the COM objects? I confess I don't know much about COM, but
I feel really uneasy about allowing an object out of our control the
access that it has.
Even in their updated model (each COM has it's own Login) we still
wouldn't know if application A is using database A, database B,
database C, etc.. and which tables in those other databases.
I need ammo to go to our next meeting and show them how this isn't
secure from our perspective. We also have SQL Log Rescue, so we have
the ability to scour the logs for info - but we can't tell who is doing
what because it all shows that it's the COM account accessing the db.
Uri Dimant wrote:[vbcol=seagreen]
> Hi
> http://vyaskn.tripod.com/sql_server...t_practices.htm --s
ecurity
> best practices
>
>
>
>
> "PSPDBA" <DissendiumDBA@.gmail.com> wrote in message
> news:1165926885.850901.28250@.n67g2000cwd.googlegroups.com...|||Wow. I had the exact discussion recently and would be very interested to
see other opinions and info on this also.
J
"PSPDBA" <DissendiumDBA@.gmail.com> wrote in message
news:1165934077.707745.266260@.79g2000cws.googlegroups.com...
> Thanks, that document helps. I think I'm more looking for an overall
> approach to security. Are there other DBAs out there that are fully
> trusting the COM objects? I confess I don't know much about COM, but
> I feel really uneasy about allowing an object out of our control the
> access that it has.
> Even in their updated model (each COM has it's own Login) we still
> wouldn't know if application A is using database A, database B,
> database C, etc.. and which tables in those other databases.
> I need ammo to go to our next meeting and show them how this isn't
> secure from our perspective. We also have SQL Log Rescue, so we have
> the ability to scour the logs for info - but we can't tell who is doing
> what because it all shows that it's the COM account accessing the db.
> Uri Dimant wrote:
>|||No one has really weighed in, I'm surprised.
J wrote:[vbcol=seagreen]
> Wow. I had the exact discussion recently and would be very interested to
> see other opinions and info on this also.
> J
> "PSPDBA" <DissendiumDBA@.gmail.com> wrote in message
> news:1165934077.707745.266260@.79g2000cws.googlegroups.com...