Comments on: SQL Server Security – Database Roles http://facility9.com/2008/12/31/sql-server-security-database-roles Jeremiah Peschka's ruminations on sql, ruby, c#, and other things Wed, 28 Jul 2010 14:05:12 -0400 http://wordpress.org/?v=2.9.2 hourly 1 By: Row-Based Security | facility9 http://facility9.com/2008/12/31/sql-server-security-database-roles#comment-200 Row-Based Security | facility9 Wed, 11 Feb 2009 01:12:22 +0000 http://facility9.com/?p=254#comment-200 [...] the first two installments of my articles on SQL Server security, I described server level roles and flexible database-level roles. This final article talks about row-based security, specifically [...] [...] the first two installments of my articles on SQL Server security, I described server level roles and flexible database-level roles. This final article talks about row-based security, specifically [...]

]]> By: How I Get By Without sysadmin | facility9 http://facility9.com/2008/12/31/sql-server-security-database-roles#comment-166 How I Get By Without sysadmin | facility9 Thu, 22 Jan 2009 14:02:49 +0000 http://facility9.com/?p=254#comment-166 [...] SQL Server Security - Database Roles Flexible Database-Level Roles [...] [...] SQL Server Security – Database Roles Flexible Database-Level Roles [...]

]]> By: Flexible Database-Level Roles | facility9 http://facility9.com/2008/12/31/sql-server-security-database-roles#comment-165 Flexible Database-Level Roles | facility9 Wed, 21 Jan 2009 22:50:54 +0000 http://facility9.com/?p=254#comment-165 [...] is following up from my previous post on Database Roles. In my previous post, I talked about fixed database roles. If you’ve forgotten, go back and [...] [...] is following up from my previous post on Database Roles. In my previous post, I talked about fixed database roles. If you’ve forgotten, go back and [...]

]]> By: Mike Walsh http://facility9.com/2008/12/31/sql-server-security-database-roles#comment-155 Mike Walsh Fri, 09 Jan 2009 04:03:59 +0000 http://facility9.com/?p=254#comment-155 Good Post - I found you through The Rambling DBA's blog (http://jmkehayias.blogspot.com/) I like the article and the explanations. A lot of folks seem to neglect some of these items in their study. The only comment I would add for clarification is about the Public Role.. By default, every user of a database is a member of that role, and they can't be removed from that role. So if you add a login to a database as a user (at the "server" or instance level you have a login and within the database you have a "user".. I know you know that just for comment readers). Every user of a database belongs to the public role. The public role in my databases is usually a very inconsequential role. It exists and everyone belongs to it. Where it can come in handy (or as I see it where it can become dangerous) is if you assign a permission to that role, every single user of that database will always have that permission. So if you always want to grant select on the "Welcome" table to every single user of a database you could grant that to this role: GRANT SELECT ON DBO.WELCOME TO PUBLIC Makes life easier if you don't do role based security and add individual users but if you have an employee that isn't supposed to read from that table, oops. So I leave that role alone. I have seen folks do some strange things with the public role and didn't like the security holes left. Auditors don't care for that role having permissions either (at least auditors who are truly familiar with SQL Server) Good Post – I found you through The Rambling DBA’s blog (http://jmkehayias.blogspot.com/) I like the article and the explanations. A lot of folks seem to neglect some of these items in their study.

The only comment I would add for clarification is about the Public Role.. By default, every user of a database is a member of that role, and they can’t be removed from that role. So if you add a login to a database as a user (at the “server” or instance level you have a login and within the database you have a “user”.. I know you know that just for comment readers).

Every user of a database belongs to the public role. The public role in my databases is usually a very inconsequential role. It exists and everyone belongs to it. Where it can come in handy (or as I see it where it can become dangerous) is if you assign a permission to that role, every single user of that database will always have that permission.

So if you always want to grant select on the “Welcome” table to every single user of a database you could grant that to this role:

GRANT SELECT ON DBO.WELCOME TO PUBLIC

Makes life easier if you don’t do role based security and add individual users but if you have an employee that isn’t supposed to read from that table, oops. So I leave that role alone.

I have seen folks do some strange things with the public role and didn’t like the security holes left. Auditors don’t care for that role having permissions either (at least auditors who are truly familiar with SQL Server)

]]> By: Jeremiah Peschka http://facility9.com/2008/12/31/sql-server-security-database-roles#comment-150 Jeremiah Peschka Fri, 02 Jan 2009 18:21:57 +0000 http://facility9.com/?p=254#comment-150 Benjamin, thanks for catching that. The way I wrote it was unclear. I updated the text, but basically if you add db_denydatareader, members of the HR group won't be able to run ad hoc SQL queries so long as your application is using Windows Forms authentication (or some other passthrough that makes use of the user's Windows credentials). Benjamin, thanks for catching that. The way I wrote it was unclear. I updated the text, but basically if you add db_denydatareader, members of the HR group won’t be able to run ad hoc SQL queries so long as your application is using Windows Forms authentication (or some other passthrough that makes use of the user’s Windows credentials).

]]> By: Benjamin Lotter http://facility9.com/2008/12/31/sql-server-security-database-roles#comment-149 Benjamin Lotter Fri, 02 Jan 2009 16:26:45 +0000 http://facility9.com/?p=254#comment-149 I was a little confused after reading the sections on db_denydatareader and db_denydatawriter. Can you clarify the following statements? Why use db_denydatareader In addition to the accounting department’s requirement to be able to create ad hoc reports as needed, HR needs to be able to run the canned reports available to them through your carefully crafted stored procedures. It turns out that they are also able to create and run ad hoc reports (thankfully your junior DBA emailed you about this yesterday before he got sick). Thankfully, you can quickly grant db_denydatareader permissions to the HR Windows group and get in touch with the application developers to have them hide ad hoc reports from the HR group. I was a little confused after reading the sections on db_denydatareader and db_denydatawriter. Can you clarify the following statements?

Why use db_denydatareader In addition to the accounting department’s requirement to be able to create ad hoc reports as needed, HR needs to be able to run the canned reports available to them through your carefully crafted stored procedures. It turns out that they are also able to create and run ad hoc reports (thankfully your junior DBA emailed you about this yesterday before he got sick). Thankfully, you can quickly grant db_denydatareader permissions to the HR Windows group and get in touch with the application developers to have them hide ad hoc reports from the HR group.

]]>