Azure DevOps 內部部署的網站設定和安全性

  • 發行項

TFS 2017 |TFS 2015 |TFS 2013

背景

針對許多版本，先前命名為 Team Foundation Server (TFS) 之 Azure DevOps Server 的默認網站設定為：

  • 埠 8080 上 Azure DevOps Server 網站的單一 HTTP 系結，未指定主機名或 IP 位址。
  • 公用 URL (先前稱為表單 http://machine-name:8080/tfs的通知 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 的數據也包含原始程式碼、工作項目數據，以及其他可能受益於其他安全性的資訊。

此外，在 TFS 2017 中，新的驗證案例 (建置/發行代理程式服務帳戶驗證，個人存取令牌) 透過網路傳送持有人令牌。 如果惡意使用者取得這些令牌，他們就可以用來模擬他們所屬的使用者。

考慮到這一切，我們決定在 Azure DevOps Server 部署中使用 HTTPS 系結的更強式提倡者。

設定群組

TFS 2017 會在所有伺服器組態案例中呈現網站設定設定選項。 提供數個設定群組，其組合網站系結、虛擬目錄和公用URL的組合，我們建議且認為最常使用。 對於這些設定群組都不適用的案例，可以使用 [編輯網站設定] 對話框完全自定義設定。

默認設定群組

[預設] 設定群組包含舊版 Azure DevOps Server 中使用的相同設定。 基於上述所有原因，這些設定仍是新 Azure DevOps Server 部署的預設值。 針對現有的部署，我們將嘗試保留現有的設定，這通常會導致選取 [預設設定] 群組。

具有重新導向設定群組的 HTTPS 和 HTTP。

具有重新導向) 設定群組的 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 瀏覽器會顯示下列錯誤。

Edge 中的憑證錯誤。

當 TFS 設定精靈為您的部署產生自我簽署憑證時，它會建立兩個 - 一個放在伺服器上的受信任跟證書授權單位存放區，另一個則由第一個存放區簽署，該存放區會放在伺服器上的個人存放區中，並由 Azure DevOps Server 使用。 以此方式設定專案有助於減輕攔截式攻擊的可能性，並啟用 HTTPS 系結中使用的憑證輪替，而不需要將新的憑證散發給所有用戶端，以避免如上所示的憑證錯誤。

若要避免這些憑證警告和錯誤，您可以匯出跟證書，並將其安裝在用戶端電腦上。 有數種方式可以完成這項作業，包括：

  • 使用憑證 MMC 嵌入式管理單元，在伺服器上手動 匯出憑證 ，然後在每個用戶端上匯入憑證。
  • 使用導出憑證 Powershell Cmdlet，可在 Windows 8/Windows Server 2012 和更新版本的操作系統中取得，以導出憑證。 然後，您可以使用 Import-Certificate 在每一個用戶端上匯入它。
  • 使用 群組原則將散發自動化至用戶端。

內部和外部證書頒發機構單位

許多大型組織都有自己的公鑰基礎結構，而且能夠從自己的證書頒發機構單位發行憑證。 一般而言，當發生這種情況時，這些授權單位的信任跟證書將已散發給客戶端計算機，因此避免需要為 Azure DevOps Server 散發其他憑證。 如果您的組織有自己的公鑰基礎結構，這可以是 Azure DevOps Server 部署的好選項。

當其他選項不適用或無法使用時，憑證通常 (從外部證書頒發機構單位 (CA) 的成本) 取得。 此程式的指示從建立 憑證簽署要求開始，可以在大部分的 CA 網站上找到。 一些重要注意事項：

  • 請確定憑證要求中提供的一般名稱與您想要在公用 URL 中的主機名相符，例如，tfs.contoso.com。
  • 在 [密碼編譯服務提供者內容] 上，建議您選取 [Microsoft RSA SChannel 密碼編譯提供者]，且長度為 2048 或更新版本。

變更您的公用 URL

另請注意，升級現有的 Azure DevOps Server 部署時，變更公用 URL 將會影響終端使用者。 雖然我們仍建議從 HTTP 轉換為 HTTPS 系結，但必須重新建立 Visual Studio 用戶端連線，舊的書籤將無法再正確解析，依此類推。 因此，請務必與 Azure DevOps Server 部署的使用者協調這種變更，以避免發生重大中斷。