My favorite line in the article is "...they don't get the job unless I trust them." I know I take that in a different way than the author meant, but it is a great reflection of my security philosophy. I'm not a lazy programmer. I just firmly believe in a level of trust that is beyond what many "security" people believe in.

I'm the only developer/DBA in my "shop." I gave it careful consideration and decided I should have all the privileges I needed to do my job. 🙂 I trust myself a great deal.

The rest of security is a matter of figuring out permissions to give to my users. At present (this is expected to change in the future and so I appreciate learning other approaches), the only apps I have are desktop apps and the only users I have are employees of our agency. The employees of our agency generally do not have tools that let them directly access the databases. They only access the data through the front-ends that I provide.

We use windows authentications. Domain users are assigned to windows groups and those groups are assigned as server logins and then database users. The groups are assigned to a small set of roles that I create for each database. The roles are usually along the lines of RegularUser, ReadOnlyUser, PowerUser. The permissions are assigned to the roles for tables, stored procs, functions, etc.

I DO assign rights directly to the tables via the roles as makes sense for the application. I've yet to read an argument (and I've read and considered and re-considered them all again and again) that has convinced me that my strategy *for my environment* is an unacceptably insecure one. They are our employees. If we didn't trust them, we wouldn't hire them. That doesn't make me foolish. I know employees can go bad and/or make mistakes. (But hey, so could that junior DBA that was talked about in the article.) My users do not get administrative privileges. They just get access to the data that they need to do their jobs.

I don't use any of the built-in rolls. I prefer to define everything myself for a small set of user-defined rolls for each database.