|
After you have considered the basic issues for connectivity to your infrastructure, it is appropriate to begin to explore and plan for other areas that might need protection through your DMZ design. There are nearly infinite possibilities for incorporation into your overall design, including the ability to protect not only the internal network but e-commerce, business partner, and extranet connections. Additionally, your enterprise may be involved in the creation of hosted services, in which you are providing protection to Web, FTP, or other servers that require unique protections and the ability to provide management capabilities as well. This section visits a number of those potential areas that may be appropriate for coverage in the overall DMZ design.
Business partner connections can provide a unique challenge to the DMZ designer. In the case of business partners, there is often a requirement to provide access to and from enterprise resource planning (ERP) packages such as those from Oracle, PeopleSoft, Microsoft's Great Plains software, and others that are currently in use to provide project management, packaging, and collaboration tools to members of multiple organizations. One of the challenges that can arise rather quickly is the question of how to appropriately allow connectivity between organizations with proper authentication and protection of information for all parties. Many of the basic designs that we discussed previously, including the use of specifically screened subnets for VPN access, provide partial solutions to these issues, but each case also requires an in-depth evaluation and most certainly collaboration between the DMZ designers involved to appropriately channel the access entry points, remote access if needed, and authentication of the users from various entities to maintain your security requirements.
Of the possibilities that can be explored in relation to business partner connections, extranets provide a great flexibility in their implementation and use by an enterprise. Extranets can be Web browser-based information stores, can allow contact by customers seeking catalog information, and can allow real-time or close to real-time tracking capabilities of shipments and the supply chain. Additionally, the extranet can be configured for collaborative efforts and used between business partners for the ultimate capability to share information and processes while working on joint projects. Extranets, much like the discussion earlier of VPN accesses, will usually be placed on isolated DMZ segments to segregate them from the hosting network's operations. These DMZ segments will house and host machines that will allow for the use of ERP software and the warehousing of information in common to the project. The use of extranet applications is most often Web browser based for the client that is seeking the information and not normally for storing highly sensitive data, although the data should still be protected.
Customer-based Web and FTP sites that are provided or hosted by your organization can again cause the DMZ design to change in some way. Hosting the information on customer-based sites requires the same processes that we looked at in relation to hosting our own Web and FTP servers in the DMZ, with an additional requirement that some sort of remote management capability be provided for the customer to administer and monitor the sites. This hosting can lead to a plan that involves use of modems or other devices not protected by the DMZ design and must be carefully explored. Ensure that your DMZ design will not be compromised by the methods used to allow remote access to these servers and their administration by the client customer. It may be appropriate to host customer-based operations in a separate DMZ segment, away from your operation altogether.
Among the possibilities that we may include in our overall DMZ design scheme is hosting or supporting e-commerce services. As with other DMZ design considerations, the DMZ segment hosting e-commerce services must provide a level of isolation that protects such things as credit card information and transactions. It can include restrictions that block access from noncustomer address ranges, and it can also include restrictions on traffic to limit it to ports for Web services and Secure Sockets Layer (SSL) to protect the internal records being generated by the action of the services. E-commerce activities should also include restrictions that disable IP forwarding between servers and segregation of services such as noncritical database information among different servers for load balancing and to distribute security to a higher degree. No contact should be allowed between the e-commerce DMZ servers inbound to the internal network.
E-mail services are among the most used (and abused) services that are provided through a combination of access points, both external and internal. E-mail server front ends should be located in segregated DMZ subnets, and the firewalls allowing access into and out of the e-mail subnet should incorporate strong ACL rule sets that only allow communication on appropriate ports internally and externally. This construction should also include mail relay settings on the DMZ mail server that do not allow relaying of mail from any network other than the internal network, which limits the potential that your front-end server might be used for spamming. The external firewall that allows access to the e-mail front end should be configured to block outbound SMTP traffic that did not originate at the front-end server, and the front-end server should be configured to only relay mail to accepted internal addresses while rejecting all other communications. Great care must be used in the proper configuration of mail servers from all vendors when access is granted in any fashion from the external networks.
|