Blue Coat Systems Proxy SG manual Policy Model

ProxySG Content Policy Language Guide

This provides the ability to test various aspects of a request, such as the IP address of the client and the URL used, or the response, such as the contents of any HTTP headers.

•Ensures policy integrity during processing.

The lifetime of a transaction may be relatively long, especially if a large object is being fetched over slow networks and subjected to off-box processing services such as content filtering and virus scanning. During this time, changes to configuration or policy rules may occur, which would result in altering the policy decisions that affect a transaction. If a request was evaluated against one version of policy, and some time later the associated response were evaluated against a different version of policy, the outcome would be unpredictable and possibly inconsistent.

The transaction ensures that both the request and the response are evaluated against the version of policy that was current when the transaction was created. To ensure that new policy is respected, long lived transactions such as those involved in streaming, or large file downloads, are re-evaluated under new policy. Re-evaluation applies to both the request and response, and any resulting new decisions that cannot be honoured (such as new authentication requirements) result in transaction termination.

•Maintains policy decisions relevant to request and response processing.

•Various types of transactions are used to support the different policy evaluation requirements of the individual protocols: administrator, cache, and proxy transactions.

•In a few special cases, two or more transactions can be created for a single request. For example, if an HTTP request is made via the SOCKS proxy (on port 1080 of the ProxySG), then it is possible for two transactions to be created: a SOCKS proxy transaction, and an HTTP proxy transaction. You can see these transactions for yourself if you turn on policy tracing. A new entry is added to the policy trace file for each transaction.

Policy Model

Each transaction begins with a default set of decisions, many of which are taken from configuration of the system. These defaults include such things as forwarding hosts or SOCKS gateways. The most important default decision affects whether or not requests should be allowed or denied. The defaults for the various transaction types are:

•Administrator Transaction— the default is to deny requests.

By default, administration is only available through one of the methods that bypasses policy evaluation. These are:

❐accessing the CLI through the serial console

❐accessing the CLI through RSA authenticated SSH

❐logging into the Management Console or CLI using the console credentials

Specific rights must be granted through policy to enable other administration methods.

•Cache Transactions—the default is to allow requests.

These requests originate from the ProxySG itself, and are used primarily to maintain the state of content. Additional policy can be added to specifically deny requests for specific content, and to distinguish content management requests from other cache transactions.

•Proxy Transactions—the default is taken from system configuration.

20