Oracle® Fusion
Applications Security Hardening Guide 11g Release 1 (11.1.2) Part Number E16690-02 |
![]() Contents |
![]() Previous |
![]() Next |
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
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.
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) |
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.
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.
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.
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.
A vault hardens access controls such as privacy boundaries set by Oracle Virtual Private Database (VPD) from being overridden.
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.
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 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 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.
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.