How scanning works

DSPM reads data in one of two ways, depending on where the data lives:

• In your environment. AWS, Azure, Google Cloud and on-prem data is read by tigergate-dspm-scanner, which you deploy in your own account, subscription, project or machine. Content never leaves it.
• Hosted by TigerGate. SaaS tools and SaaS warehouses have no environment of yours to run in, so TigerGate reads them through each provider’s API with a read-only credential you provide.

Both produce the same datastores, classifications and Findings in the console.

​

The in-account scanner

The scanner is one container image with two roles:

• Coordinator. Starts on a timer every 15 minutes. It reads its settings and schedule from TigerGate, registers on its first start, runs preflight checks, discovers the datastores in scope, compares them with the state it kept from earlier runs, and queues the work as shards.
• Workers. Take shards from the queue, read and classify the content, and send the results. They scale with the queue, from zero up to the maximum you set, and stop when the queue is empty.

A shard is a range of object keys, a table or table partition, or a range of snapshot blocks. A failed shard is retried (five attempts by default), then moved to a dead-letter queue and counted as failed in the run. On-prem, one process plays both roles. The queue and the scan state live in your environment: The state records, per object, its key, version, size, modification time, when it was last read and a hash of the classes found. It never holds content.

​

What a run reads

The default full profile reads every new or changed object whole, as a stream, and every row of every changed table. There is no size or sampling limit. The sampled profile reads a bounded sample of each store instead; choose it per deployment on the Configuration tab. Some limits apply in every profile:

• Formats that must be held in memory (PDF, zip archives, and Parquet, ORC or Office files inside an archive) are read up to 512 MiB. A larger object is reported as too_large. PDFs are also limited to 5,000 pages and 32 MiB of text.
• Formats with no reader, such as SQLite files, images and executables, are counted as not classified. A store holding them is reported as partly read, never as clean.
• Objects in archive storage tiers that need a restore are reported as unreadable.

​

What leaves your environment

For in-account deployments, only this reaches TigerGate:

• inventory and configuration metadata, and posture results;
• classifications as the class, counts, location and confidence;
• object and table identifiers;
• keyed fingerprints of identifier values, so privacy requests can find a subject’s data without the values themselves;
• run, progress, preflight and error status;
• for malware scanning, only the objects that matched the known-bad list: key, size, SHA-256 and family.

Masked samples (an example value with most characters hidden) leave while Share masked samples with TigerGate is on for the deployment. It is on by default for a new deployment; turn it off to keep masked samples in your environment, and TigerGate then also removes any sample it receives. Changing it needs an organization owner or admin. When your organization’s Data samples policy is Omitted, the scanner is told not to send samples and TigerGate removes any it receives, whatever the deployment’s setting. Raw values never leave. Fingerprint keys are per deployment: TigerGate issues one when the scanner registers and stores it encrypted. Database and file share credentials stay in your own secret store (Secrets Manager, Key Vault or Secret Manager), or in credential files on the on-prem host. TigerGate holds only references to them.

​

How the scanner talks to TigerGate

• Outbound only. The scanner calls the TigerGate API of your region over HTTPS. Nothing connects in.
• Two credentials on every call. The organization API key in X-API-Key authenticates your organization; the deployment’s scanner credential binds the call to one deployment. The scanner gets its credential by exchanging the enrollment token once. See Two credentials.
• Compressed, batched reports. Results travel as gzip-compressed report chunks of at most 8 MB, each with an idempotency key, so a retried chunk is never counted twice.
• Retries. Network errors and server errors are retried with exponential backoff. A refused API key is read again from its secret before the call is repeated, so a rotated key needs no redeploy.
• Failures are visible. Preflight results, run failures and per-datastore errors, each with a remediation, appear on the deployment in DSPM → Deployments.

​

Hosted SaaS and warehouses

For Microsoft 365, Google Drive, Salesforce, Box, Dropbox, Slack, Jira, Confluence, Zendesk, ServiceNow, Snowflake, Databricks and MongoDB:

• TigerGate’s scheduler queues each connection’s stores and reads them through the provider’s API.
• The default is full content: every byte of every file, issue, page and thread, and every row of a warehouse table.
• Later runs read only what the provider’s change feed reports as new or changed, and record deletions.
• The credential is stored encrypted at TigerGate.
• Masked samples are kept by default for hosted connections, because the content is read on TigerGate’s side either way. Turn off Keep masked samples on the connection to drop them before anything is stored. When your organization’s Data samples policy is Omitted, they are dropped for every connection.
• Inventory and content are each scheduled weekly by default; every 30 days a scan reads everything again.

See Connect SaaS sources and Scheduling and incremental scans.