你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
通过使用专用组件在客户端与应用程序或服务之间代理请求来保护应用程序和服务。 中转站验证和清理请求，并提供额外的安全层并限制系统的攻击面。
上下文和问题
许多云服务公开了允许客户端应用程序通过 Internet 或其他不受信任的网络调用其 API 的终结点。 实现 API 的代码触发或执行多个任务，包括但不限于身份验证、授权、参数验证和部分或所有请求处理。 API 代码很可能以客户端的身份访问存储和其他服务。
如果恶意用户入侵了系统并获取了对应用程序托管环境的访问权限，那么其安全机制以及对数据和其他服务的访问权限便已被攻破。 因此，恶意用户可以无限制地访问凭据、存储密钥、敏感信息和其他服务。
解决方案
此问题的一个解决方案是将实现公共终结点的代码与处理请求和访问存储的代码分离。 通过使用外观层来分离代码，该层与客户端交互，并通过内部终结点、队列或中转站将批准的请求路由到处理业务操作的工作负荷组件。 此图提供了此模式的高级概述。
可以使用 Gatekeeper 模式来保护存储，也可以将其用作更全面的外观来保护应用程序的所有功能。 重要因素包括：
受控验证： 守护程序会验证所有请求，并拒绝不符合验证要求的请求。
风险和风险有限： 风险和暴露会降低，因为守护程序无法访问受信任的主机用于访问存储和服务的凭据或密钥。 如果守护程序遭到入侵，攻击者无法访问这些凭据或密钥。
适当的安全性： 守护程序以有限的特权模式运行，而应用程序的其余部分则以访问存储和服务所需的完全信任模式运行。 如果守护程序受到攻击，那么它不能直接访问应用程序服务或数据。
此模式就像典型网络拓扑中防火墙。 与传统防火墙不同，它允许守护程序详细检查请求，并做出应用程序驱动的决策，了解如何将请求传递给执行所需任务的受信任主机。 此决定通常需要守护程序在将请求内容传递给受信任的主机之前对其进行验证和清理。 守护程序可能会授权请求、查找意外或无效的有效负载内容、执行速率限制和执行各种其他检查。
问题和注意事项
在决定如何实现此模式时，请考虑以下几点：
确保受信任的主机只暴露仅供 Gatekeeper 使用的内部或受保护端点。 受信任的主机不应公开任何外部终结点或接口。
守护程序必须在受限特权模式下运行。 在实践中，在单独的计算边界上托管守护者和受信任的后端，并使后端终结点保持私密。
守护程序不应执行与应用程序或服务或访问数据相关的处理。 其函数仅用于验证和清理请求。 受信任的主机可能需要执行额外的请求验证，但守护程序应执行核心验证。
尽可能在守护程序与受信任的主机或任务之间使用安全信道，例如 HTTPS、安全套接字层（SSL）或传输层安全性（TLS）。 但是，某些宿主环境在内部终结点上不支持 HTTPS。
添加额外的层来实现 Gatekeeper 模式可能会影响性能，因为需要额外的处理和网络通信。
守护程序可以是单一故障点（SPoF）。 若要尽量减少故障的影响，请考虑部署冗余实例并使用自动缩放机制来确保容量和维护可用性。
何时使用此模式
在以下情况下使用此模式：
你处理敏感信息。
您对外提供的服务需要具备抵御恶意流量的强有力防护。
您执行的关键任务操作无法容忍后端服务直接暴露。
需要请求验证和清理，以便与核心业务处理分开。
在以下情况下，此模式可能不适用：
可以通过后端服务上的内置平台控制来满足安全性和验证要求，而无需添加专用守护程序层。
新增的网络跳转和验证延迟无法满足严格的端到端延迟要求。
工作负载设计
评估如何在工作负荷的设计中使用 Gatekeeper 模式来解决 Azure Well-Architected Framework 支柱中涵盖的目标和原则。 下表提供有关此模式如何支持每个支柱目标的指南。
| 支柱 | 此模式如何支持支柱目标 |
|---|---|
| 安全设计决策有助于确保工作负荷数据和系统的机密性、完整性和可用性。 | 请求流中的守护程序可帮助集中安全功能，例如 Web 应用程序防火墙、DDoS 保护、机器人检测、请求操作、身份验证启动和授权检查。 - SE:06 网络控制措施 - SE:10 监控和威胁检测 |
| 通过缩放、数据和代码的优化，性能效率可帮助工作负荷高效地满足需求。 | 可以使用此模式在守护程序级别实现限制，而不是在节点级别实现速率检查。 所有节点之间的速率状态协调本身并不高效。 - PE：03 选择服务 |
如果此模式在某个支柱中引入权衡取舍，请将它们与其他支柱的目标进行对比。
Example
Gatekeeper 模式通常实现分层请求路径，其中每个层都有特定的责任和有限的信任范围。
下载此体系结构的 Visio 文件。
在此设计中，Azure 应用程序网关 和 Azure Web 应用程序防火墙 充当最外层守门人。 它会检查面向 Internet 的流量，并在流量到达 API 层之前应用安全控制。 Azure API 管理是内部守门人。 它应用特定于 API 的控件，并将已批准的流量转发到专用后端。
例如，Azure Web 应用程序防火墙可以检测和阻止 SQL 注入和跨站点脚本模式，强制实施协议和请求大小规则，并在请求到达 API 管理或专用后端之前应用基于机器人和 IP 的筛选。
在内部层使用 API 管理时，它会将策略应用于网关管道中的入站请求和出站响应。 有关 API 管理如何处理请求和响应的详细信息，请参阅 API 管理中的策略。 有关 JSON Web 令牌（JWT）验证、速率限制、标头转换和响应调整等策略选项，请参阅 API 管理策略参考。
在此路径中，统一使用Azure 资源的托管标识进行服务间身份验证。 例如，API 管理可以使用具有托管标识策略的 authenticate在不存储机密的情况下获取后端调用的Microsoft Entra令牌。
后端保持私密。 例如，后端可以是一个使用 专用终结点 的 Azure 应用服务 应用，这样便可对该应用进行专用访问。
对于容器化工作负荷，替代方法可将 API 管理加上应用服务内部路径替换为基于入口的计算：
Azure Kubernetes 服务 (AKS)，可让你更好地控制入口控制器选择、Kubernetes 策略、网络拓扑和群集操作。
Azure 容器应用是一个无服务器托管容器平台，它提供入口功能并减少基础设施管理工作。
在这些替代方法中，入口可以通过主机或路径路由、终止 TLS 并公开仅限内部的服务。 请求限制和允许或拒绝规则等特定功能取决于所选入口实现。 在所有情况下，保留守护程序边界：在入口应用验证和策略强制实施，并使后端服务只能通过该守护程序路径访问。
该路径中的每一层都会产生日志和指标，你应该将它们集中管理。 Azure Web 应用程序防火墙诊断日志会为每个请求记录匹配到和被阻止的规则。 API 管理发出网关日志，用于捕获请求持续时间、响应代码和策略结果。 后端服务发送应用程序级遥测数据。 在 Azure Monitor 中收集这些日志和指标，并将其路由到 Log Analytics 工作区进行统一查询。 通过在边缘生成或转发相关 ID，并通过 API 管理和后端服务（例如，通过请求标头和分布式跟踪上下文）来标准化端到端请求关联，以便单个事务在所有层中保持可跟踪。 使用 Microsoft Defender for Cloud 显示针对各个 Gatekeeper 组件的安全建议。 为 Azure Web 应用程序防火墙阻止率异常或 API 管理错误激增配置警报，以便在威胁到达专用后端系统之前将其检测出来。
后续步骤
实现此模式时，以下指南可能相关：
相关资源
以下云设计模式通常与 Gatekeeper 模式一起使用：