Cloud Design Patterns (Part 2): The Gatekeeper Security Pattern

With this post, I am continuing a series of post on cloud design patterns. These patterns are mostly generic and can be used with any cloud provider, but in this series, I will mainly focus on the Azure.

In this post, we will see the Gatekeeper design pattern.

Gatekeeper Pattern in Simple Words

• This pattern provides an extra layer of security to your applications and services that are hosted in the cloud.
• A gatekeeper is a middleman between the client and the applications/services/APIs, etc. that generally validates the requests and passes only valid requests.
• The Gatekeeper has limited access and does not contain important information like access details, etc.

As per the Microsoft team:

• Protect applications and services by using a dedicated host instance that acts as a broker between clients and the application or service, validates and sanitizes requests, and passes requests and data between them.
• This can provide an additional layer of security, and limit the attack surface of the system.

Hence, we can imagine the Gatekeeper as a security guard standing at our main door in our day-to-day life. If it helps, we can imagine a Gatekeeper as a firewall in a typical network topography.

Examples

• As you can see here, whenever the client tries to access the host, it needs to face the Gatekeeper first.
• If the Gatekeeper allows the client request (if the validation returns true), the client can access the services or the storage.
• Please note that the Gatekeeper does not have the access keys and tokens, it just validates and filters the requests. That is the only job of the Gatekeeper.

Things to Consider While Using This Pattern

• The Gatekeeper should not hold any access keys or tokens.
• The Gatekeeper should not perform any operations related to the services or the data storage, the only job of gatekeeper is to validate and filter the requests.
• The Gatekeeper should be simple, if the Gatekeeper is compromised, it should not require any major actions to be taken immediately.
• The Gatekeeper can be designed to be a single point of failure. That is why it should be always up and running on production.
• The Gatekeeper may have a negative impact on the performance of the system, so you should first test before implementing it directly into the production environment.
• The Gatekeeper should have monitoring and alerting capabilities.
• Use secured connections like HTTPS, SSL, and TLS between the Gatekeeper and the trusted host.

When Should I Use the Gatekeeper Pattern?

You should use the Gatekeeper pattern:

• When your application needs to be in a high-security environment because of the sensitive information it carries.
• When there is a need to have a centralized validation and filtering system in your distributed environment.
• When you want to secure your sites/services/APIs that have very sensitive data from attacks like SQL injection, cross-site scripting, session hijack, DOS, etc.

How Can We Use the Gatekeeper Pattern in Azure?

In Azure, there are not any services with the name Gatekeeper or Gateway, but there are a few services that you can use to implement the Gatekeeper design pattern. For example, you can either use For example, you can either use Application Gateway or some sort of API Management in Azure.

Some major advantages of the Gatekeeper pattern in Azure are:

• Scalable, highly available web application delivery
• Web application firewall
• Efficient, secure web front end
• Close integration with Azure services and many more

Note – As per my knowledge and as per this thread, I have mentioned two services that can be used in Azure for the Gatekeeper, but there might be some more. I have already asked a question on SO for this, and if you know anything more on this, then comment here or answer the question.

Hope it helps.