Skip Headers
Oracle® Collaboration Suite Security Guide
10g Release 1 (10.1.2)

Part Number B25494-10
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

4 Oracle Collaboration Suite Database Security

Database security requirements arise from the need to protect data from accidental loss and corruption as well as from deliberate unauthorized attempts to access or alter that data. Security concerns also include protecting against undue delays in accessing or using data, interference, and in extreme cases, denial of service.

This chapter presents the fundamental concepts of database security requirements and contains the following sections:

4.1 Introduction to Database Security Concepts

Confidentiality, integrity, and availability are the cornerstones of database security. Who should have the right to access data? What portion of all the data should a particular user be able to access? What operations should an authorized user be able to perform on the data? Can authorized users access valid data when necessary? Authorization is the permission given to a user, program, or process to access an object or set of objects. The type of data access granted to a user can be read-only or read/write. Privileges specify the type of Data Manipulation Language (DML) operations that the user can perform on data.

Database integrity ensures that data in the database is correct and consistent. Database integrity mechanisms can be divided into those that support system integrity and those that enforce relational database integrity properties such as entity integrity, referential integrity, transaction integrity, and business rules. Traditional system integrity involves ensuring that data retrieved from the system is the same as the data when it was originally inserted. In addition, data must not be altered or deleted by a user who is not authorized to do so. A database must ensure that data adheres to certain business rules, as determined by the database administrator or application developer. For example, assume that a business rule says that no employee in the emp table can receive a raise greater than 20 percent of the value in the salary column. If an insert or update statement attempts to violate this integrity rule, then the statement must fail. Integrity constraints and database triggers can be used to enforce data integrity rules within a database.

Referential integrity rules form the basis of data integrity in relational databases. Referential integrity ensures that data entered in one table, which references another table in a relational database, and the rules that govern this data are in conformance with the referenced values. Referential integrity includes rules that dictate the types of data manipulation allowed on referenced values, and these rules are used to determine the effect of data manipulation on dependent values.

4.2 Oracle Advanced Security Architecture

Oracle Advanced Security provides a comprehensive suite of security features to protect enterprise networks and securely extend corporate networks to the Internet. It provides a single source of integration with network encryption and authentication solutions, single sign-on services, and security protocols. By integrating industry standards, it delivers unparalleled security to an Oracle networking environment. Oracle Advanced Security complements an Oracle server or client installation with advanced security features. Figure 4-1 shows the Oracle Advanced Security architecture within an Oracle networking environment.

Figure 4-1 Oracle Advanced Security in an Oracle Networking Environment

Oracle_Advanced_Security
Description of the illustration aso.gif

Oracle Advanced Security supports authentication through adapters that are similar to the existing Oracle protocol adapters. As shown in Figure 4-2, authentication adapters integrate under the Oracle Net interface and allow existing applications to take advantage of new authentication systems transparently, without any changes to the application.

Figure 4-2 Oracle Net with Authentication Adapters

Oracle_Net_with_Authentication_Adapters
Description of the illustration aso1.gif

4.3 Solving Security Challenges with Oracle Advanced Security

To solve enterprise computing security problems, Oracle Advanced Security provides various options to ensure industry standards-based data privacy, integrity, authentication, single sign-on, and access authorization. For example, you can configure either Oracle Net native encryption or Secure Sockets Layer (SSL) for data privacy. Oracle Advanced Security also provides the choice of several strong authentication methods, including Kerberos, smart cards, and digital certificates.

Oracle Advanced Security provides the following security features:

4.3.1 Data Encryption

Sensitive information that travels over enterprise networks and the Internet can be protected by encryption algorithms. An encryption algorithm transforms information into a form that can be deciphered only with a decryption key. Figure 4-3 shows how encryption works to ensure the security of a transaction. For example, if a manager approves a bonus, this data should be encrypted when sent over the network to avoid eavesdropping. If all communication between a client, database, and an application server is encrypted, then when the manager sends the bonus amount to the database, the information is protected.

This section discusses the following topics:

4.3.1.1 Supported Encryption Algorithms

Oracle Advanced Security provides the following encryption algorithms to protect the privacy of network data transmissions:

