Harden an Oracle Database Against Unauthorized Access

 

As an Oracle DBA, database security is not just about setting a password and granting roles. It is a continuous process of reducing attack surface, controlling access, monitoring activities, and ensuring compliance. In one of my recent environments, I worked on hardening the Oracle database to protect it from unauthorized access. Below are the practical, real-world steps I followed.

1. Securing Database Accounts

The first step was to audit all existing users.

SELECT username, account_status FROM dba_users;

Actions taken:

• Locked and expired unused or default accounts:

ALTER USER scott ACCOUNT LOCK;
ALTER USER hr ACCOUNT LOCK

• Enforced strong passwords using profiles:

CREATE PROFILE secure_profile LIMIT
  FAILED_LOGIN_ATTEMPTS 5
  PASSWORD_LIFE_TIME 60
  PASSWORD_REUSE_TIME 365
  PASSWORD_REUSE_MAX 5
  PASSWORD_VERIFY_FUNCTION ora12c_verify_function;

Assigned profile:

ALTER USER app_user PROFILE secure_profile;

This ensured:

• Strong password complexity
• Automatic password expiration
• Account lock after multiple failures

2. Principle of Least Privilege

I reviewed excessive privileges:

SELECT * FROM dba_role_privs WHERE grantee='APP_USER';
SELECT * FROM dba_sys_privs WHERE grantee='APP_USER';

Actions:

• Removed unnecessary privileges:

REVOKE DBA FROM app_user;

• Created custom roles:

CREATE ROLE app_read_role;
GRANT SELECT ON schema.table1 TO app_read_role;
GRANT app_read_role TO app_user;

This limited users to only what they really needed.

3. Restricting Network Access Using Oracle Listener

I controlled which IPs could connect to the database by editing sqlnet.ora:

SQLNET.INBOUND_CONNECT_TIMEOUT = 10
SQLNET.EXPIRE_TIME = 10

For IP restriction:

tcp.validnode_checking = YES
tcp.invited_nodes = (192.168.1.10,192.168.1.20)

This stopped unauthorized systems from even reaching the database.

4. Encrypting Data Using TDE (Transparent Data Encryption)

To protect data at rest:

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "wallet_password";
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "wallet_password" WITH BACKUP;

Encrypt sensitive columns:

ALTER TABLE employees MODIFY (salary ENCRYPT);

Or full tablespace encryption:

CREATE TABLESPACE secure_ts
DATAFILE '/u01/oradata/secure01.dbf' SIZE 100M
ENCRYPTION USING 'AES256'
DEFAULT STORAGE(ENCRYPT);

This ensured that even if someone accessed datafiles, the data would be unreadable.

5. Enabling Auditing

I enabled Unified Auditing to track suspicious activities.

AUDIT CREATE USER;
AUDIT DROP USER;
AUDIT GRANT ANY PRIVILEGE;
AUDIT ALTER SYSTEM;

To check logs:

SELECT event_timestamp, dbusername, action_name 
FROM unified_audit_trail
ORDER BY event_timestamp DESC

This helped in:

• Tracking unauthorized access attempts
• Compliance reporting
• Forensic analysis

6. Protecting SYS and SYSTEM Users

• Changed default passwords
• Restricted login:

ALTER USER SYS IDENTIFIED BY StrongPassword;
ALTER USER SYSTEM IDENTIFIED BY StrongPassword;

Set:

ALTER SYSTEM SET remote_login_passwordfile=EXCLUSIVE;

Only DBAs were allowed to use SYSDBA access.

7. Securing Backup Files

RMAN backups were encrypted:

CONFIGURE ENCRYPTION FOR DATABASE ON;
CONFIGURE ENCRYPTION ALGORITHM 'AES256';

Now every backup was protected even outside the server.

8. Disabling Unused Services & Features

Checked active services:

lsnrctl status

Removed unnecessary services:

DBMS_SERVICE.DELETE_SERVICE('unused_service');

Disabled unused packages and features wherever possible.

9. Patching the Database Regularly

Security vulnerabilities are fixed through CPU and PSU patches.

Steps followed:

1. Check version:

SELECT * FROM v$version;

1. Download latest patch from Oracle Support
2. Apply using OPatch
3. Validate:

opatch lsinventory

This closed known security loopholes.

10. Restricting OS-Level Access

At OS level:

• Only oracle and grid users had access to Oracle directories
• Set strict permissions:

chmod -R 700 /u01/app/oracle
chown -R oracle:oinstall /u01/app/oracle

No unauthorized Linux user could access database files.

11. Using Data Redaction & VPD (Optional Advanced Security)

For sensitive columns:

BEGIN
  DBMS_REDACT.ADD_POLICY(
    object_schema => 'HR',
    object_name   => 'EMPLOYEES',
    column_name   => 'SALARY',
    policy_name   => 'mask_salary',
    function_type => DBMS_REDACT.FULL);
END;
/

This masked data for non-privileged users.

12. Continuous Monitoring

I monitored:

• Failed login attempts
• Audit logs
• Listener logs
• OS authentication logs

This ensured early detection of suspicious activities.

Final Thoughts

Hardening a database is not a one-time task; it’s a continuous responsibility.
In real-world Oracle DBA work, I always follow this order:

1. Secure users
2. Restrict privileges
3. Secure network
4. Encrypt data & backups
5. Enable auditing
6. Patch regularly
7. Monitor continuously

These practical steps transformed the database from a “basic setup” into a secure, enterprise-grade environment resistant to unauthorized access.

At Learnomate Technologies, we believe database security is not optional, it’s a responsibility every Oracle DBA must own.

Looking for the best Oracle DBA institute in Pune to build a successful career in database administration? Our Oracle DBA training program is designed to help beginners and experienced IT professionals gain real-world Oracle database skills with hands-on practice and expert guidance.

We provide industry-oriented Oracle DBA training covering Oracle 11g, 12c, 18c, and 19c, aligned with current enterprise requirements. Our course focuses on practical learning, live lab sessions, and real-time troubleshooting scenarios used by professional Oracle DBAs.