About Airlock Gateway

Within the Airlock Secure Access Hub, Airlock Gateway acts as a central reverse proxy for all HTTPS connections and protects against web attacks.
Airlock Gateway analyses all the traffic to the services and applications under protection, blocking attempted attacks long before they reach in-house services. Airlock Gateway provides comprehensive protection against OWASP Top 10 vulnerabilities, enabling centralized management of security guidelines.

Airlock Gateway works in conjunction with Airlock IAM to ensure secure session management while serving as a policy enforcement point for authentication and authorization decisions. Following DevOps principles, a cascaded setup with Airlock Gateway and Airlock Microgateway allows a DevSecOps culture, i.e. is an architecture for securing microservices.

An architecture for securing microservices

The following architecture overview shows an Airlock Gateway and Airlock Microgateways in a cascaded setup - each with individual tasks and responsibilities.

Airlock Gateway - Appliance versus Microgateway
Figure 1: Airlock Gateway and Airlock Microgateway

Having a central Airlock Gateway in front of the Airlock Microgateway is no technical requirement. However, we believe it makes a lot of sense to distinguish between edge-oriented tasks and tasks tightly connected to the services.

The distinction between Airlock Gateway and Airlock Microgateway tasks may vary in specific setups.

In this scenario, the Airlock Gateway represents the central enterprise gateway. It controls all incoming traffic and acts as a policy enforcement point for authentication, authorization and API access. For this task, the Airlock Gateway requires a rather generic configuration, enabling quick and seamless integration of new services protected by individual Airlock Microgateway instances.

The Airlock Microgateway has detailed knowledge about its protected service. Typical integration tasks, such as adding deny rule exceptions, are done on the Microgateway. Thus, all service-specific details are located close to the service itself, minimizing role conflicts and handover problems at the central gateway.

To meet the different requirements of an edge gateway and a microgateway setup, Airlock has designed the Airlock Gateway and the Airlock Microgateway under complementary considerations.

Task split between Airlock Gateway and Airlock Microgateway

The following table indicates the main use cases for which the two components were designed:

Topic
Airlock Gateway
Airlock Microgateway
Main task
Publish web applications
Secure web applications
Architecture
Appliance with hardened OS
Container
High Availability
Loadbalancing and failover for Back-end service
Managed by container platform
offers probes for health checks
Authentication / Authorization
Policy Enforcement Point
Proxy for SSO
Interaction with Airlock IAM
Injection of internal token
Policy Enforcement Point
Interaction with Airlock IAM
Internal token validation
Security
Baseline security
  • TLS ciphers and protocols
  • Session hijacking prevention
  • Threat Intelligence
  • Geo location blocking
  • HSM integration
  • Connection to Malware scanner
  • Connection to co-browsing solutions
  • ...
Strict security
  • Authentication enforcement
  • Allow rules
  • Deny rules and its exceptions
  • Enforcing OpenAPI spec.
  • ...
Service Integration
Generic turnkey configuration
Specific service integration
API Keys
API Usage Plans
Policy Enforcement Point
Interaction with Airlock IAM
Internal token validation
Configuration
  • Graphical UI
  • REST API (imperative)
  • YAML file (declarative)