Overview
Netskope DSPM (also known as Netskope One DSPM) is deployed as a SaaS application and leverages Amazon Web Services (AWS) to provide optimal scale and security for our customers.
Application & Sidecar Architecture
Netskope DSPM uses a flexible collection architecture. This consists of one or more sidecars that connect with your data stores to collect data samples and a DLP service that classifies the collected data. Both models enforce the same data privacy principle: only classification results, never the sensitive data itself, leave your network.
Netskope DSPM supports two deployment models for on-premises data classification:
- Single Appliance (Standard): Bundles both the DLP and sidecar services into one virtual machine. This is the recommended path for most customers, as it simplifies deployment to a single image, a single CLI command, and a single License Key. To learn more: Deploy the DSPM Single Appliance.
- Distributed Deployment (Advanced): Deploys the DLP appliance and sidecars separately. This model is designed for large-scale scanning scenarios that require independent scaling of DLP and sidecar resources. To learn more: Deploy the DLP Appliance for DSPM.
DLP Appliance Connectivity (Distributed Deployment)
In the distributed deployment model, sidecars work in conjunction with a separately deployed DLP appliance to classify your data. In the Single Appliance model, these components run on the same virtual machine and communicate locally.
The architecture enforces the following rules:
- Network location: The DLP appliance must reside within the same network as the sidecars it serves.
- Communication: The sidecar sends data samples to the DLP appliance for classification via HTTPS (port 443).
- Privacy: The sidecar uploads only the classification results to the Netskope DSPM application. The system never stores the actual data samples used for analysis.
- Appliance linking: You must link each sidecar pool in DSPM to a DLP appliance. A single DLP appliance can serve multiple sidecars, as long as you register their sidecar pools to the same appliance address.
- Scaling limitation: You can’t run multiple DLP appliances behind a load balancer for horizontal scaling.
Sidecar Deployment and Scalability
In the Single Appliance model, the sidecar is built in and requires no separate deployment. In the distributed model, you deploy sidecars separately and can scale horizontally by adding more instances.
A single sidecar efficiently scans multiple data stores within its installed environment. Typically, you deploy one sidecar per isolated network (e.g., VNet, VPC). The Netskope DSPM application automatically load-balances scans across all healthy sidecars in each sidecar pool.
- Recommended environment: Kubernetes (due to its support for health monitoring and auto-scalability).
- Alternative environment: If Kubernetes isn’t available, you can deploy sidecars in any Docker-compatible environment.
Typical Resource Requirements (per sidecar):
- CPU: 4 CPUs
- RAM: 16 GB
- Disk Space: 100 GB
- Capacity: Each sidecar with the above resources can support daily scans for 50-100 medium-sized data stores (approx. 1M objects).
For details on creating and managing sidecar pools, see DSPM Sidecar Administration Overview.
The following diagram illustrates a typical distributed architecture. Deployments across private networks or cloud environments (such as AWS, GCP, or Azure) follow a comparable structure using their respective container services:
Networking & Sampling
Clients connect to the Netskope DSPM application via a web browser using a tenant-specific hostname. We use an Application Load Balancer (ALB) for SSL offloading and to route requests to the server. This ALB is the only public ingress to our SaaS environment.
Your customer-specific Netskope DSPM tenant may initiate connections to the internet for the following needs:
- Connecting to the data stores configured within the Netskope DSPM application (these connections originate from a list of static IP addresses, which you can use as an allowlist)
- Sending alerts triggered by Netskope DSPM policies to destinations such as AWS SNS, Google Pub/Sub, generic webhooks, or your preferred email server
- Importing specific employee data from an external directory, such as Okta Universal Directory
We take additional steps to ensure the security of your data by never storing the data samples used during our analysis. This guarantees that your data remains secure and private at all times.
Firewall and Egress Requirements
DSPM deployments require egress and port configurations. The specific requirements depend on your deployment model:
- Single Appliance: All three sets of configurations (DSPM application, sidecar, and DLP service) apply to the same host.
- Distributed Deployment: Each component (DSPM application, sidecar, and DLP appliance) requires its own separate egress configuration.
To learn more: Firewall Settings for DSPM-Hosted Instances.
Architecture Summary
This architecture design ensures that Netskope DSPM:
- analyzes all interactions within your data store, whether via BI tools, SQL clients, or SQL command lines
- doesn’t block any query from executing
- doesn’t slow down the execution of any query
- doesn’t write to your data store
- stores only metadata and doesn’t retain copies of any sensitive data samples