Security is the main concern everywhere if you are on Cloud or on Prim database. Cloud providers provide many security features on the infrastructure level plus some have Security as a service as well.
Our main focus in this article is to maintain the security
on your on-prim databases.
1. We need to lock and expire SYS and SYSTEM users for all databases.
You don’t need SYS and SYSTEM users
on daily bases. So why to keep them open. If you really need sysdba account
better create one. You may try one user who can do things like unlocking sessions,
assigning dba_* privilege, etc.
Note: - You need to lock and
expire every user from the database that is not in use.
2. Make Sure SQL92_SECURITY parameter is set to true
Make sure the SQL92_SECURITY parameter is set to true, which is already
recommended by oracle. It was defaulting to FALSE in 10g and because of that most
of the time carried forwarded to 11g or 12c. Oracle has changed this parameter
to TRUE by default in 12.2 as per my study.
what is SQL92_SECURITY?
The SQL92 standards specify that security administrators should be able to require that users have SELECT privilege on a table when executing an UPDATE or DELETE statement that references table column values in a WHERE or SET clause. SQL92_SECURITY specifies whether users must have been granted the SELECT object privilege in order to execute such UPDATE or DELETE statements. Source (docs.oracle.com)
To change: - alter system
set sql92_security = TRUE scope = spfile;
3. Change audit_sys_operations to true
Change audit_sys_operations to true which by default is FALSE till 11g. In
12c it is by default TRUE. Changing this parameter needs bouncing of the
database, so plan accordingly if you want to change.
what is
audit_sys_operations?
AUDIT_SYS_OPERATIONS enables or disables the auditing of operations issued by user SYS, and users connecting with SYSDBA or SYSOPER privileges. The audit records are written to the operating system's audit trail. The audit records will be written in XML format if the AUDIT_TRAIL initialization parameter is set to XML.Source (docs.oracle.com)
To change: - alter system set audit_sys_operations=true scope=spfile;
4. Set some parameters to FALSE or NONE
Ensure
‘DBA_USERS.PASSWORD’ is not set to ‘EXTERNAL’ for any user
Ensure ‘REMOTE_OS_ROLES’ is set to
‘FALSE’.
Ensure ‘REMOTE_OS_AUTHENT’ is set to
‘FALSE’.
Ensure ‘REMOTE_LOGIN_PASSWORDFILE’
is set to ‘NONE’.
Ensure ‘REMOTE_LISTENER’ is empty.
Ensure ‘GLOBAL_NAMES’ is set to
‘TRUE’.
Remote privileged connections to the database should be restricted means power user (e.g. sys) is not able to connect to DB remotely, instead of only in the DB server. I believe setting REMOTE_LOGIN_PASSWORDFILE = NONE is enough. Comment your opinion.
To change: - alter system
set remote_login_passwordfile=none scope=spfile;
5. Change wrong password attempts
Change the value of your profile for the wrong password attempts to 3minimum which is FAILED_LOGIN_ATTEMPTS
by default it's 10. If someone doesn’t know the password in three attempts
most likely they really don’t know it. If someone tries to break the password
this can lock the user.
To
change: - alter profile super limit failed_login_attempts 3;
6. Change sec_case_sensitive_logon to true
Till 11g sec_case_sensitive_logon was set to FALSE and this parameter is deprecated in 12c. So make sure you are using as TRUE in 11g or 10g databases also. You may need to work with the application team on this.
what is sec_case_sensitive_logon?
SEC_CASE_SENSITIVE_LOGON enables or disables password case sensitivity in the database. Source (docs.oracle.com)
To change: - alter system set sec_case_sensitive_logon=false;
These are a few basic security you can implement in ON-PRIM database. We will update for cloud security as well.
Please feel free to add more points
in the comments. We will post in our blog with your Gmail address. Keep sharing :)