传输层安全性 (TLS) 协议使用传输层上的证书来确保两个通信方之间交换的数据的隐私、完整性和真实性。 虽然 TLS 保护合法流量,但恶意软件和数据泄露攻击等恶意流量仍可隐藏在加密后面。 Microsoft Entra Internet Access 的 TLS 检查功能通过使加密流量变得可见,从而提供增强保护,例如恶意软件检测、数据丢失防护、即时检查和其他高级安全控制。 本文概述了 TLS 检查过程。
TLS 检查过程
启用 TLS 检查时,全局安全访问会在服务边缘解密 HTTPS 请求,并应用安全控制,例如完整的 URL 增强 Web 内容筛选策略。 如果没有安全控制阻止请求,全局安全访问将加密并将请求转发到目标。
若要启用 TLS 检查,请执行以下步骤:
- 在全局安全访问门户中生成证书签名请求(CSR),并使用组织的根证书颁发机构或中间证书颁发机构对 CSR 进行签名。
- 将签名的证书上传到门户。
Global Secure Access 使用此证书作为 TLS 检查的中间证书颁发机构。 在流量拦截期间,Global Secure Access 使用中级证书动态生成短期有效的叶子证书。 TLS 检查建立两个单独的 TLS 连接:
- 从客户端浏览器到全局安全访问服务边缘的一个连接
- 从全局安全访问到目标服务器的一个
全球安全访问服务在客户端设备与服务之间进行的 TLS 握手期间使用叶子证书。 若要确保成功握手,请在所有客户端设备上的受信任证书存储中安装根证书颁发机构和中间证书颁发机构(如果用于对 CSR 进行签名)。
流量日志包括四个与 TLS 相关的元数据字段,可帮助你了解如何应用 TLS 策略:
- TlsAction:绕过或截获
- TlsPolicyId:应用 TLS 策略的唯一标识符
- TlsPolicyName:用于简化引用的 TLS 策略的可读名称
- TlsStatus:成功或失败
若要开始使用 TLS 检查,请参阅 “配置传输层安全性”。
支持的密码算法
| 支持的密码列表 |
|---|
| ECDHE-ECDSA-AES128-GCM-SHA256 |
| ECDHE-ECDSA-CHACHA20-POLY1305 |
| ECDHE-RSA-AES128-GCM-SHA256 |
| ECDHE-RSA-CHACHA20-POLY1305 |
| ECDHE-ECDSA-AES128-SHA |
| ECDHE-RSA-AES128-SHA |
| AES128-GCM-SHA256 |
| AES128-SHA |
| ECDHE-ECDSA-AES256-GCM-SHA384 |
| ECDHE-RSA-AES256-GCM-SHA384 |
| ECDHE-ECDSA-AES256-SHA |
| ECDHE-RSA-AES256-SHA |
| AES256-GCM-SHA384 |
| AES256-SHA |
已知的限制
TLS 检查具有以下已知限制:
- TLS 检查最多支持 100 个策略、1000 个规则和 8000 个目标。
- 确保生成的每个证书签名请求(CSR)都具有唯一的证书名称,并且不会重复使用。 签名的证书必须至少保持有效 6 个月。
- 一次只能使用一个活动证书。
- TLS检查不支持Application-Layer协议协商(ALPN)版本2。 如果目标站点需要 HTTP/2,上游 TLS 握手将会失败,并且在启用 TLS 检查时,无法访问该站点。
- 验证目标证书时,TLS 检查不遵循颁发机构信息访问(AIA)和联机证书状态协议(OCSP)链接。
移动平台
- 许多移动应用程序实现证书固定,从而防止 TLS 检查成功,导致握手失败或功能丢失。 若要降低风险,请先在测试环境中启用 TLS 检查,并验证关键应用程序是否兼容。 对于依赖于证书钉扎的应用,请配置 TLS 检查的自定义规则,以使用基于域的规则或基于类别的规则避开这些目标。