Network engineers face a constant battle in today's network environments as demands for data and simplified communications continue to grow. They must find a way to manage the delicate balance between simplifying the delivery of information to end users with the ever present mindset of ensuring that the delivery will be secure. Without ensuring that data can maintain security levels as outlined in company security policies, it would not be wise to publish data to areas of the network that introduce widespread exposure to unauthorized individuals.
Real World Secure Access to SharePoint Server 2007 Sites
The decision to publish SharePoint data to the Web using ISA Server 2006 should only come after a good amount of time has been spent evaluating the data to be published and the depth of the security measures that should be in place. In some cases you may find that the data to be published does not pose any type of vulnerability to the company's intellectual property, brand, or personal privacy of the employees. In this case, publishing data without being overly concerned for data security is acceptable.
In many cases, however, data security is not a negligible piece of the deployment scenario. Rather, it is the key piece. In real-world implementations, the focus on security should never be absent from the task at hand. It is always best to error on the side of caution and work toward a solution that offers users access to pertinent information without jeopardizing company property. Microsoft's intention with the ISA Server 2006 product was to provide a means of facilitating the publication of internal resources to external users while still maintaining a blanket of security that protects the company and its property. The consistent challenge in real-world deployments is to find a happy medium between data security, ease of access, and ease of implementation.
In a situation such as this, you must always keep in mind that unmanaged devices such as Windows Mobile 5 Smartphones and Pocket PCs do not fall under the same constraints and restrictions of desktops and laptops that have been added as members of the domain. These devices, though manageable through the Microsoft Exchange server deployment, are readily accessible to not only the employees who own them but also to the malicious individuals looking to obtain any piece of company information. As with any deployment that involves external roaming users, security awareness training for the end-user population is a major factor in the success of the deployment.
Securing resources on the internal network can be accomplished using any of three common solutions: 1) the edge firewall solution, 2) the multi-homed firewall solution, and 3) the back-to-back firewall configuration. Figure 19-1 shows a simple comparison of these firewall solutions.
Figure 19-1: Comparison of the three common firewall security implementations
Although our discussions in the text will focus on understanding the back-to-back firewall configuration, the practice and procedure for configuring SharePoint is consistent across any of the three firewall scenarios.
The edge firewall is by far the simplest and cheapest solution as it only involves a single firewall device that established a clear line between the internal network and the Internet. The down side is that there is a single point of attack and failure.
The multi-homed firewall, like the edge firewall, involves only one hardware device but it has at least one additional network card. The additional network card provides the opportunity to place resources on an external or perimeter network. However, there is still a single point of attack and failure in this topology.
The back-to-back firewall, as you might have guessed, is the most expensive one, but it is also the solution that affords the highest level of security and the lowest level of granularity with our access controls. Table 19-1 outlines the pros and cons of each firewall implementation.
Not as secure
Should never be member of a domain.
Not as expensive
Should never be a member of a domain.
High cost High knowledge level
Only internal firewall should be considered for membership in the internal Active Directory domain.
Before you learn about the infrastructure requirements for securely publishing SharePoint to Windows Mobile users, let's look at the network pieces that a corporation might already have employed in delivering a secure mobile messaging solution.
Solutions that involve the configuration of a perimeter network with two third-party firewall devices often include front-end servers placed into the perimeter network while the back-end storage servers are neatly tucked away on the internal network. The firewall configuration involves a loose set of firewall policy settings on the external firewall that allows traffic from any source terminating at the front-end servers. The internal firewall, on the other hand, protects the internal resources with a much more stringent set of firewall policy settings that allows traffic to pass through if the source of the traffic is a server in the perimeter network and the destination is a specific server on the internal network. This is illustrated in Figure 19-2.
Figure 19-2: A messaging infrastructure deployed with two third-party firewall devices
Deploying SharePoint in this fashion would be very similar. In fact, the external firewall access policy would only need to be extended to allow incoming traffic over port 80, and possibly port 443, to the front-end SharePoint server or Network Load Balancing (NLB) device. The internal firewall, however, would require an additional rule to allow the front-end SharePoint server to communicate with an internal SQL Server 2005 server. The default port of 1433 would need to be permitted from a source of the front-end SharePoint server to the back-end database server. This is illustrated in Figure 19-3.
Figure 19-3: Deploying a SharePoint front-end server in a perimeter network with a back-end SQL server
If you're concerned with the idea of placing your SharePoint server in the perimeter network, then be assured that placing it on the internal network is even more unwise. The ramifications of placing it amongst the other internal resources are significant in that both the external and the internal firewall would have to be configured to allow Internet clients to pass through to the internal network. Indeed, unwise. So what should you do? Use Microsoft Internet Security and Acceleration (ISA) Server 2006 as the solution.
ISA Server 2006 comes in Standard and Enterprise Editions. The core difference in the editions lies in the scalability opportunities of Enterprise Edition. Standard Edition is limited to a single server with up to 4 CPUs and 2 GB of RAM. Enterprise Edition, on the other hand, has no hardware limitations and can scale as part of a Network Load Balancing (NLB) cluster with a maximum of 32 nodes. The combination of the size of the existing infrastructure and your projections for growth will determine which edition is right for you.
What ISA Server 2006 provides is a multi-tasking application that can exponentially enhance the security of traffic within, across, or directed to resources on your corporate network. ISA Server 2006 can function in one or all of three core roles:
Web Access Protection
Branch Office Gateway
Secure Application Publishing
|More Info|| |
You can read more about ISA Server 2006 at http://www.microsoft.com/isaserver.
The secure application publishing feature of ISA Server 2006 allows organizations to protect internal servers like Exchange, SharePoint, and other Web application servers. ISA Server 2006's publishing rules can be broken down into two forms: Web publishing and server publishing. Web publishing rules are distinguished from server publishing rules in that Web publishing rules are geared toward the traditional Web-based type applications like Web servers, mail servers, and ftp servers. Server publishing rules are used when Web-based applications, we will focus on the use of Web publishing rules.
Web publishing rules provide a host of advantages including:
Reverse proxy for internal resources
Application layer inspection of connections to published services
Pre-authentication of traffic to published services
Support for RADIUS, LDAP, SecurID, and more
Publishing multiple sites to a single IP address
SSL bridging and SSL tunneling
Site publication scheduling
Reverse caching of content for external requests
By the end of this chapter, you will see just how good things can be when ISA Server 2006 is part of your network infrastructure. Microsoft has done a great job of allowing administrators to secure deployments with an easy-to-use interface and a helpful set of wizards to facilitate application publishing.
It is a common debate among IT security professionals as to whether firewall applications such as ISA Server 2006 are as secure as hardware-based firewall devices. The raw answer to that debate is that a firewall is only as secure as it is configured to be. But if that isn't enough to satisfy your curiosity, please visit http://www.microsoft.com/isaserver/hardware to see how Microsoft has worked with several vendors to bring the ease of ISA packaged with a hardware platform as a security appliance.
Once you have decided that ISA Server 2006 should be a part of the network infrastructure, you must decide where and how you will deploy it. As a firewall product, ISA Server 2006 fits nicely into any of the three firewall deployment scenarios mentioned earlier; edge, multi-homed, or back-to-back. When a SharePoint site is published to the Internet using ISA, it is protected because the true name and IP address of the SharePoint server are never exposed to the external, requesting user. Users will submit their requests to the ISA server which, in turn, will authenticate the user if necessary and then forward the request to the SharePoint server.
For small organizations, and especially those built off of Microsoft Small Business Server 2003 Premium Edition, ISA is positioned to be the Internet edge firewall that provides a barrier of protection between the Internet and the intranet. As Figure 19-4 shows, ISA would be connected to the Internet and the intranet as it inspects all outbound and inbound traffic.
Figure 19-4: ISA Server as an edge gateway
Many large companies have already invested time, money, and manpower in building a secure network environment around the back-to-back firewall configuration. This does not preclude them from needing or wanting to use ISA Server 2006 in their infrastructure. As shown in Figure 19-5, ISA Server 2006 can slip nicely into an existing perimeter network.
Figure 19-5: ISA Server 2006 as a compliment to an existing firewall configuration
This configuration minimizes the changes that are needed on the internal and external firewalls but adds all of the elements of security that ISA provides. All resources can now remain on the internal network. ISA Server 2006's reverse proxy features will introduce a "you wait and I'll go get it" method of handling traffic. ISA will receive the initial request as the internal firewall has allowed the passing of the traffic to ISA. ISA can then authenticate the user and proceed to retrieve the content on behalf of the authenticated user.
Another common practice in IT security is to deploy firewalls from different vendors in the front-end and back-end solution. If such is the case, it makes great sense to install ISA Server 2006 as the internal or front-end firewall, as shown in Figure 19-6.
Figure 19-6: ISA Server 2006 as a back-end firewall
From small, low-budget organizations to large, well-funded organizations, there is a firewall deployment right for every situation. Whether it be a single firewall, multiple firewalls, third-party devices, or ISA, planning your infrastructure to support the publication of SharePoint data is a must.