[Security_sig] Draft: DCL Database Server Profile description

[Ed Reed]

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?

>>>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/a4901cda/attachment-0001.htm