Securing SQL Assets
We talk a lot about securing your database assets in SQL Server. We cover concepts such as authentication techniques and which one is the best fit. Utilizing Schemas to separate ownership of database objects. Creating groups and users to manage permissions for objects more easily. Granting and revoking of privileges reducing the vulnerability for database consumers.
It has been years since I actually created and managed user accounts on a production system. Schemas are often overkill. Groups are not even created. Unless I miss my guess, this is the case for many installations, even those under strict governance.
Much of what we used to manage in SQL security has been lifted out into an application layer of security. One main reason for this would be web applications. Individual user accounts often don’t make sense in an application with hundreds or thousands of users.
Is this becoming more of a normative practice? Are you using individual user accounts, schemas, groups, etc. and locking down permissions for things other than backup and restore jobs? Is it secure enough to simply have a single application login for all database consumers?
Share your opinion and experience. Get into the conversation by writing btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Curbing the Curmudgeons in the Corner
Sometimes viewed as prima donnas, DBAs can be curmudgeons who have vast technical knowledge, but limited people skills. Just about every database programmer has their favorite DBA story — those famous anecdotes that begin with “I have a problem…” and end with “…and then he told me to stop bothering him and read the manual.” Or maybe the DBA just spewed the acronym RTFM at the programmer, which stands for – – Read the “Friendly” Manual!
Featured White Paper(s)
Top 10 Tips for Optimizing SQL Server Performance
read more)