Privilege Management

The chapters in this part explain risk analysis, risk impact, and solutions related to privilege management.

Separation of Development and Operation Systems

Risk Analysis

The development and operation systems should be separated at the hardware level, without any established links. When transferring data from the production system to the development system, it is essential to execute control and verification procedures, such as deleting sensitive data.

Risk Impact

Sensitive data from production system may be leaked to development system.

Solution

Define the separation of development and operation systems following the company policies, and ensure that developers and operators are separated by principle. If unable to be separated, the developer must be authorized and controlled to access the operation system.

---

SYSDBA Privilege Control

Risk Analysis

If a DBA accesses without entering the SYS password, group members with SYS privileges can log in. Therefore, it is essential to require the SYS password to be entered for login.

Risk Impact

SYS privilege is acquired without verification.

Solution

Not applicable as Tibero does not have access method like Oracle sqlplus /as sysdba.

---

Listener Password Setting Check

Risk Analysis

Starting or stopping the Listener is only granted to privileged users like DBAs, and an access password should be set to control the access to the Listener.

Risk Impact

An unauthorized user may gain access to the Listener.

Solution

Not applicable as Tibero operates the Listener and server process simultaneously.

---

Configuration File Protection Check

Risk Analysis

If sensitive configuration files are accessible and can be modified by anyone, an unauthorized user may access the files and alter the settings that can impact the DB operations.

Risk Impact

Files can be tampered for malicious purpose.

Solution

• Change the permission setting of $TB_HOME/config/$TB_SID.tip file. (recommended : 600 or 640)

• Ensure that modifications and modifications are handled by the OS account, and limit the access of general accounts.

---

Crucial File Ownership or Group Setting Check

Risk Analysis

If unnecessary ownership or group permissions are assigned to important files, unauthorized users may be able to access information through those files.

Risk Impact

If the permissions for system or network configuration files are vulnerable, or if files that should be owned by the Tibero user are instead owned by unauthorized users, there is a risk that unauthorized users could gain system privileges or destroy important data.

Solution

Change the permission setting of $TB_HOME/client/config/tbdsn.tbr file. (recommended : 600 or 640)

---

Public Access Control

Risk Analysis

If object permissions are granted to the public, any account without specific permissions can access the object and retrieve its information.

Risk Impact

If unnecessary object permissions are granted to the public for newly created accounts, there is a risk of privilege abuse.

It is acceptable if object permissions are granted to the public by default or the owner of the object is a system account during solution installation.

Solution

Restrict permissions if object access is unnecessarily granted to the public.

The following is how to remove permissions from the public.

SQL> REVOKE <privilege> ON <object> FROM PUBLIC

---

The Use of GRANT Option Control

Risk Analysis

A user who has received privileges along with the GRANT option can grant those privileges to other users.

Risk Impact

There is a risk of privilege abuse if unnecessary accounts have been granted the GRANT option. (Excluding when the privilege should be authorized)

Solution

Restrict the authorization to grant the GRANT option to DBAs only. Remove the privilege and reassign it without the GRANT option for accounts that have been unnecessarily granted.

Revoke privileges

SQL> REVOKE <privilege> ON <object_name> FROM <user_name>;

Grant privileges

SQL> GRANT <privilege> ON <object_name> TO <user_name>;

---

The Use of ADMIN Option Control

Risk Analysis

A user who has received system privileges along with the ADMIN option can grant those privileges to other users.

Risk Impact

There is a risk of privilege abuse if unnecessary accounts have been granted the ADMIN option. (Excluding when the privilege should be authorized)

Solution

Restrict the authorization to grant the ADMIN option to DBAs only. Remove the privilege and reassign it without the ADMIN option for accounts that have been unnecessarily granted.

Revoke Privileges

SQL> REVOKE <Privilege> ON <object_name> FROM <user_name>;

Grant Privileges

SQL> GRANT <Privilege> ON <object_name> TO <user_name>;