守门员模式

通过使用充当客户端和应用程序或服务之间的代理，验证和进行消毒的请求，并将它们之间的请求和数据的专用主机实例保护的应用程序和服务。这可以提供一个额外的安全层，并限制了系统的攻击面。

背景和问题

应用程序通过接受和处理请求揭露它们的功能提供给客户。在云托管方案，应用程序暴露终端客户机连接，一般包括代码来处理来自客户端的请求。此代码可以执行认证和验证，一些或所有请求的处理，并有可能访问存储等服务代表客户端的。

如果恶意用户能够危及系统和访问应用程序的托管环境，它使用安全机制，诸如凭证和存储密钥，并且该服务并访问数据，被暴露。因此，恶意用户可能能够获得无节制访问敏感信息和其他服务。

为了尽量减少接触到敏感信息和服务客户的风险，去耦，揭露出从处理请求并访问存储在代码公共端点的主机或任务。这可以通过使用一个立面或专用任务，与客户端进行交互，然后手拿开的请求（可能通过一个去耦接口）连接到主机或任务将要处理的请求来实现。图1示出了这种方法的一个高层视图。

图1 - 这种模式的高级概述

守门员模式可以简单地用来保护存储，或者它可被用作一个更全面的立面，以保护所有的应用程序的功能。的重要因素是：

控制验证。守门员验证所有请求，并拒绝那些不符合验证要求。
有限的风险和曝光。守门员不具有访问所使用的可信主机访问存储和服务的凭证或密钥。如果关守被攻破，攻击者无法获得访问这些凭据或密钥。
适当的安全性。守门员运行在一个有限的特权模式，而应用程序的其余部分在访问存储和服务所需要的完全信任模式下运行。如果关守被破坏，它不能直接访问应用程序的服务或数据。

此图案有效地作用就像一个防火墙在一个典型的网络拓扑。它允许关守来检查请求并做出关于是否将请求传递到可信主机决定（有时也被称为钥匙之王），执行所需的任务。这一决定通常需要守门员来验证并将其传递到受信任主机前消毒要求的内容。

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

确保受信任主机到网守请求通过仅暴露内部或保护端点，只有连接到守门员。受信任主机不应该暴露任何外部端点或接口。
关守必须在有限的特权模式下运行。通常，这意味着运行守门员和独立的托管服务或虚拟机的可信主机。
关守不应该执行相关的应用程序或服务，或访问任何数据的任何处理。它的功能是纯粹的验证和消毒要求。受信任的主机可能需要执行的请求额外的验证，但核心的验证应该由守门员进行。
使用守门员和信任的主机或任务，如果这是可能的之间的安全通信通道（HTTPS，SSL或TLS）。然而，一些托管环境可能不支持HTTPS内部端点。
添加额外的层，以实现守门员模式的应用有可能对应用程序的性能造成一定影响，由于它需要额外的处理和网络通信。
关守实例可能是一个单点故障。为了最大限度地减少故障的影响，考虑部署其他实例，并使用自动缩放机制，以确保有足够的能力来保持可用性。

这种模式非常适合于：

在一个云托管的情况下，该模式可以通过使用一个内部端点，一个队列，或存储作为中间通信机制解耦从受信任的角色和服务应用程序中的关守角色或虚拟机来实现。图 2 示出了使用内部的端点时的基本原则。

图 2 - 的模式使用云服务的网络和辅助角色的一个例子