10-08-2012, 03:26 PM
Database Encryption
DataBase Encryption.pdf (Size: 52.35 KB / Downloads: 51)
SECURING SENSITIVE INFORMATION
The Internet poses new challenges in information security, especially for those organizations seeking to
become e-businesses. Many of these security challenges can be addressed by the traditional arsenal of
security mechanisms:
· strong user authentication to identify users
· granular access control to limit what users can see and do
· auditing for accountability
· network encryption to protect the confidentiality of sensitive data in transmission
Encryption is an important component of several of the above solutions. For example, Secure Sockets
Layer (SSL), an Internet-standard network encryption and authentication protocol, uses encryption to
strongly authenticate users, via X.509 digital certificates. SSL also uses encryption to ensure data
confidentiality, and cryptographic checksums to ensure data integrity. Many of these uses of encryption
are relatively transparent to a user or application. For example, many browsers support SSL, and users
generally don’t need to do anything special to enable SSL encryption.
Oracle has provided network encryption between database clients and the Oracle database since
Oracle7. Oracle Advanced Security, an option to Oracle9i, provides encryption and cryptographic
integrity check for any protocol supported by Oracle9i, including Net8, Java Database Connectivity
(JDBC) (both “thick” and “thin” JDBC), and the Internet Intra-Orb Protocol (IIOP). Oracle Advanced
Security also supports SSL for Net8, “thick” JDBC and IIOP connections.
While encryption is not a security cure-all, it is an important tool used to address specific security
threats, and will become increasingly more important with the growth of e-business, most particularly in
the area of encryption of stored data. For example, while credit card numbers are typically protected in
transit to a web site using SSL, the credit card number is often stored in the clear (unencrypted), either
on the file system, where it is vulnerable to whomever can break into the host and gain root access, or in
databases. While databases can be made quite secure through proper configuration, they can also be
vulnerable to host break-ins if the host is misconfigured. There have been several recent, wellpublicized
break-ins, in which a hacker obtained a large list of credit card numbers by breaking into a
database.
Encryption of stored data thus represents a new challenge for e-businesses, and can be an important tool
in dealing with specific types of security threats.
Database Encryption in Oracle9I 2
February 2001
ENCRYPTION ISSUES
While there are many good reasons to encrypt data, there are many bad reasons to encrypt data.
Encryption does not solve all security problems, and may even make some problems worse. The
following section describes some of the misconceptions about encryption of stored data.
Issue 1: Encryption is not access control
Most organizations need to limit access to data to those who have a “need to know.” For example, a
human resources system may limit employees to reviewing only their own employment records, while
managers of employees may see the employment records of those employees working for them. Human
resources specialists may also need to see employee records for multiple employees.
This type of security policy ¾ limiting data access to those with a need to see it ¾ is typically
addressed by access control mechanisms. The Oracle database has provided strong, independentlyevaluated
access control mechanisms for many years. Recently, Oracle8i has added the ability to
enforce access control to an extremely fine level of granularity, through its Virtual Private Database
capability.
Because human resources records are considered sensitive information, it’s tempting to think that this
information should all be encrypted “for better security.” However, encryption cannot enforce the type
of granular access control described above, and may actually hinder data access. In the human resources
example, an employee, his manager, and the HR clerk all need to access the employee’s record. If
employee data is encrypted, then each person also has to be able to access the data in unencrypted form.
Therefore, the employee, the manager and the HR clerk would have to share the same encryption key to
decrypt the data. Encryption would therefore not provide any additional security in the sense of better
access control, and the encryption might actually hinder the proper functioning of the application. There
is the additional issue that it is very difficult to securely transmit and share encryption keys among
multiple users of a system.
A basic principle behind encrypting stored data is that it must not interfere with access control. For
example, a user who has SELECT privilege on EMP should not be limited by the encryption mechanism
from seeing all the data he is otherwise allowed to see. Similarly, there is little benefit to encrypting,
(for example) part of a table with one key and part of a table with another key if users need to see all
encrypted data in the table; it merely adds to the overhead of decrypting data before users can read it.
Provided that access controls are implemented well, there is little additional security provided within the
database itself from encryption; any user who has privilege to access data within the database has no
more nor less privilege as a result of encryption. Therefore, encryption should never be used to solve
access control problems.
Issue 2: DBAs can access all data
Some organizations are concerned that database administrators (DBAs), because they typically have all
privileges, are able to see all data in the database. These organizations feel that the DBAs should
merely administer the database, but should not be able to see the data that the database contains. Some
organizations are also concerned about the concentration of privilege in one person, and would prefer to
partition the DBA function, or enforce two-person rules.
It’s tempting to think that encrypting all data (or significant amounts of data) will solve the above
problems, but there are better ways to accomplish these objectives. First of all, Oracle does support
limited partitioning of DBA privilege. Oracle9i provides native support for SYSDBA and SYSOPER
Database Encryption in Oracle9I 3
February 2001
users. SYSDBA has all privileges, but SYSOPER has a limited privilege set (e.g. startup and shutdown
of the database). Furthermore, an organization can create smaller roles encompassing a number of
system privileges. A JR_DBA role might not include all system privileges, but only those appropriate to
a more junior database administrator (such as CREATE TABLE, CREATE USER, etc.) Oracle does
not audit the actions taken by SYS (or SYS-privileged users) but does audit startup and shutdown of the
database in the operating system records.
Furthermore, the DBA function by its nature is a trusted position. Even organizations with the most
sensitive data ¾ such as intelligence agencies ¾ do not typically partition the DBA function. Instead,
they vet their DBAs strongly, because it is a position of trust.
Encryption of stored data must not interfere with the administration of the database, or larger security
issues can result than you were attempting to address with encryption. For example, if by encrypting
data, you corrupt the data, you’ve created a security problem: data is not meaningful and may not be
recoverable.
Encryption can be used to mitigate the ability of a DBA ¾ or other privileged user ¾ to see data in the
database, but it is not a substitute for vetting a DBA properly, or for limiting the use of powerful system
privileges. If an untrustworthy user has significant privilege, there are multiple threats he can pose to an
organization, which may be far more significant than viewing unencrypted credit card numbers.
Issue 3: Encrypting everything does not make data secure
It’s a pervasive tendency to think that if storing some data encrypted strengthens security, then
encrypting everything makes all data secure.
We’ve already seen why encryption does not address access control issues well. Consider the
implications of encrypting an entire production database. All data must be decrypted to be read,
updated, or deleted, and, as discussed earlier, the encryption must not interfere with normal access
controls. Encryption is innately a performance-intensive operation; encrypting all data will significantly
affect performance. Availability is a key aspect of security and if, by encrypting data, you make data
unavailable, or the performance adversely affects availability, you have created a new security problem.
Encryption keys must be changed regularly as part of good security practice, which necessitates that the
database be inaccessible while the data is being decrypted and reencrypted with a new key or keys. This
also adversely affects availability.
While encrypting all or most data in a production database is clearly a problem, there may be
advantages to encrypting data stored off-line. For example, an organization may store backups for a
period of six months to a year off-line, in a remote location. Of course, the first line of protection is to
secure the data in a facility to which access is controlled, a physical measure. However, there may be a
benefit to encrypting this data before it is stored, and since it is not being accessed on-line, performance
need not be a consideration. While Oracle9i does not provide this facility, there are vendors who can
provide such encryption services. Organizations considering this should thoroughly test that data (that is
encrypted before off-line storage) can be decrypted and re-imported successfully before embarking on
large-scale encryption of backup data.
Database Encryption in Oracle9I 4
February 2001
SOLUTIONS FOR STORED DATA ENCRYPTION IN ORACLE
Oracle9i Data Encryption Capabilities
While there are many security threats that encryption cannot address well, it is clear that one can obtain
an additional measure of security by selectively encrypting sensitive data before storage in the database.
Examples of such data could include:
· credit card numbers
· national identity numbers
· passwords for applications whose users are not database users
To address the above needs, Oracle8i (release 8.1.6) introduced a PL/SQL package to encrypt and
decrypt stored data. The package, DBMS_OBFUSCATION_TOOLKIT, is provided in both Standard
Edition and Enterprise Edition Oracle9i. The package is documented in the Oracle9i Supplied PL/SQL
Packages Reference Guide.