Secure remote access for Remote Endpoint Scanning, Cookie Consent and Consent Management
Introduction
As organizations continue to support remote and hybrid work environments, securing and managing endpoints outside the corporate network is critical.
SDP 3.2.0 introduces Remote Endpoint Scanning, enabling remote devices to securely communicate with SDP services without exposing internal infrastructure to the Internet. The solution uses a secure Proxy and Connector architecture, to provide authenticated and encrypted communication across all layers.
Business Benefits
Remote Endpoint Scanning enables organizations to:
- Securely scan and manage remote devices.
- Extend Data Privacy protection beyond the corporate network.
- Maintain visibility and compliance for remote endpoints.
- Eliminate direct Internet exposure of backend SDP services.
- Support work-from-home and distributed workforce environments.
- Enforce Zero Trust security principles through certificate-based authentication.
1. Overview
The Problem
When the SDP cluster is deployed in a protected network with no route from the internet, anything outside that network cannot reach it. The following traffic is affected:
| Traffic | Imapact without the Proxy | |
| Remote endpoints (laptops and other devices outside the corporate network) | The SDP server cannot send scan commands to them, and they cannot send scan results back. | |
| Cookie Consent | A visitor’s browser cannot submit cookie preferences to the cluster. | A user’s browser or application cannot submit or retrieve consent records. |
| Consent Management |
1.2 The Solution
The solution has two components:
- SDP Proxy: installed on a Linux machine that is reachable from the internet. This can be a machine in an on-premises DMZ or a virtual machine in a cloud provider’s public subnet (for example AWS, Azure or Google Cloud). The proxy is the only component that faces the internet.
- SDP Connector: a pod that runs in the existing SDP cluster. It opens an outbound secure tunnel from the cluster to the proxy.
Because the tunnel is opened from inside the network, no inbound firewall port to the SDP cluster is required.
1.3 What users experience
The proxy changes only the network path. The consent banners and forms, the agent behavior and the SDP console look and work the same as before. No browser, agent or device needs to be configured to use the proxy: the same hostname is used everywhere, and DNS directs the request.
2. Split DNS
Split DNS is the most important prerequisite. Devices always use the same hostname for the SDP server, for example sdp.example.com. DNS determines where that hostname leads:
| Device Location | DNS Answer for sdp.example.com | Path |
| Inside the corporate network | Internal IP address of the SDP cluster | Device → SDP server (direct) |
Two DNS records are required for the same hostname, one in each DNS zone:
- Internal DNS (on-premises DNS server): an A record for sdp.example.com that points to the IP address(es) of the SDP cluster’s ingress or master node.
- Public DNS (public DNS zone, for example AWS Route 53): an A record for sdp.example.com that points to the public IP address of the proxy. Set the TTL to 300 seconds (5 minutes) so that a change takes effect quickly if the proxy is moved or rebuilt.
Both records are created and owned by the customer’s DNS team. No second domain name is required.
Verification
# From a machine INSIDE the corporate network
nslookup sdp.example.com
# Expected: the internal IP address of the SDP cluster
# From a machine OUTSIDE the corporate network (for example, a mobile hotspot)
nslookup sdp.example.com
# Expected: the public IP address of the proxy
Note: The connector connects to the proxy by IP address, not by name.
The connector runs inside the corporate network, where sdp.example.com resolves to the SDP cluster itself. The connector therefore connects to the proxy by IP address (the proxy_ip_list setting, section 7) and uses sdp.example.com only to verify the proxy’s certificate. The proxy’s IP address must be fixed.
Note: Browsers with Secure DNS (DNS over HTTPS).
Some browsers send DNS queries to a public resolver instead of the internal DNS server. A browser inside the corporate network can then receive the proxy’s public IP address, so its request leaves the network and reaches the proxy instead of the cluster. To support this case, the catch-all route described in section 7 (step 3) must be configured. Alternatively, Secure DNS can be disabled in browsers through policy.
3. Requirements
3.1 System requirements for the proxy machine
The proxy runs on a Linux machine in an on-premises DMZ or on a cloud VM in a public subnet. The requirements are the same in both cases.
Supported operating systems
- Ubuntu
- RHEL (Red Hat Enterprise Linux)
| CPU | RAM | Free Disk Space | |
| Minimum | 2 vCPUs | 4 GB | 1 GB |
| Recommended | 4 vCPUs | 8 GB | 1 GB |
3.2 Other Prerequisite
| Item | Details |
| Fixed IP address | A fixed public IP address for the proxy (directly, or through the firewall’s NAT). On a cloud VM, use a static address (for example an AWS Elastic IP) so that the address does not change when the VM restarts. |
| DNS hostname | The hostname that devices use to reach the SDP server, for example sdp.example.com. |
| TLS certificate | The SDP cluster’s domain certificate, as a certificate file (server.crt, full chain) and its private key file (server.key). See section 6, step 4. |
| Root access | root or sudo access on the proxy machine. |
| kubectl access | kubectl access to the SDP cluster, to download the proxy package and deploy the connector. |
3.3 Network requirements
| From | To | Port | Purpose |
| Internet (remote endpoints and browsers) | Proxy | TCP 443 | Device, Cookie Consent and Consent Management traffic |
| SDP cluster (connector pod) | Proxy | TCP 443 | The outbound tunnel, opened from inside the network |
- No inbound rule to the SDP cluster is required.
- The proxy serves HTTPS directly on port 443. Do not place a TLS-terminating load balancer, CDN or WAF in front of the proxy in this setup.
- Cloud VM: allow inbound TCP 443 from the internet in the VM’s security group, network security group or firewall rule (and in the subnet’s network ACL, if one is used). The connector connects to the VM’s public IP address, so outbound TCP 443 from the cluster to that address must be allowed.
- On-premises DMZ: the connector connects to the proxy’s internal (private) IP address in the DMZ, so TCP 443 from the cluster to that address must be allowed. Internet clients reach the proxy through its public address, which the firewall forwards to the same machine.
- If a firewall forwards traffic to the proxy, use destination NAT only, so that the client’s source address is preserved. The proxy must see the real client IP address; it is also required for correct source-IP reporting by Cookie Consent and Consent Management.
4. Download the Proxy Package
The connector generates a ready-to-install proxy package that already contains the key the proxy uses to authenticate the connector. The connector must be running and connected to the SDP database.
On a machine with kubectl access to the cluster, run:
/bin/sh deploy/download-proxy.sh
The script saves proxy.tgz in the current directory.
5. Install the SDP Proxy
Copy proxy.tgz to the proxy machine (for example, with scp).
On the proxy machine, extract the archive and run the installer as root:
tar -xzf proxy.tgz
sudo ./install.sh
The installer detects whether the machine runs Ubuntu or RHEL, installs the matching package, and starts the sdp-proxy service. The configuration file is /usr/local/dataprivacy/sdp-proxy/proxy.yaml. No changes to this file are normally required.
Warning:Running install.sh again removes the existing installation, including the certificates, any edits to proxy.yaml, and the logs. Before upgrading, back them up:
sudo tar -czf /root/sdp-proxy-backup-$(date +%F).tgz \\
/usr/local/dataprivacy/sdp-proxy/certs \\
/usr/local/dataprivacy/sdp-proxy/proxy.yaml \\
/var/log/sdp-proxy
After the upgrade, restore the certs folder, re-apply the proxy.yaml edits, and restart the service.
Install the TLS certificate
The proxy answers for the same hostname as the SDP cluster (for example sdp.example.com). It therefore uses the same domain certificate as the SDP cluster. No new certificate is issued for the proxy: the SDP cluster’s domain certificate and its private key are copied to the proxy machine.
- Obtain the SDP cluster’s domain certificate and private key from the team that manages them.
- The certificate file (server.crt) must contain the full chain: the server certificate followed by the intermediate CA certificates. Otherwise, clients that do not already have the intermediate certificate cannot verify it.
- Copy both files to the proxy’s certificate folder:
sudo cp server.crt /usr/local/dataprivacy/sdp-proxy/certs/server.crt
sudo cp server.key /usr/local/dataprivacy/sdp-proxy/certs/server.key - Restart the service and check its status:
sudo systemctl restart sdp-proxy
sudo systemctl status sdp-proxy
The status must show active (running).
Configure the SDP Connector
The connector is configured through a single file, connector-config.yaml, which is stored in a Kubernetes ConfigMap.
Edit connector-config.yaml.
- Set the proxy connection. Replace the example values with the values of the environment.
- Add the catch-all route for the corporate network. As described in section 2, a browser inside the corporate network that uses Secure DNS can reach the proxy instead of the cluster, for example when an administrator opens the SDP console. The proxy forwards only the paths defined as routes, so one more route is required. It forwards all other paths, but only for requests that originate from the corporate network’s public IP address:
– path: “/”
port: 8083
require_mtls: false
allowed_ips:
– “# the corporate network’s public (NAT) IP address”Do not remove allowed_ips from this route. Without it, anyone on the internet could reach the entire SDP server through the proxy.
# The name in the proxy’s TLS certificate (the SDP domain name)
proxy_host: “sdp.example.com”
proxy_skip_verify: false
# The proxy’s fixed IP address as seen from the cluster (the connector cannot use DNS, see section 2):
# proxy on a cloud VM -> the VM’s public IP address
# proxy in an on-prem DMZ -> the proxy’s internal (private) IP address
proxy_ip_list:
– “(PROXY_IP_ADDRESS)”
# The tunnel. Do not change port 8083 unless instructed to.
# Replace (SDP_CLUSTER_IP) with the internal IP address of the SDP cluster’s ingress/master node.
remotes:
– “R:127.0.0.1:8083:(SDP_CLUSTER_IP):443”
# The proxy reaches the SDP server over HTTPS through the tunnel.
# Use the name that is in the SDP server’s certificate.
upstream_tls: true
upstream_tls_skip_verify: false
upstream_server_name: “sdp.example.com”
Apply the configuration and restart the connector
- Update the ConfigMap with the edited file:
kubectl create cm connector-config –from-file=connector-config.yaml -n sdp-connector \
–dry-run=client -o yaml | kubectl apply -f – - Restart the connector so that it opens the tunnel and sends the routes to the proxy:
kubectl rollout restart deployment sdp-connector -n sdp-connector
7. Verification
Step 7a. Check the Connector
kubectl logs -n sdp-connector -l app=sdp-connector -c sdp-connector –tail=50
The output must contain lines similar to:
tunnel established — remotes: [“R:127.0.0.1:8083:(SDP_CLUSTER_IP):443”] successfully pushed certificate and key to proxy over control channel
successfully pushed (N) routes to proxy over control channel
Step 7b: Check the proxy
On the proxy machine:
sudo tail -f /var/log/sdp-proxy/proxy.log
The output must contain lines similar to:
registered client CA cert and websocket server cert via control channel
dynamically registered (N) route(s) via control channel
Step 7c: Test from outside the network
Run the following tests from a machine outside the corporate network (for example, on a mobile hotspot). Do not use curl -k: a successful request also confirms that the proxy’s certificate is valid.
| Test | Command | Expected Result |
| A public route works | curl -i (https://sdp.example.com/dpcdn/test.txt) | A response from the SDP server (not a proxy error) |
| The console is not exposed | curl -i (https://sdp.example.com/) | 403 Forbidden (from an address that is not in allowed_ips) |
| The console is reachable from the corporate network | curl -i |
200 OK (from an address that is in allowed_ips) |
Step 7d: Test the end-to-end flows
- Remote endpoint: from a device outside the corporate network, register the SDP agent and run a scan. Confirm that the scan completes and that the results appear in the SDP console.
- Cookie Consent: from a browser outside the corporate network, open a website that uses Cookie Consent and save a set of preferences. Confirm that the banner is displayed normally and that the consent record is stored.
- Consent Management: from a browser outside the corporate network, open a consent form or consent link and submit it. Confirm that the confirmation is displayed and that the consent record is stored.
Troubleshooting
| Symptom | Possible Cause | Check |
| The connector log shows that it cannot connect to the proxy | The proxy is not reachable from the cluster | Verify the IP address in proxy_ip_list. Verify that the firewall allows TCP 443 from the cluster to the proxy. Verify that sdp-proxy is running (systemctl status sdp-proxy). |
| Certificate or name-mismatch errors in the connector log | proxy_host does not match the certificate on the proxy, or the chain is incomplete | proxy_host must be a name in the certificate. server.crt must contain the full chain. For a private certificate authority, set proxy_ca. |
| The connector does not start and reports an IP address error | An invalid or placeholder entry in allowed_ips | Use only real public IP addresses or ranges. |
| Remote devices, or browsers on the internet, cannot reach the server at all | DNS | From outside the network, nslookup sdp.example.com must return the proxy’s public IP address. |
| Remote devices fail with a certificate error, and it started recently | The certificate on the proxy expired because the SDP cluster’s certificate was renewed but not copied to the proxy | Copy the current domain certificate and key to the proxy and restart sdp-proxy (section 6, step 4). |
| Users in the office receive 403 | The browser reaches the proxy through Secure DNS, and the office’s public IP address is not in allowed_ips | Add the corporate public IP address to the / route (section 7, step 3), or turn off Secure DNS in the browser. |
Log Actions
| Proxy | Location |
| Proxy | /var/log/sdp-proxy/proxy.log on the proxy machine |
| Connector | kubectl logs -n sdp-connector -l app=sdp-connector -c sdp-connector |