We can say today that if a company is not present on
the Internet it almost doesn’t matter in the business environment. And the Web
façade had already gone over the static site presenting some information about
the company. We can see now on-line banking, shopping sites, company portals,
interactive customer care and a lot more.
The requirements to exchange information with the
existing and potential clients over the Internet are generating specific
security challenges for the deployment of database-driven applications. Even
the dynamic-content sites, but especially the Web-based applications, are
storing data in some databases. And as soon as a company opens a gate toward
Internet, there will be someone out there trying to knock the door open.
Considering that a regular environment is composed
by some applications that are only publishing data to the web server, but many
of them also require the ability of the Web user to input data into the company
systems, the physical databases protection from outside attacks becomes even
more complex.
The most used topology in the industry to physically
protect the databases involved in the interaction with the public network is
based on a 3 zone network, with increased security levels, as represented in
Fig.1.
Fig.1 - Typical
Network Topology
All the public and internal web traffic is directed by the
Main Firewall to the Web Server located in the DMZ1 network segment. The
Internal Network has no direct channel through the firewall with the Internet,
all the traffic being routed through the Web Server. The first De-Militarized
Zone – as usually called – is somewhat protected by the firewall for some
attacks, but the level of security is quite low as far as the computers located
here are visible to the outside world.
The Web Server from DMZ1 has a bi-directional channel
through the Firewall 1 with the Application Servers located in the DMZ2. More
advanced security techniques can be applied between these zones. The most
important one is to allow only traffic initiated by the Web Server or the
Application Servers, but this can be enhanced with ports routing, encryption
algorithms, use of non-standard ports and so on.
The Application Servers are connected to Database Servers
located in DMZ2 as well, reading and writing information as requested by the
Web Server. The Database Servers are not visible even from DMZ1. Even so, a
company should avoid storing sensitive data here more then strictly required
for the on-going transaction.
The Database Servers located in the Internal Network are
connected through a one way tunnel opened in the Firewall 2 with the DMZ2
Database Servers. One or many demon applications are using this SqlNet only
connection (for Oracle databases) to push data into the DMZ2 databases, pull
out data when needed and write it into the internal databases. This channel can
be opened only from the Internal Network, so even a hacker that already got
into DMZ2 cannot pass into the Internal network. Once the sensitive data
located in the DMZ2 was copied inside the Internal Network it should be purged
from the DMZ2 databases. This way the potential exposure is limited to
temporary transaction data and public data (available on the Web site anyway).
A low-cost variation of this topology is based on a two-ways
open channel in Firewall 2 that allows the Application servers to access
directly the databases located in the Internal Network, as presented in Fig.2.
Fig.2 - Alternative
Topology
Because the DMZ2 databases are not present in this version,
the demon processes to move data into the internal network and publish in the
DMZ2 are not required anymore. The Application Servers will connect through a
SqlNet only bi-way channel with the Database Servers located in the Internal
Network.
The implementation is much faster as far as it is reduced to
settings of various network devices. No development work is needed to custom-build
the demon applications, but enabling a channel (even complicated) between the
Internet Zone and the internal databases is significantly increasing the risk
level.
Both options require specific firewall configurations,
network scanners and monitors, port scramblers and other network security
products and techniques, not detailed in this presentation, as far as our only
intent was to present only the solution overview. Regardless of the complexity
enforced through the configuration of the network devices, the topology based
on demon applications (option 1) will offer a much higher security level, even
if it is somewhat more expensive then option 2.
