使用 Microsoft Entra 应用程序代理远程访问应用时的安全注意事项

本文介绍了在使用 Microsoft Entra 应用程序代理时，能够保证用户和应用程序安全的组件。

下图显示了 Microsoft Entra ID 如何实现对本地应用程序的安全远程访问。

安全优势

Microsoft Entra 应用程序代理有许多安全优势。 优势列表：

• 经过身份验证的访问
• 条件访问
• 流量终止
• 所有出站访问
• 云级分析和机器学习
• 以服务的形式进行远程访问
• Microsoft 分布式拒绝服务 (DDoS) 防护服务

经过身份验证的访问

使用 Microsoft Entra 预身份验证时，只有经过身份验证的连接才能访问网络。

Microsoft Entra 应用程序代理依赖 Microsoft Entra 安全令牌服务 (STS) 进行所有身份验证。 预身份验证的独特性质会阻止大量的匿名攻击，因为只有经过身份验证的标识才能访问后端应用程序。

如果选择“直通”作为预身份验证方法，则无法获得此优势。

条件性访问

在与网络建立连接之前应用更丰富的策略控制。

使用条件访问可以定义对允许用户访问应用程序的方式的限制。 可以基于位置、身份验证强度和用户风险配置文件，创建限制登录的策略。

还可以使用条件访问配置多重身份验证策略，为用户身份验证再添一层安全保障。 此外，还可以通过 Microsoft Entra 条件访问将应用程序路由到 Microsoft Defender for Cloud Apps，以便通过访问和会话策略提供实时监视和控制。

流量终止

所有流量在云中终止。

Microsoft Entra 应用程序代理是一个反向代理，因此，发往后端应用程序的所有流量会在服务上终止。 只能与后端服务器重建会话，这意味着，不会公开后端服务器来定向 HTTP 流量。 此配置意味着可以更好地抵御有针对性的攻击。

所有访问都是出站的

无需向企业网络打开入站连接。

专用网络连接器仅使用到 Microsoft Entra 应用程序代理服务的出站连接。 无需为传入连接打开防火墙端口。 传统代理要求部署外围网络（也称为“DMZ”、“外围安全区域”或“屏蔽子网”），并在网络边缘允许未经身份验证的连接进行访问。 使用应用程序代理，不需要部署外围网络，因为所有连接都是出站的，并且是通过安全通道建立的。

有关连接器的详细信息，请参阅了解 Microsoft Entra 专用网络连接器。

云级分析和机器学习

获得一流的安全保护。

由于属于 Microsoft Entra ID，因此应用程序代理使用 Microsoft Entra ID 保护（数据由 Microsoft 安全响应中心和反数字犯罪部门提供）。 我们会共同主动发现遭到入侵的帐户，并提供保护，以免出现高风险登录威胁。我们会考虑许多因素，以确定哪些登录尝试有高风险。 这些因素包括标记为受感染设备、对网络进行匿名化处理，以及非典型或不太可能的位置。

其中的许多报告与事件已通过某个 API 提供，便于与安全信息与事件管理 (SIEM) 系统集成。

以服务的形式进行远程访问

无需担心要维护和修补本地服务器。

未修补的软件仍会遭受大量攻击。 Microsoft Entra 应用程序代理是 Microsoft 拥有的一项 Internet 级服务，因此，用户始终可以获得最新的安全修补程序和升级。

为了提高 Microsoft Entra 应用程序代理发布的应用程序的安全性，我们会阻止 Web 爬网程序机器人存档应用程序或编制其索引。 每当 Web 爬网程序机器人尝试检索已发布的应用的机器人设置时，应用程序代理都会回复一个 robots.txt 文件，其中包含 User-agent: * Disallow: /。

Microsoft 分布式拒绝服务 (DDoS) 防护服务

通过应用程序代理发布的应用程序受到保护，以免遭分布式拒绝服务 (DDoS) 攻击。 Microsoft 自动在所有数据中心启用此保护。 Microsoft DDoS 防护服务提供始终可用的流量监视以及对常见网络级别攻击的实时缓解功能。

揭秘

Microsoft Entra 应用程序代理由两个部分组成：

• 基于云的服务：此服务在 Microsoft 云中运行，是建立外部客户端/用户连接的位置。
• 本地连接器：该连接器是一个本地组件，侦听来自 Microsoft Entra 应用程序代理服务的请求并处理与内部应用程序的连接。

发生以下情况时，会在连接器与应用程序代理服务之间建立流量：

• 首次设置连接器时。
• 连接器从应用程序代理服务中拉取配置信息。
• 用户访问发布的应用程序时。

注意

