S 5.119 Integration of a web application with web, application, and database servers into a security gateway
Initiation responsibility: Head of IT, IT Security Officer
Implementation responsibility: IT Security Officer, Administrator
In order to provide a complex web application (for example an e-government application or an online shop), additional security safeguards are required due to the increased protection requirements. In the following, a standard design for providing a web application consisting of web server, application server, and database server is suggested for this special case.
Architecture with two ALGs and packet filters
The security gateway is configured in such a way that all servers are separated by one ALG in order to prevent unauthorised encroachments from one server to another and to maintain the control of the protocols used. The web server is secured both by a packet filter and by an ALG in order to provide the highest possible level of protection against attackers from the untrustworthy network.
The design was selected in such a way that every server may establish a maximum of two communication links in the application context, with these links being protected by corresponding ALGs. The following table summarises the communication links:
| Servers | Communication with | Protocol | Notes |
|---|---|---|---|
| Web servers | Client from the external network | HTTPS | If required, the encrypted connection may already be terminated at the ALG.See also S 5.115 Integration of a web server into a security gateway |
| Web servers | Application servers | Application-specific protocols, for example SOAP, RPC, Corba, and such like | There also are security proxies for the protocols |
| Application servers | Database servers | Database protocol | See also S 5.117 Integration of a database server into a security gateway |
Table: Communication connections
Additionally, accesses for administration from the internal network may be required in each case. These must be restricted to the corresponding administration computers and must only be performed using correspondingly protected protocols (for example SSH). It should be checked whether a physical connection to the trustworthy network may be relinquished completely in order to prevent an attack by insiders.
The following figure again illustrates the architecture described above. The communication links permitted in each case are entered.
Figure 1: Design of a typical web application consisting of web server, application server, and database.
Simplified architecture without ALGs
If the application is not characterised by any specific security requirements, the ALGs may not be applicable and the web server can be installed in a DMZ of the outer packet filter, while the application and the database servers can be installed in separate DMZs of the internal packet filter. The communication links are only limited by corresponding packet filter rules in this case.
In this case, it is no longer possible to check the communication content, however. If no ALGs are installed between the client and the web server (reverse HTTP proxy), HTTP queries from the untrustworthy network may no longer be checked for their compliance with the HTTP specification and tested for unusual content (in the respective context), for example.
It is absolutely recommended to use a corresponding ALG (reverse HTTP proxy) at least for the clients' access to the web server.
The following figure illustrates the simplified architecture with two packet filters. The communication links are as described in the above table, only with no protocol-specific security proxies being used.
Figure 2: Design of a typical web application consisting of web server, application server, and database without using any ALGs.
Whether the simplified design suffices for the web application used in each case must be decided on a case-by-case basis. The decision must be made based on the protection requirements of the processed data; the decision must not be exclusively based on cost-related arguments. The decision and the reasons for the decision made must be documented and it must be checked regularly whether the requirements have changed. Particularly in the event of changes and extensions regarding the web application, it must be ensured that the architecture still corresponds to the security requirements.
The following items may be used for the considerations:
- For web applications only accessed from a "relatively trustworthy network, the simplified design also provides for a sufficient level of security.
- If the web application is an application that may be accessed using the internet or if the processed data has high protection requirements, at least a reverse HTTP proxy should be used for protecting the web server against attacks from the internet.
- If additional databases are operated on the database server that belongs to the web application, the protection requirements of this data must also be taken into consideration. In this case, securely and carefully configuring the database server is of particular importance. The use of a security proxy for the database accesses is absolutely recommendable in this case.
Review questions:
- With regard to the architecture with two ALGs and packet filters: Have all servers been separated by an ALG in order to prevent unauthorised encroachments from one server to another?
- With regard to the architecture with two ALGs and packet filters: Is the web server protected by a packet filter and an ALG in order to provide for additional protection against external attackers?
- With regard to the simplified architecture without ALGs: Have the web servers, as well as the application server and the database server been installed in a separate DMZ of the packet filter?
- With regard to the simplified architecture without ALGs: Is a reverse HTTP proxy used for external accesses to the web server?
- Have the decisions and reasons regarding the selected architecture for integrating the web application been documented?
- Has it been ensured that changes to the web applications comply with the organisation's security policies?
- with regard to database servers of the web application running further databases: Is a security proxy used for the database accesses for all database instances?