Case Study: Web-Based Online Billing Application

Company X has decided to deploy a web-based online billing application so that its customers can view and pay their bills through the Internet. This application must be able to use the data in the existing billing database so that the company continues to have one source of billing information. Because customers will be providing their credit card or checking account numbers as part of the payment process, the company is particularly concerned about protecting that information as well as respecting the privacy of its customers.

The perimeter network configuration at Company X is somewhat complex. As shown in Figure 15.2, Company X has an Internet firewall with four interfaces. One interface connects to the Internet, and a second one connects to the internal corporate network and provides NAT capabilities for all internal addresses. The third interface connects to a screened subnet that both internal and external users frequently access. That subnet provides external email connectivity, DNS resolution, and web-based applications; it also hosts web proxy servers used by internal hosts that want to access Internet websites and reverse proxy servers used by external hosts that want to access internal web resources. The fourth and final interface connects to another screened subnet that provides VPN capabilities for telecommuting employees.

Figure 15.2. This perimeter network has a firewall that connects two screened subnets with the Internet and internal network; it also provides NAT capabilities for internal hosts that access the Internet.

Company X has completed the software selection process based on its business requirements and has chosen an application to be deployed as quickly as possible. The application has three components: a web-based user interface, the application server to run the core components of the application, and a database. Because the company wants to use its existing online billing database, it wants to modify and expand this database rather than establish a new one.

You have been asked to research the application and determine how it can be deployed smoothly into the Company X environment. You should be most interested in identifying any potential network defense changes and problems that the application might pose to the current network configuration.

Deployment Locations

You have several options for where to put each component of the application. You want to use the existing database, which is currently located on the internal network; conceivably, you could move this host, but the company doesn't want to move it unless it's absolutely necessary. Because you want to keep the lower tiers (containing data) on protected networks, you might choose to keep the database on the internal network. Let's think about where the other systems could be deployed and what the strengths and weaknesses of each architecture are.

Web Interface on Existing Screened Subnet

Company X already has a screened subnet established for hosting services used by external hosts. You could locate the web interface on this subnet, perhaps on an existing server that already delivers web pages. Users would connect to this server. The server would then make requests on their behalf to the application and database servers, which would be located on the internal network. Potential problems with this architecture are as follows:

• The firewall might not be able to handle the protocols used between the web server and the application server.

• The data that is passed between the web server and application server might need to be encrypted because it is passing on a publicly accessible network.

• External hosts would directly access the web server.

Web Interface and Application on the Same Screened Subnet

Another option is to deploy the web interface and the application server to the same screened subnet and leave the database server on the internal network. Although it is certainly preferable to leave the application server on an internal network if users do not need to contact it directly, it might be necessary to have the web server and application server on the same subnet if the firewall cannot securely and efficiently pass traffic between them.

If sensitive data is passed between the web and application servers and it is prohibitively difficult to encrypt this data, you can largely circumvent this problem. You can create a separate screened subnet, deploy only these two servers to it, and use strong network security measures to tightly restrict access to this subnet.

All Components on the Internal Network

The web interface, application server, and database server could all be located on the internal network. As mentioned in the previous case study, in this case, you would want a reverse proxy server on a screened subnet that handles web requests on behalf of the web interface. If that's not feasible, external users could potentially be allowed to enter the internal network, but that creates a much higher level of risk.

Architecture Recommendation

Of the options presented here, you should probably recommend placing the web server on a screened subnet and the application and database servers on the internal network as the best overall solution. This solution is the least expensive and the least resource-intensive, while providing a good level of network security.

If it were impossible to separate the web and application servers due to protocol or firewall issues, then placing them on separate hosts on the existing subnet or a new subnet would be an acceptable alternative. Avoid deploying all components to the internal network unless all other alternatives have been eliminated.