守护程序模式

通过使用专用主机实例在客户端与应用程序或服务之间中转请求来保护应用程序和服务。 中转站将会验证和清理请求，并且可以提供额外的安全层并限制系统的攻击面。

上下文和问题

云服务将会暴露在允许客户端应用程序调用其 API 的终结点之下。 用于实现 API 的代码可触发或执行多个任务，包括但不限于身份验证、授权、参数验证以及部分或全部请求处理。 API 代码可能会代表客户端访问存储服务和其他服务。

如果恶意用户入侵了系统并获取了对应用程序托管环境的访问权限，那么其安全机制以及对数据和其他服务的访问权限便已被攻破。 因此，恶意用户可以无限制地访问凭据、存储密钥、敏感信息和其他服务。

解决方案

此问题的一个解决方案是，将实现公共终结点的代码与处理请求和访问存储的代码分离。 你可通过使用某个门面或专用任务完成此操作，该门面或专用任务将与客户端交互，然后将请求提交（可能是通过一个分离的接口）到将要处理该请求的主机或任务。 图提供了此模式的综合概述。

守护程序模式可用于保护存储，或者用作更全面的保护层来保护应用程序的所有功能。 重要因素是：

• 受控的验证。 守护程序会验证所有请求，并拒绝不满足验证要求的请求。
• 有限的风险和公开。 守护程序不能访问受信任主机访问存储和服务所用的凭据或密钥。 如果守护程序受到攻击，攻击者无权访问这些凭据或密钥。
• 适当的安全性。 守护程序在有限特权模式下运行，而其他应用程序在访问存储和服务所需的全信任模式下运行。 如果守护程序受到攻击，那么它不能直接访问应用程序服务或数据。

此模式就像典型网络拓扑中防火墙。 它支持 Gatekeeper 检查请求，并决定是否将请求传递到执行所需任务的受信任主机。 此决策通常需要守护程序验证和整理请求内容，然后再将它传递到受信任主机。

问题和注意事项

在决定如何实现此模式时，请考虑以下几点：

• 请确保受信任的主机仅暴露在内部或受保护的终结点之下，且这些终结点仅供守护程序使用。 受信任的主机不应公开任何外部终结点或接口。
• 守护程序必须在受限特权模式下运行，这通常需要在单独的托管服务或虚拟机中运行守护程序和受信任的主机。
• 守护程序不应执行与应用程序或服务有关的任何处理或访问任何数据。 其作用仅是用于验证并整理请求。 受信任的主机可能需要执行额外的请求验证，但守护程序应该执行核心验证。
• 请尽可能在守护程序与受信任的主机或任务之间使用安全信道（HTTPS、SSL 或 TLS）。 但是，某些宿主环境在内部终结点上不支持 HTTPS。
• 添加此附加层来实现守护程序模式可能会对性能造成影响（因为它需要额外的处理和网络通信）。
• 守护程序实例可能是单点故障。 若要尽量减少失败的影响，请考虑部署冗余实例并使用自动扩缩机制，以确保具有维持可用性的容量。

何时使用此模式

对于存在以下情况的应用程序，此模式非常有用：

• 处理敏感信息
• 面对的是需要高度防范恶意攻击的服务
• 执行不能中断的任务关键型操作。
• 需要与主要任务分开执行请求验证，或者集中进行该验证以简化维护和管理工作

工作负荷设计

架构师应评估如何在其工作负荷的设计中使用“守护程序模式”，以解决 Azure Well-Architected Framework 支柱中涵盖的目标和原则。 例如：

与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。

示例

在云托管场景中，可以通过将守护程序角色或虚拟机与应用程序中的受信任角色和服务进行分离来实现此模式。 该实现可以将内部终结点、队列或存储用作中间通信机制。 本图演示了如何使用内部终结点。

相关资源

当执行守护程序模式时，Valet 密钥模式可能也相关。 在 Gatekeeper 和受信任的角色之间通信时，可通过限制访问资源权限的密钥或令牌增强安全。 该模式描述了如何使用令牌或密钥让客户端以有限方式直接访问特定资源或服务。