Skip Headers

Contact
Us

3 Locking Down the Transactional Database with Advanced Security Features

This chapter contains the following:

Hardening the Transactional Database: Explained

Data Encryption: Points to Consider

Data Management Hardening: Points to Consider

Data Masking: Points to Consider

Hardening the Transactional Database: Explained

Oracle Database offers the following advanced security features and guidelines to match higher levels of security requirements for a range of reasons.

Industry segment or organization type of the enterprise may impose regulatory requirements that determine how much risk is tolerable or how much to harden the deployment.

Protecting Sensitive Data

Transparent Data Encryption (TDE) prevents access to sensitive data in the file system or on backups or disk. Oracle Virtual Private Database (VPD) protects sensitive data from users with database administrator (DBA) access and Oracle Database Vault (ODV), if installed, prevents this protection from being overridden. Oracle Data Masking protects personally identifiable information (PII) and sensitive data in cloned databases.

The table shows security features used for various requirements and hardening goals.

Security Requirement	Hardening target	Hardening Reason	Security Feature
Protecting sensitive data at rest	Data beyond the PII defined by Oracle Fusion Applications	If access is gained to the file system or backups the data cannot be read.	Transparent Data Encryption Protecting sensitive data from DBAs
Protecting sensitive data from DBAs	Data beyond the PII defined by Oracle Fusion Applications	DBA access is not be subject to security policies in Oracle Platform Security Services (OPSS) and should therefore be limited or blocked through other means.	Oracle Data Vault and Oracle Audit Vault
Protecting sensitive data in clones	Data beyond the PII specified by the data masking templates defined in Oracle Enterprise Manager, integrated with Oracle Fusion Applications	Developers need realistic test data to test modifications and configurations. Such test data should be easy to construct, should test the real boundaries of the data, and should not allow developers to access information in the test environment that they would not be authorized to access in a live environment, except where there is a specific business reason for them to do so. Even when the data has been masked, access to it should be rigorously controlled, and all users made aware of their obligations and responsibilities with regard to it.	Oracle Data Masking
Protecting sensitive data in transit	Data beyond the PII protected by the enterprise deployment guidelines of Oracle Fusion Applications		Network security (instead or in addition to SSL)

Additional Data Protections

You can further secure the transmission of the data through mechanisms such as SSL or other network protections. You can use digital certificates to either encrypt or provide hash digests of the data prior to transmission to extend you defense-in-depth protections of private and sensitive data.

For partners who need a subset of production data, consider a dedicated data extract of only the data they need.

For more information about the advanced database security features, see the Oracle Database Advanced Security Administrator's Guide.

Data Encryption: Points to Consider

Encryption protects data as it is written to the file system against unauthorized access via that file system or on backups and archives. The data can be decrypted by applications when it is retrieved.

For information on the secure information life cycle in Oracle Fusion Applications, see the Oracle Fusion Applications Security Guide.

Transparent Data Encryption

For encryption beyond the Oracle Fusion Applications encryption application programming interfaces (APIs) protections on data such as credit card numbers in application user interface fields, Transparent Data Encryption (TDE) is certified but optional with Oracle Fusion Applications.

TDE enables encrypting data independent of managing encryption keys. TDE supports encryption at at the level of tablespaces. Encrypting an entire tablespace automatically encrypts all objects created in that tablespace, including sensitive data. You do not have to analyze and determine the need for encryption on individual table columns.

Security Hardening Guidelines

As a security hardening guideline, use TDE at the level of tablespaces, which represents an optimal balance between performance and security.

TDE encrypts sensitive table data stored in data files at the tablespace level. The following table lists the tablespaces and the types of objects in Oracle Fusion Applications.

Logical Tablespace Type	Physical Tablespace	Object Type
SUMMARY	FUSION_TS_SUMMARY	Materialized Views (MV), MV logs
TRANSACTION_TABLES	FUSION_TS_TX_DATA	Transactional tables
TRANSACTION_INDEXES	FUSION_TS_TX_IDX	Indexes on transactional tables
REFERENCE	FUSION_TS_SEED	Setup and seed tables
INTERFACE	FUSION_TS_ARCHIVE	Interface tables
MEDIA	FUSION_TS_MEDIA	Tables with multimedia objects, such as text, video, sound, graphics, and spatial data
TOOLS	FUSION_TS_TOOLS	Tables that are part of other 3rd party products and tools
ARCHIVE	FUSION_TS_ARCHIVE	Obsolete tables and objects
TEMPORARY	TEMP	Global temporary tables
AQ	FUSION_TS_QUEUES	AQ$ and its related tables (_H, _I, _T, _S, _R)

