If you were to build a SharePoint Server 2007 server farm that in no way was connected to the Internet, it would be very secure. Sure, there could be compromises by people who have physical access or access via modems, but that wouldn’t be an issue fixed by a specific farm topology. What if you build a farm that is accessible only on your private, internal network protected by a firewall? Isn’t that the same? Don’t get a false sense of security because you have a firewall. A private network is only as secure as its weakest link. If you had another service on this private network that was compromised, your SharePoint Server 2007 installation would be at risk. Therefore, we are assuming that you have adequately secured your private network and did not create firewall rules to the Internet for SharePoint Server 2007. It should be reasonably secured.

The first step in allowing remote access to SharePoint Server 2007 would be to set up a VPN client. Because the only remote access to the servers would be via corporate VPN, this is considered a secure solution by even the most skeptical information technology security professionals. Figure 20-8 shows a private server farm and three ways of securely accessing the content therein.

Figure 20-8. A secure server farm would allow only local, VPN, or dial-up access.

Figure 20-8 also shows the example of using dial-up connections for secure access. This is quickly being replaced with VPN technology but is still a viable remote solution when security is paramount.

The upside to a private network implementation is that you can rest assured that your valuable content is safe. The tradeoff is loss of functionality. Because SharePoint Server 2007 is often an organization’s core for collaboration, a private network limits the accessibility of collaborative information. If you need a more robust intranet sharing topology, you should consider allowing external access over SSL.

A split-farm topology places a firewall between members of the farm to include the SQL server. This gets into an advanced implementation because a number of factors affect the functionality of the farm. The primary reason for splitting the farm into different subnets is to secure the SQL server. Figure 20-9 is a logical representation of a common farm topology when splitting subnets.

Figure 20-9. The SQL server is commonly behind the primary firewall.

The practice of placing the SQL server behind the primary firewall is to protect it from threats, such as the Slammer Worm. In reality, we often see it placed behind the primary firewall because less attention is spent securing the perimeter firewall than the internal firewall. Yes, both firewalls should be secured to the same level, but the real-world fact is that they are not. Placing the SQL server in a more secure subnet isn’t a perfect solution, however. If a hacker were to obtain access to your SharePoint Server 2007 farm from the Internet, he is now a short hop away from gaining access to your entire private network. We believe the best practice is to place the entire farm in the screened subnet.

Another common approach is to place an application server behind the primary firewall, thus securing your indexing functions and, more importantly, Central Administration. This does provide benefits, such as securing Web applications (e.g., the Records Center and Central Administration) and negating the need for indexing firewall rules (don’t forget, the indexer still needs to be able to connect to content sources!). But you may actually be opening up more vulnerability to your network than if you left the application server in the screened subnet. The risk may not be worth the extra security provided because NetBIOS traffic, or possibly server message block (SMB), still exists in most farm topologies. A prime example of this is query propagation. As can be seen in Figure 20-9, the WFE servers are also hosting the query role. Indexes are propagated continuously via file shares on the WFE servers. So, if you put the application server (hosting the index role) behind the primary firewall, you must now open firewall ports to allow file share access. This is generally bad practice, and most security professionals would advise strongly against it. For this reason, we think only the SQL server should be split from the farm if needed; in most cases, all members of the farm should be in the same subnet.

If you have a technically talented security team and you thoroughly understand firewall rules, auditing, and SharePoint Server 2007, you could most certainly implement your farm in a more advanced topology. Just remember to keep your installation as simple as possible while still meeting your technical requirements. The more barriers you raise between farm member servers, the more you will struggle with administrating that farm.

Another possibility for those who need Internet access to their intranet Web applications is to place the entire farm in the screened subnet. This simplifies the external access to your SharePoint Server 2007 server farm, but it does come at a price. First, you will need a SQL server dedicated to your screened subnet, if not to your SharePoint Server 2007 server farm. Many installations leverage an existing SQL server instance internally. There is the additional cost of hardware and software for that SQL server instance. Second, SharePoint Server 2007 is often used to connect to valuable corporate information that is stored in back-end systems, such as enterprise resource planning (ERP) or enterprise resource management (ERM) systems. If the entire farm is in the screened subnet, you will most likely need to create holes in the primary firewall to allow this access. A screened subnet intranet farm is shown in Figure 20-10.

Figure 20-10. Placing all members of the farm in the same subnet simplifies administration.

The bottom line to implementing collaborative Web applications with Internet access is that, eventually, data must traverse between the private network and the Internet. It is both good and bad. The Internet provides a medium to easily collaborate, but it also provides a medium that offers others access to that data. Your goal should be designing, implementing, and testing an intranet environment that takes the most secure route. Only you can know the route for you through research and testing.

We don’t think zones give you absolute isolation, but they do provide a reasonable amount of protection from intentional data compromise. Most extranets are a good place for zones and policies. Because most of your extranet users are basically trusted users, the level of security can probably be less than if users were not trusted. Essentially, you are designing a "best effort" Web-sharing platform when you leverage zones.

So what does a zone-leveraged farm topology look like? It will most likely have a single collaborative Web application that is accessed by one or more URLs. In addition, each of these URLs may be rendered by different servers, as seen in Figure 20-11.

Figure 20-11. You can publish different URLs of the same Web application on separate hardware.

