Showing posts with label Locking SYS and SYSTEM Users. Show all posts
Showing posts with label Locking SYS and SYSTEM Users. Show all posts

3.7.25

Oracle Database Security: Essential On-Premises Database Protection Strategies

 In today's digital landscape, Oracle database security is a paramount concern, whether your databases are on the cloud or on-premises. While cloud providers offer numerous security features at the infrastructure level, this article focuses on effective on-premises database protection strategies to secure your Oracle databases.

1. Locking SYS and SYSTEM Users

One of the first steps in database security best practices is to lock and expire the SYS and SYSTEM users for all databases. These accounts are not needed on a daily basis. If you require a sysdba account, consider creating a new user with necessary privileges, such as unlocking sessions and assigning dba_ privileges*. Remember to lock and expire every unused user from the database to enhance security.

2. SQL92_SECURITY Parameter

Ensure that the SQL92_SECURITY parameter is set to true. This setting, recommended by Oracle, was often defaulted to FALSE in earlier versions like 10g. Starting from 12.2, it is set to TRUE by default. The SQL92_SECURITY standard mandates that users must have the SELECT privilege on a table to execute UPDATE or DELETE statements referencing table column values in a WHERE or SET clause.

To set this parameter, use the following command:

ALTER SYSTEM SET sql92_security = TRUE SCOPE = SPFILE;

3. Audit SYS Operations

Another crucial step is to change the audit_sys_operations parameter to true. This parameter, which was FALSE by default until 11g, enables the auditing of operations issued by the SYS user and those connecting with SYSDBA or SYSOPER privileges. The audit records will be written to the operating system's audit trail, enhancing database vulnerability management.

To enable this, execute:

ALTER SYSTEM SET audit_sys_operations = TRUE SCOPE = SPFILE;

4. Configuring Security Parameters

Set certain parameters to FALSE or NONE to tighten security. Key configurations include:

  • Ensure DBA_USERS.PASSWORD is not set to EXTERNAL for any user.
  • Set REMOTE_OS_ROLES to FALSE.
  • Set REMOTE_OS_AUTHENT to FALSE.
  • Set REMOTE_LOGIN_PASSWORDFILE to NONE.
  • Leave REMOTE_LISTENER empty.
  • Set GLOBAL_NAMES to TRUE.

These adjustments restrict remote privileged connections, ensuring that powerful users (like SYS) cannot connect remotely but only from the DB server.

To change the remote login password file setting, use:

ALTER SYSTEM SET remote_login_passwordfile = NONE SCOPE = SPFILE;

5. Managing Failed Login Attempts

Adjust your profile settings for failed login attempts security. Change the FAILED_LOGIN_ATTEMPTS value to a minimum of 3. This will lock the user after three unsuccessful attempts, significantly reducing the risk of unauthorized access.

To modify this setting, execute:

ALTER PROFILE super LIMIT FAILED_LOGIN_ATTEMPTS 3;

6. Case-Sensitive Logon in Oracle

It’s crucial to set sec_case_sensitive_logon to true. This parameter was FALSE until 11g and is deprecated in 12c, so ensure you are using TRUE in all applicable databases. This setting enhances password security by enforcing case sensitivity.

To set this parameter, use:

ALTER SYSTEM SET sec_case_sensitive_logon = TRUE;

Conclusion

These foundational steps in Oracle database hardening will significantly improve the security of your on-premises databases. Implementing these Oracle security configurations is crucial for safeguarding your data and ensuring compliance with industry best practices.