Selecting the network encryption algorithm is a user configuration option that provides varying levels of security and performance for different types of data transfer. Prior versions of Oracle Advanced Security provided three editions: Domestic, Upgrade, and Export--each with different key lengths. Oracle Advanced Security 10g Release 1 (10.1) contains a complete complement of the available encryption algorithms and key lengths, previously only available in the Domestic edition. Users deploying prior versions of the product can obtain the Domestic edition for a specific product release.

4.3.1.1.1 RC4 Encryption

The RC4 encryption module uses the RC4 encryption algorithm created by RSA Security, Inc. Using a secret, randomly-generated key that is unique to each session, all network traffic is fully safeguarded, including all data values, SQL statements, and stored procedure calls and results. The client, server, or both, can require or request the use of the encryption module to guarantee data protection. The optimized implementation supported by Oracle provides a high degree of security for a minimal performance penalty. For the RC4 algorithm, Oracle provides encryption key lengths of 40-bits, 56-bits, 128-bits, and 256-bits.

4.3.1.1.2 DES Encryption

Oracle Advanced Security implements the U.S. Data Encryption Standard (DES) algorithm with a standard, optimized, 56-bit key encryption, and also provides DES40, a 40-bit version, for backward compatibility.

4.3.1.1.3 Triple-DES (3DES) Encryption

Oracle Advanced Security also supports Triple-DES encryption (3DES), which encrypts message data with three passes of the DES algorithm. 3DES provides a high degree of message security, but with considerable performance penalty. The magnitude of penalty depends on the speed of the processor performing the encryption. 3DES typically takes three times as long to encrypt a data block as compared to the standard DES algorithm. 3DES is available in two-key and three-key versions with effective key lengths of 112 bits and 168 bits, respectively. Both versions operate in outer Cipher Block Chaining (CBC) mode.

4.3.1.1.4 Advanced Encryption Standard

Approved by the National Institute of Standards and Technology (NIST) in Federal Information Processing Standards (FIPS) Publication 197, Advanced Encryption Standard (AES) is a new cryptographic algorithm standard developed to replace DES. AES is a symmetric block cipher that can process data blocks of 128 bits, using cipher keys with lengths of 128, 192, and 256 bits, which are referred to as AES-128, AES-192, and AES-256, respectively. All three versions operate in outer CBC mode.

4.3.1.2 Data Integrity

To ensure the integrity of data packets during transmission, Oracle Advanced Security can generate a cryptographically secure message digest, using MD5 or SHA-1 hashing algorithms, and include it with each message sent across a network.

Data integrity algorithms add little overhead, and protect against the following attacks:

  • Data modification

  • Deleted packets

  • Replay attacks

4.3.1.3 FIPS

Oracle Advanced Security Release 8.1.6 has been validated under U.S. FIPS 140-1 at the Level 2 security level. This provides independent confirmation that Oracle Advanced Security conforms to federal government standards.

4.3.2 Strong Authentication

Authentication is used to prove the identity of a user. Authentication, without which there can be little confidence in network security, is imperative in distributed environments. Passwords are the most common means of authentication. Oracle Advanced Security provides strong authentication with Oracle authentication adapters that support various third-party authentication services, including SSL with digital certificates.

Figure 4-4 shows user authentication with an Oracle database configured to use a third-party authentication server. Having a central facility to authenticate all the members of a network (clients to servers, servers to servers, and users to both clients and servers) is one effective way to address the threat of network nodes falsifying their identities.

Figure 4-4 Strong Authentication with Oracle Authentication Adapters

Strong_Authentication
Description of the illustration asoauthent.gif


See Also:

Oracle Advanced Security Administrator's Guide for more information about the authentication methods supported by Oracle Advanced Security

4.4 SSL Combined with Other Authentication Methods

You can configure Oracle Advanced Security to use SSL concurrently with database user names and passwords, RADIUS, and Kerberos, which are discussed in the following sections:

4.4.1 Oracle Advanced Security and SSL

Figure 4-1, which displays the Oracle Advanced Security implementation architecture, shows that Oracle Advanced Security operates at the session layer on top of SSL and uses TCP/IP at the transport layer. This separation of functionality lets you employ SSL concurrently with other supported protocols.

4.4.2 How SSL Works with Other Authentication Methods

Figure 4-5 illustrates a configuration in which SSL is used in combination with another authentication method supported by Oracle Advanced Security. In this example, SSL is used to establish the initial handshake (server authentication), and a different authentication method is used to authenticate the client.

