SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Why Use the Principle of Least Privilege?


Why Use the Principle of Least Privilege?

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: Administrators
Points: 62460 Visits: 19102
Comments posted to this topic are about the item Why Use the Principle of Least Privilege?

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Jim Murphy
Jim Murphy
SSChasing Mays
SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)SSChasing Mays (639 reputation)

Group: General Forum Members
Points: 639 Visits: 1265
HA! That graphic is priceless.

It is all too easy to begin the development process by configuring the application to use "sa" (or another sysadmin account), and even demo using "sa" while stating the excuse that "you shouldn't use sa in production" (the proverbial "Do as I say, not as I do"). Frankly, we shouldn't use "sa" in development either. In fact, for a user to gain access to a system, they need both a username and a password, therefore disabling sa is best since it removes both halves of the equation.

Following the more-secure best practice of using only Windows authentication doesn't help much if we set up using MYCOMPUTER\ADMINISTRATOR (which is a SQL sysadmin) or equivalent. Therefore, this applies to any other login, SQL or Windows, that has the sysadmin server role. This is a nice reminder to begin the development process with a lower privileged user account so we never end up rolling out an application into production which is a sysadmin.

RegEx patterns can go a long way to help, but are usually implemented in the application/business layer, causing DBAs to depend on these faithful developers to protect our own systems. Uh. That's not good. Triggers? Policies? Functions/Stored Procs? What is YOUR preferred method of sanitizing user input (as brokered via a developer)? I tend to lean toward driving the developers through a database 'interface' via stored procs using parameters (and not the @whereClause or @orderBy kind of parameters!).

Jim

Jim Murphy
http://www.sqlwatchmen.com
@SQLMurph
Evil Kraig F
Evil Kraig F
SSCrazy Eights
SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)

Group: General Forum Members
Points: 8593 Visits: 7660
I'm currently on the dev end of a bad little duel between the dba and dev sides of the house. Acquisitions and the like have forced some of it, pride and bad methodology others. Where I'm at now used to be a cowboy shop. QA was barely sneezed on as you passed the salad bar by for the meat of production. They'd do four rolls in a day if they had to, to get it right. Problem was our users/UAT is now used to only working off production to check production changes. Argh. Needless to say along the way they royally shot themselves in the foot, to CEO level of notice.

Mind you, I came in after the fact. Now they've got full change controls in place and I'm trying, from the underbelly, to convince the rest of this dog to wag its tail. They're incredibly frustrated at not being able to run amok. Now, I'll admit, not being able to pull up sysprocesses when something I'm optimizing isn't making sense (alright, Mr. Proc, just what ARE you doing?) or doing a trace can get frustrating, but it's proper build methodology.

I *know* this from both sides, and am constantly defending the people who have chained me to the table... and that's what it feels like. Imagine someone who's never worked the other side of the data house. It's miserable for them. All a DBA can do is commiserate, explain, teach... and remember not to leave the keys out.


- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Eric M Russell
Eric M Russell
SSChampion
SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)

Group: General Forum Members
Points: 12277 Visits: 10648
In any database that I have ownersip of, I typically grant application accounts authorization by adding them as members of a single role, and that role grants them only EXEC permission on the stored procedures that the application needs. If an account can't select from any table and can't view the schema information, then that severely limits how it could be leveraged by a SQL injection attack or stolen login credentials.
I do have a separate "power user" account in the development and QA environment that allows developers or testers to browse object schemas or select from any table. In the Development environment, it even grants them permission to insert / update / delete any table, so they can perform and cleanup after unit tests. However, that account doesn't get carried over to production.
This should be done, not just a means of providing security from external attacks, but also as a means of constraining how the database is being used by application developers. If they want to query the database in a certain way, rather than coding an ad-hoc SQL statement, they should instead run it past the database developer or DBA, who then creates the proper stored procedure.
It's just like those big concrete dividers that the department of transportation puts between the east and west bound lanes of an interstate highway. If the barriers were not there, idiots would of course be routinely doing U-turns in front of oncoming traffic.


"The universe is complicated and for the most part beyond your control, but your life is only as complicated as you choose it to be."
Steve Jones
Steve Jones
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: Administrators
Points: 62460 Visits: 19102
Eric M Russell (4/12/2011)

It's just like those big concrete dividers that the department of transportation puts between the east and west bound lanes of an interstate highway. If the barriers were not there, idiots would of course be routinely doing U-turns in front of oncoming traffic.


That's a great quote, and a nice analogy. :-D:-)

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
K. Brian Kelley
K. Brian Kelley
Keeper of the Duck
Keeper of the Duck (10K reputation)

Group: Moderators
Points: 10242 Visits: 1917
[Jim].[dba].[Murphy] (4/11/2011)
RegEx patterns can go a long way to help, but are usually implemented in the application/business layer, causing DBAs to depend on these faithful developers to protect our own systems. Uh. That's not good. Triggers? Policies? Functions/Stored Procs? What is YOUR preferred method of sanitizing user input (as brokered via a developer)? I tend to lean toward driving the developers through a database 'interface' via stored procs using parameters (and not the @whereClause or @orderBy kind of parameters!).

