[Security_sig] Draft: DCL Database Server Profile description

[Mary Edie Meredith]

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
> 
>