[Security_sig] Draft: DCL Database Server Profile description

Ed Reed ereed at novell.com
Fri Apr 29 00:29:53 PDT 2005


re: Is it helpful to characterize the type of server configuration, or 
does this just muddy the water? 
 
I don't think that changes the security aspects of the system.  True, the balance of memory to disk resources and CPU will vary from the DB to the app server, but that's true across the board.  We can add something like this, but I'm not sure what it adds.  What do you have in mind? 
 
Ed

>>>Lynn de la Torre <ldelatorre at osdl.org> 04/28/05 7:26 pm >>>
Ed,
This is really great! You have summarized in a few paragraphs the
essence of the database server profile. A few minor
corrections/suggestions.
On Thu, 2005-04-28 at 10:42, 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.
Is it helpful to characterize the type of server configuration, or
does this just muddy the water?
I might add:
Depending upon the type of workload, whether true transactional or some
decision support included, the configuration will change. However, it is
safe to assume that there will generally be more than 4 cpus, a large
amount of memory to balance the cpus, and some type of large disk array
attached, usually SAN.
> 
>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 Warehouse
>  Information wearhouse and decision support center ad-hoc queries are
>only allowed to come through application servers (see 2.1.2, below)
Definitely a good assumption to make for our purposes.
> 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.
>
>
>
>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/20050429/19d01945/attachment-0001.htm


More information about the security_sig mailing list