Secure Customer Portal: Isolate the Operational DB

A portal where customers look up their own information adds value, but it also opens a door toward company data. Designing it so the portal has no direct contact with the operational database reduces risk and protects business continuity.

• A portal exposed to the internet must be separated from internal systems.
• A read-only copy and a controlled access interface limit what can be reached.
• Isolating the database also keeps heavy portal load from affecting daily operations.

The risk of connecting the portal to the live database

If the portal accesses the operational system directly, a portal bug, abuse or vulnerability can alter or expose critical information, or slow the system operations depend on. A direct connection mixes two worlds with very different levels of exposure.

A more prudent design

1. Separation. The portal lives in an environment distinct from internal systems.
2. Read-only copy. The portal queries a replica of the data it needs and cannot modify the original.
3. Controlled interface. Access to that data goes through an API with authentication and narrow permissions.
4. Minimum necessary. Only the data each customer needs to see is published.
5. Access log. Evidence remains of who looked up what.
6. Strong authentication. Protected credentials and multi-factor authentication where appropriate.

Implementation details depend on each system and are not described here.

Benefits

• Lower impact if the portal is attacked or fails.
• Internal operations continue even if the portal is under load.
• Better traceability and less exposure of personal data.
• Ability to test with synthetic data without touching real information.

What to do

• Define what information the customer needs to see and publish no more.
• Require separation between the portal and internal systems.
• Check that portal access is read-only.
• Review authentication and access logging.
• Include the portal in the backup and continuity plan.

Frequently asked questions

Why not connect the portal directly to the system, which is simpler? It is faster to build, but widens exposure and the impact of any failure.

Will portal data be out of date? It depends on the refresh frequency defined, which is set to fit the business need.

Does this apply to small portals? Yes, the separation principle holds at any size.

When supporting our clients, we usually recommend integrating portals with internal systems through an isolated API and a read-only replica. For overall continuity, see RPO and RTO explained.

IT Lab supports Chilean organisations in this. Contact us.