本地 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之间的通信。 因此，它们可能会受到恶意参与者监视甚至修改通信内容的攻击。 当Azure DevOps Server部署在企业防火墙后面的 Intranet 上时，这些问题在一定程度上得到缓解，因为绝大多数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的生产部署，我们不建议将其用于公开到公共 Internet 的Azure DevOps Server部署。 通常，自签名证书容易受到中间人攻击。 它们还会给用户带来问题，因为它们会导致证书警告和错误，直到其根证书安装在每台客户端计算机上。 例如，Edge 浏览器将显示以下错误。

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 或更大。

更改公共 URL

还应注意，升级现有Azure DevOps Server部署时，更改公共 URL 会影响最终用户。 虽然我们仍建议从 HTTP 转换为 HTTPS 绑定，但 Visual Studio 客户端连接需要重新建立，旧书签将无法再正确解析，依此类推。 因此，请务必与Azure DevOps Server部署的用户协调此类更改，以避免重大中断。