Crucial technologies and design principles
Since the summer of 1999, every new Microsoft software product that has come out of Redmond has used the .NET brand. The .NET brand comprises a set of Commercial Off-the-Shelf (COTS) applications that run on top of the Windows 2000 family of OSs. These applications include SQL Server 2000, Commerce Server 2000, BizTalk Server 2000, Exchange 2000 Server, Application Center 2000 Server, Mobile Information 2001 Server, and Internet Security and Acceleration (ISA) Server 2000. Microsoft also uses the .NET brand to signify an application-development architecture and methodology known as the .NET framework. Because Microsoft's intentions for the .NET brand are so broad, the technology will affect every IT infrastructure that's rooted on Microsoft technology or that uses mission-critical Microsoft applications.
When you plan your .NET infrastructure, you need to think about what security services you want to implement. A short list of essential security services should include strong authentication, data confidentiality and integrity protection (for data sent across the network and for data stored on any type of storage medium), nonrepudiation services, and antireplay protection. These services, and the technologies that provide them, are important for any infrastructure—not only .NET. Of course, .NET-specific security features also exist. However, I focus on securing the broad .NET infrastructure rather than on the security features inherent in .NET's various applications.
To implement these essential security services, you need to master a few key technologies and essential design principles. The way you set up your security zones and firewalls, Intrusion Detection Systems (IDSs), authentication, authentication delegation, public key infrastructure (PKI), and platform hardening is essential to your .NET infrastructure.
A Typical .NET Infrastructure
Figure 1, page 36, shows a typical .NET infrastructure. The components that require protection are the Web servers, the business object servers, the directories, the Certificate Authorities (CAs), the enterprise resource planning (ERP) system, the database, and the communication links between components.
Internal and external client access to the .NET infrastructure is purely Web based. A typical .NET infrastructure also includes different availability and load-balancing solutions. At the Web server level, the Network Load Balancing Service (NLBS) that ships with Win2K Advanced Server, Win2K Datacenter Server, and Application Center 2000 provides high-availability and load-balancing capabilities. The SQL Server database and the ERP systems are clustered. Notice that the infrastructure also includes a COM+ business object cluster. You use Application Center 2000 to integrate and administer this COM+ cluster and the Web server's NLBS. (For more information about high-availability solutions, see David Chernicoff, "Components of a High-Availability System," November 2000.)
At the time of this writing, an in-depth discussion about some of .NET's applications' features isn't yet possible because some details of those features are unclear. However, given that Microsoft is building the .NET infrastructure on top of Win2K, we can presume that .NET will exploit Win2K's security features. Also, given the increasing importance of Internet-based protocols, we can presume that access to .NET infrastructure components will mostly occur through standard Internet protocols (e.g., HTTP, SMTP, Lightweight Directory Access Protocol—LDAP).
Security Zones and Firewalls
When you plan your secure .NET infrastructure, you'll need to evaluate your current corporate security zones and firewalls. Your .NET infrastructure might require you to make some alterations. Even if the application you're building doesn't interact with external entities, you need to consider firewalls. Internal firewalls can protect sites or departments that have special security requirements and can restrict access to parts of your internal network (in the event that an intruder breaches the firewalls that are part of your external security perimeter).
Two common questions related to security zones and firewalls might arise as you're designing your infrastructure. The first question is, Where should I place my data and my servers? The security zone in which you should place your data and servers depends on what you're using the data or server for. Evaluate the confidentiality of the data that your servers process and store, then store confidential customer data in your trusted security zone.
If your organization uses a demilitarized zone (DMZ) in its topology, as Figure 1 shows, complications will arise. Of course, you should place only public data in a DMZ. However, the integrity of even public data requires protection. During the 2000 presidential elections, neither candidate would have wanted an intruder to alter the vote count that CNN published on its Web site. (On second thought, perhaps Al Gore wouldn't have minded.)
The second question is, How do I deal with Remote procedure calls (RPCs) and Secure Sockets Layer (SSL)/Transport Layer Security (TLS) traffic that moves between entities on opposite sides of a firewall? Many commercial Web sites use SSL/TLS to provide a basic set of security services to customers. This basic service set typically includes server authentication, client authentication, and integrity and confidentiality protection for data transmitted between the SSL client and server. To deal with SSL traffic at the firewall level, you can take one of two approaches: SSL tunneling, which Figure 2, page 38, shows, or SSL bridging, which Figure 3, page 38, shows. Most commercial firewalls support SSL tunneling, which uses the HTTP CONNECT message to tell the firewall to disregard the content of a particular SSL session and to simply forward the SSL packets. In an SSL bridging setup, the firewall is SSL-aware and holds a proper SSL certificate. The firewall acts as an SSL tunnel endpoint. SSL bridging might be a good solution not only to deal with SSL traffic at the firewall level but also to enable SSL on the public (i.e., untrusted) portion of the communication channel in conjunction with non-SSL-enabled applications.
RPCs let a client interact with a remote application. All the components involved in the .NET infrastructure that Figure 1 shows can use RPCs to communicate. Of particular interest to this discussion is the use of RPCs for intercomponent communication in Microsoft's distributed component models (i.e., Distributed COM—DCOM—and COM+) and for Active Directory (AD) replication.