SQL Database Access Control

I want to setup such a databse access control mechanism so that anyone in the team patches anything in live should be captured as to who patched what.

Currently there is no control in place and team shares DBO user credentials for database patching which can not be changed since it is used by application.

How can I restrict team from using dbo account for database log in and if someone does that how an alert can be setup or any other ways to handle that?

Re patches, one way I thought is to create Stored Procs for common / usual database patches, give execute rights to Stored procs to individual's windows login by removing updayes rights of their windows login so that they can update whatever SP allow them to patch?

Can I take the access control forward by restricting  dbo usage and giving SP access to team or is there any other better way to hadle this area?

My organisation is very much concerned about the anonymous patching impacting business operations. Please advice?
A DAsked:
Who is Participating?
 
lcohanConnect With a Mentor Database AnalystCommented:
"since dbo password which is used by application is known to the users, no one logs in with their own windows login to ssms, instead they use dbo account  (sql authentication) and patch the database values. "

Hmmmm....in that case in my opinion there are 2 major issues:

1. A application should not have DDL rights into a database but DML rights so only SELECT,INSERT,UPDATE,DELETE, and EXEC should be granted to that ID

2. The password for the APP role must be changed/encrypted/hidden from developers so they will have to use their own ID to connect and modify database objects right?

I mean there's no magic possible in an environment without security where everybody IS and knows the SA password or DBO as you name it.
1
 
lcohanConnect With a Mentor Database AnalystCommented:
"anyone in the team patches anything in live should be captured as to who patched what."
If by "patching" you refer to making DDL changes to your SQL Database(s) then you need indeed to  create logins for each user instead of sharing the same login to connect/make changes and also different database roles so you could manage who does what at the database role level and then you just add users/logins to that particular role. So simply said you grant SELECT, INSERT, DELETE, EXEC, ETC... to that role and add users to it.

See more here about that security model.
https://msdn.microsoft.com/en-us/library/ms189121.aspx

Also, now that you have separate logins hitting your database you have a nice SQL built in report called "Schema change History" accessible via SSMS - right click the database, select Reports, Standard reports then "Schema change History" and you will see who changed what .
1
 
A DAuthor Commented:
Hi,

I meant database patches related to application data. E.g. patching a value in customer table.

Users already have Select, Update, Create etc rights to thier respective windows authentication as per thier roles but since dbo password which is used by application is known to users, no one logs in with thier own windows login to ssms, instead they use dbo account  (sql authentication) and patch the database values.
0
Cloud Class® Course: C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

 
A DAuthor Commented:
Users already have Select, Update, Create etc. rights to their respective windows authentication as per their roles but since dbo password which is used by application is known to the users, no one logs in with their own windows login to ssms, instead they use dbo account  (sql authentication) and patch the database values.

Can anyone suggest more solutions for this?
0
 
A DAuthor Commented:
1. A application should not have DDL rights into a database but DML rights so only SELECT,INSERT,UPDATE,DELETE, and EXEC should be granted to that ID

Even if DML rights are granted still there is no way we have to capture who executed Update statement on business tables due to lack of / limited access control.

2. The password for the APP role must be changed/encrypted/hidden from developers so they will have to use their own ID to connect and modify database objects right?


The change has been suggested but in that will take some time as it would be big piece of work which needs to be rolled out in planned manner and still solves only one issue. Other issues about the access control / audit etc. still remains open. Bringing an Identity and Access control management tool into picture is an option but I don't know if organization will approve the cost for it.

Below is high level plan which is prepared until we fix these issues permanently. Any views, please?

1 - Identify the simple data patches service team uses to fix the known issues and list them.
2 - convert the simple data patch scripts into Stored Procedures.
3 - Provide execute access to team on the Stored Procedures.
4 - Keep manual watch on usage of DBO account.
5 - All other infrequent data patches should go to Technical Leads (Senior Peers) after placing them to central location. Technical Leads to assess the patches, suggest modifications (if required) and execute the patches in live.
6 - Team to update the incident details by mentioning about the Data Patches and send back the incident with all other required details.
0
 
A DAuthor Commented:
I have been provided an option of bringing Access Management Tool in place to resolve this issue in long term.

Any expert comments on which Access Management tool or which module of the tool may resolve this issue in cost effective way?
0
 
A DAuthor Commented:
Hi

Somehow above plan is not entirely possible practically. We are still lacking with Database auditing and with our current application and database configuration not able to control the process of Database patching.

Is there any way to configure SQL client tool (SSMS) in such a way that support team users won't be able to choose SQL authentication option and can only get the option of Windows authentication only when logging into Database instance?

Is it possible without changing mode of authentication or SQL logins setup at server side?
0
 
lcohanDatabase AnalystCommented:
There is NO way unfortunately to do what you are requesting:

<<
to configure SQL client tool (SSMS) in such a way that support team users won't be able to choose SQL authentication option and can only get the option of Windows authentication only when logging into Database instance?

Is it possible without changing mode of authentication or SQL logins setup at server side?
>>

without making suggested changes.
1
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.