| Oracle® Label Security Administrator's Guide 10g Release 2 (10.2) Part Number B14267-02 |
|
|
View PDF |
| Oracle® Label Security Administrator's Guide 10g Release 2 (10.2) Part Number B14267-02 |
|
|
View PDF |
Control of access to sensitive information is of concern to managers, information officers, DBAs, application developers, and 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 ensures that sensitive information will be unavailable to unauthorized persons even while authorized users have access to needed information, sometimes in the same tables.
Data can be viewed as sensitive for 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.
However, 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 Oracle Database 10g Release 2 (10.2) 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 user-friendly graphical interface called Oracle Policy Manager. Developers can readily add label-based access control to their Oracle Database applications.
This chapter introduces Oracle Label Security in the larger context of data security. It contains the following sections:
Oracle Label Security Integration with Oracle Internet Directory
Note:
This book assumes that you understand the basic concepts and terminology of Oracle Database administration and application development. It supplements core Oracle Database 10g Release 2 (10.2) documentation by focusing on the additional considerations involved in using, administering, and developing applications for Oracle Label Security.See Also:
For a complete introduction to Oracle Database 10g Release 2 (10.2) features and terminology, refer to Oracle Database ConceptsComputer 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, "Scope of Data Security Needs" 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:
Security officers, administrators, and application programmers must protect databases and the servers on which those databases reside. Also they must administer and protect the rights of internal database users, and they must guarantee electronic commerce confidentiality as customers access those databases. Oracle provides products to address this full spectrum of computer security issues.
Oracle 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. On successful completion of evaluation, a security rating is assigned to the system or product. This certification provides confidence in the security of products and systems to commercial and government users.
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:
Oracle Database 10g Release 2 (10.2) 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 proper privilege, such as the SELECT privilege. To access the data in an object, a user or process must first have the necessary DAC privileges.
Labels enable sophisticated access control rules beyond those of DAC 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 Oracle Database DAC requirements and then satisfy Oracle Label Security requirements.
Oracle Database enforces DAC based on the user's system and object privileges: The user must be authenticated to the Oracle Database and must also 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 guidelines:
Oracle Label Security label definitions and label hierarchies
the labels of the user and row
Oracle Label Security enforcement options
The flexibility and functionality of Oracle Label Security supports applications in a wide variety of production environments. It maintains standard Oracle Database 10g Release 2 (10.2) data integrity, availability, and recovery capabilities, including user accountability and auditing, while enforcing a site's security policies.
Figure 1-2, "Oracle Label Security Architecture" illustrates how data is accessed under Oracle Label Security, showing the sequence of DAC and label security checks. An application user in an Oracle Database 10g Release 2 (10.2) session sends out a SQL request. Oracle Database checks the DAC privileges, making sure that the user has SELECT privileges on the table. Then it checks whether a Virtual private Database (VPD) policy has been attached to the table, finding that the table is protected by Oracle Label Security. The SQL statement is modified.
Oracle Label Security is started for each row. Access is granted or denied based on result of comparing the data label and the session label of the user, which is again based on the Oracle Label Security privileges of the user.
Oracle Label Security is built on the VPD technology delivered in the Oracle Database 10g Release 2 (10.2) Enterprise Edition and leverages that product's Application Context functionality.
Figure 1-2 Oracle Label Security Architecture
Oracle Label Security provides row-level security access controls that operate in addition to the underlying access controls of the Oracle 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 the SELECT privilege on an application table. As illustrated in Figure 1-3, "Oracle Label Security Label-Based Security", when the user runs 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 be configured to perform security checks on UPDATE, DELETE, and INSERT statements as well.
Figure 1-3 Oracle Label Security Label-Based Security
Oracle Label Security enables a comprehensive set of access authorizations, explained in Chapter 3, "Understanding Access Controls and Privileges", to ensure that the sensitivity label itself can be protected, separately from the other data contained in the row.
Oracle Label Security provides for flexible policy enforcement to handle special processing requirements. Examples include limiting enforcement to only one type of Data Manipulation Language (DML) statement, limiting label creation by users, or enabling default labels.
Policies can protect individual application tables. Usually not all tables in an application need to be protected. For example, lookup tables such as zip codes do not need such protection.
Oracle Label Security allows the security administrator to add special labeling functions and SQL predicates to a policy, possibly simplifying user operations.
Administrators or application developers can create multiple Oracle Label Security policies. For example, a human resources policy can coexist with a defense policy in the same database. Each policy can be independently configured, with its own unique label definitions and its own column for data labels.
A single policy can be defined and applied to multiple application tables.
VPD supports policy-driven access control. VPD policies enforce object-level access control or row-level security. It provides an application programming 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 Oracle Database or context variables provided by Oracle, such as user name or IP address. Using VPD policies permits developers to remove access security mechanisms from applications and centralize them within Oracle Database.
As illustrated in Figure 1-4, "Oracle Database 10g Release 2 (10.2) Enterprise Edition Virtual Private Database Technology", VPD lets you associate security conditions with tables, views, or synonyms. In this example, when each user selects from the ORDERS table, the required 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.
Figure 1-4 Oracle Database 10g Release 2 (10.2) Enterprise Edition Virtual Private Database Technology
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, thereby reducing both total cost of ownership and the time to market for new products and applications.
Oracle Label Security administrators can create policies for row-level security by 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. This way Oracle Label Security is a generic solution that can be used in different circumstances.
Oracle Label Security adds label-based access controls to the Oracle object-relational database management system. Access to data is mediated based on these factors:
Table 1-1 Access Mediation Factors in Oracle Label Security
| Label or Policy Factor | Chapter Reference |
|---|---|
|
The label of the data row to which access is requested |
Chapter 3, "Understanding Access Controls and Privileges" |
|
The label of the user session requesting access |
Chapter 3, "Understanding Access Controls and Privileges" |
|
The policy privileges for that user session |
Chapter 3, "Understanding Access Controls and Privileges" |
|
The policy enforcement options established for that table |
Chapter 3, "Understanding Access Controls and Privileges" |
Consider, for example, a standard DML operation (such as SELECT) performed on 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 based on its level of confidentiality. Every label contains three components:
a single level (sensitivity) ranking
zero or more horizontal compartments or categories
zero or more hierarchical groups
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 it 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, "Understanding Access Controls and Privileges".
A label can be any one of the following four combinations of components:
a single level component, with no groups or compartments, such as U::
a level and a set of compartments with no groups, such as U:Alpha, Beta:
a level and a set of groups with no compartments, such as U::FIN, ASIA
a level with both compartments and groups, such as U:Beta, Psi:ASIA, FIN
Users can be granted label authorizations that determine the 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 necessary authorization. If a row has multiple labels, then a user must have the required authorizations for each such label 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, "Understanding Access Controls and Privileges" 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 must be reviewed for security.
In Oracle Label Security, administrators or application developers can apply different policy enforcement options for maximum flexibility in controlling the DML operations users can perform. Chapter 7, "Administering User Labels and Privileges" 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:
A user's label indicates the information that a user is permitted to access, and determines the type of access (read or write) the user is allowed to perform.
A row's label indicates the sensitivity of the information that the row contains, and can also indicate its ownership and its affiliation with similar data.
A user's policy privileges can enable bypassing some aspects of a label-based access control policy.
A table's policy enforcement options determine various aspects of how access controls are enforced for read and write operations.
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 Oracle Database as its primary repository. OPM can be used to manage VPD regardless of the Oracle Label Security configuration.
