Table of Contents
This chapter describes how to configure and use Separation of Duties that allows separation of administrator privileges in Tibero.
A single administrator account, SYS, is used to perform overall database management in Tibero DBMS. This may result in security issues, such as the abuse of administrator privileges or hijacking of accounts, that can break down the security system and lead to data leak, manipulation, corruption, etc.
Tibero Separation of Duties (hereafter SOD) is a method of dividing the existing SYS privileges into three. The administrator role is divided into three accounts and each account is granted only the necessary privileges to perform the specified role. No single account can be used to break down the security system.
The following three administrator accounts are created when SOD is installed.
Manages tablespaces, data files, schema objects, etc.
Security Administrator (SYSSEC)
Manages database security and privilege management.
Manages history of database activities.
A system administrator manages daily database activities and use taking the role of a DBA. This includes database maintenance, backup and recovery, establishment of policies and procedures, but excludes security and audit. For more information about the duties, refer to “2.1.1. DBA”.
A system administrator does not possess permissions to grant general user permissions, but can grant basic permissions for connect (access permission) and resource(resource usage permission).
All information, except for audit related information, can be seen from the static view.
A security administrator manages user access and permissions. SOD bases its security standards on whether a user can perform specific action, and manages security through privileges and roles. For information about privileges and roles, refer to “5.2. Privileges” and “5.4. Roles”. In SOD, only security administrator can manage and grant such permissions.
Due to security issues related to existing DBA privileges and permissions to use the following commands have been removed.
Removed Privileges
CREATE ROLE
DROP/GRANT/ALTER ANY ROLE
GRANT ANY PRIVILEGE
GRANT ANY OBJECT PRIVILEGE
AUDIT SYSTEM/ANY
The following static views related to security can be used for management.
A system auditor manages database auditing. In SOD, a system auditor is responsible for auditing and general DBA role. For information about this role, refer to “5.6. Auditing”.
In SOD, other administrators do not have the privileges to perform auditing. Only system auditors can view audit related view (DBA_AUDIT_TRAIL).
The following describes how to install SOD.
Before starting the installation, 'SEPARATION_OF_DUTIES=Y' must be added to the tip file. This parameter cannot be changed dynamically and the database must be restarted after modification. It is recommended not to modify this parameter unless it is absolutely necessary.
Add the -sod Y option when mounting the database after configuring the tip file. For manual installation, add the option when executing system.sh after creating the database.
Set the ID and password for each account.
SYS administrator is divided into the following accounts, and each administrator's ID and default password are as follows:
| Administrator Name | Administrator ID | Default Password |
|---|---|---|
| System Administrator | SYSADM | SYSADM |
| Security Administrator | SYSSEC | SYSSEC |
| System Auditor | SYSAUD | SYSAUD |
The default passwords should be changed by each administrator after the installation is complete.
Note the following when using SOD.
SOD is separate function provided by Tibero and can only be activated during installation. It cannot be activated once the database is installed since the three administrator accounts must be created during installation. Dividing the administrator role in three will allow the function to be used efficiently.
A user with DBA permissions in existing databases possesses similar level of permissions as the SYS user which can lead to security leaks. In SOD, DBA permissions do not exist and administrator permissions cannot be granted to general users.
When using SOD, the existing SYS account cannot be used. (SYS account becomes locked and cannot be unlocked). SYS related information cannot be seen from the static view.