zia-check-user-url-access

What this skill does

# ZIA: Check User URL Access

## Keywords

can user access, is url blocked, why blocked, url access check, user access, policy evaluation, url allowed, access denied, troubleshoot access, blocked site, user policy

## Overview

Determine whether a specific user (or group/department) can access a given URL by evaluating all applicable ZIA policies in priority order. This skill simulates the policy evaluation engine by checking URL category classification, then walking through URL filtering, SSL inspection, DLP, and firewall rules to produce a definitive access verdict with full reasoning.

**Use this skill when:** An administrator asks whether a user can access a specific URL, why a URL is being blocked, or needs to understand which policy rules affect access for a specific user.

---

## Workflow

Follow this 6-step process to evaluate user URL access.

### Step 1: Identify the User and URL

Collect from the administrator:

- **URL** to check (e.g., "chat.openai.com", "github.com")
- **User identifier** -- username, email, group name, or department

**Look up the user:**

```text
get_zia_users(search="<username_or_email>")
```text

Note the user's:

- User ID
- Department (ID and name)
- Groups (IDs and names)

If the admin specified a group or department instead:

```text
get_zia_user_groups(search="<group_name>")
get_zia_user_departments(search="<department_name>")
```text

---

### Step 2: Classify the URL

```text
zia_url_lookup(urls=["<url>"])
```text

This returns:

- `urlClassifications` -- the category(ies) the URL belongs to
- `urlClassificationsWithSecurityAlert` -- whether there are security alerts

Note all categories returned. A URL can belong to multiple categories.

#### Example

```text
URL: chat.openai.com
Categories: AI/ML Applications, Technology
Security Alert: None
```text

---

### Step 3: Evaluate URL Filtering Rules

```text
zia_list_url_filtering_rules()
```text

Walk through rules in **order** (lowest order number = highest priority). For each rule, check if it matches:

1. **Is the rule enabled?** Skip disabled rules.
2. **Does the URL category match?** Check if any of the URL's categories appear in the rule's `urlCategories`.
3. **Does the user match?** Check if the user, their groups, their department, or their location appears in the rule's `users`, `groups`, `departments`, `locations`. If none are specified, the rule applies to all users.
4. **First matching rule wins.** Stop evaluating once a match is found.

Record:

- Matching rule name, ID, and order
- Action: `ALLOW`, `BLOCK`, `CAUTION`
- Why it matched (category + user scope)

---

### Step 4: Evaluate SSL Inspection Rules

```text
zia_list_ssl_inspection_rules()
```text

Walk through rules in order. Check if the URL's categories or cloud application match any SSL rule. Record:

- Action: `INSPECT`, `DO_NOT_INSPECT`, `DO_NOT_DECRYPT`
- Impact on downstream policies (DLP effectiveness)

---

### Step 5: Evaluate DLP Rules (if SSL inspected)

Only applicable if SSL inspection action is `INSPECT`:

```text
zia_list_web_dlp_rules()
```text

Check if any DLP rules target the URL's categories. If yes, note:

- Rule name and action
- DLP engines involved
- Whether uploads, downloads, or both are scanned

If SSL is `DO_NOT_INSPECT`, DLP rules for HTTPS traffic are ineffective. Note this.

---

### Step 6: Present Access Verdict

#### Report Format

