使用 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，以便通过 access 和 session 策略提供实时监视和控制。

流量终止

所有流量都在云中终止。

由于Microsoft Entra应用程序代理是反向代理，因此发往后端应用程序的所有流量都会在服务中终止。 该服务仅与后端服务器重新建立会话，这意味着后端服务器不会直接暴露给 HTTP 流量。 此配置意味着更好地保护你免受目标攻击。

所有访问都是出站访问

无需打开连接到公司内部网络的入站连接。

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

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

远程访问服务

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

未修补的软件仍会造成大量攻击。 Microsoft Entra应用程序代理是Microsoft拥有的、具备互联网级别的服务，所以始终获得最新的安全修补程序和升级。

为了提高Microsoft Entra应用程序代理发布的应用程序的安全性，应用程序代理会阻止 Web 爬网程序机器人对应用程序编制索引和存档。 每次 Web 爬网程序机器人尝试检索已发布应用的机器人设置时，应用程序代理都会使用包含 User-agent: * Disallow: /的 robots.txt 文件进行答复。

Microsoft分布式拒绝服务 （DDoS） 保护服务

通过应用程序代理发布的应用程序受到分布式拒绝服务（DDoS）攻击的保护。 Microsoft在所有数据中心自动启用此保护。 Microsoft DDoS 防护服务提供始终开启的流量监控，并对常见网络级攻击进行实时缓解。

揭秘

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

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

在以下情况下建立连接器与应用程序代理服务之间的流：

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

连接器使用客户端证书对应用程序代理服务进行身份验证，进行几乎所有调用。 此过程的唯一例外是建立客户端证书的初始设置步骤。

安装连接器

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

1. 连接器在安装过程中向服务注册。 安装程序会提示用户输入其Microsoft Entra管理员凭据。 然后，将从此身份验证中获得的令牌呈现给 Microsoft Entra 应用程序代理服务。
2. 应用程序代理服务会评估令牌。 它会检查用户是否至少是租户中的应用程序管理员。 如果用户不是，进程将终止。
3. 连接器生成客户端证书请求，并将其连同令牌一起传递给应用程序代理服务。 服务反过来会验证令牌并签署客户端证书请求。
4. 连接器使用客户端证书与应用程序代理服务的未来通信。
5. 连接器使用其客户端证书从服务执行系统配置数据的初始拉取，并已准备好接受请求。

更新配置设置

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

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

访问已发布的应用程序

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

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

若要详细了解这些步骤中发生的情况，请继续阅读。

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

如果应用程序使用直通作为预身份验证方法，请跳过本部分步骤。

Microsoft Entra ID将用户重定向到 STS，以便在应用程序配置为使用 Microsoft Entra ID 进行预身份验证时进行身份验证。 执行以下步骤：

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。

后续步骤

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