# Account 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 operation 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. ### *** ## DBA Privileges Control ### Risk Analysis An unauthorized user may misuse or abuse the DBMS with DBA privileges. ### Risk Impact There is a potential risk of system failure or database tampering by using DBA privileges. ### Solution Verify the users and the necessity of accounts with DBA privileges. If any accounts are unnecessarily granted DBA privileges, either remove the account or revoke the DBA privileges. Additionally, establish security policies to prevent data leakage and loss. Removing DBA privileges is as follows: ``` SQL> REVOKE DBA FROM ; ``` ### *** ## Use of Default Account ### Risk Analysis The database can be accessed through a well-known default account and password. ### Risk Impact Accessing the database with a default, well-known account can allow access or elevated privileges to view, modify or delete data. ### Solution * Delete any unused application accounts to restrict access at both the OS and DB level. * Use the account for original purpose only, and in case of the need to limit access to certain database, remove it from the SUPER USER or GROUP installation account. ### *** ## Use of Default DB Password ### Risk Analysis An authorized user may access the DBMS using the default password to default DB user account such as SYSCAT, SYSGIS, OUTLN, TIBERO and TIBERO1. ### Risk Impact An unauthorized access to the database can result in viewing, modifying, or deleting data, potentially with elevated privileges. ### Solution Delete or lock any unused default DB account, or change the default password of used account. #### **Account Lock** ``` SQL> ALTER USER ACCOUNT LOCK; ``` #### **Change Password** ``` SQL> ALTER USER IDENTIFIED BY ‘’; ``` ### *** ## Blocking Unlimited Login Attempts ### Risk Analysis If unlimited login attempts are allowed, an infinite number of login attempts can occur due to a Brute Force attack. ### Risk Impact Brute Force attacks can cause damage. ### Solution Lock the account by setting the FAILED\_LOGIN\_ATTEMPTS to lock the account after login failures exceed a certain number of times. A profile provides the feature to manage password policies grouped by users by creating various user password management policies and assigning each user to use a specific policy. #### **Create profile** ``` SQL> CREATE PROFILE LIMIT PASSWORD_VERIFY_FUNCTION verify_function FAILED_LOGIN_ATTEMPTS ; ``` #### **Change profile** ``` SQL> ALTER PROFILE LIMIT FAILED_LOGIN_ATTEMPTS ; ``` #### **Allocate profile** ``` SQL> ALTER USER PROFILE ; ``` ### *** ## Password Lock Time Setting Check ### Risk Analysis Brute force attacks by malicious users may result in unlimited login attempts. ### Risk Impact Brute Force attacks can cause damage. ### Solution Set the PASSWORD\_LOCK\_TIME parameter to lock the account for a specified time period after a number of failed login attempts, preventing login during that time. (default : UNLIMITED, recommended : 1 or 2 or 24) #### **Change profile** ``` SQL> ALTER PROFILE LIMIT PASSWORD_LOCK_TIME ; ``` #### **Allocate profile** ``` SQL> ALTER USER PROFILE ; ``` ### *** ## Periodic Password Change ### Risk Analysis If the password to DBA\_USERS account is not updated periodically or is set to a vulnerable password, unauthorized user may be assigned with DBA or USER privileges. ### Risk Impact Privileges could be exposed and abused. ### Solution Change the PASSWORD\_LIFE\_TIME in the profile setting. (default : UNLIMITED, recommended : 30 \~ 90days) **Change profile** ``` SQL> ALTER PROFILE LIMIT PASSWORD_LIFE_TIME < number of days>; ``` #### **Allocate profile** ``` SQL> ALTER USER PROFILE ; ``` ### *** ## Password reuse period settings for DB account check ### Risk Analysis When changing the password of the DBA\_USERS account, if you use the same password without setting a password reuse period, DBA privileges may be granted to an unauthenticated user. ### Risk Impact Privileges could be exposed and abused. ### **Solution** Change the value of PASSWORD\_REUSE\_TIME to prevent the reuse of previously used password during the date set in PASSWORD\_REUSE\_TIME. (default : UNLIMITED, recommended : 30 \~ 90 days) **Change profile** ``` SQL> ALTER PROFILE LIMIT PASSWORD_REUSE_TIME ; ``` #### **Allocate profile** ``` SQL> ALTER USER PROFILE ; ``` ### --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.tibero.com/en_tibero-technical-guides/topics/security/account-management.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.