Blocking Personal Cloud Storage in a Guest-Heavy Branch
Contoso's Manila branch has 180 staff and a guest Wi-Fi network. Corporate laptops run WARP in Gateway with DNS and HTTP filtering; guest devices do not. Both networks NAT to the same public egress IP, which is registered as one Gateway location. Policy requires blocking uploads to personal Dropbox, Google Drive, and Box on corporate devices, while allowing OneDrive for Business. Guests should get internet-only access with no corporate filtering dependency. Since rollout, helpdesk sees two problems: users on corporate laptops can still reach personal Dropbox by enabling a browser built-in secure DNS, and a proposed HTTP block on dropbox.com would also block a business partner shared folder. The team has no TLS inspection today and wants to avoid breaking finance sites. They ask whether to use DNS policies, HTTP policies, or both, and how to separate guest from corporate traffic.
1. Recommend a policy architecture using DNS, HTTP, identity, and egress separation. Justify each control.
Read the worked answer
Use both DNS and HTTP, but for different jobs. DNS policies are cheap and catch domains before connection; HTTP policies can match method and path and can block uploads. Because corporate laptops have WARP identity, create a Gateway HTTP policy for the corporate group that blocks POST and PUT to personal storage domains and allows the OneDrive business tenant. Add DNS blocks for known personal storage domains as defense in depth. Do not write a broad dropbox.com block, because partner shares may use dropbox.com; use tenant-aware or path-aware rules, or a category with an explicit partner exception. Guests have no WARP identity, so identity-based policies will not apply. Give guest traffic a different NAT egress IP and register it as a separate Gateway location with a guest policy, or terminate guest internet at an upstream firewall. Do not try to distinguish guest from corporate by user agent alone.
2. Users bypass filtering by enabling browser secure DNS. What will and will not fix this, and how does TLS inspection change the answer?
Read the worked answer
Browser secure DNS bypasses Gateway DNS because the resolver is not Cloudflare Gateway. Block known DoH resolver endpoints with HTTP policy, disable browser DoH through device management, and enforce WARP DNS. DoH hides DNS queries but does not hide the destination domain from domain-based HTTP filtering, so Gateway can still block the site by domain without TLS inspection. Upload-path and file-type blocking is different: it needs TLS inspection. If finance sites cannot be inspected, start with domain and category blocks plus tenant allowlists, pilot TLS inspection on a small non-finance group, exclude sensitive categories, and document certificate and privacy handling. Do not inspect guest traffic.
3. A proposed broad dropbox.com HTTP block would break a partner shared folder. How would you refine the rule while keeping the security objective?
Read the worked answer
Separate consumer personal storage from sanctioned business use. For Dropbox, allow the specific business tenant or partner path and block the consumer login and upload paths, using host and path matching. If tenant control is unavailable, use a category block with a documented exception for the partner domain, reviewed by the data owner. Pair the rule with DLP for sensitive content so the exception is not a blind spot. Log allowed partner traffic and denied personal traffic, and review weekly. Because there is no TLS inspection, path matching may be limited; in that case prefer domain allowlisting for the partner and block the broader personal-storage category, accepting reduced granularity. Test with a partner user and a personal account before enforcing.