Figure 4-5 SSL Combined with Other Authentication Methods

SSL_with_Other_Authentication_Methods
Description of the illustration sslotherauth.gif

  1. The client seeks to connect to the Oracle database server.

  2. SSL performs a handshake during which the server authenticates itself to the client and both the client and server establish which cipher suite to use.

  3. Once the SSL handshake is successfully completed, the user seeks access to the database.

  4. The Oracle database server authenticates the user with the authentication server using a non-SSL authentication method such as Kerberos or RADIUS.

  5. Upon validation by the authentication server, the Oracle database server grants access and authorization to the user, and then the user can access the database securely by using SSL

4.4.3 SSL and Firewalls

Oracle Advanced Security supports two types of firewalls:

  • Application proxy-based firewalls, such as Network Associates Gauntlet or Axent Raptor.

  • Stateful packet inspection firewalls, such as Check Point Firewall-1 or Cisco PIX Firewall.

When you enable SSL, stateful inspection firewalls behave similar to application proxy firewalls because they do not decrypt encrypted packets.

Firewalls do not inspect encrypted traffic. When a firewall encounters data addressed to an SSL port on an intranet server, it checks the target IP address against its access rules. It then allows the SSL packet to pass through to permitted SSL ports, rejecting all other packets.

With the Oracle Net Firewall Proxy kit, a product offered by some firewall vendors, firewall applications can provide specific support for database network traffic. If the proxy kit is implemented in the firewall, the following processing takes place:

  • The Net Proxy (a component of the Oracle Net Firewall Proxy kit) determines where to route the traffic it handles.

  • The database listener requires access to a certificate to participate in the SSL handshake. The listener inspects the SSL packet and identifies the target database, returning the port on which the target database listens to the client. This port must be designated as an SSL port.

  • The client communicates on this server-designated port in all subsequent connections.

  • The number of ports that are open in the firewall increase as a function of the number of database connections requested for different databases. However, this approach prevents the database server from using randomly chosen SSL ports. This is because the SSL ports chosen by the database must match the SSL ports on the firewall. You can avoid this condition by deploying Oracle Connection Manager, an application included with Oracle Database Enterprise Edition.

Oracle Connection Manager enables you to route client connections over multiple Oracle Net protocols. Each client connection request establishes an SSL connection between the client and Oracle Connection Manager, which in turn establishes a TCP/IP connection with the target database. Multiple clients can thus connect to multiple databases behind the firewall, using a single SSL port on the firewall.

4.4.4 SSL Usage Issues

Although the use of SSL enables secure communication with other Oracle products, such as Oracle Internet Directory, there are some issues that you need to bear in mind:

  • Because SSL supports both authentication and encryption, the client/server connection is somewhat slower than the standard Oracle Net TCP/IP transport (using native encryption).

  • Each SSL authentication mode requires configuration settings.

4.5 Secure Configuration Practices

Any techniques that you employ to assure data security can be rendered useless unless the database administrator follows good security practices. For example, you should always:

4.6 Database Security Policies

This section briefly introduces security policies. It covers:

4.6.1 Security Threats and Countermeasures

An organization should create a well-documented security policy. This policy should enumerate the security threats the organization is trying to guard against and the specific measures the organization must take when it encounters these threats. Security threats can be addressed by the following measures:

  • Procedural, such as requiring data center employees to display security badges

  • Physical, such as securing computers containing critical information in restricted-access facilities

  • Technical, such as implementing strong authentication requirements for critical business systems

  • Personnel-related, such as performing background checks or vetting key personnel

The organization should consider whether the response to a threat is procedural, physical, technical, personnel-related, or a combination of these. For example, one possible security threat is the disruption of critical business systems caused by a malicious person damaging a computer. A physical response to this threat is to secure key business computers in a restricted-access facility. A procedural response is to create system backups at regular intervals. Personnel measures could include background checks on employees who access or manage key business systems.

4.6.2 What Information can Security Policies Cover

In addition to addressing requirements unique to the organization environment, the organization should also design and implement technical measures in its information security policies to address generic issues, as listed in Table 4-1:

Table 4-1 Issues and Actions Governing Security Policies

Security Concern/Practice Recommended Actions
Establish and maintain application-level security Attach privileges and roles to each application.

Ensure that users cannot misuse these roles and privileges when they are not using the application.