Using multiple URLs will complicate things, there’s no doubt about it. Remember that, in the Web application best practices section of this chapter, we discussed that all alerts are sent on the default zone. By default, this zone is the first URL created for a Web application. In a zone-leveraged farm topology, you want to carefully design around this fact. The best practice is usually to create the most secure zone as the default zone. This allows the embedded URL in e-mails to be accessible by anyone from anywhere on the Internet. A common mistake is creating the default URL as the internal address. That usually is not accessible from the Internet, so embedded alert URLs for remote users will fail. The most secure zone in an extranet topology should probably be an SSL-enabled application and also the default internal URL.

Recall that zone names have nothing to do with security by themselves; they are simply a naming convention for you. The advantages to using multiple extended and mapped Web applications, leveraging zones, is that you can apply security polices to a set of users for a given URL. This allows you to create and define policies for a URL. In this scenario, it is common to deny Manage Lists And Browse Folders for extranet users. This is thoroughly documented on TechNet, but you can see an example of the Central Administration setting in Figure 20-12.

Figure 20-12. You apply policies to Web application zones for users or groups.

Part of your solution’s overall design will be determining the minimum set of rights for extranet users. We usually err on the side of being too restrictive and then loosen permissions as needed and approved. You probably won’t apply any policies to your trusted users because they already have full access on another URL. We have seen customers, with mixed success, apply more restrictive policies for their trusted users, but only on the external URL. For those customers, it provided a way to restrict and scope the management of SharePoint Server 2007 to users while they are only on the intranet LAN.

If security is paramount in your extranet design, you will probably want to create a server farm, including a dedicated SQL server instance and Active Directory, that is dedicated to your extranet. This design simplifies the creation of the farm, but often complicates the connections to other systems. Extranets almost always need connections to internal systems for reasons such as accounting or inventory, and they create more issues in the firewall connections and authentication to those sources. Carefully think through the following when you design your extranet solution:

One definite advantage to a physically isolated extranet solution is a single URL on a single zone. You can still leverage Web application policies to restrict extranet users. You can also mix the scenarios and split the extranet farm topology and leverage zones. Be warned: The complexity of your design increases dramatically when you do this. For example, extending your portal to the extranet via a different URL seems like a good idea, but how will users now get to their My Sites? Carefully plan and test any design that leverages both zones and physical isolation. Figure 20-13 shows an example of an extranet server farm consuming shared services from the internal provider. You would need to open external access to http://mysites or render it on the external server for full My Site functionality to external users.

Figure 20-13. You can build a second farm for isolation and still leverage interfarm shared services.

We find that a wrong example often instructs better than a good example. Therefore, we will begin with a wrong way to do Internet sites. Many organizations that are under budget constraints or simply lack the resources to build a second farm consider putting their WWW site into their collaborative farm. We can affirm that this is almost always a really bad idea. Figure 20-14 shows an example of what this would look like.

Figure 20-14. Multiple Web applications sharing a common configuration database in the same farm

This solution is appealing because many administrators plan to use a split-farm topology to secure their WWW traffic from their collaborative traffic. Figure 20-14 shows a split-farm topology. So what’s the problem? First, you would need to create another SSP to host services consumed by your WWW site, such as search. This seems simple enough and would provide modest content isolation if you ignore this cautionary scenario. But both your intranet and WWW Web applications must share a common configuration database, even if they have their own content databases and associated SSPs. Second, you should remember that all servers in the farm serve all Web applications. To isolate traffic, you should direct users to the correct box via DNS and disable the unneeded IIS applications on the appropriate server. Third, there is no method to granularly define Search and Excel Calculation Services server roles within a farm. Yes, you can define which servers perform these roles, but you cannot limit the use of these services for a specific service. Figure 20-15 shows a graphical representation of this limitation with search. Once again, Figure 20-15 shows you what cannot be done in a farm topology.

Figure 20-15. You cannot associate specific query servers with a specific Index server.

Using Figure 20-15 as an example, both WFE1 and WFE2 would have a complete index copy and service queries for SSP1 and SSP1 Indexers. Because of this topology limitation, and the fact all Web applications must share a configuration database, you should not use the same server farm for intranet and WWW Web applications. A better design, when resources are an issue, is to use your private, collaborative server farm to develop content and deploy to a dedicated SharePoint Server 2007 server farm for WWW consumption.

The best practice of developing code on a Dev system, testing it on a Test system, and deploying it to a Production system should be followed when possible. This section refers to an internal farm, and that farm can be your collaborative farm or a dedicated Test farm. The latter is preferable, but we do not know your resource limitations or organizational culture.

Most Dev systems for SharePoint Server 2007 are virtual machines that can be easily deleted and rebuilt, but you need to test that code and preview any content before deployment. To accomplish this, you will need a test SharePoint Server 2007 server farm. As was previously mentioned, you do not want to use your internal farm for WWW traffic. Therefore, you must create a new server farm, which will probably reside in your screened subnet. Leveraging the Publishing Infrastructure, many companies simply edit content in-place while using development systems for custom code. This reduces the involvement of information technology for custom WWW content. But many organizations require private viewing of WWW content by managers, executives, and their legal department before deployment on the Internet-facing Web site. We recommend content deployment from one of your internal server farms to your external, dedicated WWW server farm. Figure 20-16 shows an example of two distinct server farms with content deployment between them.

Figure 20-16. You can deploy content from a secure farm to a less secure farm.

Because it is a one-way connection during content deployment, the security risk of transferring content is very low. Be aware that this mechanism of content deployment is meant for Web content and not customizations such as Web parts, workflows, and policies. In fact, it should probably be used only for pages and images. But pages and images constitute the majority of updates on most WWW servers, so this method of content deployment is still a very viable solution for most companies.