設計範例：公司部署 (SharePoint Server 2010)
適用版本： SharePoint Foundation 2010, SharePoint Server 2010
上次修改主題的時間： 2017-01-18
本文說明邏輯架構元件的實際實作，以達成可行設計。本文將與下列設計範例合併使用：
設計範例：使用傳統驗證的企業入口網站
設計範例：使用宣告式驗證的企業入口網站
若要下載其中一項模型，請參閱 SharePoint Server 2010 設計範例：使用傳統驗證或宣告式驗證的企業入口網站(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x404)(可能為英文網頁)。
本文內容：
關於設計範例
整體設計目標
伺服器陣列
使用者、區域及驗證
服務
製作及發佈的替代作法
管理網站
應用程式集區
Web 應用程式
網站集合
內容資料庫
區域及 URL
區域原則
這兩個設計範例說明 Microsoft SharePoint Server 2010 一般在企業中的部署情況。這兩個設計範例幾乎適用於所有邏輯架構元件，並說明這些元件如何應用在整體設計中。這兩個設計範例說明的是相同服務和網站，但使用不同驗證方法，如下：
傳統驗證：此設計範例提供將網站從 Microsoft Office SharePoint Server 2007 升級至 Microsoft SharePoint Server 2010 的方式。此範例使用的是傳統驗證，而以 Windows 驗證方法存取網站。每個驗證方法使用不同區域。SharePoint 網站使用 Windows 驗證，防火牆或閘道產品則可設定為使用表單驗證，以蒐集要轉送至 SharePoint Server 2010 的 Windows 認證。合作夥伴員工帳戶則新增至公司目錄。
宣告驗證：此設計範例使用新的宣告驗證模型。單一區域實作多個驗證提供者及驗證類型。宣告驗證支援表單型驗證、SAML 權杖型驗證及 Windows 驗證。此設計範例在新增合作夥伴公司時使用 SAML 權杖型驗證，直接比對合作夥伴目錄進行驗證。其中提供許多提供者選項供合作夥伴員工帳戶使用。
請使用最符合您驗證需求的設計範例。
本文說明範例設計目標，並解釋如何使用範例所示的邏輯架構元件來達成這些目標。
關於設計範例
設計範例以虛擬公司 Fabrikam, Inc 的企業部署進行說明。此部署涵蓋兩個伺服器陣列。其中一個伺服器陣列架設該公司的內部網路及合作夥伴網站，另一個伺服器陣列則架設公司網站 (www.fabrikam.com)。本節其餘部分將說明這些頂層網站。
內部網路
公司內部網路包含下列網站：
已發佈的內部網路內容 (例如 HRweb)
共同作業小組網站
我的網站
這些都是員工每天使用的內容和共同作業網站。這些應用程式各自都代表特殊的內容類型。每種類型的內容：
強調 SharePoint Server 2010 的不同功能。
主控不同資料特性的資料。
會因不同用量設定檔而異。
需要不同的權限管理策略。
因此，上述每個應用程式的設計選擇都是要最佳化每個應用程式的效能及安全性。
服務應用程式的設計將結合上述三個應用程式，以提供：
在應用程式之間導覽
整體企業搜尋
共用設定檔資料及企業中繼資料
下圖說明這三個組成公司內部網路的應用程式：
.gif "內部網站")
本圖中的 URL 來自傳統驗證設計範例。
合作夥伴 Web 應用程式
合作夥伴 Web 應用程式會架設可供外部使用的網站，以與合作夥伴公司和個別合作夥伴進行安全的共同作業。這個應用程式的目的是要讓員工輕鬆地建立網站以進行安全的共同作業。合作夥伴將無權存取伺服器陣列上其他類型的內容。區域和服務應用程式均針對此目的而設計。
在設計範例中，合作夥伴 Web 應用程式與內部網路內容架設在同一伺服器陣列。
公司網際網路網站
公司網際網路網站是公司的網際網路平台服務。其中的內容設定為以唯讀權限匿名存取，讓客戶可使用這些內容。之所以選擇這種應用程式的設計，主要原因包括：
**內容隔離：**客戶無法存取伺服器陣列上任何其他類型的內容。
**目標式管理：**對管理網站的員工提供經過驗證的存取權，使其可執行管理及製作工作。
**安全的內容製作及發佈：**合作夥伴 Web 應用程式伺服器陣列 A 上架設單獨網站集合，做為製作之用。這可讓內部與遠端員工，以及專門從事網站開發或內容製作的編輯合作夥伴，進行安全的共同作業和內容開發。內容發佈功能設為自動將第一個伺服器陣列上製作網站集合的內容，發佈至第二個伺服器陣列的實際執行網站集合。下圖說明發佈程序。
.gif "已發佈網站")
整體設計目標
設計範例提供了 SharePoint Server 2010 功能在數種常見應用程式類型上的實際實作。本文將討論每種個別應用程式的設計實作。設計範例的主要設計目標包括：
以最少的伺服器陣列架設企業一般所需的最常見網站類型，也就是，內部網路、外部網路及網際網路。
在設計環境時，建立一個可以成長的架構。個別應用程式的設計決策將不會妨礙新增其他應用程式。例如，初始部署可能只包括共同作業小組網站，或只包括構成內部網路的三個應用程式 (小組網站、我的網站及已發佈的內部網路內容)。使用類似的邏輯架構設計，您可以將應用程式新增至解決方案，而不會影響初始應用程式的設計。換言之，此設計不包含限制環境使用的設計選擇。
在不影響不同網站類型的內容安全性之下，為多個使用者群組提供存取權。來自不同網路區域 (內部網路及外部網路) 且使用不同驗證提供者的使用者都可以參與共同作業。此外，使用者只能存取他們可以存取的內容。依照類似的邏輯架構設計，可讓您對位於多個位置以及具有不同目標的使用者提供存取權。例如，您的初始設計可能只是要讓內部員工存取。不過，使用類似設計，您也可以讓遠端員工、合作夥伴員工、合作夥伴公司及客戶進行存取。
確定設計可用於外部網路環境。謹慎地為伺服器陣列作出設計選擇，以確保其能夠安全地部署於周邊網路。
本文其餘部分將討論出現在設計範例中的每個邏輯元件 (從上到下)，並討論應用於設計範例的設計選擇。此方法的目的在於示範根據應用程式設定邏輯架構元件的不同方式。
伺服器陣列
本設計範例使用兩個伺服器陣列。本節說明影響公司環境中所需伺服器陣列數目的授權需求，並說明設計範例所示的伺服器陣列拓撲。
授權需求
若要同時架設內部網路內容及網際網路網站，至少必須具備兩部伺服器。這樣才能滿足授權需求。
SharePoint Server 2010 有下列兩種伺服器授權可用：
**Microsoft SharePoint Server 2010，伺服器授權：**這個授權適用於共同作業內部網路內容。此授權需使用用戶端存取授權 (CAL)。如果所建立的網站要用於合作夥伴共同作業，則必須確認是否為合作夥伴員工購買了必要的 CAL 數目。
**Microsoft SharePoint Server 2010 for Internet Sites：**這個授權只適用於網際網路對向的網站。這個授權不需使用 CAL。如果所建立的網站要用於合作夥伴共同作業，您不需要購買額外的 CAL。不過，您無法建立專供您員工使用的網站。
注意
這些授權無法在同一部伺服器電腦或同一個伺服器陣列中上合併使用。
在上述授權選擇下，最重要的設計選擇就是決定哪個伺服器陣列負責主控合作夥伴 Web 應用程式。在設計範例中，第一個伺服器陣列負責主控內部網路內容，第二個伺服器陣列負責主控公司網際網路網站。根據授權條款，任何一個伺服器陣列都可以主控合作夥伴 Web 應用程式。
因為有兩個伺服器陣列可選，要決定哪個伺服器陣列應該主控合作夥伴 Web 應用程式的一般設計準則包括下列：
**共同作業的本質：**如果合作夥伴外部網路網站的主要目的，是要安全地傳達資訊給許多合作夥伴，則網際網路伺服器陣列會是最經濟的選擇。另一方面，如果主要目的是要與小部分的合作夥伴員工共同作業，則內部網路伺服器陣列可能是較好的選擇。請選擇能讓您根據預定角色進行最佳化的伺服器陣列。
**合作夥伴員工人數：**如果要與許多合作夥伴員工共同作業，而降低成本十分重要，您可以使用網際網路網站授權，將共同作業和匿名內容安全地架設在網際網路對向的伺服器陣列上。
在設計範例中，合作夥伴 Web 應用程式將用於與合作夥伴公司進行密集共同作業，包括公司網際網路網站的開發及分階段部署。將合作夥伴 Web 應用程式放在第一個伺服器陣列，可讓組織根據每個伺服器陣列的預定用途 (亦即共同作業與唯讀內容)，分別進行最佳化。不過，這兩個伺服器陣列都能主控合作夥伴 Web 應用程式。
本設計範例包括了 Microsoft Office Web Apps。Office Web Apps 需使用 Microsoft Office 2010 用戶端授權。換言之，如果您讓 Office Web Apps 可供合作夥伴使用，則還必須為他們購買 Office 2010 用戶端授權。
伺服器陣列的拓撲
設計範例中的每個伺服器陣列都是由具有下列拓撲的伺服器所組成：
兩部前端網頁伺服器
一部應用程式伺服器
兩部資料庫伺服器 (叢集或鏡像)。
本設計範例說明 SharePoint Server 2010 的邏輯架構，如下所示：
在前端網頁伺服器間鏡像所有網站。
管理中心網站安裝在應用程式伺服器上，讓使用者無法直接存取。
實際上，除了有時會有增加容量和提高效能的需求外，伺服器電腦的數目及伺服器陣列拓撲對邏輯架構而言並不重要。邏輯架構可以設計成與伺服器陣列拓撲無關。效能及容量規劃程序可協助您調整伺服器陣列的大小，以符合效能及容量目標。如需詳細資訊，請參閱＜效能及容量管理 (SharePoint Server 2010)＞。
擴充超過兩個伺服器陣列
您的營運規模可能需要超過所示的兩個伺服器陣列。適合架設在專用伺服器陣列中的網站包括下列：
我的網站：許多擁有大量員工或學生的組織都會選擇將「我的網站」架設在專用伺服器陣列中。
製作網站及臨時網站：如果已發佈內容極為複雜或規模極大，可能最好使用 Microsoft SharePoint Server 2010 for Internet Sites 授權，將製作網站及臨時網站架設在專用的單一伺服器陣列中，才能獲得較佳最佳化效益。例如，對包含設有標記之中繼資料的內容進行發佈，將提高製作伺服器陣列與已發佈伺服器陣列之間的服務設計範例複雜性，包括在伺服器陣列之間共用服務，以及決定多用途伺服器陣列中其他 Web 應用程式類型之間如何共用服務等問題。
合作夥伴網站：在安全性及隔離需求之下，可能保證合作夥伴共同作業可在專用伺服器陣列上進行。這可讓僅限內部使用的內容及與外部合作夥伴合作開發的內容之間能有實體隔離。
使用者、區域及驗證
當您在 SharePoint Server 2010 中建立 Web 應用程式時，必須選擇宣告式驗證或傳統模式驗證。驗證模式將決定 SharePoint Server 2010 如何在內部使用帳戶。下表摘要說明這兩種方法。
驗證類型 |
描述 |
建議 |
傳統模式驗證 |
SharePoint Server 2010 會將使用者帳戶視為傳統 Windows Active Directory 帳戶。這種模式支援下列驗證通訊協定：Kerberos、NTLM、基本、摘要及匿名。 不支援表單型驗證。 一個區域僅能設定使用一種驗證方法。 |
若將環境從 Microsoft Office SharePoint Server 2007 升級，建議使用傳統模式，因為這種情況下，表單型驗證不是必要條件。 如果您正執行升級且選取傳統模式驗證，就不需要執行使用者移轉。 |
宣告式驗證 |
SharePoint Server 2010 會將使用者帳戶視為宣告身分識別。Windows 帳戶會自動轉換成宣告身分識別。這種模式還會支援表單型驗證，及比對信任身分識別提供者來進行驗證。 單一區域可設定使用多種驗證類型。 |
建議在新的 SharePoint Server 2010 部署上使用宣告式驗證。如果升級 Office SharePoint Server 2007 解決方案時需使用表單型驗證，就必須使用宣告式驗證。 |
本文所討論的兩種設計範例代表了這兩種驗證方法。下列小節將特別討論這兩種設計範例如何使用驗證。
傳統模式驗證設計範例
使用傳統模式驗證的設計範例採用一個區域使用一種類型的傳統驗證方法，這是舊版所用的方法。因此，此範例提供一個從 Office SharePoint Server 2007 升級至 SharePoint Server 2010 的方式。
在此警告您，傳統模式不支援表單型驗證。使用傳統模式驗證時，所有已驗證的帳戶必須位於 Active Directory 網域服務 (AD DS) 內。建議遠端存取網站的使用者最好在防火牆或閘道產品上使用表單型驗證，以蒐集要轉送至 SharePoint 伺服器陣列的 Windows 認證。
傳統模式範例說明四種類別的使用者，每種類別使用者各指派至不同區域。在每個 Web 應用程式內，最多可建立五個區域並使用其中一個可用的區域名稱 (預設、內部網路、網際網路、自訂或外部網路)。
下表說明傳統類型設計範例所規定的區域、使用者及驗證類型。
.gif "列出區域、使用者及驗證的表格。")
搜尋編目帳戶需存取至少一個使用 NTL 驗證的區域。如果供使用者使用的區域中沒有一個設為使用 NTLM，請將自訂區域設為使用 NTLM 驗證。
宣告式驗證設計範例
建議所有新的 SharePoint Server 2010 部署採用宣告式驗證，且需使用表單型驗證的 Office SharePoint Server 2007 解決方案在升級時，也必須使用宣告式驗證。宣告式驗證除了可提供標準的 Windows 驗證方法外，它還能允許您比對其他目錄 (例如，Windows Live ID)、Active Directory Federation Services 2.0，或支援 SAML 權杖及 WS 同盟通訊協定的協力廠商身分識別提供者，來進行驗證。
在宣告式驗證設計範例中，宣告式驗證用於共同作業伺服器陣列。宣告式驗證允許同一個區域使用多種驗證類型。本設計範例即讓所有驗證類型使用「預設」區域。下表說明本範例中規定共同作業伺服器陣列使用的區域、使用者及驗證類型。
.gif "列出區域、使用者及驗證的表格。")
在設計範例中，「已發佈的內部網站內容」網站、「小組網站」及「我的網站」僅供員工 (包括位於內部及外部網路的員工) 存取。本設計範例僅實作一個內部及外部網路皆可使用的 URL (使用的是 SSL)，且使用 Active Directory 帳戶。如果需要，LDAP 可以與表單型驗證或 SAML 搭配使用，不過這需要額外設定。
在本設計範例中，合作夥伴 Web 應用程式代表的是可讓合作夥伴員工及合作夥伴公司存取的外部網路網站。在此情況下使用宣告式驗證，則需要在一或多個 Secure Token Service (STS) 中設定信任。使用下列一種方式即可取得信任。
SharePoint 伺服器陣列可設為信任外部 STS，例如，與 Windows Live 相關聯的 STS (用以驗證個別合作夥伴)，或是位於合作夥伴公司內的 STS (用以直接比對合作夥伴目錄進行驗證)。
位於公司環境內的 STS 可以設為信任外部 STS。這種關係必須由兩家公司的管理員明確建立。在此情況下，SharePoint 伺服器陣列設為僅信任位於其自己公司環境內的 STS。此內部 STS 會驗證從外部收到的 STS，然後發行權杖，讓合作夥伴使用者可存取 SharePoint 伺服器陣列。這是建議方式。
另一種替代實作宣告式環境驗證合作夥伴的方式，就是使用表單型驗證，並使用單獨儲存區 (例如資料庫) 管理這些帳戶。
如需實作宣告式驗證環境的詳細資訊，請參閱下列白皮書：Windows 宣告式身分識別：Active Directory Federation Services 2.0、Windows CardSpace 2.0 及 Windows Identity Foundation 簡介(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196776&clcid=0x404)(可能為英文網頁)。
在宣告式驗證設計範例中，已發佈伺服器陣列設為使用傳統模式驗證。替代作法是讓已發佈伺服器陣列也使用宣告式驗證，並實作另一個區域供匿名使用者使用。此設計的重點，就是使用單獨區域供匿名使用者使用，讓唯讀環境與讀寫環境無論實作何種驗證模式，兩者之間能有所隔離。下表說明已發佈伺服器陣列的區域、使用者及驗證類型。
.gif "列出區域、使用者及驗證的表格。")
同樣地，搜尋編目帳戶需存取至少一個使用 NTL 驗證的區域。如果需要，可在宣告式驗證區中加入 NTLM 驗證。在傳統模式中，如果供使用者使用的區域中沒有一個設為使用 NTLM，請將自訂區域設為使用 NTLM 驗證。
區域
當您設計區域時，有多個對部署成功與否十分重要的重要決策。這些決策包括下列區域的設計和設定決策：
預設區域
供外部存取的區域
下列小節將說明設計範例中所採用的決策。
預設區域的設定需求
最需要仔細考量的區域就是「預設」區域。SharePoint Server 2010 對於「預設」區域的設定有下列需求：
當使用者要求無法與區域建立關聯時，會套用「預設」區域的驗證和原則。因此，「預設」區域必須是最安全的區域。
送出含有「預設」區域連結的管理電子郵件。這包括送給將達到配額限制之網站擁有人的電子郵件。因此，收到這類電子郵件訊息和提醒的使用者，必須可透過「預設」區域存取連結。這對網站擁有人特別重要。
主機名稱的網站集合只能透過「預設」區域使用。預定要存取主機名稱網站集合的所有使用者，都必須透過「預設」區域取得存取權。
為外部環境設定區域
在外部網路環境中，區域的設計十分重要，原因在於下列兩個因素：
使用者要求可以從數個不同網路起始。在設計範例中，使用者會從內部網路、網際網路及合作夥伴公司起始請求。
使用者會使用多個 Web 應用程式的內容。在設計範例中，內部網路由三個不同的 Web 應用程式組成。此外，內部及遠端員工可能會在所有 Web 應用程式 (內部網路、合作夥伴網站及公司網際網路網站) 中提供和管理內容。
在外部網路環境中，請務必遵循下列設計原則：
跨多個 Web 應用程式設定區域彼此鏡像。驗證設定和預定使用者應該相同。但各 Web 應用程式中與區域相關的原則則可互不相同。例如，您必須確定相同的員工在所有 Web 應用程式中皆是使用內部網路區域。換言之，請勿在某 Web 應用程式設定內部網路區域供內部員工使用，而在另一個 Web 應用程式中則又將該區域設定供遠端員工使用。
針對每個區域和每個資源，適當且正確地設定備用存取對應。備用存取對應是在建立區域時自動建立。但是，SharePoint Server 2010 可以設為對外部資源 (例如檔案共用) 中的內容進行編目。您必須使用備用存取對應為每個區域手動建立連至這些外部資源的連結。
若各 Web 應用程式中的區域未彼此鏡像，且外部資源連結不正確，將會產生下列風險：
伺服器名稱、網域名稱系統 (DNS) 名稱及 IP 位址可能會公開於內部網路之外。
使用者可能無法存取網站和其他資源。
服務
本文所示的服務架構說明以最複雜方式對三種不同網站 (內部網路、合作夥伴網站及公司網際網路網站) 部署服務。對於合作夥伴網站，部署的是專用且分割之服務。對於製作網站集合及已部署的網際網路網站，則部署單獨專用的 Managed Metadata Service 應用程式執行個體。
較簡易的替代作法，是部署一組服務應用程式，且在網站之間共用每項服務 (如有必要)。這種架構必須透過安全性調整，使顯示的內容僅限於使用者有存取權的內容。下圖說明此較簡易作法。
.gif "服務架構")
部署服務應用程式的主要設計決策，在於如何廣泛使用組織分類。若要簡化服務架構，可在所有 Web 應用程式之間共用受管理中繼資料、使用者設定檔及搜尋，再藉由安全性調整來管理內容存取權。在本文所述的簡化架構中，所有網站共用一個 Managed Metadata Service 執行個體。不過，在這種設定下，所有使用者都能存取公司分類。解決方案架構師必須決定是否要實作多個 Managed Metadata Service 執行個體，也需決定如何廣泛共用使用者設定檔資料。
合作夥伴網站
對於合作夥伴網站 (伺服器陣列 1 中的自訂群組)，設計範例規定的基本服務為 Search 及 Managed Metadata。如果將 Office Web Apps 新增至合作夥伴網站所用的服務群組中，請務必確認您具備足夠供此網站所有使用者 (包括合作夥伴在內) 使用的授權。設計範例中並不包含 User Profile Service 應用程式，以防止合作夥伴使用者瀏覽組織中的人員資料。
在簡化架構中，合作夥伴可存取整個公司分類，也可瀏覽組織中的人員資料。但是，搜尋結果範圍限為合作夥伴可存取的網站及內容。
如果您的合作夥伴網站需要將專案之間的內容加以隔離，部署專用且分割的服務應用程式 (如設計範例所示) 會是不錯的選擇。這種作法雖然會使服務架構變得較複雜，但可以確保合作夥伴無法存取與內部網路內容相關的中繼資料，或甚至是合作夥伴網站內其他專案。
公司網際網路網站
在簡化設計架構中，公司的 Managed Metadata Service 應用程式也共用於已發佈的內部網路網站。在設計範例中，Managed Metadata Service 應用程式的專用執行個體部署在共同作業伺服器陣列上，專供製作網站集合及已發佈的伺服器陣列使用。
如果已發佈的伺服器陣列屬於匿名且唯讀性質，公開不與已發佈內容相關聯的受管理中繼資料就不會有風險。匿名使用者僅能存取已發佈的內容，且無法提供評等或建立其他類型的中繼資料。
在整個組織中共用 Managed Metadata Service 應用程式 (如本文所述簡化架構)，將可讓作者使用公司分類。相對地，若是為製作網站及發佈網站部署該服務的專用執行個體 (如設計範例所述)，可確保受管理中繼資料受到隔離。
Search Service 應用程式專用執行個體部署在架設公司網際網路網站的伺服器陣列上。這是對於已發佈之網際網路對向網站的建議設定。
製作及發佈的替代作法
對於公司網際網路網站，在設計範例中說明的發佈程序，包含透過內容部署功能將內容從製作網站集合移至發佈伺服器陣列。較簡單的替代作法是直接在發佈伺服器網站上製作。這種作法通常稱為在實際環境中進行製作。
在實際執行環境進行製作，可大幅簡化解決方案，因為這種作法會將服務整合在一個伺服器陣列上，如此也就不需要進行內容部署。在設計範例中，包含了可讓作者使用的額外區域，他們可在這些區域中安全地工作，而不會影響匿名使用者。請務必在與作者所用區域相關聯的連接埠上，封鎖要進入的匿名存取。如果網站上每小時製作活動少於 500 次寫入，在實際執行環境中進行製作將不會影響已發佈網站的效能。
SharePoint Server 2010 包含可用於此情況的發佈功能，以確保內容在就緒之前不會對匿名使用者公開。如需詳細資訊，請參閱下列文章：
排定已發佈頁面的開始及結束日期(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196777&clcid=0x404)(可能為英文網頁)
核准或拒絕待處理的提交(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196778&clcid=0x404)(可能為英文網頁)
為發佈設定權限(可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196779&clcid=0x404)(可能為英文網頁)
管理網站
在設計範例中，每個伺服器陣列的管理中心網站是架設在應用程式伺服器上。如此可避免使用者直接連接到網站。如果效能瓶頸或安全性危害影響到前端網頁伺服器的可用性，則管理中心網站會保持在可用狀態。
本設計範例或本文不涵蓋管理網站的負載平衡 URL。建議如下：
如果管理 URL 中使用連接埠號碼，請使用非標準連接埠。URL 預設會包括連接埠號碼。雖然在客戶對向的 URL 中通常不會使用連接埠號碼，不過管理網站使用連接埠號碼將可提高安全性，因為可將對這些網站的存取限制在非標準連接埠上。
為管理網站建立單獨 DNS 項目。
除了這些建議之外，您還可以讓管理中心網站在多個應用程式伺服器之間達到負載平衡，以達到備援目的。
應用程式集區
實作單獨 Internet Information Services (IIS) 應用程式集區的目的，一般是為了隔離內容之間的程序。應用程式集區可讓多個網站在相同的伺服器電腦上執行，且仍然保有各自工作者處理序及身分識別。這可降低網站遭受攻擊的機會，讓攻擊者難以在伺服器插入程式碼攻擊其他網站。
實際來說，在下列每種情況下，都請考慮使用專用應用程式集區：
要區隔已驗證內容與匿名內容。
要將儲存外部商務應用程式密碼的應用程式，與會和外部商務應用程式互動的應用程式之間有所隔離 (雖然可改用 Secure Store Service 來達到這個目的)。
要將使用者可極自由地建立及管理網站的應用程式，與用以進行內容共同作業的應用程式之間有所隔離。
在設計範例中，使用應用程式集區的方式如下：
每個管理網站都架設在專用應用程式集區中。這是 SharePoint 2010 產品 的需求。
內部網路內容分成兩個不同應用程式集區。共同作業內容 (「我的網站」及小組網站) 主控在一個應用程式集區中。已發佈的內部網路內容主控在另一個應用程式集區中。這種設定可為較可能使用商務資料連線的已發佈內部網路內容提供處理序隔離。
合作夥伴 Web 應用程式主控在專用應用程式集區中。
公司網際網路網站架設在第二個伺服器陣列的專用應用程式集區中。如果這個伺服器陣列也要主控合作夥伴共同作業的內容，則這兩種內容 (網際網路及合作夥伴內容) 需分別主控在兩個不同應用程式集區中。
Web 應用程式
Web 應用程式係為 SharePoint 2010 產品 所建立並使用的 IIS 網站。每個 Web 應用程式在 IIS 中代表不同網站。
一般而言，使用專用 Web 應用程式可以：
**使匿名內容與已驗證內容之間有所區隔。**在設計範例中，公司網際網路網站架設在專用 Web 應用程式及應用程式集區中。
**隔離使用者。**在設計範例中，合作夥伴網站架設在專用 Web 應用程式及應用程式集區中，確保合作夥伴無法存取內部網路內容。
**強制規定權限。**專用 Web 應用程式可藉由原則或使用管理中心的 [Web 應用程式的原則] 頁面，強制規定權限。例如，您可以在公司網際網路網站上建立原則，明確拒絕一或多個使用者群組的寫入權限。不論 Web 應用程式內個別網站或文件上設定的權限為何，都會強制執行 Web 應用程式的原則。
**最佳化效能。**若 Web 應用程式與其他具有類似資料特性的應用程式放在一起，則這些應用程式可達到較好的效能。例如，「我的網站」的資料特性通常包括大量規模較小的網站。相對地，小組網站通常會包含少量的極大型網站。透過將這兩種不同類型的網站放於不同的 Web 應用程式，產生的資料庫就會包含特性類似的資料，如此可最佳化資料庫效能。在設計範例中，「我的網站」及小組網站並沒有特有的資料隔離需求，它們會共用相同的應用程式集區。不過，「我的網站」及小組網站會放在不同的 Web 應用程式中，以最佳化效能。
**最佳化管理性。**建立不同 Web 應用程式會產生不同的網站和資料庫，所以您可以實作不同的網站限制 (資源回收筒、到期時間和大小)，以及交涉不同的服務等級協定。例如，如果「我的網站」內容不是您組織中最重要的內容類型，您可能會允許較多時間來還原這些內容。如此可讓您先還原較重要的內容，再還原「我的網站」內容。在設計範例中，「我的網站」放在不同的 Web 應用程式中，好讓管理員能夠較對待其他應用程式採取更積極的方式，管理「我的網站」的成長。
網站集合
網站集合可銜接邏輯架構和資訊架構。在設計範例中，網站集合的設計目的，是要滿足 URL 設計需求，以建立內容的邏輯分隔。
為了滿足 URL 設計需求，每個 Web 應用程式會包括一個單一根層級網站集合。管理路徑用來加入頂層網站集合的第二層。如需 URL 需求及使用管理路徑的詳細資訊，請參閱本文後述的＜區域及 URL＞。在網站集合第二層之下，每個網站都是子網站。
下圖說明「小組網站」的網站層級。
.gif "小組網站")
基於根層級網站集合的需求，設計決策重點會以網站集合第二層為主。在設計範例中，即根據應用程式的本質做出選擇。
已發佈的內部網路內容
對於已發佈的內部網路內容，將假設公司內多個部門將主控已發佈內容。在設計範例中，每個部門的內容主控在不同網站集合中。這樣做有下列好處：
每個部門可單獨管理內容及授與內容的權限。
每個部門的內容可儲存在專用資料庫中。
使用多個網站集合的缺點包括：
主版頁面、版面配置、範本、網頁組件及導覽方式無法在網站集合之間共用。
需要花更多心力處理網站集合之間的自訂及導覽方式。
根據內部網路應用程式的資訊架構及設計，已發佈內容可以向使用者呈現成一個無縫應用程式。或者，每個網站集合也可以呈現為單獨網站。
我的網站
「我的網站」具有特殊特性，部署「我的網站」的建議十分簡單。在設計範例中，「我的網站」應用程式所用頂層網站的 URL 為 http://my。所建立的第一個頂層網站集合使用「我的網站主機」範本，而且使用管理路徑 (即使用包含相對路徑)，如此可允許使用者建立無限多個網站。所有在管理路徑之下的網站均為繼承「我的網站主機」範本的獨立網站集合。URL 最後會加上使用者名稱，格式為 http://my personal/使用者名稱。下圖說明「我的網站」。
.gif "我的網站")
小組網站
您可以使用下面其中一種方式來設計「小組網站」應用程式中的網站集合。
允許小組透過自助網站架設方式來建立網站集合。這種方式的優點，在於小組可以視需要輕鬆建立網站，而不需要管理員的協助。不過，這種方式也有許多缺點，包括：
無法實作完善規劃的分類。
應用程式會變得難以管理。
容易讓網站遭放棄不用。
無法讓可能共用網站集合的專案或小組共用範本及導覽方式。
根據組織運作方式，為組織建立有限的網站集合。以這種方式來說，網站集合是由 SharePoint 管理員建立。建立網站集合後，小組可以根據自己的需求在網站集合中建立網站。這種方式可實作完善規劃的分類，提供因應小組網站在管理及成長上的結構。其中還提供許多方式可讓共用網站集合的專案及小組共用範本及導覽方式。
設計範例採用的是第二種方式，這會使小組網站與已發佈內部網路內容具有類似的網站集合階層。資訊架構師的挑戰就在於建立適合組織的網站集合第二層。下表說明針對不同組織類型的建議。
| 組織類型 | 建議的網站集合分類 |
|---|---|
產品開發 |
|
研究 |
|
高等教育機構 |
|
國家立法機構 |
|
企業法律事務所 |
|
製造 |
|
合作夥伴 Web 應用程式
合作夥伴網站主要用於針對設有一定範圍或一定時限的專案，與外部合作夥伴進行共同作業。根據設計，合作夥伴 Web 應用程式內的各個網站不會彼此相關。合作夥伴 Web 應用程式的需求包括必須確保下列事項：
專案擁有人可以輕鬆建立合作夥伴共同作業的網站。
合作夥伴及其他參與者只能存取他們所處理的專案。
權限由網站擁有人管理。
搜尋某個專案所得的結果不會公開其他專案的內容。
管理員可以輕易識別出不再使用的網站，並刪除這些網站。
為滿足這些需求，在設計範例中，每個專案各有一個網站集合。如此，將有下列好處：
個別網站集合可讓專案之間有適當的隔離層級。
可實作自助網站架設。
由於合作夥伴 Web 應用程式也同時主控開發公司網際網路網站內容的網站集合，所以建立不同網站集合以分別用於製作內容及臨時之用。
公司網際網路網站
公司網際網路網站採用單一根層級網站集合。在此網站集合之下的所有網站都是子網站。這種結構讓該網站內所有頁面的 URL 都變得簡化。下圖說明公司網際網路網站的架構。
.gif "公司網際網路網站")
內容資料庫
您可以使用下列兩種方式，在設計中加入內容資料庫 (設計範例即同時使用這兩種方式)：
為具有適當大小警告臨界值的內容資料庫建立目標大小。在達到大小警告臨界值時，建立新的資料庫。使用此方式，會僅根據大小目標值，自動將網站集合新增至可用的一或多個資料庫。這是最常用的方式。
建立網站集合與特定內容資料庫的關聯。這種方式可讓您將一或多個網站集合放入專用資料庫，以與其他資料庫分開管理。
若選擇將網站集合關聯至特定內容資料庫，則可以使用下列方法來完成：
使用 Windows PowerShell 在特定資料庫中建立網站集合。
套用下列資料庫容量設定，讓資料庫專用於單一網站集合：
警告事件產生前的網站數目 = 1
此資料庫中可以建立的最大網站數目 = 1
執行下列步驟，將網站集合群組新增至專用資料庫：
在 Web 應用程式中，建立資料庫，並將資料庫狀態設為 [就緒]。
將所有其他資料庫的狀態設定為 [離線]。內容資料庫離線時，無法建立新的網站集合。但是，讀取與寫入作業仍可存取離線資料庫中的現有網站集合。
建立網站集合。它們會自動新增至資料庫。
將所有其他資料庫的狀態設回 [就緒]。
已發佈的內部網路內容
對於已發佈的內部網路內容，設計範例僅使用單一資料庫，以便於管理。如有需要，請根據目標大小值新增資料庫。
我的網站
對於「我的網站」，在設計範例中，藉由管理資料庫達到目標大小上限，而獲得規模效益。為達到此目的，設定了下列設定：
限制網站儲存量的最大值為：此設定 (在管理中心的 [配額範本] 頁面中設定) 可限制個人網站大小。
第二階段資源回收筒：此設定 (在 [Web 應用程式一般設定] 頁面中設定) 可決定還需要額外配置給第二階段資源回收筒多少空間。
這個資料庫可以建立的網站數目上限：此設定是在您建立資料庫時設定。請根據您在上面兩項所指定的值，來計算總共可允許的網站大小。然後，根據每個資料庫的大小目標，決定資料庫可容納的網站數目。
在設計範例中，根據 200 GB 的資料庫目標大小和 1 GB 的「我的網站」目標大小，提供了下列範例大小設定：
每個網站的網站大小限制 = 1 GB
資料庫目標大小 = 175 GB
保留給第二階段資源回收筒使用的空間 = 15%
網站數目上限 = 180
網站層級警告 = 150
達到網站層級警告時，會建立新的資料庫。建立新的資料庫之後，新的「我的網站」會交替地新增到新的資料庫及現有資料庫中，直到其中一個資料庫的網站數目達到上限為止。
小組網站
對於小組網站，在設計範例中，也同樣藉由管理資料庫達到目標大小上限，而獲得規模效益。大多數組織的小組網站應會遠大於「我的網站」。在設計範例中，所提供的資料庫設定是根據 30 GB 的網站集合限制。請為您組織的小組網站選擇適當限制。
對於組織中具有大型儲存需求的小組，另一種方式就是對每個頂層小組網站集合使用一個專用資料庫。
合作夥伴網站
就像在「我的網站」的情況一樣，合作夥伴網站藉由管理資料庫達到目標大小上限，而獲得規模效益。但是，在設計範例中，合作夥伴網站也負責主控公司內部網路網站的製作網站集合。因此，資料庫設計同時採用這兩種方式。
製作網站集合主控於專用資料庫上。
設定資料庫及大小設定，以管理其他所有網站及資料庫。
由於合作夥伴網站架設在專用 Web 應用程式中，因此您可以設定較適用於所建立網站類型的大小限制。設計範例提供了下列範例大小設定：
資料庫目標大小 = 200 GB
每個網站的儲存配額 = 5 GB
網站數目上限 = 40
將製作網站集合架設在專用資料庫上
公司網際網路網站
藉由在公司網際網路網站的設計中使用單一網站集合，您可以為此 Web 應用程式使用單一資料庫。
區域及 URL
設計範例說明如何在公司部署中調整多個應用程式之間的 URL。
設計目標
下列目標會影響 URL 的設計決策：
URL 慣例不限制藉以存取內容的區域。
在設計範例中，標準 HTTP 及 HTTPS 連接埠 (80 及 443) 可用於所有應用程式。
URL 不包括連接埠號碼。實際上，連接埠號碼一般不會用於實際執行環境。
設計原則
為達到上述設計目標，而採用下列設計原則：
不使用主機名稱的網站集合。請注意，主機名稱的網站集合與 IIS 主機標頭不同。主機名稱的網站集合不能使用備用存取對應功能。需要有備用存取對應功能，才能透過多個網域 URL 存取相同的內容。因此，如果使用主機名稱的網站，這些網站就只能透過「預設」區域才能使用。
每個應用程式採用單一根網站集合。這對於使用備用存取對應而言是必要的。如果 Web 應用程式需使用多個根網站集合，而您希望只開放「預設」區域讓使用者存取，主機名稱的網站集合會是不錯的選擇。
對於包含多個高層級網站集合的應用程式 (這些網站集合每一個即代表頂層小組或專案，例如小組網站)，設計範例採用的是管理路徑。管理路徑可讓您更有效地管理這些類型網站的 URL。
設計缺點
要達成這些設計目標，將產生一些缺點，包括下列：
URL 較長。
不會使用主機名稱的網站集合。
設計負載平衡 URL
在建立 Web 應用程式時，您必須選擇負載平衡 URL 以指派給該應用程式。此外，還必須為每個在 Web 應用程式中建立的區域建立負載平衡 URL。負載平衡的 URL 包括通訊協定、配置、主機名稱及連接埠 (若有使用)。在所有 Web 應用程式及區域中，負載平衡 URL 必須是唯一的。因此，每個應用程式，及每個應用程式中的每個區域，在整個設計範例中都需使用唯一的 URL。
內部網路
構成內部網路的三個 Web 應用程式每個都需使用唯一的 URL。在設計範例中，內部網路內容的目標對象包括內部員工及遠端員工。在宣告式驗證設計範例中，無論員工位於公司內部還是位於遠端，他們對每一個這些應用程式都使用相同 URL。雖然這種方式會讓 SharePoint 設計多一層安全性 (因為所有流量都屬於 SSL)，不過這種方法會透過防火牆或閘道產品一併傳送內部流量與遠端流量，或是設定分割 DNS 環境，以在內部網路中解析內部要求。
在傳統驗證的設計範例中，內部員工及遠端員工使用不同的 URL。下表說明傳統驗證設計範例中，內部及遠端員工存取每個應用程式所用的 URL。
| 應用程式 | 內部員工 URL | 遠端員工 URL |
|---|---|---|
已發佈的內部網路內容 |
http://fabrikam |
https://intranet.fabrikam.com |
小組網站 |
http://teams |
https://teams.fabrikam.com |
我的網站 |
http://my |
https://my.fabrikam.com |
合作夥伴網站
在設計範例中，存取合作夥伴網站的人包括內部員工、遠端員工及合作夥伴員工。在宣告式驗證設計範例中，這些使用者每一位都輸入相同 URL，無論所用的驗證方法為何。在傳統驗證設計範例中，不同類型使用者分別輸入不同 URL。雖然遠端員工及合作夥伴員工都是使用 SSL (HTTPS) 從外部存取合作夥伴網站，每一組人員還是需要不同 URL 才能享受到使用不同區域 (亦即，不同驗證方法及不同區域原則) 的好處。下表說明內部員工、遠端員工及合作夥伴存取合作夥伴網站所用的 URL，如傳統驗證設計範例所示。
| 區域 | URL |
|---|---|
內部員工 URL |
http://partnerweb |
遠端員工 URL |
https://remotepartnerweb.fabrikam.com |
合作夥伴 URL |
https://partnerweb.fabrikam.com |
公司網際網路網站
公司網際網路網站為公用網站，所有使用者均可使用預設 URL (http://www.fabrikam.com) 存取。所套用的是網際網路區域原則 (亦即，匿名存取及拒絕寫入)。
不過，為了支援此公用網站上的管理及製作工作，設計範例為內部及遠端員工都提供了 URL。您可以在這些區域上使用原則，確保適當存取目標安全性群組，以進行製作及維護工作。傳統驗證及宣告式驗證設計範例對於此伺服器陣列都是採用相同方式。下表說明每個區域的 URL。
| 區域 | URL |
|---|---|
內部員工 URL |
http://fabrikamsite |
遠端員工 URL |
https://fabrikamsite.fabrikam.com |
客戶 URL |
http://www.fabrikam.com |
在 URL 路徑中使用包含絕對路徑及包含相對路徑
您可以藉由定義管理的路徑來指定 Web 應用程式之 URL 命名空間中的哪些路徑會用於網站集合。您可以指定在根網站的不同路徑下有一個或多個網站集合。若沒有管理路徑，所有在根網站集合下建立的網站都會是根網站集合的一部分。
您可以建立下列兩種類型的管理路徑：
**包含絕對路徑：**指派具有明確 URL 的網站集合。一個包含絕對路徑只能套用至一個網站集合。您可以在根網站集合下建立許多包含絕對路徑。使用此方法建立的網站集合 URL 範例為 http://fabrikam/hr。每個新增的包含絕對路徑都會影響效能，因此，建議您使用包含絕對路徑建立的網站集合限制在 20 個左右。
**包含相對路徑：**新增至 URL 的路徑。此路徑表示緊跟在路徑名稱後所指定的所有網站，都是唯一的網站集合。此選項常用於支援自助網站架設的網站集合 (例如「我的網站」)。使用此方法建立的網站集合 URL 範例為 http://my/personal/user1。
設計範例同時使用這兩種類型，如下列小節所述。
包含絕對路徑：已發佈的內部網路內容
在設計範例中，已發佈的內部網路 Web 應用程式使用包含絕對路徑。
已發佈的內部網路內容
在已發佈的內部網路內容 Web 應用程式內，每個子網站 (例如，HR、設備和採購) 都使用包含絕對路徑。這些網站集合每一個都可以與不同內容資料庫產生關聯 (如有需要)。在此範例中使用包含絕對路徑，係假設 Web 應用程式中沒有建立其他類型的網站，包括包含相對路徑。
建議使用包含絕對路徑建立網站限制在 20 個左右。如果您的組織需要更多網站集合，請考慮使用包含相對路徑或主機名稱的網站集合。
在傳統驗證設計範例中，使用包含絕對路徑會產生下表所示的 URL。
| 內部員工 (內部網路區域) | 遠端員工 (預設區域) |
|---|---|
http://fabrikam |
https://intranet.fabrikam.com |
http://fabrikam/hr |
https://intranet.fabrikam.com/hr |
http://fabrikam/facilities |
https://intranet.fabrikam.com/facilities |
http://fabrikam/purchasing |
https://intranet.fabrikam.com/purchasing |
在此範例中，根網站集合 http://fabrikam 代表內部網路的預設首頁。此網站預定會主控使用者的內容。
包含相對路徑：小組網站、「我的網站」及合作夥伴網站
小組網站、「我的網站」及合作夥伴 Web 應用程式使用包含相對路徑。「包含相對路徑」適用於允許使用者建立他們自己網站集合的應用程式，也適用於包含大量網站集合的 Web 應用程式。「包含相對路徑」表示萬用字元後面的下一個項目是網站集合的根網站。
小組網站
在小組網站應用程式內，每個小組網站集合皆使用「包含相對路徑」。良好的控管作法建議將頂層小組網站數目保持在可管理的數目內。而且，小組網站的分類邏輯應該配合公司運作方式。
在傳統驗證設計範例中，使用包含相對路徑產生下表所示的 URL。
| 內部員工 (內部網路區域) | 遠端員工 (預設區域) |
|---|---|
http://teams/sites/Team1 |
https://teams.fabrikam.com/sites/Team1 |
http://teams/sites/Team2 |
https://teams.fabrikam.com/sites/Team2 |
http://teams/sites/Team3 |
https://teams.fabrikam.com/sites/Team3 |
在此範例中，根網站集合 http://team 不一定主控使用者的內容。
我的網站
「我的網站」提供自助網站架設。瀏覽內部網站的使用者第一次按一下 [我的網站] 時，會自動為使用者建立「我的網站」。在設計範例中，「我的網站」使用包含相對路徑 /personal (http://my/personal)。「我的網站」功能會自動在 URL 的最後加上使用者名稱。
在傳統驗證設計範例中，這會產生下表所列格式的 URL。
| 內部 (內部網路區域) | 遠端員工 (預設區域) |
|---|---|
http://my/personal/user1 |
https://my.fabrikam.com/personal/user1 |
http://my/personal/user2 |
https://my.fabrikam.com/personal/user2 |
http://my/personal/user3 |
https://my.fabrikam.com/personal/user3 |
合作夥伴 Web 應用程式
合作夥伴 Web 應用程式的設計旨在允許員工輕鬆地建立安全網站，以與外部合作夥伴進行共同作業。為達此目標，允許使用自助網站架設。
在傳統驗證設計範例中，合作夥伴 Web 應用程式使用包含相對路徑 /sites (http://partnerweb/sites)。這會產生下表所列格式的 URL。
| 內部員工 (內部網路區域) | 遠端員工 (預設區域) |
|---|---|
http://partnerweb/sites/project1 |
https://remotepartnerweb.fabrikam.com/sites/project1 |
http://partnerweb/sites/project2 |
https://remotepartnerweb.fabrikam.com/sites/project2 |
http://partnerweb/sites/project3 |
https://remotepartnerweb.fabrikam.com/sites/project3 |
合作夥伴參與者可以使用下表列出的 URL 存取合作夥伴網站。
| 合作夥伴 (外部網路區域) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
合作夥伴網站有個例外 (如設計範例所示)，就是專用於製作公司網際網路網站內容的網站集合。針對此網站集合，會使用包含絕對路徑。這個範例提供了在同一個 Web 應用程式中同時使用包含絕對路徑和包含相對路徑。
區域原則
您可以建立 Web 應用程式的原則，在 Web 應用程式層級強制規定權限。您可以定義一般 Web 應用程式的原則，或只針對特定區域定義原則。原則可強制規定 Web 應用程式或區域內所有內容的權限。原則權限會覆寫針對網站和內容設定的其他所有安全性設定。您可以根據使用者或使用者群組來設定原則，但不能根據 SharePoint 群組設定原則。如果新增或變更區域原則，搜尋必須重新編目網站，才能取得新的權限。
在宣告驗證設計範例中，共同作業伺服器陣列並未使用原則，因為在該伺服器陣列中，單一區域啟用多種驗證類型。原則實作於傳統驗證設計範例，及宣告驗證設計範例中規定使用 Windows 驗證的已發佈伺服器陣列。在已發佈伺服器陣列上，使用原則會讓匿名使用者與有存取權可管理網站的使用者之間，多一層安全性。
設計範例提供多個達成下列目標的原則範例：
拒絕對已發佈內容的寫入權限。
確保作者和測試人員擁有已發佈內容的適當存取權。