What is the minimum SQL security needed for a MS SQL 2005 database?
What is the minimum SQL security needed for a MS SQL 2005 database?
I've setup a database instance and have added a database. The software that I wrote interfaces the database and adds/updates/removes table data but does not change the database structure. My concern is that I want to make sure that I'm not giving the user too much access in case they connect with a SQL database manager/etc.
In server roles I've assigned "public" to the user and
In User Mapping I've assigned "db_owner" and "public"
Also, something to consider is that I'm going to have a lot of users being added/removed, so if there's a better way to manage this process please let me know.
Thank you!
I've setup a database instance and have added a database. The software that I wrote interfaces the database and adds/updates/removes table data but does not change the database structure. My concern is that I want to make sure that I'm not giving the user too much access in case they connect with a SQL database manager/etc.
In server roles I've assigned "public" to the user and
In User Mapping I've assigned "db_owner" and "public"
Also, something to consider is that I'm going to have a lot of users being added/removed, so if there's a better way to manage this process please let me know.
Thank you!
>>In User Mapping I've assigned "db_owner" and "public"
Not a good practice...the db_owner part. The idea is to write procs and assign the user permission to run them.
Are you using SQL Auth? If so, then the user doesn't really even need to know the userid and pwd. They just connect to the app, and go about their business. They shoudln't really need to access the db directly.
Not a good practice...the db_owner part. The idea is to write procs and assign the user permission to run them.
Are you using SQL Auth? If so, then the user doesn't really even need to know the userid and pwd. They just connect to the app, and go about their business. They shoudln't really need to access the db directly.
ASKER
angelIII, We're still in testing at this point so this is very good information. So, db_datareader and db_datawriter roles just let them update/add/remove table data, nothing else?
chapmandew, Yes, we are using SQL Auth however we also have to support trusted connections as well. I see your point about not allowing them to even know the username/password however that won't fly with this project. They also want the ability to create their own reports/etc so the database has to be open but protected at the same time.
chapmandew, Yes, we are using SQL Auth however we also have to support trusted connections as well. I see your point about not allowing them to even know the username/password however that won't fly with this project. They also want the ability to create their own reports/etc so the database has to be open but protected at the same time.
ASKER CERTIFIED SOLUTION
![Avatar of Guy Hengel [angelIII / a3]](https://filedb.experts-exchange.com/files/public/2013/11/25/ddbe0ea6-aa6e-4279-b781-57b735dd3ea0.jpeg){kind=small}
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
so, remove that ASAP, and instead you might want to specify db_datareader and db_datawriter roles.
side note: lock down sql server 2005 article:
http://duartes.org/gustavo/articles/Lock-Down-SQL-Server-2005.aspx