Azure设计模式之看门人模式
看门人模式
通过在客户端和应用程序或服务间使用专门的代理保护应用程序与服务,对请求进行验证或过滤,并在它们之间传递请求与数据。这样就提供了额外的安全层,并降低了系统被攻击的范围。
问题背景
应用程序通过接受和处理网络请求向客户端提供功能。在云方案中,应用程序连接到终端中,通常包括用于处理客户端请求的代码。该代码执行身份验证、部分或全部的请求处理,可能也会访问存储和其他服务。
如果存在恶意代码蓄意破坏系统并访问应用程序的宿主环境,那么所使用的安全机制(如凭据和存储密钥)以及所访问的服务甚至数据都将被公开。这样一来,恶意用户可以无限制地获取敏感信息并访问其他服务。
解决方案
若要使敏感信息和服务被恶意代码访问的风险降至最低,需要将公开终端的主机或与请求处理以及存储的代码进行解耦。可使用外观模式专门与客户端或使用专用任务来实现这一点,然后将请求(可能通过解耦接口)交给将处理该请求的主机或任务。下图提供了此模式的介绍。
网关守卫模式可用来保护存储,也可用作保护应用程序的所有功能。包括如下重要因素:
控制验证。网关守卫验证所有请求,拒绝那些不符合验证的请求。
降低了暴露太多信息的风险。网关守卫没有对存储和服务的访问权限，因为没有凭据或密钥。如果网关守卫被破坏,攻击者依然无法获得这些凭据或密钥。
相对安全。网关守卫在有限的权限模式下运行,而应用程序的其余部分以访问存储和服务所需的完全信任模式运行。如果网关守卫被破坏,它就不能直接访问应用程序服务或数据。这种模式在网络中起着类似防火墙的作用。它允许网关守卫检查请求并决定是否将请求传递到执行所需任务的受信任主机(有时称为开锁)。此决定通常要求网关守卫在将请求内容传递到受信任主机之前对其进行验证。
问题和注意事项
在决定如何实现此模式时, 需要考虑以下几点:
确保内部受保护的终端处理的请求都经过网关。受信任的主机不应公开任何外部终结点或接口。
网关守卫必须以有限权限模式运行。通常,这意味着在独立的托管服务或虚拟机中运行网关守卫和受信任主机。
网关守卫不应执行与应用程序或服务相关的任何处理逻辑,也不应访问任何数据。它的功能纯粹是为了验证和净化请求。受信任的主机可能需要对请求执行其他验证, 但核心验证应由网关守卫来执行。
在网关守卫和受信任的主机或任务之间使用安全通信通道(HTTPS、SSL或TLS)。但是,某些宿主环境不支持内部端点的HTTPS。
将额外层添加到应用程序以实现网关守卫模式可能会对性能产生一定的影响,这是因为它需要额外的处理和网络通信。
网关守卫实例可能是单点故障。若要将故障的影响降至最低,考虑部署其他实例并使用自动伸缩机制来确保对可用性进行维持。
何时使用此模式
此模式适用于:
处理敏感信息的应用程序,需要暴露具有高度保护免受恶意攻击的服务,或执行无中断任务中的关键操作。
分布式应用程序,执行请求验证与主要任务分离,可将验证集中管理,以简化维护和管理。
例如
在云方案中,可通过将网关守卫角色或虚拟机从应用程序中的受信任角色和服务中解耦来实现此模式。通过使用内部端点、队列或存储作为中间通信机制来执行此过程。下图说明了如何使用内部端点。
相关模式
在实现网关守卫模式时,代客密钥模式（https://docs.microsoft.com/en-us/azure/architecture/patterns/valet-key）也可能是相关的。在网关守卫和受信任角色之间进行通信时,最好使用限制访问资源权限的密钥或标记来提高安全性。并通过描述如何使用令牌或键值来为客户提供对特定资源或服务的受限访问。
通过在客户端和应用程序或服务间使用专门的代理保护应用程序与服务,对请求进行验证或过滤,并在它们之间传递请求与数据。这样就提供了额外的安全层,并降低了系统被攻击的范围。
问题背景
应用程序通过接受和处理网络请求向客户端提供功能。在云方案中,应用程序连接到终端中,通常包括用于处理客户端请求的代码。该代码执行身份验证、部分或全部的请求处理,可能也会访问存储和其他服务。
如果存在恶意代码蓄意破坏系统并访问应用程序的宿主环境,那么所使用的安全机制(如凭据和存储密钥)以及所访问的服务甚至数据都将被公开。这样一来,恶意用户可以无限制地获取敏感信息并访问其他服务。
解决方案
若要使敏感信息和服务被恶意代码访问的风险降至最低,需要将公开终端的主机或与请求处理以及存储的代码进行解耦。可使用外观模式专门与客户端或使用专用任务来实现这一点,然后将请求(可能通过解耦接口)交给将处理该请求的主机或任务。下图提供了此模式的介绍。
网关守卫模式可用来保护存储,也可用作保护应用程序的所有功能。包括如下重要因素:
控制验证。网关守卫验证所有请求,拒绝那些不符合验证的请求。
降低了暴露太多信息的风险。网关守卫没有对存储和服务的访问权限，因为没有凭据或密钥。如果网关守卫被破坏,攻击者依然无法获得这些凭据或密钥。
相对安全。网关守卫在有限的权限模式下运行,而应用程序的其余部分以访问存储和服务所需的完全信任模式运行。如果网关守卫被破坏,它就不能直接访问应用程序服务或数据。这种模式在网络中起着类似防火墙的作用。它允许网关守卫检查请求并决定是否将请求传递到执行所需任务的受信任主机(有时称为开锁)。此决定通常要求网关守卫在将请求内容传递到受信任主机之前对其进行验证。
问题和注意事项
在决定如何实现此模式时, 需要考虑以下几点:
确保内部受保护的终端处理的请求都经过网关。受信任的主机不应公开任何外部终结点或接口。
网关守卫必须以有限权限模式运行。通常,这意味着在独立的托管服务或虚拟机中运行网关守卫和受信任主机。
网关守卫不应执行与应用程序或服务相关的任何处理逻辑,也不应访问任何数据。它的功能纯粹是为了验证和净化请求。受信任的主机可能需要对请求执行其他验证, 但核心验证应由网关守卫来执行。
在网关守卫和受信任的主机或任务之间使用安全通信通道(HTTPS、SSL或TLS)。但是,某些宿主环境不支持内部端点的HTTPS。
将额外层添加到应用程序以实现网关守卫模式可能会对性能产生一定的影响,这是因为它需要额外的处理和网络通信。
网关守卫实例可能是单点故障。若要将故障的影响降至最低,考虑部署其他实例并使用自动伸缩机制来确保对可用性进行维持。
何时使用此模式
此模式适用于:
处理敏感信息的应用程序,需要暴露具有高度保护免受恶意攻击的服务,或执行无中断任务中的关键操作。
分布式应用程序,执行请求验证与主要任务分离,可将验证集中管理,以简化维护和管理。
例如
在云方案中,可通过将网关守卫角色或虚拟机从应用程序中的受信任角色和服务中解耦来实现此模式。通过使用内部端点、队列或存储作为中间通信机制来执行此过程。下图说明了如何使用内部端点。
相关模式
在实现网关守卫模式时,代客密钥模式（https://docs.microsoft.com/en-us/azure/architecture/patterns/valet-key）也可能是相关的。在网关守卫和受信任角色之间进行通信时,最好使用限制访问资源权限的密钥或标记来提高安全性。并通过描述如何使用令牌或键值来为客户提供对特定资源或服务的受限访问。