Security considerations

Shared system resources vs. dedicated Airlock Gateway instances

The multitenancy feature of the Airlock Gateway REST interface provides isolating protection between tenant-users who share the same Gateway system resources and processes.

However, negative side-effects of configuration changes by tenant-users could severely affect system resources and thus the service availability of other tenant-users. For strict isolation, tenant-users must be distributed to dedicated Airlock Gateway instances.

Principle of least privilege for API endpoints

Tenant-users have a limited access to REST resources, see Limited access to REST resources. In addition, we recommend restricting the permitted paths to API endpoints for each tenant-user according to the principle of least privilege.

Example:
If a tenant needs to be able to change the maintenance mode of a back-end only, any other API endpoints e.g. for general mapping changes should not be permitted.

Secure connections via Airlock Gateway

If the REST API is exposed over untrusted networks (e.g. the public Internet), we recommend protecting the interface with Airlock Gateway API security functionality.

  • Best practice:
  • Configure the REST API as a back-end host on the same Airlock Gateway instance.
  • Expose the back-end host using a dedicated virtual host for REST management access.
  • Protect the API with our Airlock Gateway security features.

Tenant-user setting in Airlock Gateway clusters

Tenant-user settings are not automatically shared within clustered Airlock Gateway instances/deployments. Make sure to distribute the tenancy settings to all Gateway entities within the same cluster.