Jim


Unfortunately, I'm going to have to go back to leaning on the developer. Here's why:

1 - Attackers started using SQL injection to insert links to malicious sites to appear on legitimate web pages. Most of these were automatically opened using javascript. We built filters that looked for those sites via triggers.
2 - Attackers started using tinyurl and bit.ly and other link shortening sites as a counter to our efforts. We responded by looking for javascript and a href in our triggers.
3 - Attackers started doing weird things like running convert statements to change the appearance of the code. We deployed (modified) our triggers to stop that but there are many, many techniques and we couldn't get them all.
4 - Attackers started using legitimate mechanisms within javascript to obfuscate what was being done and, combined with #3, we couldn't trap for that, even using a RegEx.

In the BBS days, we had a philosophy when we built door applications. We would define the valid inputs that were permitted (the domain, if you will, from mathematics). If it didn't fit that domain, the input was rejected. This is harder when you're trying to do text fields and the like, but not undoable. And once you've properly defined one input check for this, it's easy to re-use. That goes back to Steve's comment about Andy always speaking on patterns and practices. Once you write the check routines you need, you can re-use them, saving you time and work. And you deploy it at the app level so we never see it at the database level, because by the time it gets to us, we might not be able to do anything about it.

K. Brian Kelley
@‌kbriankelley
SanDroid
SanDroid
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1576 Visits: 1046
Steve,
Great article and wonderfull graphic.
One question I have always had about this new Policy of least privilidge that M$ started pushing for in XP is this.

Are internall or supported products (like Install Shield, Remedy, Office, IE) following all these rules, or are they given exceptions that allow thier products to still work?

There are some products that we have developed in house where we work that allow us to seemlessly update everyone to the latest version of our current software.
With these changes, our only answer from M$ has been to purchase a partners product that does a limited what we want to do.

Don't get me wrong, I understand the need for this change in security and code execution levels and all the issues it resolves.
I would like to see better support from M$ when it breaks things that are working using previous design patterns they had provided.
Eric M Russell
Eric M Russell
SSChampion
SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)

Group: General Forum Members
Points: 12277 Visits: 10648
Steve Jones - SSC Editor (4/12/2011)
Eric M Russell (4/12/2011)

It's just like those big concrete dividers that the department of transportation puts between the east and west bound lanes of an interstate highway. If the barriers were not there, idiots would of course be routinely doing U-turns in front of oncoming traffic.

That's a great quote, and a nice analogy. :-D:-)

Just for clarification, I didn't intend to compare fellow developers who occasionally code ad-hoc SQL to those other guys (idiots) who make u-turns on the interstate highway. It's not the same thing, and I myself have been in situations where I've had to resort to coding ad-hoc SQL to solve some problem like pivoting or complex filtering that would still require dynamic SQL even if it were done in a stored procedure. Even in that case, I'll grant the application account select permission on only the specific tables it needs.
It was just that I think interstate dividers are a good non-IT example of implementing the Principle of Least Privilege.
:-)


"The universe is complicated and for the most part beyond your control, but your life is only as complicated as you choose it to be."
Steve Jones
Steve Jones
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: Administrators
Points: 62460 Visits: 19102
SanDroid (4/12/2011)
Steve,
Great article and wonderful graphic.
One question I have always had about this new Policy of least privilege that M$ started pushing for in XP is this.

Are internal or supported products (like Install Shield, Remedy, Office, IE) following all these rules, or are they given exceptions that allow thier products to still work?

There are some products that we have developed in house where we work that allow us to seamlessly update everyone to the latest version of our current software.
With these changes, our only answer from M$ has been to purchase a partners product that does a limited what we want to do.

Don't get me wrong, I understand the need for this change in security and code execution levels and all the issues it resolves.
I would like to see better support from M$ when it breaks things that are working using previous design patterns they had provided.


I doubt that many of the MS products adhere to this, though a lot of that is different departments coding to meet their deadlines, without necessarily following some standard. I think a lot of this changed in the 2003-2004 time frame when MS stepped back, stopped development of some products like SQL Server, and re-engineered their processes to be more rigid, standard, and secure.

I definitely agree that MS has not necessarily been a great advocate here if best practices for security and incorporating that into their own development cycles.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Steve Jones
Steve Jones
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: Administrators
Points: 62460 Visits: 19102
Eric M Russell (4/12/2011)

Just for clarification, I didn't intend to compare fellow developers who occasionally code ad-hoc SQL to those other guys (idiots) who make u-turns on the interstate highway. It's not the same thing, and I myself have been in situations where I've had to resort to coding ad-hoc SQL to solve some problem like pivoting or complex filtering that would still require dynamic SQL even if it were done in a stored procedure. Even in that case, I'll grant the application account select permission on only the specific tables it needs.
It was just that I think interstate dividers are a good non-IT example of implementing the Principle of Least Privilege.
:-)


I didn't take it as a "developers suck" as much as "people will take short cuts if they can".

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search