通过

传输层安全检查常见问题解答（预览版）

本文解答了有关传输层安全检查的常见问题。

什么是传输层安全性（TLS）检查？

TLS 检查解密和分析加密的网络流量，以帮助组织检测威胁、强制实施安全策略并防止数据外泄。 由于大多数 Internet 流量现已加密，TLS 检查可查看数据流，否则这些数据流对安全工具不透明。 TLS 检查使企业能够应用高级保护，例如内容筛选，而不会影响合法通信的保密性。

TLS 检查的工作原理是什么？

通过 TLS 检查，组织可以通过解密加密网络流量进行安全检查，并在将网络流量转发到目标之前对其进行重新加密。 若要有效地实施 TLS 检查，请考虑以下作最佳做法：

  • 与用户明确通信：在生产环境中启用 TLS 检查之前，请确保告知用户加密流量的处理方式。 许多组织选择提供使用条款（ToU）或类似通知。
  • 选择证书颁发机构：选择根证书颁发机构或中间证书颁发机构，以对全局安全访问创建的证书签名请求（CSR）进行 TLS 检查。
  • 定义 TLS 策略：配置符合组织安全性和作要求的 TLS 检查策略。
  • 配置条件访问：创建条件访问策略，并将其与链接到 TLS 策略的全局安全访问安全配置文件相关联。
  • 分发受信任的证书：确保所有客户端设备上都安装了所选证书颁发机构，以建立信任并启用无缝 TLS 检查。

生成用于 TLS 检查的证书时需要哪些加密算法？

全局安全访问目前支持对签名证书使用 SHA-256、SHA-384 和 SHA-512。

如何使用 Active Directory 证书服务对 CSR 进行签名（AD CS）

TLS 检查需要中间证书颁发机构，确保使用的是从属 CA 模板。 若要对 TLS 设置生成的 CSR 进行签名，可以使用 AD CS Web 注册 UI 或使用 certreq 命令行工具。

certreq -submit -attrib "CertificateTemplate:SubCA" "C:\pathtoyourCSR\tlsca.csr" "tlsca.cer"

为什么在使用 Git 时收到“SSL 证书问题无法获取本地颁发者证书”错误？

发生此错误的原因是某些开发人员工具（如 Git）默认不使用作系统的证书存储;而是维护自己的证书存储。 你可以将 git 定向到使用 Windows 的证书存储：

git config --global http.sslbackend schannel

或将证书追加到 Git 的证书颁发机构捆绑包。 以下 PowerShell 脚本演示如何将证书添加到 Windows 系统上的 Git CA 捆绑包。

# Define the path to your custom root Certificate Authorities
  $certPath = "./myTLSInspectionRootCA.crt"
# Verify the certificate file exists
  if (-Not (Test-Path $certPath)) {
  Write-Host "Certificate file not found at $certPath"
  exit 1
  }
# --- Git Configuration ---
 $gitCAPath = git config --get http.sslcainfo
 if ($gitCAPath) {
 try {
 Get-Content $certPath | Add-Content -Path $gitCAPath
 Write-Host "Certificate appended to Git CA bundle at $gitCAPath"
 } catch {
 Write-Host "Failed to append certificate to Git CA bundle $_"
}
} else {
Write-Host "Git CA bundle path not found. Is Git installed and configured?"
}

什么是证书固定，以及它如何影响 TLS 检查？

证书固定是一种安全机制，可将应用程序的 TLS 连接限制为一组特定的受信任证书或公钥。 证书固定可确保应用程序仅与提供这些确切凭据的服务器通信，即使其他证书有效且受系统信任。 此方法通过防止未经授权的拦截加密流量，帮助抵御中间人（MITM）攻击。 但是，它还会干扰依赖于 TLS 检查的网络安全工具，这些工具的工作原理是使用中间证书解密和重新加密流量。

应如何处理使用证书固定的应用程序？

如果 TLS 检查终止了使用证书固定的应用程序的流量，则连接将失败。 为了确保应用程序按预期工作，请在流量转发配置文件中创建自定义绕过规则，以从全局安全访问中排除来自这些应用程序的流量。 可以在 Internet 访问转发配置文件中的自定义绕过中执行此操作。 我们正在努力制定自定义 TLS 规则，以便仅获取流量并绕过 TLS 检查。

是否支持 TLS 1.3？

Microsoft Entra TLS 检查默认启用 TLS 1.2 和 TLS 1.3。 为会话选择了最高相互支持的版本，从客户端到全局安全访问，从全局安全访问到目标。 Microsoft Entra 不支持使用加密客户端 Hello （ECH） 的 TLS 1.3，因为服务器名称指示（SNI）已加密，这可以防止全局安全访问为 TLS 终止创建相应的叶证书。

如果旧版应用程序使用不安全的 TLS 版本（如 TLS 1.1），会发生什么情况？

建议绕过这些目标的 TLS 检查。 TLS 1.2 是建议的最低版本，因为较旧版本（如 TLS 1.1 和 TLS 1.0）不安全且容易受到攻击。 如果可能，请移动这些应用程序以支持 TLS 1.2 或更高版本。

是否使用硬件安全模块 （HSM） 来保护密钥？

我们使用受软件保护的密钥。 全局安全访问中间证书密钥存储在内存中，以动态生成网站的叶证书。 虽然这些密钥不受 HSM 的保护，但对服务器的访问受到高度限制，我们使用严格的安全控制来保护密钥访问和系统完整性。

其他哪些全局安全访问功能依赖于 TLS 检查？

基于内容的安全控制依赖于 TLS 检查，包括 URL 增强的 Web 类别筛选、反恶意软件、DLP、ATP 等。 此外，全局安全访问块通知要求启用 TLS 检查。

相关内容