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?
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?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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?
Can anyone suggest more solutions for this?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
1. A application should not have DDL rights into a database but DML rights so only SELECT,INSERT,UPDATE,DELET
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.
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.
ASKER
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?
Any expert comments on which Access Management tool or which module of the tool may resolve this issue in cost effective way?
ASKER
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?
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?
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.
<<
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.
ASKER
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.