Architecture Matters: Increasing Oracle Database Security Without Application Performance Loss

Version 3

    by Larry McIntosh, Ken Kutzer, and Randal Sagrillo

     

    This article discusses SPARC processor innovations that help protect Oracle Database data while providing superior application performance. Oracle Optimized Solution architectures defy the established notion that increasing data security with encryption means sacrificing database application performance.

     

    Introduction

     

     

    In light of widespread cyberattacks and computer crime, protecting sensitive data in Oracle Databases is an especially vital concern. Securing applications, preventing intrusion, and thwarting data compromise require a well-defined, comprehensive security policy with multifaceted protection mechanisms.

     

    To this end, Oracle is validating architectures—such as Oracle Optimized Solution for Secure Oracle Database—that document best practices to safeguard data and systems, optimize performance, and increase application availability. Today these architectures incorporate Oracle platforms based on Oracle's SPARC M7 processor. As this article shows, several Software in Silicon (SWiS) features built into SPARC M7 CPU help to protect business-critical Oracle Database applications and data. While some processor innovations (specifically SQL in Silicon features) target fast analytics on Oracle Database for superior mixed-workload performance, there are two important Security in Silicon features:

    OOS_Logo_small125.png
    Oracle Optimized Solutions provide tested and proven best practices for how to run software products on Oracle systems. Learn more.

     

    • Silicon Secured Memory (SSM). SSM is an on-chip memory-access validation mechanism that can detect common memory access violations due to programming errors or malicious attempts to exploit buffer overruns. (For more details on SQL in Silicon and SSM features, see the article "Software in Silicon: What It Does and Why.")
    • On-chip cryptography engines. Each SPARC M7 CPU has 32 on-chip cryptographic instruction accelerators, one for each core. The engines directly support 15 industry-standard algorithms in the SPARC M7 processor for efficient data cryptography for Oracle Database.

     

    What's remarkable about these built-in security capabilities is that they are transparent to database applications and incur a negligible performance penalty. This means that organizations can dramatically enhance Oracle Database security with almost no sacrifice in speed!

     

    This article focuses on how organizations can best protect sensitive data within Oracle Database. In particular, it discusses the advantages of using SPARC M7 processor–based platforms with Oracle Advanced Security Transparent Data Encryption (TDE), exploring TDE configuration and implementation nuances. It also touches on the range of security mechanisms in the end-to-end Oracle Optimized Solution stack, showing how such architectures protect Oracle Database data while enabling fast OLTP and analytics performance.

     

    This article is another in the "Architecture Matters" series highlighting the benefits of deploying Oracle-on-Oracle solutions. When it comes to safeguarding sensitive Oracle Database data as described here, architecture really does matter. Because of embedded cryptography functionality in the SPARC M7 design, Oracle enables encryption that is seamless, fast, and efficient. Accelerated cryptography and features across the stack help to protect data throughout the end-to-end database lifecycle.

     

    "The future data center is completely encrypted, and this is the first processor that enables that."

     

    —JOHN FOWLER, ORACLE EXECUTIVE VICE PRESIDENT FOR SYSTEMS

     

    Built-in Cryptographic Acceleration

     

    Encryption is a typical element in many corporate security policies—guarding sensitive financial, health, or identity information is a compliance requirement for regulatory standards such as Sarbanes Oxley (SOX), the Gramm-Leach-Bliley Act (GLBA), the Health Insurance Portability and Accountability Act (HIPAA), and the Payment Card Industry-Data Security Standard (PCI DSS). On SPARC M7 processor–based systems, encryption is fast and efficient because cryptographic operations are offloaded from processor cores to the 32 on-chip accelerators (Figure 1).

     

    f1.png

    Figure 1.  Each SPARC M7 processor features 32 on-chip cryptographic instruction accelerators.

     

    In benchmarks of on-chip cryptography speeds, the SPARC M7 processor exhibited superior performance compared to current and recent Intel Xeon processors. For on-processor digest operations with Secure Hash Algorithm (SHA) functions, Oracle's SPARC T7-2 server with two SPARC M7 processors showed dramatically faster digest computations than x86 server configurations with two Intel Xeon Processor E5-2699 v4 CPUs. (See SHA Digest Encryption: SPARC T7-2 Beats x86 E5 v4.) In another encryption benchmark using Advanced Encryption Standard Cipher Feedback mode (AES-CFB, an algorithm that TDE implements with Oracle Database), a two-processor SPARC T7-2 server showed three to four times faster encryption speed than a two-processor x86 server—even with the x86 server using optimized AES-NI instructions. (See AES Encryption: SPARC T7-2 Beats x86 E5 v4.)

     

    Protecting Data at Rest

     

    The Oracle Advanced Security option to Oracle Database has two functional components: Transparent Data Encryption (TDE), which encrypts database data at rest; and Data Redaction, which allows the database to censor data prior to returning results back to applications or users (for example, masking all but the last few digits of an account number, personal identifier, or credit card). Organizations that must protect sensitive financial and personal information often have the need for both encryption and redaction capabilities.

     

    TDE provides strong encryption for Oracle Database, full key lifecycle management, and integrated support for Oracle Database tools and technologies. It automatically encrypts data when it is written to disk and automatically decrypts it when data is returned to the application (Figure 2). It is fully compatible with Oracle Database and optional database products such as Oracle Multitenant, Oracle Real Application Clusters (Oracle RAC), Oracle Database In-Memory, Oracle Advanced Compression, Oracle Recovery Manager (Oracle RMAN), Oracle Data Pump, and more. This integration means that data can be encrypted and protected on backup media and exported files, as well as on active storage media. TDE returns outbound SQL query results in the clear, which means that security architects must also consider data in transit and implement safeguards on communication channels.

     

    f2.png

    Figure 2.  TDE protects data at rest in Oracle Database without application changes.

     

    SPARC processors in Oracle Optimized Solutions enable a defense-in-depth approach across the database lifecycle, enabling efficient data protection. Built-in cryptography engines make data encryption fast and efficient throughout the entire database lifecycle—when data is online, at rest, in transit, and during offline stages of backup and archive. (See the article "Increasing Data Security with SPARC M7 'Always On' Cryptography.") Efficient on-chip cryptography supplies superior data protection, with less complexity and integration risk compared to point encryption technologies (such as self-encrypting disk drives, network encryption devices, and encrypting tape drives).

     

    Efficient TDE Encryption on the SPARC M7 Processor

     

    Like the Oracle Database software itself and other database options, TDE is supported on a variety of non-Oracle hardware platforms. On these systems, however, TDE encryption can be costly either in terms of CPU performance impact or the need to add specialized hardware encryption devices, which increases deployment cost and configuration complexity.

     

    On SPARC M7 processor–based systems, however, TDE encryption for Oracle Database is fast and efficient because cryptographic operations are simply offloaded to the on-chip accelerators. The performance difference for turning on TDE encryption (versus no encryption) is generally slight—in practice, it adds a small amount of overhead, usually a percentage in the low single digits (see "Performance Questions About Transparent Data Encryption").

     

    In industry-standard testing of Java 2 Platform, Enterprise Edition (J2EE) applications, Oracle's SPARC T7-1 systems with TDE encryption experienced much faster results in comparison to multiprocessor Intel and IBM Power-8 systems running unencrypted (Figure 3). The SPARC T7-1 systems used TDE encryption at the database tier as well as secure JDBC encryption to protect network traffic between the application server and the database server. (See "SPARC T7-1 Server Delivers World Record Result for SPECjEnterprise2010," October 2015. SPEC and the benchmark name SPECjEnterprise are registered trademarks of the Standard Performance Evaluation Corporation. Results from www.spec.org as of 10/25/2015.)

     

    f3.png

    Figure 3. SPECjEnterprise results showed faster encrypted performance on single-processor SPARC T7-1 systems vs. competitive multiprocessor systems without encryption.

     

    In other testing of database performance with and without TDE encryption, a SPARC T7-1 server with a single SPARC M7 CPU dramatically outperformed a two-processor x86 system. On the SPARC T7-1 server, turning on TDE increased average query execution time only by about 2 percent—in comparison to an increase of about 20 percent on the x86 server—even with both platforms optimized to use native hardware instructions. (See "Oracle Advanced Security – Transparent Data Encryption: Secure Database on SPARC M7 Processor Performance Nearly the Same as Clear.")

     

    Leveraging the Oracle Solaris Cryptographic Framework

     

    To take advantage of the underlying hardware acceleration built into the SPARC M7 processor, TDE makes use of the Oracle Solaris Cryptographic Framework. This framework, which has achieved FIPS 140-2 validation, provides a common store of algorithms and PKCS #11 libraries to handle cryptographic requirements. It allows applications to directly access hardware-accelerated, on-core cryptographic functions in the SPARC M7 processor without requiring the use of special drivers, the kernel environment, or root permissions.

     

    In this way, encryption operations—originating from TDE, the Oracle Solaris networking stack, or even Oracle ZFS Storage Appliance—can automatically leverage cryptographic acceleration in the SPARC M7 processor. The Key Management Framework (KMF) feature of Oracle Solaris also provides tools and programming interfaces for managing public key objects, such as X.509 certificates and public/private key pairs. (TDE key management tools, discussed later, leverage this functionality as well.)

     

    Configuring the TDE Option for Oracle Database

     

    TDE defends against attacks that bypass the database layer and access stored database information directly, preventing a data breach in the event that media devices are stolen or files are accessed in a cyberattack. Even a privileged operating system user can't decipher encrypted Oracle Database tablespaces via a hex dump.

     

    After TDE is configured and Oracle Database elements are identified as items to be encrypted, TDE works transparently (as its name implies)—no application changes are required. Once the Oracle Database option is licensed, there are three high-level configuration decisions to make:

     

    • What database entities to encrypt. There are two types of TDE encryption: column and tablespace. Column encryption encrypts data in selected table columns, which is useful when the tables are large and only a small number of columns must be encrypted. Tablespace encryption is optimal for protecting an entire table rather than individual columns, especially when there is sensitive data in multiple columns or it's difficult to identify which columns must be encrypted. There are some restrictions with column encryption (for example, an index must be a normal B-tree index, and there are certain compatible data types and lengths; see "Encrypting Columns in Tables").  After applying column encryption, best practice is to rebuild column indices for optimal performance.
    • What encryption algorithm to use. TDE supports 3DES168, AES128, AES192, or AES256 (see "Supported Encryption and Integrity Algorithms"). Choosing an algorithm largely depends on security policy requirements. PCI DSS, for example, mandates the use of strong cryptography, which the standard currently defines as at least 112-bits of effective key strength. TDE defaults are AES192 for column and AES128 for tablespace encryption. For highly sensitive data that requires stronger protection, security policy can mandate the use of AES256.
    • How to manage encryption keys. Managing encryption keys and deciding where to place the keystore are also critical implementation decisions. (A keystore, also referred to as a wallet prior to Oracle Database 12c, is a container for TDE master keys and other security objects, such as X.509 certificates.) Oracle Database provides a key management framework to help TDE administrators manage keys and credentials in keystores.

     

    How TDE Uses Encryption Keys

     

    Both column and tablespace encryption use a two-tiered key-based architecture (Figure 4). Each encrypted entity has a key: one for each encrypted column (in the case of column encryption), as well as one for each encrypted tablespace (in the case of tablespace encryption). In each case, TDE uses a master key to encrypt and decrypt the column- and tablespace-specific keys, which in turn encrypt and decrypt the data.

     

    f4.png

    Figure 4.  A two-tiered key management scheme enhances security and simplifies master key rotation.

     

    This two-tiered approach helps to protect data because both the keys and the encrypted data must be separately compromised to decrypt sensitive data. In addition, the two-tiered scheme allows master keys to be periodically changed (called key rotation) without having to re-encrypt the sensitive data. In addition to key rotation, best practices include periodically backing up master encryption keys to comply with security policy requirements.

     

    Many security policies stipulate separation of duty, a common practice that assigns security-relevant tasks to multiple users. Oracle Database 12c introduces a new administrative privilege, SYSKM, for managing TDE master encryption keys and keystores. Other new Oracle Database 12c privileges include a privilege for Oracle RMAN operations (SYSBACKUP) and one for Oracle Active Data Guard tasks (SYSDG). Such privileges grant a user the required authorization to perform a certain function, limiting the need to grant the SYSDBA administrative privilege. (For backward compatibility, the SYSDBA privilege can still be used to perform these tasks.)

     

    A user with the SYSKM administrative privilege can perform all key and keystore management commands using the ADMINISTER KEY MANAGEMENT statement. While keystore management requires privilege, using TDE does not—a user does not need to be privileged to encrypt or decrypt TDE column or tablespace data. The database manages encryption and decryption, and database users and applications do not need to be aware that the accessed data is stored in encrypted form.

     

    Keystore Configuration Choices

     

    When deploying TDE, it's necessary to configure the location of the keystore and the type of keystore to implement. As depicted in Figure 4, the TDE master encryption keys are stored externally to the database. By default, they are located in a file system–based software keystore (a PKCS #12 compliant keystore file encrypted by a PKCS #5 password-derived key). The same software keystore can be used to store other application-level keys along with the TDE master keys. In some cases, security policy might require locating the TDE master keys in an external hardware-based keystore, a device known as a hardware security module (HSM).

     

    Oracle Key Vault can simplify the complexity of managing file-based software keystores across multiple systems and applications across an enterprise. Oracle Key Vault is a software appliance (delivered as an ISO package) configured on a dedicated server. It can centrally manage TDE master keys, Oracle wallets/keystores, Java keystores, credential files, and certificate files (such as X.509 certificates for network encryption) across the entire enterprise. Oracle Key Vault streamlines common management tasks (key creation, rotation, deactivation, and removal), and can help to prevent key loss due to forgotten passwords or accidental deletion. (For more information, see "Oracle Key Vault Use Cases" in the Oracle Key Vault Administrator's Guide.)

     

    TDE defines three types of software keystores:

     

    • Password-based. These keystores must be opened interactively with a password before master keys can be retrieved and used.
    • Auto-login. Auto-login keystores are protected by a system-generated password and do not need to be explicitly opened by a TDE administrator, making them well-suited for automatic database startup. Non-local auto-login keystores can be used across multiple different systems.
    • Local auto-login. These keystores can be used only on the system on which they were created, limiting noninteractive use to that specific system.

     

    When choosing the software keystore type, consider the security implications (entering a password versus a system-generated password that's shared or local) and convenience (attended versus unattended operation). Keystore passwords should follow best practices and security policy for strong password creation (using a combination of numbers, capitalized letters, punctuation, and a total of more than 12 characters in length).

     

    Other Encryption Considerations

     

    To develop an effective plan for protecting sensitive data in Oracle Database applications, it's necessary to consider various security implications within the data processing flow and implement relevant safeguards. Oracle documentation provides specific guidance with respect to securing database installations and data dictionaries (see the Oracle Database 2 Day + Security Guide and the Oracle Database Security Guide).

     

    Sensitive data must be protected across the full lifecycle of a production database including operational activities such as data movement (import and export), replication, maintenance, backup/restore, and recovery. TDE integrates directly with many Oracle Database technologies, including Oracle Data Pump, Oracle Active Data Guard, and Oracle Recovery Manager (RMAN), among others. On Oracle servers with SPARC M7 processors, these operations gain a performance benefit from hardware-accelerated cryptography. (See "Using Transparent Data Encryption with Other Oracle Features.")

     

    Here are some examples of TDE integration points in which data is protected during common lifecycle operations:

     

    • Data movement with Oracle Data Pump export/import. Oracle Data Pump can export and import tables that contain encrypted columns, as well as encrypting entire dump sets (see "How Transparent Data Encryption Works with Export and Import Operations"). The ENCRYPTION=ENCRYPTED_COLUMNS_ONLY setting specifies that only the TDE-encrypted columns are written to the dump file set in encrypted format.
    • Replication using Oracle Active Data Guard. Oracle Active Data Guard provides tools to replicate production databases and create physical standbys that mitigate possible failures and disasters. If a database uses TDE, each Oracle Active Data Guard standby must have a copy of the encryption keystore. Active Data Guard Rolling Upgrade can also be used to minimize downtime when converting a database to use TDE encryption; see the paper "Converting to Transparent Data Encryption Using Active Data Guard (DBMS_ROLLING)".
    • Backups using Oracle RMAN. Oracle RMAN can compress and encrypt entire database backups to disk. This encryption safeguards data transported to tape or offsite storage disks for safekeeping (see "Encrypt Database Backups" for more details).

     

    In addition to operational activities, it's necessary to consider data handling during SQL processing. Because the focus of TDE is protecting data at rest, security policy often requires defensive mechanisms at other points in the application stack. Protections might be required for server compute, storage, network, and memory resources—including data files, logs, and the system global area (SGA). There are several nuances to consider in conjunction with using TDE encryption.

     

    Protecting Data in Transit

     

    As shown in Figure 2, query results are returned unencrypted even when TDE is implemented to protect stored data. Oracle Database 12c provides a means of protecting database connections, encrypting data that travels on the network between database clients and servers. Administrators can use the Oracle Net Manager GUI or a sqlnet.ora configuration file to configure this network encryption. As a result, the database takes advantage of TLS and IPsec encryption and integrity checking for IP packets at the operating system level. The Oracle Solaris Cryptographic Framework automatically offloads these encryption and decryption operations to on-chip accelerators in the SPARC M7 processor (see "Securing the Network in Oracle Solaris 11.3" and "Transparent Data Encryption (TDE) Frequently Asked Questions").

     

    In addition to TDE, the Oracle Advanced Security option includes data redaction capabilities. Data redaction also helps to safeguard data in transit because it returns only redacted results of an SQL query to an application, reducing the risk of data exposure for network traffic.

     

    Data in the SGA

     

    With TDE column encryption, column data is encrypted in data files (as well as undo logs, redo logs, and the SGA buffer cache). However, when tablespace encryption is selected, data is not encrypted in the SGA buffer cache. Thus, column encryption provides an added benefit over tablespace encryption by safeguarding data in the SGA buffer cache.

     

    Oracle Database In-Memory configures an additional area in the SGA called the In-Memory Area that dramatically speeds up analytical queries using eight on-chip Data Analytics Accelerators (DAX) on the SPARC M7 processor. The Oracle Database In-Memory option uses a dual-format architecture, maintaining data in row format for OLTP but also configuring a new in-memory (IM) column store optimized for analytics (see "Architecture Matters, Part 3: Next Steps—Optimizing for Database Performance, Security, and Availability"). When TDE encryption is used in conjunction with Oracle Database In-Memory, SGA data protection is largely the same—with TDE column encryption, data in the SGA buffer cache is encrypted, but with tablespace encryption, the data in the SGA buffer cache is not encrypted. For both column and tablespace encryption, data in the IM column store is not encrypted, but its data is difficult to decipher because it is typically compressed. In all cases, applications are still protected by Silicon Secured Memory (SSM), which prevents memory reference errors and silent data corruption.

     

    For mixed analytics and OLTP workloads, Oracle Database In-Memory can supply a performance benefit on SPARC M7 processor–based systems, offloading queries to DAX coprocessors and freeing CPU cores for other processing. Built-in functionality in the SPARC M7 processor helps to keep data safe and deliver superior mixed workload performance, dispelling conventional wisdom that it's not possible to do data analytics, OLTP, and encryption all at the same time. With an Oracle-on-Oracle solution, it can be done!

     

    Special Storage Considerations for Encrypting Legacy Databases

     

    For legacy databases that were not encrypted when the databases were first created, there is an additional security consideration. During a table's lifetime, operations (such as table sorts, moves, or copies) can leave original data on storage blocks within the database file. The data remains until these blocks are reused and overwritten. (This is similar to data being present on a disk device after the operating system deletes a file.)

     

    When TDE is first enabled, only the current version of the tablespace or columns is encrypted, which can possibly leave behind blocks containing the data in plain text, known as ghost copies, from previous operations. Until the database overwrites these blocks, a privileged operating system user could potentially access the plain-text data via a hex dump.

     

    Depending on security policy and requirements, it is often necessary to take steps to minimize this risk. A procedure to remedy the problem, described in "Managing Security for Plaintext Fragments," gives steps for different operating systems to re-create the tablespace and securely delete the old one. On Oracle Solaris, the shred utility can be used to securely delete the old data file. For Oracle Database instances that use Oracle Automatic Storage Management (Oracle ASM), My Oracle Support Note 1995248.1 documents the recommended approach.

     

    Note that these methods might not meet stringent security policy requirements such as those listed in NIST Guidelines for Media Sanitization Publication 800-88 (see "Summary of Sanitization Methods"). Procedures that overwrite previously written blocks, for example, will not comply with a security policy that requires media destruction.

     

    How to Configure TDE and Manage Keys

     

    For either a software- or hardware-based keystore, the five-step process of setting up TDE encryption is largely the same (see the Oracle Database Advanced Security Guide):

     

    1. Set the keystore location with the ENCRYPTION_WALLET_LOCATION parameter in the sqlnet.ora file.
    2. Create the software keystore (using the SQL statement ADMINISTER KEY MANAGEMENT CREATE KEYSTORE) or configure the hardware security module.
    3. Open the keystore (using ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN).
    4. Set the TDE master encryption key (using ADMINISTER KEY MANAGEMENT SET KEY).
    5. Encrypt the data.

    There are three different interfaces that a privileged user can use to configure master keys and manage a TDE keystore:

     

    • The command line
    • Oracle Wallet Manager
    • Oracle Enterprise Manager Cloud Control 12c

     

    Option 1: Using the Command Line

     

    As an example, the following SQL statements set up a software keystore (a wallet) for encrypting data in Oracle Database 12c:

     

    1. Identify the database via the ORACLE_SID, log in as a user with key management privilege, and check the keystore location as configured in the database:

     

    # echo $ORACLE_SID

    dbdss

    # sqlplus c##sec_admin as syskm

    SQL> select WRL_PARAMETER from V$ENCRYPTION_WALLET;

    WRL_PARAMETER------------------------------------------------------------------------/u01/app/oracle/admin/dbdss/wallet

     

    2. Create a directory for the keystore in the expected operating system location:

     

    # mkdir /u01/app/oracle/admin/dbdss/wallet

     

    3. Create the keystore for the database and configure auto-login for the keystore:

     

    SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/oracle/admin/dbdss/wallet' IDENTIFIED BY Dutche8s;
    SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE '/u01/app/oracle/admin/dbdss/wallet' IDENTIFIED BY Dutche8s;

     

    4. Check the keystore status and then close the keystore:

     

    SQL> select STATUS from V$ENCRYPTION_WALLET;

    STATUS------------------------------OPEN_NO_MASTER_KEY

    SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE;

    keystore altered

     

    5. Reopen the keystore, set the TDE master encryption key, and back it up:

     

    SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY Dutche8s;

    keystore altered.

    SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY Dutche8s WITH BACKUP USING 'mang_backup_key';

    keystore altered.

     

    6. List the files created in the keystore directory:

     

    # ls -al /u01/app/oracle/admin/dbdss/wallet

    -rw-r--r--  1 oracle  dba  3893 Sep 25 14:08 cwallet.sso

    -rw-r--r--  1 oracle  dba  2408 Sep 25 14:08 ewallet_2015092522080150_mang_backup_key.p12

    -rw-r--r--  1 oracle  dba  3848 Sep 25 14:08 ewallet.p12

     

    Option 2: Using Oracle Wallet Manager

     

    As an alternative to the command line, Oracle Wallet Manager (Figure 5) provides a graphical interface for managing keys and keystores. It can be used to manage public key security credentials on application clients and servers, including keys for Oracle Database and Java applications, as well as X.509 certificates and PKCS #12 private keys for secure networking and credentials for hardware security modules. (Note that the ADMINISTER KEY MANAGEMENT statement can perform all of the key and keystore management functions instead of the Oracle Wallet Manager utility, superseding it as well as the orapki command-line utility and the ALTER SYSTEM statement.)

     

    f5.png

    Figure 5.  The Oracle Wallet Manager GUI can also be used to manage master encryption keys and keystores.

     

    Option 3: Using Oracle Enterprise Manager Cloud Control

     

    Oracle Enterprise Manager Cloud Control 12c (and later releases) provides another interface option for keystore management. This option is well-suited for large enterprises that might already be deploying this comprehensive management tool to perform other enterprise and database management tasks. Oracle Enterprise Manager Cloud Control provides a single pane-of-glass interface to monitor and manage all types of services and components, including database, middleware, and platform infrastructure. It complements Oracle Enterprise Manager Ops Center software (supplied at no charge with Oracle server platforms).

     

    An administrator can use Oracle Enterprise Manager Cloud Control to configure and manage master keys and keystores across the enterprise, including TDE keystores for Oracle Database, Java applications, network certificates, and security credentials (Figure 6).

     

    f6.png

    Figure 6.  Administrators can also use Oracle Enterprise Manager Cloud Control 12c to manage TDE master keys and keystores.

     

    Example: Encrypting a Database Table

     

    Once a master encryption key and keystore have been created for an Oracle Database instance, a DBA can use an SQL statement such as the following to create a simple table with an encrypted column:

     

    SQL> CREATE TABLE employee (
           first_name VARCHAR2(128),
           last_name VARCHAR2(128),
           empID NUMBER(4) ENCRYPT );

     

    In this table, data in the column empID is encrypted on storage and in the SGA buffer cache using AES192, the default for column encryption:

     

    SQL> select table_name, column_name, ENCRYPTION_ALG from ALL_ENCRYPTED_COLUMNS;

    TABLE_NAME---------------------------------EMPLOYEE

    COLUMN_NAME--------------------------------EMPID

    ENCRYPTION_ALG-----------------------------AES 192 bits key

     

    TDE protects the data on disk. Only those authorized for access can retrieve the data, which is returned in the clear:

     

    SQL> SELECT empID FROM employee;

    empID   

    ----------      

    1234      

    5678

    .

    .

    .

     

    Final Thoughts: Built-in Security in the Oracle Stack

     

    Encrypting Oracle Database data using TDE is easy to set up and—perhaps most importantly—extremely efficient on systems with the SPARC M7 processor, making it easy to safeguard sensitive information without impacting service-level objectives (SLOs). Because TDE operations are offloaded to separate cryptographic engines on these systems, virtually all of the cores' processing power remains available for database applications. There's no need to oversize systems because of encryption's impact on CPU performance or to add specialized encryption hardware. In addition, an Oracle-on-Oracle solution makes it possible to take advantage of effective security and cryptography throughout the Oracle Database lifecycle, helping to protect data in process, on storage, and during backup, archival, and recovery.

     

    Oracle continues to invest in innovations across the Oracle stack that help to improve service levels and security for Oracle Database. Other features in the SPARC M7 processor—such as Silicon Secured Memory (SSM) that detects common memory access violations and Data Analytics Accelerators (DAX) that speed analytical queries in conjunction with Oracle Database In-Memory—help to make transaction and analytical processing both secure and efficient, providing data protection without the need to deploy more systems. Other integration elements—such as OpenSCAP compliance auditing and the Oracle Solaris Cryptographic Framework at the operating system layer—provide additional system and networking safeguards, creating a defense-in-depth solution.

     

    Oracle Optimized Solutions incorporate best-of-breed Oracle server platforms based on the SPARC M7 processor, so they automatically take advantage of these recent SPARC M7 processor innovations and comprehensive Oracle coengineering efforts across the stack, along with end-to-end testing and extensive best practice documentation. To learn more about the Oracle Optimized Solution for Secure Oracle Database, visit the solution website or contact your Oracle account team.

     

    See Also

     

    Documentation

     

     

    Papers

     

     

    Online Resources

     

     

    About the Authors

     

    Larry McIntosh is the chief architect within the Oracle Optimized Solutions team. He has designed and implemented highly optimized computing, networking, and storage technologies for both Sun Microsystems and Oracle. McIntosh has over 40 years of experience in the computer, network, and storage industries and has been a software developer and consultant in the commercial, government, education, and research sectors and an information systems professor. He has directly contributed to the product development phases of Oracle Exadata Database Machine and various Oracle Optimized Solution architectures. His most recent contribution has been in the design, development, testing, and deployment of Oracle Optimized Solution for Secure Oracle Database.

     

    Ken Kutzer is a team lead for Oracle Optimized Solution for Secure Oracle Database and Oracle Optimized Solution for Oracle Database as a Service. He is responsible for driving the strategy and efforts to help raise customer and market awareness for Oracle Optimized Solutions in these areas. Kutzer holds a Bachelor of Science degree in electrical engineering and has over 20 years in the computer and storage industries.

     

    Randal Sagrillo is a solutions architect for Oracle. He has over 35 years of IT experience and is an expert in storage and systems performance, most recently applying this expertise to next-generation data center architectures, integrated systems, and Oracle engineered systems. Sagrillo is also a frequent and well-attended speaker on database platform performance analysis and tuning and has spoken at several industry conferences including Oracle OpenWorld, Collaborate, Computer Measurements Group, and Storage Networking World. In his current role, he is responsible for solution architecture and development around Oracle Optimized Solutions. Before joining Oracle, he held a variety of leadership roles in product management, program management, and hardware/software product development engineering.