本地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和其他网站。
  • 使用计算机名称（而不是完全限定的域名 (FQDN) ）在公共 URL 中保存大量键入。
  • 将主机名保留在未指定的绑定中可以灵活地进行连接 - 当用户尝试连接到其服务器时，计算机名称、FQDN 或 IP 地址都将正常工作。

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

此外，在 TFS 2017 新身份验证方案中， (生成/发布代理服务帐户身份验证，个人访问令牌) 通过网络发送持有者令牌。 如果这些令牌由恶意用户获取，则可以使用这些令牌模拟他们所属的用户。

鉴于这一切，我们决定是时候更强烈地倡导在Azure DevOps Server部署中使用 HTTPS 绑定了。

设置组

TFS 2017 在所有服务器配置方案中都提供了网站设置配置选项。 提供了多个设置组，这些组捆绑了站点绑定、虚拟目录和公共 URL 的组合，我们建议和相信这些组合最常使用。 对于这些设置组都不适用的方案，可以使用“编辑网站设置”对话框完全自定义设置。

Default setting group

默认设置组包括以前版本的Azure DevOps Server中使用的相同设置。 出于上述所有原因，这些设置仍然是新Azure DevOps Server部署的默认设置。 对于现有部署，我们将尝试保留现有设置，这通常会导致选择“默认设置”组。

HTTPS and HTTP with redirect setting group.

使用重定向) 设置组的 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 浏览器将显示以下错误。

Certificate errors in Edge.

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

若要避免这些证书警告和错误，可以导出根证书并将其安装在客户端计算机上。 可通过多种方法完成此操作，包括：

  • 使用证书 MMC 管理单元在服务器上手动 导出证书 ，然后在每个客户端上导入该证书。
  • 使用导出证书 powershell cmdlet（可在 Windows 8/Windows Server 2012 及更高版本的操作系统中使用）导出证书。 然后，可以使用导入证书在每个客户端上导入它。
  • 使用组策略自动分发到客户端。

内部和外部证书颁发机构

许多大型组织都有自己的公钥基础结构，并且能够从自己的证书颁发机构颁发证书。 通常情况下，在这种情况下，这些颁发机构的受信任根证书将分发到客户端计算机，从而避免需要为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部署的用户协调这种更改，以避免重大中断。