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