[Security_sig] Database Server Use Case - Draft 0.1

[Mary Edie Meredith]

Here is the first use case generated from Ed's wonderful 
description.  I could use some suggestions for 
Implementation notes.  

Please review by the next SIG call.

Other cases will follow. 


--------------------------------
Use Case:
Database Server
---------------------------------
Version 0.1 (DRAFT)
Last Modified Date: 07/01/05

Copyright (c) 2005 by The Open Source Development Lab, Inc. Verbatim
copying and distribution of this document is permitted in any medium,
provided this notice is preserved.  Draft copies of this document
may not be posted publicly without indicating the draft status.

---------------------------------

Table of Contents
--------------------------------- 
Description 
Target Acceptance 
Participants/Roles 
Scenarios 
Implementation Notes 
References 

---------------------------------
Description
---------------------------------
This use case describes what we call a “Database Server” found
in a Data Center.  The purpose of creating this description is so
that the OSDL Security Special Interest Group (SIG) can use this
description to evaluate the security needs for a Database Server.
The goal is to determine the operating system capabilities (the
kernel and above) needed so that managers of database servers can
create a secure environment.  The assumptions need to be clearly
defined to do that analysis.  Once identified, the capabilities
needed can be compared to what is available on any OS platform to
identify possible gaps.

This is one of a series of server usage profiles, which will
be used to distinguish between security capabilities that are
of general use, and those that have particular applicability to
certain deployment scenarios.  In particular, the environmental
assumptions surrounding each scenario differ, and so the types of
security capabilities each requires differ, too.

Although the initial effort in creating server usage profiles is
targeted at security, we intend this description to be good enough
for other use cases to reference when they refer to server types,
in this case“Database Server”.  In other words, we want the
description to be useful for discussions beyond the topic of
security.
---------------------------------
Target Acceptance
---------------------------------
This document is intended to help drive acceptance of any missing
features into the mainline Linux kernel or any utilities that are
impacted.  Test cases for newly developed or modified features can
be designed with this use case in mind.
---------------------------------
Participants/Roles
---------------------------------

---
* Systems Administrator
* Operations Staff
---
Special class of user that has special privileges on a given
system. This is a role held by an individual that acts as the
administrator for the system or by an individual that might have
a specific role within the administration role, for example
responsibility for system backup.

---
* Application Administrator
---
Special class of user that has special privileges for a given
application. This is a role held by an individual that acts as the
administrator for all aspects of an application.

---
* Database Administrator
---
Special class of user that has special privileges on a given
system. This is a role held by an individual that acts as the
administrator for a database.  A database administrator can
be responsible for one or more databases.  There can be
several database administrators with responsibilities
on a given database server.

---
* User
---
Any user on the system. This is a role that is held by all
individuals using a system.  The user can interact with the system
through the processes associated with applications they are using.
Root Users are users who have root privileges. They are typically
the system administrator.  Privileged users have some of the root
user privileges, but not all.  They are typically and operations
staff member.
---
* Developer
---
A special case of user whose role is to create custom scripts or
programs that serve to add new functionality such as creating new
applications, tying applications together, processing the output
of applications for human consumption, or processing database
information in ways not easily accomplish by packaged options.
---------------------------------
Scenarios
---------------------------------
The “Database Server” is the classic raised-floor, big iron,
possibly clustered, 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 (refer to the use case for application server)
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 and
decision support center ad-hoc queries are only allowed to come
through application servers 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.  Database instance files must be able to be managed by
separate database or application administrators, on a per-instance
basis, so that responsibilities can be separated.  When clustered or
networked file systems are used, means must be available to assure
that disk and file space allocated to database instances will be
available when required, and protected from access or use by other
databases in the cluster.

To assure continuity of operations (an important security objective
that includes defending against denial of service attacks on
systems), on-line backups, both incremental and full, must be able to
be taken of still-open-and-operating database instances, when such
instances cannot be scheduled to be unavailable to allow “cold”
backups to be taken.  Transaction journaling of changes, so that
backups are transactionally consistent, may also be necessary, along
with the ability to restore databases and roll them forward, possibly
transaction-by-transaction, past the point of the last available
checkpoint, so as to recover from specific corrupting transactions.

Security-relevant characteristics: relatively few authorized users,
need for separation of system and database administration roles
and permissions, need for accountability of system, database,
and application administrator actions, need for open-file (hot)
backups, need for transactionally consistent backups.

---------------------------------
Implementation Notes
---------------------------------
These Implementation Notes apply to some or all scenarios.
These are just guidelines, not cast in concrete.  They aren't an
implementation specification. Rather, they're details that will
affect implementation and are relevant to the current use case. They
will guide, but not control the implementation-level design.

There are currently no implementation notes for implementing security
on Database Servers.

---------------------------------
References
---------------------------------
References for terminology, whitepapers, articles, or potential
projects/implementations.

Security discussions can be found in the archives of the Security
SIG:
http://lists.osdl.org/pipermail/security_sig/

-- 
Mary Edie Meredith 
maryedie at osdl.org
503-906-1942
Data Center Linux Initiative Manager
Open Source Development Labs