You can find my all .Net core posts here.
By this post, I am starting the 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 one more Security pattern which is Gatekeeper design pattern.
Gatekeeper pattern in simple words
- This pattern provides an extra layer of security to your applications and services which are hosted in the cloud
- A gatekeeper is a middleman between the client and the applications\services\APIs etc which generally validates the requests and passes only valid requests
- 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 Gatekeeper as a security guard standing at our main door in our day to day life and we can imagine Gatekeeper as a firewall in a typical network topography.
- As you can see here, whenever the client tries to access the host, it needs to face the Gatekeeper first
- If 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 the tokens, it just validates and filters the requests. That is the only job of 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 the alerting capability
- Use secured connection like HTTPS, SSL, TLS between the gatekeeper and the trusted host
When should I use Gatekeeper pattern?
This question may arise in your mind that when should I use this Gatekeeper pattern.
You should use the Gatekeeper pattern:
- When your application needs to be under high-security environment because of the sensitive information it carries, in such case, an additional security layer is required
- 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 which has very sensitive data from the attacks like SQL Injection, Cross-site scripting, Session hijack, DOS etc
How can we use Gatekeeper pattern in Azure?
In Azure, there are not any services with the name Gatekeeper or Gateway.
But there are a few services which you can use to implement the Gatekeeper design pattern. For example, you can either use Application Gateway or some sort of API Management in the Azure.
Some major advantages of Gatekeeper pattern in the 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 2 services which can be used in Azure for the Gatekeeper but there might be some more. I have already asked a question on SO for this, if you know anything more on this then comment here or answer the question.
Hope it helps.
2 thoughts on “The Gatekeeper security pattern: Cloud design patterns part II”