Policy Mapping and Traffic Routing
Last updated
Last updated
When Reblaze processes incoming requests (as described in the discussion of the traffic filtering process), the system must perform:
Policy mapping: deciding which security rulesets are applicable to the request.
Traffic routing: If the request successfully passes through the filtering process, the system must decide how and where to route it to the protected backend.
As shown in the diagram above, a fundamental component within Reblaze is the Server Group. Generally, admins will configure a Server Group to represent a domain. Each Server Group specifies:
A Security Policy, used for policy mapping.
The Proxy Template that is based upon.
The domain's SSL Certificate.
During the traffic filtering process, some stages of processing (for example, Global Filtering) are universal; the same rulesets are enforced upon all requests.
However, other stages of processing will vary. Admins can specify different rulesets for enforcement, depending on the request's destination URL. For these stages, policy mapping is necessary.
When a request is received, it is first matched with the appropriate Server Group. As shown above, every Server Group includes a Security Policy, which is the foundation for policy mapping.
Each Security Policy includes a list of paths (which are usually expressions, although individual URLs can be specified too). It associates each path with several rulesets:
Content Filter Profile (which defines the threat signatures, content requirements, and other restrictions to enforce upon the request according to its content)
Rate Limit Rule(s) (which restrict the rates at which traffic sources can submit requests)
ACL Profile (which define the disposition of requests, depending on the tags that it received during processing)
The request's destination URL is evaluated against the list of paths, to find the best match. The rulesets associated with that path are the ones used to process the request. For more information, see the explanation of Security Policy path mapping.
When a request has successfully passed through traffic filtering, Reblaze forwards it to the customer's backend, accepts the backend's response, and returns the response to the client.
To do this, the system must know how to route requests to the backend. This is configured in Security Policies.
Each Security Policy includes a list of paths (which are usually expressions, although individual URLs can be specified too). Each path is associated with, among other things, a Backend Service.
When a request is processed, its destination URL is evaluated against the list of paths, to find the best match. The Backend Service associated with that path is the one to which Reblaze will send the request, and then receive the response, and so on.
