[Security_sig] Draft: DCL Database Server Profile description

Ed Reed ereed at novell.com
Thu Apr 28 13:37:54 PDT 2005


Over the years, we've begun to settle on the notion that you need to know whether you need to secure each public interface (the channels by which applications talk to databases, for instance), and if so, how. 
 
I'll add the notion that the database and mid-tier servers may very well be clustered, in order to improve availability and performance load balancing, for just two of many possible reasons.  Then, the control over how shared resources, such as shared disk or networked file systems, are allocated, protected, and how application or database data can be separated and protected, is easily mentioned. 
 
Ed

>>>Mary Edie Meredith <maryedie at osdl.org> 04/28/05 3:28 pm >>>
On Thu, 2005-04-28 at 13:04 -0600, Ed Reed wrote:
>My take is that matters of SAN, encryption, etc. are all details
>within the use cases, not easily surfaced at this level of overview.
> 
>Whether NAS is different from the departmental server, I don't know.
> But SAN almost falls into the category of tape libraries, as far as I
>can tell - it's an abstract shared resource.  It's management and
>security is certainly important, particularly in that we haven't
>thought much, in the past, about the risks of sharing disk spindles by
>multiple machines, though that certainly comes up in clusters.
> 
>I didn't talk about clusters, I guess...would that be a good add,
>either here or in the Mid-Tier description?

I believe clustering is appropriate for both database and application.
However, there you start to enter the muddy waters of what you mean
by a cluster.  

Would it be possible to say that The database server environment may
include shared resources with other trusted servers.  Examples are
configurations like clustering and storage solutions like NAS and SAN.
It seems like if we need to think about how application servers interact
with database servers, we need to consider all interfaces with the db
server to other intelligent forms of life (--:  Besides this gives is
the license to care about NFS V4 security in the context of a database
server. Right?
>
>>>>Mary Edie Meredith <maryedie at osdl.org> 04/28/05 2:09 pm >>>
>On Thu, 2005-04-28 at 11:42 -0600, Ed Reed wrote:
>>Here's my first take on the description of what I mean by a Database
>>Server.  There are aspects, in this description, of environmental
>>assumptions, security objectives, risk analysis, etc.  It's in
>>English, though, or at least tries to be.  It's almost a short use
>>case.
>>
>>I'll follow with descriptions of the other profiles shortly.
>>
>>Your comments and suggestions welcome (at least until I see them ;-)
>>
>>Ed
>>======================
>>Database Server
>>This is the classic raised-floor, big iron server, providing database
>>processing resources to applications throughout the organization.  It
>>typically supports multiple database instances, possibly from
>multiple
>>database technologies and vendors.  Transactional semantics are
>>typical, with different performance tuning parameters used as daily
>>processing loads change from on-line transactional to batch update /
>>reporting in nature.
>>
>>Access to such a machine is presumed to be limited to trusted
>>application servers located within the same data center, or at least
>>to be isolated from casual access from users and developers.  No
>>access from customers, competitors or hostile attackers is expected.
>>User accounts on such a machine are limited to those needed by the
>>operations staff and database administrators to install and maintain
>>the operating system and databases, themselves.  Information
>wearhouse
>>and decision support center ad-hoc queries are only allowed to come
>>through application servers (see 2.1.2, below) so as to make resource
>>and performance management possible.  Only privileged users, not
>>necessarily root users, but trusted employees and contractors, have
>>login privileges on the machine. 
>>
>>All administrative and user actions with respect to the machine are
>>candidates for audit capture, analysis and reporting.  Business
>>critical information is held on the machine which, if stolen or
>>inadvertently published, could have material effect on the
>>organizations financial performance, share price, or public
>>reputation.  Customer privacy-sensitive information, ranging from
>>financial to health-care in nature, are likely to be held on such a
>>server.
>
>Do we need to talk about the disk farm for this machine possibly being
>a shared disk farm (over Fibre Channel, iSCSI, NFS ) that we assume is
>also secure?
>
>Also, in the case of NFS V4, is there a way of describing
>the relationship of the database server to storage that would imply
>certain encryption types (if not all of them) that we discussed
>in the Security SIG call a couple of weeks ago (Authentication only,
>Integrity, Privacy)?
>
>Or should is all this be left for other sub use cases?
>
>
>>security_sig mailing list
>>security_sig at lists.osdl.org
>>http://lists.osdl.org/mailman/listinfo/security_sig
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/security_sig/attachments/20050428/117c4fe9/attachment-0001.htm


More information about the security_sig mailing list