​

Build precise web access decisions

​

Problem statement

Broad allow rules create malware, abuse, and data-loss exposure. Blanket deny rules break legitimate work. Enterprise web policy must decide with more context than IP address alone: who the user is, what application is involved, where traffic is going, when it is happening, and what content is moving.

​

Client scenario

Use Access Restriction when you need to:

• allow or block by user, group, destination, category, or application
• apply stricter controls during business hours or for regulated teams
• combine identity, HTTPS visibility, and profiling into one enforcement path
• prove why a request was allowed, denied, or redirected

​

Key benefits

SafeSquid access restriction ties enforcement to the rest of the platform:

• Authentication provides identity and group context
• SSL Inspection provides visibility into encrypted traffic
• profiling engines provide request, response, category, time, and application context
• logs and reporting provide evidence for investigation and audit

That makes policy more precise and easier to defend operationally.

​

Prerequisites

​

Client-side preparations

• Route client traffic through SafeSquid.
• If policy must apply to HTTPS traffic, deploy the Root CA and enable HTTPS inspection.

​

SafeSquid-side setup

• Confirm identity integration if you want user- or group-based policy.
• Define the profiles and categories the access policy will consume.
• Decide your rule order before deployment because top-down policy order affects outcome directly.

​

Setup instructions

​

Build policy inputs first

Before writing restriction rules, define the signals they will consume:

• authenticated users and groups
• request profiles
• response profiles
• categories
• time or business context

This avoids building access rules that look complete but match nothing useful.

​

Create ordered restriction entries

In the Configuration Portal, create access-restriction entries from most specific to most general. Put business exceptions and critical-deny rules above broad defaults. If a broad rule sits too high, later rules never get a chance to apply.

​

Keep the action model explicit

For each restriction entry, document whether it should:

• allow
• deny
• redirect
• apply additional inspection or restriction profiles

Operators should be able to explain the intended outcome without reverse-engineering the entire rule stack.

​

Test by realistic user path

Do not validate only with anonymous traffic. Test with the actual user, group, device path, and destination type the rule is meant to govern.

​

Verification and validation

​

Positive tests

Use at least one test for each intended decision path:

• a user or group that should be allowed
• a user or group that should be denied
• a destination or category that should be blocked
• an application or profile that should trigger special handling

Expected result:

• the rule order produces the intended action
• the applied profiles and filter path are visible in logs
• the user sees the expected allow, deny, or redirect behavior

​

Negative tests

Test a nearby but legitimate workflow that should stay allowed. Expected result:

• the broader restriction rule does not break approved business activity
• exception logic does not leak into unintended users

​

Troubleshooting guide

​

A rule exists but never seems to apply

Likely causes:

• a higher rule matches first
• the required identity or profile signal is missing
• HTTPS traffic is not being decrypted

Isolation steps:

• review rule order
• confirm authentication and profile assignment
• confirm whether the traffic is visible to SafeSquid

Remediation:

• move the rule higher if appropriate
• fix the missing prerequisite signal
• retest with the same user and destination

​

Too much traffic is blocked

Likely causes:

• a broad deny rule sits above a needed exception
• category or profile conditions are too wide

Isolation steps:

• identify the exact rule that triggered
• compare affected users against intended scope

Remediation:

• narrow the matching conditions
• place the approved exception above the broad deny
• retest both blocked and allowed paths

​

Policy works for HTTP but not HTTPS

Likely causes:

• HTTPS inspection is not enabled
• bypass logic excludes the traffic from inspection

Isolation steps:

• confirm the request path is decrypted
• inspect whether request or bypass profiles are modifying the flow

Remediation:

• enable the required HTTPS inspection path
• remove or narrow the bypass condition

​

Related controls / next steps

• Use Request Profiles and Response Profiles to classify traffic before enforcing policy.
• Use Web Categorization to refine destination-based decisions.
• Use Security Logs and Reporting Module to prove which rule triggered.