| 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 othe rs. 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 gen eral users have access to needed information, sometimes in the same tables.
Data can be vie wed as sensitive for many different reasons. Examples include personal and private matters or communications, professional trade secr ets, 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 cost ly 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 p rivileges. Administrators can easily add selective row-restrictive policies to existing databases by means of the easy-to-use graphic al 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 c omplete introduction to Oracle9i features and terminology, see Oracle Database Concepts |
Computer security involves the protection of computerized dat a and processes from unauthorized modification, destruction, disclosure, or delay. In the Internet age, the risks to valuable and sen sitive data are greater than ever before. Figure 1-1 shows the complex computing environment tha t 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 co mmerce confidentiality as customers access those databases. Oracle Corporation provides products to address this full spectrum of com puter security issues.
Oracle Co rporation is a leader in information assurance. Security evaluation is a formal assessment process performed by independent bodies ag ainst 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 cer tification 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 L abel Security has been evaluated under the Common Criteria (ISO 15408) at Evaluation Assurance Level (EAL) 4, the highest level gener ally achieved by commercial software vendors.
A database se curity policy implements an overall system security policy within a broad, organizational security policy. The overall securit y policy can enforce the following types of rules:
Access control defi nes a user's ability to read, write, update, insert, or delete information. The following approaches are available to meet access con trol needs:
Oracle9i pr ovides 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 obje ct, 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 i n 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 s ensitivity within that policy. Level access is then determined by comparing the user's identity and label with that of the row.
< a name="1007005">Oracle Label Security access control depends first on the basic DAC policy. Together, DAC and Or acle 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 satis fy 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 auth enticated to the Oracle9i database, and must have the object and system privileges DAC requires for the reque sted operation.
If DAC permits access, the user's requested operation must then meet the cr iteria 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 recover y capabilities, including user accountability and auditing, while enforcing a site's security policies.
< p class="BP">Figure 1-2 illustrates how data is accessed under Oracle Label Security, showing th e 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.
< a name="1010317">Oracle Label Security is built on the virtual p rivate database (VPD) technology delivered in the Oracle Enterprise Edition and leverages that product's Application Context function ality.
Text description of the illustration olsag004.gif
Oracle Label Security provides row level security access controls that operate in addition to the u nderlying access controls of the Oracle9i database. This section presents Oracle Label Security features in t he following topics:
A Label Security administrator defines a set of labels for data and users, along with auth orizations for users and program units, that govern access to specified protected objects. A policy is nothing more than a name assoc iated with these labels, rules, and authorizations.
For example, assume that a user has SEL ECT privilege on an application table. As illustrated in Figure 1-3, when the user executes a SE LECT 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 ols ag008.gif
VPD supports policy-driven access control. VPD policies enforce object-level access control or row-level security. It provides a n 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. Su ch policies restrict access by using the content of application data stored in the Oracle9i database or conte xt 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 w ith 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 th e illustration olsag002.gif
Oracle Label Security provides a built-in security policy and infrastructure that easily enforces row-level secu rity. 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 fo r 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 th at 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 e xample, a standard Data Manipulation Language operation (such as SELECT) performed upon a row of data. When evaluating this access re quest by a user with the CONFIDENTIAL label, to a data row labeled CONFIDENTIAL, Oracle Label Security determines that this access ca n, 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 u se 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 thre e components:
Levels represent a hierarchy of dat a sensitivity to exposure or corruption, where the concern is maintaining privacy or security. Levels constitute the primary mechanis m to exclude users who are not authorized to see or alter certain data. A user with a lower authorization level, represented by a num erically lower number, is automatically restricted from accessing data labeled with a higher level number. A typical government organ ization 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 design ates 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 hierarchica l 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 fou r 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 lab eled. 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 use r can access or affect rows for which that user lacks appropriate authorization. If a row has multiple labels, a user must have appro priate 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 pol icy. In addition, the administrator can authorize the user or program unit to perform specific actions, such as the ability of one us er 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 perfo rm privileged operations. System security is at its highest when only stored program units--and not individual users--have Oracle Lab el Security privileges. Further, such program units encapsulate the policy, minimizing the amount of application code that needs to b e reviewed for security.
In Oracle Label Security, administrators or application developers can apply different policy enforcement options for maximum flexibility in controlling the D ata Manipulation Language operations users can perform. Chapter 7 explains policy enforcement options.
When label-based acc ess is enforced within a protected table, access to a row requires a user's label to meet certain criteria determined by policy defin itions. These access controls act as a secondary access mediation check, after the discretionary access controls implemented by the a pplication developers.
In summary, Oracle Label Security provides four aspects of label-bas ed access control:
Si tes 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 Di rectory". Changes are automatically propagated to the associated directories.
A complet e introduction to this integration is presented in Chapter 5, "Oracle Label Security Using Oracle I nternet Directory".
Note that the graphical user interface for the Oracle Policy Manage r (OPM) should be used for viewing data only when Oracle Label Security is configured to use the Oracle Internet Directory. OPM can b e 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. |
|
