How to Secure Exposed Databases: Add a Middle Layer and Tighten Access

Problem Context

In small companies a developer often also acts as the DBA. The production database was directly reachable from the Internet, and after a developer left the company the old credentials remained valid, allowing continued access.

Proposed Network Segmentation

Insert a “gateway” database (middle‑layer) that is the only component exposed to the external network. The real production database stays behind the internal firewall.

Implementation Steps

Deploy a new database instance that will serve as the middle‑layer. Open the required port (e.g., 1521) to the Internet and restrict access to the PDA applications.

Move the production database into the internal network, ensuring it is not reachable from outside the firewall.

Create a database link (DBLINK) from the middle‑layer instance to the production instance, for example:

CREATE DATABASE LINK prod_link CONNECT TO prod_user IDENTIFIED BY **** USING 'prod_host:1521/prod_service';

Grant the link user only the minimal SELECT/INSERT/UPDATE privileges on the tables needed by the PDA.

Modify the PDA connection strings to point to the middle‑layer host and use the credentials created for the link.

Test the end‑to‑end flow, then disable the old external DB listener.

Security Benefits

The production database is no longer exposed to the public Internet, reducing the attack surface.

Compromised former‑employee credentials only allow access to the middle‑layer DB, where privileges are tightly scoped.

All privileged operations are mediated through the DBLINK, enabling fine‑grained permission control.

Operational Recommendations

Rotate service accounts and passwords regularly (e.g., annually) and immediately after staff departures.

Enforce the principle of least privilege for developers; they should not have direct connections to production.

Place the database servers on hardened Linux hosts, use strong passwords, and keep them behind a firewall.

Perform periodic security audits and review DBLINK permissions.

Conclusion

Segregating the production database behind a firewall and exposing only a controlled middle‑layer instance eliminates the primary risk of direct Internet exposure while preserving application functionality.