<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.6.5" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Why is Database Security So Hard?</title>
	<link>http://www.pythian.com/blogs/835/why-is-database-security-so-hard</link>
	<description>News and views from Pythian DBAs</description>
	<pubDate>Fri,  9 Jan 2009 22:22:14 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.5</generator>
		<item>
		<title>By: AM</title>
		<link>http://www.pythian.com/blogs/835/why-is-database-security-so-hard#comment-172144</link>
		<dc:creator>AM</dc:creator>
		<pubDate>Wed, 19 Mar 2008 11:54:09 +0000</pubDate>
		<guid>http://www.pythian.com/blogs/835/why-is-database-security-so-hard#comment-172144</guid>
		<description>Bill, you are right, of course: it would be unwise to design a system in which the (same?) database was being both a smart file system and an application framework at the same time.  But I didn't say that originally, I said that DBMS are able to play either role.  To continue your metaphor - a DBMS is neither a wrench nor a screwdriver nor a hammer, but one of &lt;a href="http://www.swiss-army-knife-wenger.co.uk/wenger_giant_swiss_army_knife.html" rel="nofollow"&gt;these&lt;/a&gt;.

Of course _requirements_ are complicated and hard to get right: in general.  So we learn and apply requirements patterns and software architectural plans to get a handle on that complexity, to control it.  Your example of user access is an excellent one: and how to deal with it depends on domain design decisions (what is a user? what attributes do they have at various layers of the system?).  My point, though, is that a framework architecture (i.e. the DBMS) that potentially cross-cuts so many layers has the potential to get wired-up in all those decisions you try to make, and can therefore easily blur the layers of abstraction.  (Imagine a machine whose instruction set depended on the spelling of your name.)  And my suggestion is: perhaps there are typical patterns of use (I called them "profiles") which, once recognized, could be hardened in different ways.  This discussion was about security, after all.</description>
		<content:encoded><![CDATA[<p>Bill, you are right, of course: it would be unwise to design a system in which the (same?) database was being both a smart file system and an application framework at the same time.  But I didn&#8217;t say that originally, I said that DBMS are able to play either role.  To continue your metaphor - a DBMS is neither a wrench nor a screwdriver nor a hammer, but one of <a href="http://www.swiss-army-knife-wenger.co.uk/wenger_giant_swiss_army_knife.html" rel="nofollow">these</a>.</p>
<p>Of course _requirements_ are complicated and hard to get right: in general.  So we learn and apply requirements patterns and software architectural plans to get a handle on that complexity, to control it.  Your example of user access is an excellent one: and how to deal with it depends on domain design decisions (what is a user? what attributes do they have at various layers of the system?).  My point, though, is that a framework architecture (i.e. the DBMS) that potentially cross-cuts so many layers has the potential to get wired-up in all those decisions you try to make, and can therefore easily blur the layers of abstraction.  (Imagine a machine whose instruction set depended on the spelling of your name.)  And my suggestion is: perhaps there are typical patterns of use (I called them &#8220;profiles&#8221;) which, once recognized, could be hardened in different ways.  This discussion was about security, after all.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bill Karwin</title>
		<link>http://www.pythian.com/blogs/835/why-is-database-security-so-hard#comment-169181</link>
		<dc:creator>Bill Karwin</dc:creator>
		<pubDate>Sat, 08 Mar 2008 21:53:19 +0000</pubDate>
		<guid>http://www.pythian.com/blogs/835/why-is-database-security-so-hard#comment-169181</guid>
		<description>Hmm.  Saying a database is both a smart filesystem and an application framework is like saying that a hammer is both a wrench and a screwdriver.  I.e., NOT.  :-)

The thing about securing databases is that we must prevent illegitimate access, while permitting legitimate access.  The complexity is not in the database, it's in the definition of illegitimate vs. legitimate.  In real-world scenarios, this distinction is complex and full of fine-grained special cases.

For instance, I want to allow users access to their own account details.  But I don't want users to access each other's account details.  Unless the user is an administrator.  Or a merchant, in which case they should be able to access certain information about the user, such as her shipping address.  But only if that user has authorized the merchant by ordering something from him.  But that authorization is time-limited.  Unless that user is a repeat customer of that merchant.  Except when either the user or the merchant have blacklisted the other, because they had some bad transaction in the past.

The possible exception cases go on and on!  Trying to block every case that needs to be blocked, while preserving access in cases that need access is hard.  It's not because the technology itself is complex.  It's because the real-world processes that we're trying to model are complex.</description>
		<content:encoded><![CDATA[<p>Hmm.  Saying a database is both a smart filesystem and an application framework is like saying that a hammer is both a wrench and a screwdriver.  I.e., NOT.  :-)</p>
<p>The thing about securing databases is that we must prevent illegitimate access, while permitting legitimate access.  The complexity is not in the database, it&#8217;s in the definition of illegitimate vs. legitimate.  In real-world scenarios, this distinction is complex and full of fine-grained special cases.</p>
<p>For instance, I want to allow users access to their own account details.  But I don&#8217;t want users to access each other&#8217;s account details.  Unless the user is an administrator.  Or a merchant, in which case they should be able to access certain information about the user, such as her shipping address.  But only if that user has authorized the merchant by ordering something from him.  But that authorization is time-limited.  Unless that user is a repeat customer of that merchant.  Except when either the user or the merchant have blacklisted the other, because they had some bad transaction in the past.</p>
<p>The possible exception cases go on and on!  Trying to block every case that needs to be blocked, while preserving access in cases that need access is hard.  It&#8217;s not because the technology itself is complex.  It&#8217;s because the real-world processes that we&#8217;re trying to model are complex.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