You can view the list of encrypted tablespaces in Oracle Enterprise Manager. Enable tablespace level transparent data encryption on all Oracle Fusion Applications tablespaces

For information on enabling TDE on tablespaces, see the Oracle Database Advanced Security Administrator's Guide.

Data Management Hardening: Points to Consider

A vault hardens access controls such as privacy boundaries set by Oracle Virtual Private Database (VPD) from being overridden.

Oracle Database Vault

Oracle Database Vault (ODV) establishes limitations on the power of privileged users to access sensitive data through segregation of duties policies on database administrator (DBA) roles and by securely consolidating application data in the database. ODV lets you manage security for your database instance as a realm composed of the database or database objects that you want to secure. You can further secure the realm by creating rules, command rules, factors, identities, rule sets, and secure application roles.

Establishing the vault protects against insider threats, enforces separation of duties, and helps meets regulatory compliance requirements.

Security Hardening Guidelines

Using Oracle Database Vault Realms, you can enforce access to applications through a trusted path, preventing database users who have not been specifically authorized access from using powerful privileges to look at application data. For example, a database administrator (DBA)who has the SELECT ANY TABLE privilege can be prevented from using that privilege to view application data.

Define a single Oracle Fusion Applications Realm in Oracle Database Vault to protect all Fusion Applications schemas and objects.

Oracle Database Vault revokes the CREATE USER and other user management privileges from anyone who does not have the DV_ACCTMGR role.

For information about protecting application data from DBAs and other privileged users using Oracle Database Vault Realms, see the Oracle Database Vault Administrator's Guide.

For information about installing Oracle Database Vault on the existing ORACLE_HOME using Oracle Universal Installer and integrating it with such features as Transparent Data Encryption, see the Oracle Database Vault Administrator's Guide..

Data Masking: Points to Consider

Data masking prevents views of sensitive data. Data masking in Enterprise Manager overwrites sensitive data with randomly generated data in non-production instances such as for development, testing, or diagnostics. This type of masking is irreversible and the sensitive data cannot be reconstituted.

Oracle Data Masking

Oracle Data Masking is available for masking data in non-production instances or clones.

Oracle Fusion Applications Data Masking templates apply masking formats on sensitive data in clones. Change the list of sensitive attributes to be masked by Oracle Data Masking using Oracle Enterprise Manager.

For information about masking sensitive attributes in cloned databases, see the Oracle Enterprise Manager Concepts Guide.

Security Hardening Guidelines

For masking beyond the encryption application programming interfaces (APIs) protections on data such as credit card numbers in application user interface fields, Oracle Data Masking is certified with Oracle Fusion Applications.

The following entities are masked by Oracle Data Masking.

Relational, transactional data across product families
Dependent objects such as Intermedia Index or materialized views (MV)
Empty tables such as those in schemas that are installed but not configured for use, are masked.

Oracle Fusion Applications provides masking definitions that specify only tables and columns that are possible candidates for masking.

The following table lists the masking template containing the masking definitions for each Oracle Fusion Applications offering.

Offering	Masking Template
Customer Data Management	FUSION_CDM_VR1_Mask_Template.xml
Customer Relationship Management	FUSION_CRM_EXCEPT_CDM_TCA_VR1_Mask_Template.xml
Financials	FUSION_FIN_V1.0_Mask_Template.xml
Government Risk and Compliance	FUSION_GRC_VR1_Mask_Template.xml
Human Capital Management	FUSION_HCM_VR1_Mask_Template.xml
Procurement	FUSION_PRC_V1.0_Mask_Template.xml
Supply Chain Management	FUSION_SCM_VR1_Mask_Template.xml
Combined masking template for all product families	Combination_v1_ALL_Families.xml

The masking templates specify sensitive database tables and columns in Oracle Fusion Applications, and the data formats to be used to mask the columns. The masking templates provide examples as a starting point. They are not complete for all cases and can cause issues in how certain parts of the applications function.

Determine what data should be masked based on the needs of your enterprise. The purpose of the cloned data, what data you are storing, and so on, affects what masking to enable. You must balance the security of the masked test system against the usefulness of the masked test system to testers. You may need to accommodate specifics in your deployment such as customizations and the data semantics of flexfields to adequately mask all sensitive information.

Caution

As a security hardening guideline, clone the data needed for the set of tests in question, or at least truncate any tables containing sensitive data that are not needed for the tests. Every piece of sensitive information that is cloned and not used represents an unnecessary risk.