Base the use of roles on user-specific criteria, such as a user connecting only from a particular IP address, or only through a particular application tier.

Manage privileges and attributes (system/object/user) Permit only a limited set of users to access, process, or alter data or to run a particular type of SQL statement or to access another user's object.

Apply the required limitations on user access to objects or actions on objects, such as schemas, tables, or rows, or resources, such as system usage time (CPU, connect, or idle times).

Create, manage, and control roles (database, enterprise) Create named groups of privileges called roles to facilitate granting them to users, including previously named groups.
Establish the granularity of access control desired Set up session-based attributes in a secure manner. For example, store user attributes (user name, employee number, and so on) to be retrieved later in the session, enabling fine-grained access control.

Create security policy functions and attach them to critical or sensitive tables, views, or synonyms used by an application. DML statements on such objects are then modified dynamically, and transparently to the user, to disable inappropriate access.

Establish and manage the use of encryption Use Secure Socket Layer (SSL) connections, well-established encryption suites, or PKI certificates for critical/sensitive transmissions/applications.
Establish and maintain security in 3-tier applications Preserve user identity through a application tier to the database.

Avoid the overhead of separate database connections by proxying user identities (and credentials such as a password or certificate) through the application tier to the database.

Control query access, data misuse, and intrusions Monitor query access based on specific content or row to detect data misuse or intrusions.

Use proxy authentication to support auditing of proxied user connections.

Use Regular Auditing and Fine-Grained Auditing to detect unauthorized or inappropriate access or actions.


4.7 Authentication by the Oracle Database

Oracle can authenticate users attempting to connect to a database, by using information stored in that database.

To set up Oracle to use database authentication, you create each user with an associated password that must be supplied when the user attempts to establish a connection. This process prevents unauthorized use of the database because the connection will be denied if the user provides an incorrect password. Oracle stores a user's password in the data dictionary in an encrypted format to prevent unauthorized alteration, but a user can change his own password at any time.

To establish which authentication protocols are allowed by the client or database, a DBA can explicitly set the SQLNET.ALLOWED_LOGON_VERSION parameter in the sqlnet.ora server file. Then each connection attempt is tested, and if the client or server does not meet the minimum version specified by its partner, authentication fails with an ORA-28040 error. The parameter can take the values 10, 9, or 8 (default), which represent the database server versions. Oracle recommends the value 10.

Database authentication includes the following facilities:

4.7.1 Password Encryption While Connecting

Passwords are always automatically and transparently encrypted during network (client/server and server/server) connections. This is done by using a modified DES (Data Encryption Standard) or 3DES algorithm before sending them across the network.

4.7.2 Account Locking

Oracle can lock a user's account after a specified number of consecutive failed log-in attempts. You can configure the account to unlock automatically after a specified time interval or by database administrator intervention.

Use the CREATE PROFILE statement to specify the number of failed login attempts allowed before the account locks and the duration for which the account remains locked before it unlocks automatically.

The DBA can also lock accounts manually. In these cases, the accounts cannot unlock automatically and must be unlocked explicitly by the DBA.

4.7.3 Password Lifetime and Expiration

The database administrator can specify a lifetime for passwords, after which they expire and must be changed before account login is permitted. A grace period can be specified, during which each attempt to log in to the database account receives a warning message to change the password. If it is not changed by the end of that period, the account is locked. No further login to that account is allowed without assistance by the DBA.

The DBA can also manually set the password state to expired, causing the user's account status to change to expired. The user or the DBA must then change the password before the user can log in to the database.

4.7.4 Password History

The password history option checks each newly specified password to ensure that a password is not reused for a specified amount of time or for a specified number of password changes. The database administrator can configure the rules for password reuse with CREATE PROFILE statements.

4.7.5 Password Complexity Verification

Password complexity verification checks that each password is complex enough to provide reasonable protection against intruders who try to break into the system by guessing passwords.

The sample Oracle password complexity verification routine (PL/SQL script UTLPWDMG.SQL, which sets the default profile parameters) specifies that a password must:

  • Be a minimum of four characters in length.

  • Not be the same as the user ID.

  • Include at least one alphabet character, one numeric character, and one punctuation mark.

  • Not match any word on an internal list of simple words, such as welcome, account, database, and user.

  • Differ from the old password by at least three characters.