Enterprise Service Cloud - Docs

Security Architecture

The PDB isolation implementation is based on the architecture as documented in the Oracle White Paper Isolation in Oracle Multitenant Database 12c Release 2open in new window.

The strict separation of customer workloads is based on the MODS security architecture:

  • Separation of the customer VMs (and therefore CDBs) is implemented by OVM hardening measures
  • Isolation of PDB from CDB (and between multiple PDBs) in order to separation customer workloads

The following figure shows the various measures to ensure separation of a PDB from the operating system, the CDB and from other PDBs:

PDB isolation and security measures

  • Adapted DBA role for user PDBADMIN
  • Restricted OS access using PDB_OS_CREDENTIAL
  • Restricted file access using PDB PATH_PREFIX and CREATE_FILE_DEST
  • Restricted user operation in PDBs in a multitenant CDB using lockdown profiles

PDB isolation and security is implemented on three levels:

PDB Protection

  • Restrict user operation in PDBs in a multitenant container database using Lockdown Profiles
  • Security Shapes revoke default public execute privileges from powerful packages and object types
  • Managing OS Access using PDB_OS_CREDENTIAL

CDB Protection

  • Managing OS Access using PDB_OS_CREDENTIAL

OS Protection

  • Manage File Access using PDB PATH_PREFIX and PDB CREATE_FILE_DEST

The Swiss Cheese Model visualizes the different layers of the PDB isolation architecture :

MODS Swiss Cheese Model

Security Shapes

The following Database Security Shapes are available for MODS Regular:

  • SC_CIS_RECOMMENDATION includes security measures based on CIS Oracle Database 19c benchmark. This is the most restrictive security configuration
  • SC_SEC_BEST_PRACTISES is the default MODS configuration. It Includes security measures based on Swisscom and Trivadis Database security best practice. Over all it is slightly less strict than SC_CIS_RECOMMENDATION
  • SC_ORA_DEFAULT covers the default database configuration after installation. This security configuration includes only a minimal set of security measures by Oracle. It is primarily for reference purposes and is not recommended as a database configuration.

The security shapes can be adapted in the PDB edit workflow via vRA.

Database User Management

The user management on PDB level is in the responsibility of the customer. PDBADMIN is the MODS standard local user for administative task on PDB level. The initial password of PDBADMIN will be provided just after a PDB has been created. It must be changed immediately.

We recommend to use the PDBADMIN account for administrative tasks only, and to create additional, less privileged users for application usage and for end users.

Additional local users can be created as PDBADMIN user, or as any user with CREATE USER privilege via SQL command.

Password Verification Functions

MODS provides several password verification functions that customers can use in their own database user profiles. The creation of database user profiles is made possible within the framework of PDB isolation.

Basically, it is the customer's responsibility to implement database security measures that go beyond the basic configuration of MODS.

The security architecture of the Oracle Database requires that a password verification function always belongs to the SYS user.

In principle, the owner of each PDB has DBA or equivalent privileges on his PDB but, this does not include SYS, SYSDBA or similar rights.

As a consequence, the customer cannot create their own password verification functions but they can use in their user profiles the password verification functions deployed by MODS in all PDBs.

The following MODS specific password verification functions are currently available in the customers' PDBs:

  • "Default Strong" : the default verification function (min. length of 12 characters) and additional verifications.
  • "Verify Function" : a less strict verification function (min. length of 8 characters) and additional verifications.
  • "Strong Verify Function" : a verification function with min. length of 9 characters and additional verifications.

Lockdown Profiles

Lockdown profiles are an Oracle feature that controls the activation/deactivation of certain options, features and statements in a PDB, via a set of rules.

The rules are defined in CDB and managed by Swisscom.

It is compulsory that a lockdown profile is enabled in each PDB as it is an essential part of the PDB isolation strategy.

  • At the PDB creation, via vRA, the customer chooses a lockdown profile from the list of available profiles, depending on their requirements.
  • It is however possible to select another lockdown profile later on, as a Day-2 action on the PDB via vRA

List of available Lockdown Profiles

MODS Regular includes the following lockdown profiles:

  • Default Lockdown Profile

    This is the default profile. It follows the CIS and Oracle best practices. It covers the common use cases for functional, and performance specific customisation. This profile explicitly restricts critical functionalities.

  • Java Lockdown Profile

    It is identical to the Default Lockdown profile except that it additionally allows to run Oracle JVM.

  • Restricted Lockdown Profile

    Lockdown profile which is much more restricted than the Default (most of the options and features are disabled).

  • Default MODS HE Lockdown Profile

    It is the Default Lockdown Profile currently in use in MODS Highend platform. It enables the customer to perform some tests if needed.

In normal operation all databases should use the Default lockdown profile.

For databases where Java is in use, the dedicated Java lockdown profile has to be used. We consider this as exception which should only be valid for a limited number of PDBs.

Critical DBs may use the Restricted lockdown profile. This is also a possibility for the customer to implement stronger limitation for their customers / users.

Lockdown Profiles Update Process

The configuration of the Lockdown Profiles has to be reviewed on a regular basis. The review includes a verification of whether there are potential enhancements/changes to the Lockdown Profiles.

As of now the following trigger events are used to review the current Lockdown Profiles:

  • Quarterly Oracle Critical Patch Advisories in particular with a high CVSS rating above 9.0.
  • Needs based on penetration test results or findings from the Threat Model
  • Major database releases e.g. 19c to 23c

