Software Component Placement

At the heart of software architecture are issues involving where to deploy various components of each application. The architecture will vary greatly depending on whether the application and its data must reside on a single system or whether they can be run on multiple systems. We will discuss this in more detail as we look at single-system and multitier applications, including those used by internal users only. We will also look at issues surrounding administrator access to application components.

Single-System Applications

An application and its associated data are often designed to reside on a single host, and it might be impossible or impractical to split them among multiple hosts. In this situation, your major design decision is where the system should be located. Assuming that the system has external users, you will want to put it either on a screened subnet or possibly on your internal network and deploy a proxy server for it on a screened subnet. In both cases, external users are connecting to the system on your screened subnet and are unable to establish a connection directly to your internal network. You will just need to alter your firewall rules to allow external hosts to initiate a connection to only the screened subnet host using only the necessary port numbers.

Multitier Applications

Multitier applications present much more complex design issues than single-system applications. A multitier application consists of distributed components that can sometimes reside on the same system, but usually reside on separate systems. Multitier applications often have a user interface component (sometimes called the presentation component), a middleware component, and a database component. Sometimes the middleware and database components are combined, and sometimes several tiers exist. The considerations that impact the design of a secure architecture for multitier applications are often related to defining proper security zones, as we discuss in Chapter 13, "Separating Resources."

Generally, with multitier applications, the most sensitive tier is the one that contains the data, such as financial or personal information. This is the tier that should be the most isolated from users. If the application is designed with security in mind, users should never access the data directly; instead, they should interact with an intermediary application tier that accesses the data on their behalf. Therefore, avoid placing servers that contain data on publicly accessible networks. Instead, such servers should be located on private networks, and access to them should be tightly restricted.

Likewise, the tier that contains the user interface is the one that the users directly contact. This tier should be on a screened subnet (which is close to the external network), or perhaps accessible only by a proxying firewall. In any case, it's important to separate the top tier, with which the users interact, from the lower tiers, which contain the data and middleware. By keeping the tiers on separate security zones, you greatly reduce the risk that data will be compromised or that middleware code will be accessible if the top tier is compromised.

Administrator Access to Systems

Another important thing to keep in mind when designing software architecture is that others beside users will need to access your application's functionality and data. Database administrators, software developers, backup operators, and technical support personnel will all likely need to have some access to components of the application. Therefore, you will need to consider their needs when designing your application architecture.

User-Unfriendly Security

If you create a security architecture that becomes too unwieldy, IT staff members, just like regular application users, may try to circumvent security. Human nature is to do things easily and quickly. If you make tasks too complicated and time-consuming, people will look for ways to do them differently. Unfortunately, the alternative methods are likely to be less secure. Educating your staff about why the security measures are necessary should help. Always consider usability versus the risks in your environment.

Too Much Security Can Be a Bad Thing

Here's a simple example of how too much security can be a bad thing. I've seen instances in which web developers needed to follow several steps to update a single page. In some environments, the standard way to update a web page is to log on to a staging server and transfer the code to that box. Then you can initiate an additional connection from that box to the production box and transfer the code again, one file at a time. The purpose of doing this is to have the intermediate server log all connections and page updates.

The web developers quickly grew tired of having to do all of these logins and remember the complex passwords, so they instead copied their code onto a floppy, walked into the server room, and copied the code from the floppy to the server. By implementing a solution that was great from a network security standpoint but lousy from a usability standpoint, the solution failed to provide the level of security that the network administrator had been seeking.

External Administrative Access to Applications

Another problem that is difficult to handle is that of people from other companies who need administrative access to your application. In many cases, this is a developer or technical support person from your application vendor. This person can create a whole new set of security concerns. You will have to find a way to give this person access to your systems. This person might be using completely different protocols or accessing different hosts than those used by your application's users.

Although the application might be on a screened subnet that is directly accessible from the Internet, the development or staging systems that external personnel might need to access are traditionally located on your internal network. You might want to think of alternative ways to give access to external personnel, rather than permitting them to enter your internal network from the Internet. An example is a modem connection that gives outsiders access to limited resources on a single development server and no network access at all.

Applications for Internal Users Only

Throughout this chapter, we have focused on applications whose users were connecting to them over the Internet. However, you should keep a separate category of applications in mind: those that are used exclusively by internal users. Although most of these applications do not have any connectivity to external networks such as the Internet, some of them do. A good example would be an application that downloads weather data from a site on the Internet, stores it locally, and presents it to users on the internal network. Another example is the SETI@Home screensaver, which downloads data from the SETI project's servers at UC Berkeley and uploads results back to that server. Although such applications can certainly present a security risk, generally that risk is lower than that of applications that external users access.

Many of the security principles we discuss throughout this chapter still apply to applications that only internal users use. However, there are usually very few architectural decisions to make with such applications. They will normally be deployed to your internal network. The biggest architectural item to consider is whether the application can "pull" updates by initiating connections to the Internet host, or whether it is forced to accept "push" updates initiated by the Internet host. In the latter case, you should seriously consider placing the application on a screened subnet so that the external host can't establish a direct connection to your internal network. It's almost always safer to pull updates rather than to push them because you are in control of the operations when you're pulling. If you need to get updates for internal users, it's best to push or pull the updates to an intermediate box on your network; users can then interact with the intermediate box.