```text
URL Access Check Results
=========================

**User:** John Smith ([email protected])
- Department: Engineering
- Groups: Developers, All Employees
- Location: San Jose Office

**URL:** chat.openai.com
- Categories: AI/ML Applications, Technology
- Security Alerts: None

---

## Access Verdict: ALLOWED

---

## Policy Evaluation (in priority order)

### 1. URL Filtering
**Matching Rule:** "Allow AI Tools for Engineering" (ID: 12345, Order: 5)
- Action: ALLOW
- Matched because:
  - URL category "AI/ML Applications" is in the rule's category list
  - User's department "Engineering" is in the rule's department list
- Rules evaluated before match: 4 (none matched this user + category)

**Note:** A higher-priority rule "Block AI Tools" (Order: 8) exists that
BLOCKS "AI/ML Applications" for All Users, but the Engineering-specific
ALLOW rule at Order 5 takes precedence.

### 2. SSL Inspection
**Matching Rule:** "Inspect AI Applications" (ID: 23456, Order: 3)
- Action: INSPECT
- SSL traffic to AI/ML applications IS decrypted and inspected

### 3. DLP Web Rules
**Matching Rule:** "Monitor AI Data Uploads" (ID: 34567, Order: 2)
- Action: ALLOW (with logging)
- DLP Engine: Sensitive Data Detection
- Effect: Uploads are scanned for sensitive data. If detected, the
  upload is logged but not blocked (ALLOW action).

### 4. Cloud Firewall
No matching firewall rules for this URL/category.

---

## Effective Policy Summary

| Policy Layer      | Rule                          | Action       | Effective? |
|------------------|-------------------------------|--------------|------------|
| URL Filtering    | Allow AI for Engineering       | ALLOW        | Yes        |
| SSL Inspection   | Inspect AI Applications        | INSPECT      | Yes        |
| DLP              | Monitor AI Data Uploads        | ALLOW + LOG  | Yes        |
| Firewall         | (default)                     | ALLOW        | Yes        |

**Result:** User CAN access chat.openai.com. Uploads will be scanned
by DLP and logged if sensitive data is detected.
```text

---

### Verdict: BLOCKED Example

```text
## Access Verdict: BLOCKED

### 1. URL Filtering
**Matching Rule:** "Block Social Media" (ID: 12345, Order: 3)
- Action: BLOCK
- Matched because:
  - URL category "Social Networking" matches
  - User is in "All Users" scope (no exceptions for this user's groups)

**Other rules checked:**
- "Allow Social for Marketing" (Order: 2): ALLOW -- but user is NOT
  in the Marketing department, so this rule did not match.

**Why blocked:** The user is not in any group or department that has
an explicit ALLOW exception for Social Networking.

**To fix:** Either:
1. Add the user's group to an existing ALLOW rule
2. Create a new URL filtering rule to allow this user/group
3. Move the user to a department with an existing exception
```text

---

## Edge Cases

### URL in Multiple Categories

```text
URL: dropbox.com
Categories: File Sharing, Cloud Storage, Business Applications

Multiple categories means multiple potential rule matches. I'll evaluate
against ALL categories and report which category triggered the match.
```text

### No Matching Rules (Default Policy)

```text
No explicit rules matched for this user and URL category.
The DEFAULT URL filtering rule applies.

Default Rule: "<name>" (ID: <id>)
- Action: <ALLOW/BLOCK/CAUTION>

This is the catch-all rule at the bottom of the policy.
```text

### User in Multiple Groups with Conflicting Rules

```text
Conflict detected: User is in both "Developers" and "Contractors" groups.

- Rule "Allow GitHub" (Order: 3): ALLOW for Developers
- Rule "Block Code Repos" (Order: 5): BLOCK for Contractors

Resolution: Rule at Order 3 is evaluated first. Since the user IS a
member of the Developers group, the ALLOW rule matches first.

Verdict: ALLOWED (Developer rule takes precedence by order)
```text

### Caution Action

```text
Action: CAUTION

The user will see a warning page but CAN proceed to the site after
acknowledging the caution. This is neither a full block nor a full allow.
```text

---

## When NOT to Use This Skill

- Investigating all rules for a category (not user-specific) -- use "investigate-url-category" skill
- Auditing SSL bypass rules -- use "audit-ssl-inspection-bypass" skill
- Creating or modifying URL filtering rules -- use `zia_create_url_filtering_rule` directly
- Looking up URL categories without policy evaluation -- use `zia_url_lookup` directly

---

## Quick Reference

**Primary workflow:** Identify User → Classify URL → Evaluate URL Filtering → Evaluate SSL → Evaluate DLP → Present Verdict

**To