icon Batch Starting in Next Week-Data Science with Gen AI ENROLL NOW

Practical Steps I Took to Harden an Oracle Database Against Unauthorized Access

Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
  • 20 Jan, 2026
  • 0 Comments
  • 3 Mins Read

Practical Steps I Took to Harden an Oracle Database Against Unauthorized Access

Practical Steps I Took to 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.

Let's Talk

Find your desired career path with us!

Let's Talk

Find your desired career path with us!