共用方式為


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 部署的使用者協調這種變更,以避免發生重大中斷。