Security Architecture

Concepts and General Architecture

The security architecture is intimately linked with the Multitenant Architecture implemented at MODS.

Based on that, the security concept comprises the following principles:

• The customer owns their PDB (pluggable database). As such, the customer has all the administrative privileges required to manage their PDB.
• However, the scope of action of the customer is limited to the realm of their PDB.
• There is a strict separation of customer workloads:
  1. At VM level, the separation of the customer VMs (and therefore CDBs) is implemented by OVM hardening measures.
  2. At database level, the strict isolation of a PDB from the CDB (and between multiple PDBs) is the foundation of the security architecture.

The figure above shows the various measures taken to ensure:

• Separation of the PDB from the operating system
• Isolation of the PDB from the CDB
• Isolation between the PDBs

PDB Isolation

Technically, isolation and security are ensured through:

• Restricting user operation in PDBs in a multitenant container database using lockdown profiles
• Managing OS Access using PDB OS credential feature (under implementation)

The concept of the PDB isolation and security architecture is described in the MODS White Paper Ora Default001 PDB Isolation and Security and in the Oracle White Paper Isolation in Oracle Multitenant Database 12c Release 2.

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

Security and Hardening features

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

MODS offers further features to enable the customer to further secure and harden their PDBs:

• Password Verification Functions to ensure user passwords comply with the relevant password policies
• Security Shapes revoke default public execute privileges from powerful packages and object types, as per CIS benchmark recommendations
• Encryption of data at rest and in transit
• Database Auditing
• Security Assessment

Database User Management

PDBADMIN User

The customer has the administrative (DBA) privileges within their PDB via the PDBADMIN user, the owner of each PDB. A customized enhanced DBA role is granted to the PDBADMIN user in the customer's PDB. As such, the customer is empowered to execute all DBA duties within their PDB, as for example, users and roles management, privilege management, tablespaces and datafiles, etc...

The PDBADMIN user is granted these administrative privileges with the grant option (for object privileges) or the admin option (roles and system privileges). This user is then able to further grant their privileges to other local PDB users.

Besides the standard DBA privileges, specific additional privileges are also granted to the PDBADMIN user, such as the roles for Auditing Management.

The initial password of PDBADMIN will be provided after a PDB has been created. It must be changed immediately.

MODS Security however ensures that the customer is only granted privileges locally at the PDB level, and not privileges at the CDB and instance levels.

PDB User Management

The user management on PDB level is in the responsibility of the customer. PDBADMIN is the MODS standard local user for administrative task on PDB level. However, it is recommended 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.

Common User Access

The customer gets access to the CDB with some common users, for very specific purposes, such as:

• Monitoring of the Resource Management at CDB level

  Since Resource Management is enabled at CDB level, the customer chooses a performance profile to be associated to their PDB (Low, Medium, High). This results in enforcing some resource management between the different PDBs of the container CDB. This common user has the select privilege on the required views to monitor the CDB Resource Management from the CDB.

• Performance monitoring

  This common user is granted select any dictionary and select_catalog_role for the purpose of performance monitoring (access to DBA performance views).

• Auditing

  The customer already has full audit-related privileges in PDBs via the PDBADMIN user. This common user enables the customer to have a common account to easily access audit records from one place, including audit records of the CDB itself. Any purging related activities should be done using PDBADMIN user from within the PDB (no possibility to purge CDB audit records with the common user).

• Management of user sessions

  The purpose of this user is to allow clients to kill PDB sessions from the CDB level (no login at PDB level).

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.
• "Verify Function 14C" : same as above, with min. length of 14 characters and additional verifications.
• "Strong Verify Function" : a verification function with min. length of 9 characters and additional verifications.
• "Recommended" : the Swisscom recommended verification function (min. 17 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 Highend 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 RE Lockdown Profile

  It is the Default Lockdown Profile currently in use in MODS Regular 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.

Security Shapes

The Security Shapes are a concept elaborated and offered by MODS to apply a different level of hardening to a PDB.

As of now, the Security Shapes pertain to revoking default public execute privileges from powerful packages and object types, as per CIS benchmark recommendations.

The following MODS Database Security Shapes are currently available:

• CIS Recommendations Security Shape

  This shape includes security measures based on CIS Oracle Database benchmark. This is the most restrictive security configuration.

• Security Best Practices Security Shape

  This is the default configuration recommended by MODS. It Includes security measures based on Database security best practices by Swisscom. Over all it is slightly less strict than the CIS Recommendations shape.

• Ora Default Security Shape

  This shape 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.

A security shape can be selected at the time of PDB creation or as a day-2 PDB update action.

Encryption

Data Encryption at Rest (TDE)

The customer has the possibility to request the configuration of Transparent Data Encryption at the time of PDB creation. Once configured, this enables them to create encrypted tablespaces.

Transparent Data Encryption is a part of Oracle's Advanced Security Option.

Ref: Oracle White Paper Encryption and Redaction with Oracle Advanced Security

Note: the encryption keys are currently being managed by Swisscom. It is considered to offer the possibility in future for the customer to use their own keystores for their PDBs.

A detailed description of TDE for Tablespaces can be found in the Oracle Database 19c Security Guide at 2.4.3 How Transparent Data Encryption Tablespace Encryption Works

Network Encryption (SQLNet)

Oracle Database offers natively the possibility to encrypt the data in transit on the network.

At MODS, the SQLNet server configuration enforces the encryption of data on the network, and no further configuration is required on the client side.

Database Auditing

Oracle's Unified Auditing is enabled on all CDBs.

In a multitenant architecture, auditing is configured independently at CDB level and in each PDB:

• Common Audit Policies

  These are defined in the CDB$ROOT container and are valid for all common users, be they connected to the root container or to a PDB. Activities performed by a common user are logged in the Audit Trail of the container (either CDB$ROOT or a PDB) where it is currently connected. The common policies and the maintenance of the CDB's Audit Trail are managed by Swisscom.

• Local Audit Policies

  These pertain to the audit policies that are defined and applicable within a certain PDB. These policies apply to the local PDB users and their activities are being logged in the PDB's Audit Trail. The customer, having the AUDIT_ADMIN role, can configure the PDB's local auditing as per their requirements. However, Swisscom does provides several recommended local audit policies.

Security Assessment

Security Assessments are performed using the CIS Assessment Tool (CIS-CAT Pro Assessor) on a regular basis.

This ensures the ongoing Security Monitoring of databases and the VMs, as per the standards of the CIS benchmarks:

• Databases (CDB$ROOT and all PDBs)
• VMs' Operating System

The customer receives the report of Security Assessments performed on their PDB.

Security Framework

In order to ensure the highest level of Security for the platform and for the customers' environments, the following are being performed on a continuous basis:

• Threat Modeling

  An in-depth analysis of the MODS Database Service is being done regularly. It consists in establishing an architectural dataflow diagram of the platform, identifying threats and assessing the associated risks. Then a risk mitigation is carried out to eliminate the risks.

• Penetration Testing

  An external Security company is mandated to simulate cyber attacks on the platform in order to assess its robustness, its resilience and to identify possible vulnerabilities.

• Vulnerability Management and Patching

  The mitigation of the risks and vulnerabilities identified through the Threat Model and the Penetration Testing is then performed as an ongoing effort to harden and secure the platform.

  This also includes reviewing the security patches published quarterly by the editor/manufacturer (Oracle) and also the critical security fixes that may need to be applied through an emergency procedure.