Deployment

(type, instruction, success factors)

Deployment inside network.

For Secfense Broker to work, it needs to be placed within the organization's network between the user and the application server. We distinguish between 3 types of deployment based on application load balancer placement in the infrastructure.

Inline – No Load Balancer

In this type of deployment, the Broker is placed directly before the protected application. Such placement is achieved by altering the DNS records related to protected applications to direct to Secfense Broker IP addresses. Administrators need to keep in mind that any TLS encryption needs to be performed on the Broker itself, so either proper certificates must be imported or Secfense CA must be added to clients' trusted certificate store.

Even though Secfense Broker has some limited load balancing capabilities, Inline deployment is not advised to be used with multiple backend servers as no health monitoring would be performed, which can lead to broken sessions.

Inline – with Load Balancer

When a load balancer is present in the network, we can place the Broker directly behind it. This case allows for easy production deployment - users will keep using the same DNS records and the load balancer will perform TLS termination as it always did. Secfense Broker would wedge itself into the traffic and add its own security layer.

Even though some load balancing is possible behind the Broker server, it is best to use this setup with a single end server rather than a pool.

Please keep in mind that in any deployment that involves a load balancer, the Virtual Server, backend, service (or any other configuration item, depending on load balancer type) must have the X-Forwarded-For header added to the traffic. Application Representation also needs to have explicit information that Secfense Broker is behind a proxy, and the Load Balancer outgoing IP address(es) need to be whitelisted:

On a stick

This configuration allows for Secfense Broker to be put "next to" the production traffic. Proper rules on the load balancer catch incoming traffic to protected applications and instead of forwarding them to the end servers, it sends the packets to the Broker for authorization. Once authorization procedures are fulfilled, the Broker sends back the traffic to a separate VServer designed just for this task, which in turn forwards the authenticated users to the application.

In this setup, all features of load balancing can be utilized (health monitoring, load balancing algorithms, content switching, etc.). Also, all TLS operations are performed between the User, Load Balancer, and pool - Secfense Broker has no need to contact the traffic members directly.

This setup is preferred when there is a possibility of using a load balancer in the network.

Please keep in mind that in any deployment that involves a load balancer, the Virtual Server, backend, service (or any other configuration item, depending on load balancer type) must have the X-Forwarded-For header added to the traffic.

Application Representation also needs to have explicit information that Secfense Broker is behind a proxy, and the Load Balancer outgoing IP address(es) need to be whitelisted: