When it comes to applications and their various elements, the best starting point for considering application security is Microsoft TechNet. There's an article there called "Three-Tier Security in an E-commerce Environment" (http://www.microsoft.com/TechNet/ecommerce/msf3sec.asp) that provides an excellent overview of the key aspects of securing distributed applications.
The three-tier security model described in this article consists of three layers:
The presentation services layer provides the user interface that presents information to, and collects information from, the user. For Web-based applications, this interface typically consists of HTML/DHMTL and Active Server Pages (ASP).
This interface should be the only point of contact with the user. In addition to providing the user interface, the presentation services layer can convert data for use by the business logic or data services layers or perform the reverse by converting internal data for display to the user.
TIP
For Web applications with database back-ends, consider having the client make HTTP calls to a COM+ component, which in turn makes a direct call to the database. This design is inherently more secure than one in which the client makes an HTTP call directly to the database via ADO.
In general, the presentation layer:
The business services layer implements component-based business logic that handles the infrastructure by using integrated application services. These services can include IIS, ASP, COM+, and Message Queuing. Access to the data services layer is accomplished by wrapping OLE-database/ODBC technologies in components, such as ADO.
Although the data services layer typically consists of a database management system (DBMS), it can also include other data store mechanisms, such as directory services, e-mail stores, and spreadsheets. For our purposes, the data services layer consists of Microsoft SQL Server.
TIP
Isolate your database from the Web or component servers by running it on its own server. Hackers have exploited stored procedures, which run as localsystem, to gain access to the operating system.
As Michael Howard indicates in his book, a common security weakness in this tier is implementing weak security on the database and putting too much faith in mechanisms that are implemented in the presentation and business services layers. This flawed scenario is based on the assumption that since the only direct communication with the database is from the business services tier, strong security is not required on the database.
Although it's not the goal of this chapter to delve into the labyrinth of designing secure network topologies, it is worthwhile to mention firewalls and the use of a Demilitarized Zone (DMZ), also called a perimeter network. The firewall industry provides an unlimited number of options for monitoring, filtering, and blocking inbound and outbound network traffic.
NOTE
It's important to note that even though packet-filtering routers and proxy servers do provide a measure of filtering, they are not firewalls and should not be regarded as the most optimal security solution for traffic monitoring and control.
If firewall vendors provide a staggering number of options for securing your network, the myriad of possibilities for architecting secure network topologies is even more overwhelming. The next illustration, Figure 12.3, shows a fairly simple and fairly common topology that employs a single firewall. (For the sake of simplicity, the topology shown does not include routers, DNS servers, or remote access servers.)
Figure 12.3 Network topology that uses a single firewall and three network adapters
The advantages of the popular configuration shown in Figure 12.3 are (relative to other configurations) that it's the least expensive, the easiest to configure, and the easiest to maintain. The greatest disadvantage of this configuration is that it provides a single point of failure. A hacker who compromises the single firewall has access to all your corporate assets. This leads us to the next topology (Figure 12.4), which implements a DMZ by using two firewalls to provide a buffer zone between the publicly accessible servers and the corporate network.
Figure 12.4 A topology that uses two firewalls to create a DMZ
Consider this: if you make the expenditure in effort, time, and money to build a highly available Web server cluster with Application Center—which eliminates the single point of failure for application access—does it make sense to rely on a security perimeter that has a single point of failure? Probably not.
The example we've provided is not the definitive topology, but it gives you a good basis for considering the type of design you may require to secure your Application Center cluster(s) and back-end servers. Regardless of the topology that you implement, the objective of creating a secure perimeter remains the same—to segregate internal and external traffic as much as possible by using electronic and physical techniques, without downgrading performance. One of the major challenges in architecting a secure site is maintaining a reasonable level of performance without compromising security.
WARNING
If users inside a secure network have a modem at their desk that gives them external access, your firewall system is compromised by default.
Some security strategies to consider are:
NOTE
These clusters must host different applications.
TIP
If you have invested in a firewall, or are going to invest in one, ensure that it's properly configured. Get the firewall vendor or a security professional that's familiar with the firewall technology in question to install the firewall.