Stop company data leaving through the browser

ReadyLab and laptop~8 minGateway HTTP policiesDLP profilesApplication typesPayload loggingAntivirus

A customer list blocked on its way to personal storage, the same checks inside an internal app, malware blocked on download, and the matched data shown from the log.

The problem

Alice wants to finish tidying the Summit invite list at home, so she exports it from the wiki and uploads it to her personal file sharing. Separately, the company's service desk holds things nobody should have pasted there, like a card number and a password.

Lands with: security and compliance teams

Before you start

The protection layer in block mode: ./protect.sh block on a laptop deploy, protection_mode = "block" in the lab.
The client signed in as .
open in a tab. Driftbox is a pretend personal file sharing service; its sign-in accepts any username and password.
The Backlog section is lab only.
The DLP key from the keys page, for the last section.

Run it

The export is allowed, the upload is not

Do	Say
As Alice, open Nexus → Marketing → Summit invite list (pasted from CRM - needs tidying) → Export.	Ten customers with names and mobile numbers. Anyone who can read a wiki page can export it.
Traffic policies → Firewall policies → HTTP → Block company data uploads to file sharing.	One rule for every file sharing service Cloudflare knows, from Dropbox to WeTransfer. It checks uploads for customer data, card numbers and employee records.
Sign in to Driftbox and upload the exported file.	Blocked, with a page that says why and a notification from the client. Other files still upload.
Back in the wiki, show that nothing changed.	The control is on the path the data takes, not in each app. Pipeline's account export is caught the same way.

Whybackground, if you are asked

The rule selects the File Sharing application type, which covers Dropbox, Google Drive, OneDrive, WeTransfer, Box and some sixty more, and inspects uploads only. Because the control sits in the path, the next app that can export a file is covered on the day it is bought. Driftbox stays usable: it is the customer list that cannot leave, not the site.

The same checks on an internal app

Do	Say
As Alice, open `https://backlog.corp.internal`, then BKL-1060.	An ordinary ticket on an internal tool.
Open BKL-1043, "Customer card declined on renewal".	Blocked. Someone pasted a customer's card number into it. The same DLP rules apply to internal traffic.
Open BKL-1051.	A service account password. Blocked by a different rule.

Whybackground, if you are asked

This traffic never touches the internet, and the same DLP profiles still apply. Backlog has no idea anything happened. "It is only on the internal network" was its whole protection before.

Malware

Do	Say
Download `https://secure.eicar.org/eicar.com.txt`.	Every file through Gateway is scanned. This is the standard harmless test file, and it is blocked.

What was in it

Do	Say
Insights → Logs → HTTP request logs → the blocked upload → Decrypt payload log, and paste the key.	The matched mobile numbers, partly masked. Only the company's key can read them.

Whybackground, if you are asked

The payload is encrypted with a key Cloudflare does not hold, so the evidence does not become a second copy of the data.

What the audience should see

The wiki page saved as a file.
The Driftbox upload blocked, with Horizon Inc's block page and a client notification.
BKL-1043 and BKL-1051 blocked; BKL-1060 opens.
The test file blocked as malicious.
A decrypted payload with masked mobile numbers.

Where the evidence is

Gateway HTTP request logs: each block with its policy, the DLP profile that matched, and the encrypted payload. The test file shows as an antivirus detection.

Known limitations

Driftbox is pretend. The same rule covers real services by application type.
Personal and company accounts on the same service are not told apart.
File sandboxing is not set up.

Part of: The whole of Cloudflare One · Secure web gateway and data protection · The full tour