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.
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 PUBLICThe 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>;Last updated