TFS 2017 |TFS 2015 |TFS 2013
背景
對於許多版本，Azure DevOps Server 的預設網站設定 （先前稱為 Team Foundation Server （TFS） ） 是：
- 埠 8080 上 Azure DevOps Server 網站的單一 HTTP 系結，未指定主機名稱或 IP 位址。
- 表格
http://machine-name:8080/tfs的公用 URL（先前稱為通知 URL）。
這些設定的主要優點是，在大多數情況下，它們的設定非常簡單，方便使用者使用。 特別是：
- 使用 HTTP 而非 HTTPS 可避免取得及安裝憑證。
- 使用 8080 而不是 80 可以避免與同一台機器上的其他網站發生潛在衝突。
- 使用 「tfs」 作為網站的虛擬目錄，可讓您更輕鬆地在相同伺服器上的相同埠上裝載 Azure DevOps Server 和其他網站。
- 在公用 URL 中使用電腦名稱，而不是完整網域名稱 （FQDN），可節省大量輸入。
- 將繫結中的主機名稱保留為未指定，可讓您靈活地連線 - 當使用者嘗試連線到其伺服器時，電腦名稱、FQDN 或 IP 位址都會運作。
不過，這些設定預設並不安全。 特別是，藉由不使用 HTTPS 系結，除非使用 IPSec 等其他解決方案，否則不會在傳輸過程中加密 Azure DevOps Server 的通訊。 因此，它們可能容易受到惡意行為者監控甚至修改通訊內容的攻擊。 當 Azure DevOps Server 部署在公司防火牆後方的內部網路上時，這些問題會在某種程度上減輕，因為絕大多數的 Azure DevOps Server 實例都是如此。 但即使在這些案例中，傳送至 Azure DevOps Server 和從 Azure DevOps Server 傳送的數據也包含原始程式碼、工作專案數據，以及其他資訊，這些資訊通常可以從額外的安全性中受益。
此外，在 TFS 2017 中，存在新的驗證案例 （組建/發行代理程式服務帳戶驗證、個人存取權杖） ，這些案例會透過網路傳送持有人權杖。 如果這些令牌是由惡意使用者取得，則可用來冒充其所屬的使用者。
鑑於所有這些，我們決定是時候更強烈地提倡在 Azure DevOps Server 部署中使用 HTTPS 系結了。
設定群組
TFS 2017 會在所有伺服器設定案例中呈現網站設定設定選項。 提供了幾個設置組，這些組捆綁了我們推薦並認為最常用的站點綁定、虛擬目錄和公共 URL 的組合。 對於這些設定群組都不合適的案例，可以使用「編輯網站設定」對話方塊來完全自訂設定。
預設設定群組包含舊版 Azure DevOps Server 中使用的相同設定。 基於上述所有原因，這些設定仍然是新 Azure DevOps Server 部署的預設值。 對於現有的部署，我們將嘗試保留現有的設定，這通常會導致選取預設設定群組。
HTTPS 和 HTTP （具有重新導向） 設定群組會佈建兩個繫結：
- 連接埠 443 上的一個 HTTPS 繫結，以電腦的完整網域名稱 （FQDN） 作為主機名稱。
- 埠 80 上的一個 HTTP 繫結，同樣使用電腦的 FQDN 作為主機名稱。
新增埠80上的HTTP繫結只是為了方便終端使用者 — 配置了重定向，以便所有流量最終使用埠443上的HTTPS繫結。 此設定群組的公用 URL 格式為 https://fully-qualified-domain-name. 根據預設，此設定群組會佈建新的自我簽署憑證，並將其用於 HTTPS 繫結。 我們通常不建議將自行簽署的憑證用於生產環境的 TFS 部署。 請參閱下方的憑證選項，以取得何時適合使用自我簽署憑證，以及有哪些其他選項可用。
僅限 HTTPS 設定群組會在連接埠 443 上佈建單一 HTTPS 繫結，並將機器的 FQDN 做為主機名稱。 同樣地，此設定群組的公用 URL 格式 https://fully-qualified-domain-name為 ，預設會佈建自我簽署憑證。
「僅限 HTTP 」設定群組會在埠 80 上佈建單一 HTTP 繫結，且未指定主機名稱。 此設定群組的公用 URL 格式為 http://machine-name.
使用 HTTPS 和 HTTP （具有重新導向） 設定群組時，不建議使用 HTTP 公用 URL。 大多數現代瀏覽器預設會認為混合的 HTTP 和 HTTPS 內容不安全，並且可能會顯示空白頁面。 雖然通常可以覆寫預設瀏覽器設定並允許不安全的內容，但這會導致類似於使用過期 SSL 憑證瀏覽網站的體驗。
憑證選項
使用 HTTPS 繫結和 SSL/TLS 加密來部署網站，與更廣泛的公開金鑰基礎結構（PKI）主題密切相關，這是一個內容豐富且有趣的領域，對此已經有大量的文件紀錄。 我們不會嘗試涵蓋這裡的所有複雜度，而是著重於設定 Azure DevOps Server 部署 HTTPS 系結的高階選項。 許多組織都有部署憑證的特定原則，因此決定要用於 Azure DevOps Server 部署的憑證的第一個步驟通常是與組織層級資訊技術群組交談。
這些選項包括：
- 允許 TFS 設定精靈產生自我簽署憑證以供部署使用。
- 從內部憑證管理中心取得憑證。
- 從外部憑證管理中心取得憑證。
自我簽署憑證
自我簽署憑證對於 Azure DevOps Server 的試用部署很有用，因為它們非常容易佈建和使用。 它們不太適合 Azure DevOps Server 的生產部署，而且我們不建議將它們用於公開至公用因特網的 Azure DevOps Server 部署。 一般而言，自我簽署憑證容易受到中間人攻擊。 它們也會給使用者帶來問題，因為它們會導致憑證警告和錯誤，直到在每部用戶端電腦上安裝其根憑證為止。 例如，Edge 瀏覽器將顯示以下錯誤。
當 TFS 設定精靈為您的部署產生自簽憑證時，它會建立兩個—一個放在伺服器上的受信任的根憑證授權單位存放區中，另一個由第一個憑證簽署並放在伺服器上的個人存放區中，供 Azure DevOps Server 使用。 以這種方式設定有助於降低中間人攻擊的可能性，並啟用HTTPS繫結中使用的憑證的輪換，而無需將新證書分發給所有客戶端，以避免如上所示的證書錯誤。
若要避免這些憑證警告和錯誤，您可以匯出根憑證並將其安裝在用戶端電腦上。 有幾種方法可以實現這一點，包括：
- 使用 [憑證 MMC] 嵌入式管理單元，在伺服器上手動 匯出憑證，然後在每個客戶端上匯入憑證。
- 使用 Windows 8 / Windows Server 2012 和更新版本作業系統中可用的 Export-Certificate powershell Cmdlet 來匯出憑證。 然後，可以使用 Import-Certificate 在每個用戶端上匯入它。
- 使用 群組原則 來自動化分發給用戶端。
內部和外部憑證授權單位
許多大型組織都有自己的公開金鑰基礎架構，並且能夠從自己的憑證授權單位發行憑證。 一般而言，在此情況下，這些授權單位的受信任根憑證已散發至用戶端計算機，因此不需要散發 Azure DevOps Server 的其他憑證。 如果您的組織有自己的公開金鑰基礎結構，這可能是 Azure DevOps Server 部署的好選項。
當其他選項不合適或不可用時，可以從外部憑證授權單位 （CA） 取得憑證 （通常需要付費）。 此程式的指示 （從建立 憑證簽署要求開始） 可在大多數 CA 網站上找到。 一些重要注意事項：
- 請確定憑證要求中提供的一般名稱與公用 URL 中想要的主機名稱相符，例如 tfs.contoso.com。
- 在 [密碼編譯服務提供者屬性] 上，建議您選取 Microsoft RSA SChannel 密碼編譯提供者，且位長為 2048 或更大。
變更公開網址
也應該注意，升級現有的 Azure DevOps Server 部署時，變更公用 URL 會影響終端使用者。 雖然我們仍建議從 HTTP 轉換成 HTTPS 系結，但必須重新建立 Visual Studio 用戶端連線，舊書籤將無法再正確解析，依此類推。 因此，請務必與 Azure DevOps Server 部署的使用者協調這種變更，以避免重大中斷。