| Oracle® Label Security Administrator's Guide 10g Release 1 (10.1) Part Number B10774-01 |
|
|
View PDF |
| Oracle® Label Security Administrator's Guide 10g Release 1 (10.1) Part Number B10774-01 |
|
|
View PDF |
Control of access to sensitive information is of concern to managers, information officers, DBAs, and application developers, among many others. Selective access control based on a user's level of security clearance can ensure confidentiality without overbroad limitations. This level of access control enables confidence that sensitive information will be unavailable to unauthorized persons even while general users have access to needed information, sometimes in the same tables.
Data can be viewed as sensitive for many different reasons. Examples include personal and private matters or communications, professional trade secrets, company plans for marketing or finance, military information, or government plans for research, purchases, or other actions.
Allowing information to be seen or used by inappropriate persons can be embarrassing, damaging, or dangerous to individuals, careers, organizations, agencies, governments, or countries.
Yet such data is often intermingled with other, less sensitive information that is legitimately needed by diverse users. Restricting access to entire tables or segregating sensitive data into separate databases can create an awkward working environment that is costly in hardware, software, user time, and administration.
Oracle Label Security obviates the need for such measures by enabling row-level access control, based on the virtual private database technology of Oracle9i Enterprise Edition. It controls access to the contents of a row by comparing that row's label with a user's label and privileges. Administrators can easily add selective row-restrictive policies to existing databases by means of the easy-to-use graphical interface called Oracle Policy Manager. Developers can readily add label-based access control to their Oracle9i applications.
This chapter introduces Oracle Label Security in the larger context of data security. It contains the following sections:
| See Also:
For a complete introduction to Oracle9i features and terminology, see Oracle Database Concepts |
Computer security involves the protection of computerized data and processes from unauthorized modification, destruction, disclosure, or delay. In the Internet age, the risks to valuable and sensitive data are greater than ever before. Figure 1-1 shows the complex computing environment that your data security plan must encompass.
This section introduces basic terms and concepts of computer security as they relate to Oracle Label Security, in the following topics:
Text description of the illustration net81070.gif
Security officers, administrators, and application programmers must protect databases and the servers on which those databases reside; they must administer and protect the rights of internal database users; and they must guarantee electronic commerce confidentiality as customers access those databases. Oracle Corporation provides products to address this full spectrum of computer security issues.
Oracle Corporation is a leader in information assurance. Security evaluation is a formal assessment process performed by independent bodies against national and international criteria. It provides external and objective assurance that a system meets the security criteria for which it was designed. Upon successful completion of an evaluation, a security rating is assigned to the system or product. This certification provides confidence in the security of information technology products and systems to commercial and government users.
The Oracle RDBMS has met the Database Management System Protection Profile (DBMS PP). Oracle Label Security has been evaluated under the Common Criteria (ISO 15408) at Evaluation Assurance Level (EAL) 4, the highest level generally achieved by commercial software vendors.
A database security policy implements an overall system security policy within a broad, organizational security policy. The overall security policy can enforce the following types of rules:
Access control defines a user's ability to read, write, update, insert, or delete information. The following approaches are available to meet access control needs:
Oracle9i provides discretionary access control (DAC) on each table, controlling access to information through privileges (SELECT, INSERT, UPDATE, and DELETE) that authorize corresponding SQL operations on the table.
DAC controls access to data in a one-dimensional, binary way, meaning that access is granted or denied to the entire object. The administrator grants users privileges that determine the operations they can perform upon data. To access an object, such as a table or view, a user or process must have the appropriate privilege, such as the SELECT privilege. To access data in an object, a user or process must first have the necessary DAC privileges.
Labels enable sophisticated access control rules beyond those of discretionary access control by using data in the row. When a policy is applied, a new column is added to each data row. This column will store the label reflecting each row's sensitivity within that policy. Level access is then determined by comparing the user's identity and label with that of the row.
Oracle Label Security access control depends first on the basic DAC policy. Together, DAC and Oracle Label Security dictate the criteria controlling whether access to a row is permitted or denied.
In most applications, only a relatively small number of tables need the extra security of label-based access controls. The protection provided by standard DAC is sufficient for the majority of application tables.
To be allowed access to a row, a user must first satisfy Oracle9i DAC requirements, and then satisfy Oracle Label Security requirements.
Oracle9i enforces DAC based on the user's system and object privileges: The user must be authenticated to the Oracle9i database, and must have the object and system privileges DAC requires for the requested operation.
If DAC permits access, the user's requested operation must then meet the criteria added by Oracle Label Security, using all of the following facts:
Oracle Label Security's flexibility and functionality supports applications in a wide variety of production environments. It maintains standard Oracle9i data integrity, availability, and recovery capabilities, including user accountability and auditing, while enforcing a site's security policies.
Figure 1-2 illustrates how data is accessed under Oracle Label Security, showing the sequence of DAC and label security checks. An application user in an Oracle9i session issues a SQL request. Oracle9i checks the DAC privileges, making sure the user has SELECT privileges on the table. Then it checks whether a VPD policy has been attached to the table, finding that the table is protected by Oracle Label Security. The SQL statement is modified on the fly.
Oracle Label Security is invoked for each row. Access is granted or denied based on comparing the data label and the user's session label, subject to the user's Oracle Label Security privileges.
Oracle Label Security is built on the virtual private database (VPD) technology delivered in the Oracle Enterprise Edition and leverages that product's Application Context functionality.
Text description of the illustration olsag004.gif
Oracle Label Security provides row level security access controls that operate in addition to the underlying access controls of the Oracle9i database. This section presents Oracle Label Security features in the following topics:
A Label Security administrator defines a set of labels for data and users, along with authorizations for users and program units, that govern access to specified protected objects. A policy is nothing more than a name associated with these labels, rules, and authorizations.
For example, assume that a user has SELECT privilege on an application table. As illustrated in Figure 1-3, when the user executes a SELECT statement, Oracle Label Security evaluates each row selected to determine whether the user can access it. The decision is based on the privileges and access labels assigned to the user by the security administrator. Oracle Label Security can also be configured to perform security checks on UPDATE, DELETE, and INSERT statements.
Text description of the illustration olsag008.gif
VPD supports policy-driven access control. VPD policies enforce object-level access control or row-level security. It provides an application program interface (API) that allows security policies to be assigned to database tables and views. For example, one can allow access to salary data only for managers in the same facility. Using PL/SQL, developers and security administrators can create security policies with stored procedures. These procedures can be bound to a table or view by means of a call to an RDBMS package. Such policies restrict access by using the content of application data stored in the Oracle9i database or context variables provided by Oracle9i, such as user name or IP address. Using VPD policies permits developers to remove access security mechanisms from applications and centralize them within Oracle9i.
As illustrated in Figure 1-4, VPD lets you associate security conditions with tables, views, or synonyms. In this example, when each user selects from the ORDERS table, the appropriate security condition is automatically enforced. No matter how the data is accessed, the server automatically enforces security policies, eliminating the need to use many views to implement security.
Text description of the illustration olsag002.gif
Oracle Label Security provides a built-in security policy and infrastructure that easily enforces row-level security. This out-of-the-box solution requires no programming, dramatically reducing both total cost of ownership and the time to market for new products and applications.
Oracle Label Security administrators create policies for row-level security by simply providing a descriptive name, without writing PL/SQL. There is no need to write additional code; in a single step you can apply a security policy to a given table. This straightforward, efficient way to implement fine-grained security policies allows a granularity and flexibility not easily achieved with VPD alone. Oracle Label Security is thus a generic solution that can be used in many different circumstances.
Oracle Label Security adds label-based access controls to the Oracle9i object-relational database management system. Access to data is mediated based on these factors:
Consider, for example, a standard Data Manipulation Language operation (such as SELECT) performed upon a row of data. When evaluating this access request by a user with the CONFIDENTIAL label, to a data row labeled CONFIDENTIAL, Oracle Label Security determines that this access can, in fact, be achieved. If the row label were higher, say TOP SECRET, access would be denied.
In this way, data of different sensitivities--or belonging to different companies--can be stored and managed on a single system, while preserving data security through standard Oracle access controls. Likewise, applications from a broad range of industries can use row labels with policies providing additional highly targeted access control wherever necessary, without disturbing other existing uses for the same tables.
Labels and policy enforcement depend on the factors explained in the following sections:
In Oracle Label Security, each row of a table can be labeled as to its level of confidentiality. Every label contains three components:
Levels represent a hierarchy of data sensitivity to exposure or corruption, where the concern is maintaining privacy or security. Levels constitute the primary mechanism to exclude users who are not authorized to see or alter certain data. A user with a lower authorization level, represented by a numerically lower number, is automatically restricted from accessing data labeled with a higher level number. A typical government organization might define levels CONFIDENTIAL, SENSITIVE, and HIGHLY_SENSITIVE. A commercial organization might define a single level for COMPANY_CONFIDENTIAL data.
The compartment component is not hierarchical, but simply designates some useful categories typically defined to segregate data--such as data related to separate ongoing strategic initiatives. Some organizations omit using compartments initially.
The group component is hierarchical and is used to reflect ownership. For example, FINANCE and ENGINEERING groups can be defined as children of the CEO group, creating an ownership relation. This hierarchy determines that a user labeled with only ENGINEERING could not view data labeled with FINANCE, but a user labeled CEO could see data labeled as either subgroup. The full rules for how groups determine access are described in Chapter 3.
A label can be any one of the following four combinations of components:
Users can be granted label authorizations that determine what kind of access (read or write) they have to the rows that are labeled. When a label has been applied to a row, only users authorized for access to that label can see it or possibly change it. No user can access or affect rows for which that user lacks appropriate authorization. If a row has multiple labels, a user must have appropriate authorizations for each such label in order to see or alter that row.
Policy privileges enable a user or stored program unit to bypass some aspects of the label-based access control policy. In addition, the administrator can authorize the user or program unit to perform specific actions, such as the ability of one user to assume the authorizations of a different user. Chapter 3 explains privileges.
Privileges can be granted to program units, authorizing the procedure, rather than the user, to perform privileged operations. System security is at its highest when only stored program units--and not individual users--have Oracle Label Security privileges. Further, such program units encapsulate the policy, minimizing the amount of application code that needs to be reviewed for security.
In Oracle Label Security, administrators or application developers can apply different policy enforcement options for maximum flexibility in controlling the Data Manipulation Language operations users can perform. Chapter 7 explains policy enforcement options.
When label-based access is enforced within a protected table, access to a row requires a user's label to meet certain criteria determined by policy definitions. These access controls act as a secondary access mediation check, after the discretionary access controls implemented by the application developers.
In summary, Oracle Label Security provides four aspects of label-based access control:
Sites that integrate their use of Oracle Label Security with Oracle Internet Directory gain significant efficiencies of label security operation and administration. Policies and user authorization profiles are created and managed directly in the directory by means of the commands described in Appendix B, "Command-line Tools for Label Security Using Oracle Internet Directory". Changes are automatically propagated to the associated directories.
A complete introduction to this integration is presented in Chapter 5, "Oracle Label Security Using Oracle Internet Directory".
Note that the graphical user interface for the Oracle Policy Manager (OPM) should be used for viewing data only when Oracle Label Security is configured to use the Oracle Internet Directory. OPM can be used to view and modify data only when Oracle Label Security is configured to use the Oracle9i database as its primary repository. OPM can be used to manage VPD regardless of the Oracle Label Security configuration.
|
 Copyright © 2000, 2003 Oracle Corporation All Rights Reserved. |
|
