From the Article
We can't change the way SQL Server, or other vendor technologies, work at a base level, but we can reduce the amount of damage that's done by not being the easy prey for attackers. In my mind, that means we should be securing our data as best we can, including encrypting communications and limiting access rights, as well as encrypting the actual data we store.
Ah... you've hit upon a topic near and dear to my heart.
One of the biggest problems I've found is just how high the priv levels are for application logins. Like it or not, applications shouldn't have more than PUBLIC privs, IMHO. This can be accomplished fairly easily through stored procedures by making it so the procedures have the privs and the users have EXECUTE privs on the procs. The user don't have privs to even read from a table. This has been made a whole lot easier using the "DB_Executor" role which has been made possible as of 2005 by being able to grant EXECUTE privs to a DB role (it seems that a lot of people have adopted the name "DB_Executor" for this role).
Ironically, the use of xp_CmdShell can be a good measure of whether or not your system is actually properly locked down or not. In a properly locked down system, individual users can't even see tables, never mind run xp_CmdShell yet the stored procedures called by the users can use it.
So far as I'm concerned, a system isn't properly secure unless the only people that have any privs other than PUBLIC are the DBAs. I'm not saying that you don't need encryption of things like SSNs because you still have to protect against possible internal threats but there's really no excuse for having the potential of external threats.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is usually not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs