本地Azure DevOps网站设置和安全性

TFS 2017 |TFS 2015 |TFS 2013

背景

对于许多版本,Azure DevOps Server的默认网站设置(以前Team Foundation Server (TFS) 为:

  • 端口 8080 上Azure DevOps Server网站的单个 HTTP 绑定,未指定主机名或 IP 地址。
  • 公共 URL (以前称为"通知 URL") 格式 http://machine-name:8080/tfs

这些设置的主要好处是,它们设置起来非常简单,并且在大多数情况下为最终用户提供了方便。 具体而言:

  • 使用 HTTP 而不是 HTTPS 可避免获取和安装证书。
  • 使用 8080 而不是 80 可避免与同一计算机上其他站点的潜在冲突。
  • 使用"tfs"作为站点的虚拟目录,可以更轻松地在同一服务器上Azure DevOps Server端口上托管站点和其他网站。
  • 在公共 URL 中,使用计算机名称(而不是 FQDN (完全限定的) 名称)可节省大量键入内容。
  • 在绑定中保留未指定的主机名可以灵活地进行连接 - 当用户尝试连接到其服务器时,计算机名称、FQDN 或 IP 地址都将正常工作。

但是,这些设置在默认情况下不安全。 具体而言,通过使用 HTTPS 绑定,除非使用 IPSec 等其他解决方案,否则Azure DevOps Server通信不会在传输过程中加密。 因此,它们可能容易受到恶意参与者监视,甚至修改通信内容的攻击。 在企业防火墙后面的 Intranet 上部署 Azure DevOps Server,这些问题在一定程度上得到缓解,因为大多数 Azure DevOps Server实例都是。 但即使在这些方案中,发送到和Azure DevOps Server的数据也包括源代码、工作项数据和其他通常可能受益于其他安全性的信息。

此外,在 TFS 2017 中, (生成/发布代理服务帐户身份验证、个人访问令牌) 通过线路发送 bearer 令牌。 如果这些令牌是由恶意用户获取的,则它们随后可用于模拟他们所属的用户。

考虑到这一切,我们决定现在应更强烈地在部署中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) 的更广泛的主题密切相关,该主题是一个丰富且有趣的主题,其中已存在各种文档。 我们不会尝试在这里涵盖所有复杂性,而是侧重于为部署部署配置 HTTPS 绑定Azure DevOps Server选项。 许多组织都有关于部署证书的特定策略,因此决定用于 Azure DevOps Server 部署的证书的第一步是与组织级信息技术组对话。

选项包括:

  • 允许 TFS 配置向导生成供部署使用的自签名证书。
  • 从内部证书颁发机构获取证书。
  • 从外部证书颁发机构获取证书。

自签名证书

自签名证书适用于 Azure DevOps Server 试用部署,因为它们很容易预配和使用。 它们不太适用于 Azure DevOps Server 的生产部署,不建议用于公开Azure DevOps Server Internet 的部署。 通常,自签名证书容易受到中间人攻击。 它们还给用户带来问题,因为它们将导致证书警告和错误,直到其根证书安装在每台客户端计算机上。 例如,Edge 浏览器将显示以下错误。

Edge 中的证书错误。

当 TFS 配置向导为部署生成自签名证书时,它将创建两个证书 - 一个放置在服务器的 受信任的根证书颁发机构 存储中,另一个证书由第一个签名,放置在服务器的个人存储中,供 Azure DevOps Server 使用。 这样设置有助于降低中间人攻击的可能性,并启用 HTTPS 绑定中使用的证书的轮换,而无需将新证书分发到所有客户端,以避免证书错误,如上所示。

若要避免这些证书警告和错误,可以导出根证书,将其安装在客户端计算机上。 有几种方法可以做到这一点,包括:

内部和外部证书颁发机构

许多大型组织都有自己的公钥基础结构,并且能够从自己的证书颁发机构颁发证书。 通常,在这种情况下,这些颁发机构受信任的根证书将已分发到客户端计算机,因此无需分发其他证书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,以避免重大中断。