所有通信都通过 TLS 发生，始终从连接器发起，目标为应用程序代理服务。 该服务只会建立出站连接。

连接器在执行几乎所有的调用时，都会使用客户端证书向应用程序代理服务进行身份验证。 只有在执行初始设置步骤时，此过程才有所不同，因为客户端证书是在此步骤中建立的。

安装连接器

首次设置连接器时会发生以下流量事件：

1. 在安装连接器的过程中，将连接器注册到服务。 系统会提示用户输入其 Microsoft Entra 管理员凭据。 从此身份验证获取令牌，并将其提供给 Microsoft Entra 应用程序代理服务。
2. 应用程序代理服务评估该令牌。 它检查用户是否为租户中的全局管理员。 如果用户不是管理员，则终止此过程。
3. 连接器生成客户端证书请求，并将此请求连同令牌一起传递给应用程序代理服务。 该服务转而验证令牌并为客户端证书请求签名。
4. 以后，连接器将使用此客户端证书来与应用程序代理服务通信。
5. 连接器使用其客户端证书从服务执行初始的系统配置数据提取，并准备好接收请求。

更新配置设置

每当应用程序代理服务更新配置设置时，都会发生以下流量事件：

1. 连接器使用其客户端证书连接到应用程序代理服务中的配置终结点。
2. 验证客户端证书。
3. 应用程序代理服务向连接器返回配置数据（例如，连接器应属于的连接器组）。
4. 如果当前证书超过 180 天，连接器将生成新的证书请求。

访问发布的应用程序

当用户访问发布的应用程序时，应用程序代理服务与专用网络连接器之间发生以下事件：

1. 服务对应用用户进行身份验证
2. 服务在连接器队列中放入请求
3. 连接器处理来自队列的请求
4. 连接器等待响应
5. 服务将数据流式传输给用户

若要深入了解其中每个步骤的具体内容，请继续阅读下文。

1.服务对应用用户进行身份验证

如果应用程序使用直通作为其预身份验证方法，则跳过此部分中的步骤。

如果应用程序被配置为使用 Microsoft Entra ID 进行预身份验证，则用户会被重定向到 Microsoft Entra STS 进行身份验证。 执行以下步骤：

1. 应用程序代理会检查条件访问策略要求。 此步骤可确保将用户分配到该应用程序。 如果需要双重验证，身份验证序列会提示用户执行第二个身份验证方法。
2. Microsoft Entra STS 将为应用程序颁发已签名的令牌，并将用户重定向回应用程序代理服务。
3. 应用程序代理会验证令牌是否已颁发给正确的应用程序、是否已签名、是否有效。
4. 应用程序代理设置加密的身份验证 Cookie，以指示已成功地向应用程序进行身份验证。 该 Cookie 包含基于 Microsoft Entra ID 颁发的令牌的过期时间戳。 该 Cookie 还包含身份验证所基于的用户名。 该 Cookie 已使用只有应用程序代理服务知道的私钥加密。
5. 应用程序代理将用户重定向回到最初请求的 URL。

如果预身份验证步骤的任何一个环节失败，用户的请求会被拒绝，并向用户显示一条消息指出问题的起源。

2.服务在连接器队列中放入请求

连接器向应用程序代理服务保持打开出站连接。 传入某个请求时，服务会在一个打开的连接上将该请求排入队列，等待连接器提取。

该请求包含请求头、已加密 Cookie 中的数据、发出请求的用户，以及请求 ID。 虽然已加密 Cookie 中的数据会随请求一起发送，但不会发送身份验证 Cookie 本身。

3.连接器处理来自队列的请求。

应用程序代理基于请求执行以下操作之一：

• 如果请求是一个简单的操作（例如，像 RESTful API GET 请求一样在正文中不包含任何数据），则连接器将与目标内部资源建立连接并等待响应。

• 如果请求的正文中包含关联的数据（例如 RESTful API POST 操作），连接器将使用客户端证书与应用程序代理实例建立出站连接。 建立此连接是为了请求数据，并打开与内部资源的连接。 收到来自连接器的请求后，应用程序代理服务开始接受用户的内容并将数据转发到连接器。 连接器随之将数据转发到内部资源。

4.连接器等待响应。

完成向后端发送请求并传输所有内容后，连接器将等待响应。

收到响应后，连接器将与应用程序代理服务建立出站连接，以返回标头详细信息并开始流式传输返回的数据。

5.服务将数据流式传输给用户。 

此时会对应用程序进行一些处理。 例如，应用程序代理会转换标头或 URL。

后续步骤

• 应用程序代理网络拓扑
• 专用网络连接器