Blue Coat Systems Time Clock Proxy SG Manuale Utente
ProxySG Content Policy Language Guide
48
Best Practices
•
Express separate decisions in separate layers.
As policy grows and becomes more complex, maintenance becomes a significant issue.
Maintenance will be easier if the logic for each aspect of policy is separate and distinct.
Maintenance will be easier if the logic for each aspect of policy is separate and distinct.
Try to make policy decisions as independent as possible, and express each policy in one layer or
two adjacent layers.
two adjacent layers.
•
Be consistent with the model.
Set the default proxy policy according to your policy model and then use blacklist or whitelist
approaches as appropriate.
approaches as appropriate.
The recommended approach is to begin with a default proxy policy of deny in configuration.
Allow requests in early layers and deny requests in later layers. Ensure that all layers that allow
requests precede any layers that deny requests. The following is a simple illustration of this
model:
Allow requests in early layers and deny requests in later layers. Ensure that all layers that allow
requests precede any layers that deny requests. The following is a simple illustration of this
model:
define subnet corporate_subnet
10.10.12.0/24
end
; First, explicitly allow access to our users
<proxy>
ALLOW client.address=corporate_subnet
; Next, impose any authentication requirements
<proxy>
authenticate(corp_realm) ; all access must be authenticated
; And now begin to filter-out unwanted requests
<proxy>
DENY url.domain=forbidden.com
DENY category=(Gambling, Hacking, Chat)
; more layers…
•
Expose only what is necessary.
Often, it may be useful to keep the rule logic and the condition definitions separate so that the
rules can be maintained by one group, but the definitions by another. The rules may contain
exception details or other logic that should not be modified; however, the conditions, such as
affected groups or content, may change frequently. With careful separation of the rules and the
conditions, the rules can be expressed in the local policy file, and users unfamiliar with CPL can
update the condition definitions through the VPM.
rules can be maintained by one group, but the definitions by another. The rules may contain
exception details or other logic that should not be modified; however, the conditions, such as
affected groups or content, may change frequently. With careful separation of the rules and the
conditions, the rules can be expressed in the local policy file, and users unfamiliar with CPL can
update the condition definitions through the VPM.
When using this technique, installation order is important. Condition definitions must be
available before policy referencing those conditions will compile, so the conditions you want to
expose for general use must be defined in the VPM before they are referenced in the Local policy
file.
available before policy referencing those conditions will compile, so the conditions you want to
expose for general use must be defined in the VPM before they are referenced in the Local policy
file.