S 5.117 Integration of a database server into a security gateway

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator, IT Security Officer

There are two main application scenarios to consider when installing database servers to access an untrustworthy network:

• Access to the data of the database using a web front-end
• Direct access to the data of the database (for example using SQL)

Both application scenarios are described in the following two sections:

Access using a web front-end

The web server and the database server should be installed in different DMZs so that the database server is still protected by a proxy of the application level gateway (ALG) if the web server becomes compromised. However, the protection provided by the proxy is minimal, e.g. the TCP/IP stack of the database server is protected, for example. Furthermore, attacks based on the TCP/IP header data are prevented. If there are no special security requirements, the server may also be placed in the same DMZ as the web server.

The design and the communication links in this case are as follows:

• Access to the web server from the internet is only possible via HTTP or HTTPS. These accesses would be protected accordingly by the ALG.
• An application running on the web server converts the requests into corresponding database queries, executes these queries on the database, and prepares the results accordingly.
• The administration of the database host and the database system as well as the maintenance of the data in the database are performed using connections from the internal network, which would have to be protected accordingly.

These connections are also shown in the following figure.

Figure 1: Access to a database using a web front-end

The client in the untrustworthy network may only submit queries to the web server using web page requests and direct access to the database itself is impossible.

In this design, it is important that the application preparing the queries and results on the web server is correspondingly securely programmed and does not offer any opportunities for possible attacks to the database (using SQL injection, for example) in addition to securing the transport level. If it is possible to formulate database queries directly in the corresponding database language (for example SQL) using the web front-end, access to the web front-end should only be possible using HTTPS.

Direct access

If access to the database is allowed directly from the untrustworthy network, the server should be placed in its own DMZ. Since only a few proxies are available for database protocols, using a TCP or UDP relay is often unavoidable.

Figure 2: Direct access to a database

Due to the lack of security proxies for database query protocols, it is difficult to control the queries using security proxies, and the solution presented first using a web front-end is generally the more secure solution.

Depending on the protection requirements of the data in the database, it is urgently recommended not to grant external access to the "real database", but to copy the data to a separate database that is synchronised with the "real database" at corresponding intervals instead.

Review questions:

• If the data in the database is accessed from an untrustworthy network using a web front-end, are web server and database server located in different DMZs?
• Are the servers integrated into the security gateway administered using a trustworthy path?
• With regard to database access using web front-end: Are direct database accesses from the external network prevented?
• If direct access to the data in the database from an untrustworthy network is required, is the database server located in a separate DMZ protected additionally by a proxy or only as a copy of the original database?
• With regard to direct database access from an insecure network: Is the database server located in a DMZ ?