The outcome of a review is that all changes to Lockdown Profiles will be implemented onto the Next Generation Lockdown Profile. The update and roll over of the changes to the new Default Lockdown Profile will be performed in a dedicated process at least once a year, preferably as part of a patching cycle.

The customer is informed about the update (time and content of changes). It is optional if the customer would like to test the updated Next Generation Lockdown Profile.

As part of this update process, the Default profile will be saved as the Legacy Lockdown Profile.

As a result, it is possible to select the following lockdown profiles:

  • Next Generation Lockdown Profile

    Lockdown profile based on Default. New enhancements are implemented in Next Generation lockdown profile. Customer does have the possibility to verify the changes for a defined time before they are officially implemented in Default.

  • Legacy Lockdown Profile

    It is the former Default Lockdown Profile. For legacy purpose there is always the Legacy lockdown profile where the customer has the possibility to still use the "old" configuration until the next lockdown release change.

Encryption

Data Encryption at Rest (TDE)

Tablespaces can be encrypted by using Oracle Transparent Data Encryption (TDE). See how to enable TDE in the how-to section

Note: Oracle TDE is part of the Oracle ADVANCED Security Option (ASO).

Network Encryption (SQLNet)

SQLNet encryption is enforced by the following server side configuration, and therefore require encryption:

##############################################################################
# Security - Server Side
##############################################################################
SQLNET.ENCRYPTION_SERVER=REQUIRED
SQLNET.ENCRYPTION_TYPES_SERVER=(AES256)
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA512, SHA384, SHA256, SHA1)

Database Auditing

Documentation in progress.

Common User Access

For specific purposes the customer can get limited access to the CDB by common users. Use cases are:

  • Monitoring and Settings for Unified Audit - C##SC_CDBA_AUD_MGMT
  • AWR Report - C##SC_CDBA_AWR_MGMT
  • Resource Management and Session Monitoring - C##SC_CDBA_RES_MGMT
  • CIS Security Scans - C##CISSCAN

Access to common users is not enabled by default and can be requested by a service request.

Security Framework

In order to maintain the highest level of security for the platform and for the customers' environments, the following measurements and activities are being performed on a regular base:

  • Threat Modeling
  • Penetration Testing
  • CIS Scans
  • Vulnerability Management
  • Patching

CIS Scans

On MODS Regular we use the common user C##CISSCAN in order to execute CIS scans on a regular base. We use CIS-CAT Pro Assessoropen in new window for that.

The required privileges for user C##CISSCAN are specified by the CIS-CAT Pro tool: read-only access to the data dictionary, no data modifications, no read access to customer data.

User C##CISSCAN is created as “schema only account” with the NO AUTHENTICATION clause:

CREATE USER C##CISSCAN NO AUTHENTICATION;

Before the actual scan, user C##CISSCAN gets a internally generated password, and will be converted back to a schema-only user after the scan. This process is fully automated.

User C#CISSCAN is created as follows:

-- Create the role
CREATE ROLE C##CISSCANROLE CONTAINER=ALL;
-- Grant necessary privileges to the role
GRANT CREATE SESSION TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON V_$PARAMETER TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON CDB_TAB_PRIVS TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON CDB_TABLES TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON CDB_PROFILES TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON CDB_SYS_PRIVS TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON CDB_STMT_AUDIT_OPTS TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON CDB_ROLE_PRIVS TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON CDB_OBJ_AUDIT_OPTS TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON CDB_PRIV_AUDIT_OPTS TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON CDB_PROXIES TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON CDB_USERS TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON CDB_ROLES TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON CDB_USERS_WITH_DEFPWD TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON CDB_DB_LINKS TO C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON V_$INSTANCE to C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON V_$DATABASE to C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON V_$PDBS to C##CISSCANROLE CONTAINER=ALL;
GRANT SELECT ON V_$SYSTEM_PARAMETER TO C##CISSCANROLE CONTAINER=ALL;
GRANT AUDIT_VIEWER TO C##CISSCANROLE CONTAINER=ALL;
-- Create the user and assign the user to the role
CREATE USER C##CISSCAN IDENTIFIED BY <password> CONTAINER=ALL;
GRANT C##CISSCANROLE TO C##CISSCAN CONTAINER=ALL;
ALTER USER C##CISSCAN SET CONTAINER_DATA=ALL CONTAINER=CURRENT;
-- THE NEXT FOUR GRANTS MUST BE PERFORMED BY SYS:
CREATE VIEW SYS.X_$KSPPI AS SELECT * FROM SYS.X$KSPPI;
CREATE VIEW SYS.X_$KSPPCV AS SELECT * FROM SYS.X$KSPPCV;
GRANT SELECT ON SYS.X_$KSPPI to C##CISSCANROLE;
GRANT SELECT ON SYS.X_$KSPPCV to C##CISSCANROLE;

Credential Handling

After executing the PDB action Get Credentials the initial login details are displayed in the cloud portal's detail panel. The initial user is always called PDBADMIN and it has quite high privileges. With PDBADMIN the customer can create additional database users in the database itself (e.g. via SQLPlus) as well as other things. The initially created password of PDBADMIN will expire automatically after 24 hours if the customer does not change it before. It can be changed as follows:

sqlplus pdbadmin/<initial-pw>@<connection-string>

ALTER USER pdbadmin IDENTIFIED BY "<new-password>";

In case an initial password was not changed within 24 hours since the credential was created the PDBADMIN account gets locked. Then the customer should re-create the credential in the cloud portal by executing first Delete Credentials and subsequently Get Credentials again.

Last Updated: