Varonis Data Security Platform

At a glance

Required scopes & roles

Varonis API tokens are scoped by the Varonis admin role assigned to the token. Create a dedicated service role with read-only access to:

• Alerts, Read-only (data-threat alerts KRI).
• Data Classification, Read-only (exposure, stale-data, regulated-shares KRIs).
• Permissions, Read-only (blast radius, privileged-excessive, dormant-accounts KRIs).
• Events, Read-only (UBA anomalies, external-events KRIs).
• Users, Read-only (privileged analysis, dormant accounts).
• Shares / SaaS Sharing, Read-only (regulated-shares and SaaS-external-shared KRIs).

Do not grant any write / modify / classify-as / respond-to permissions. The connector never mutates Varonis state.

Setup steps

1. Identify your Varonis deployment. SaaS customers log into https://<tenant>.varonis.io; on-prem customers have a DSP Management Server hostname. The API is served from the same host under /api/v1/.
2. Create a service-account user in the Varonis admin console (Management → Users → Add). Name: draxis-connector. Role: the read-only service role you created with the scopes above (or use the built-in "Auditor" role if it matches).
3. Generate an API token as that service account. Admin Console → API → Create Token. Varonis shows the token once at creation, copy into your password manager.
4. (On-prem only) Verify public-TLS reachability. Draxis runs from public egress IPs; an on-prem DSP on a private IP is blocked by the SSRF guard. Front with a reverse proxy that terminates public TLS and allowlists Draxis's egress range.
5. Verify connectivity before wiring Draxis:

   curl -sk -H 'Authorization: Bearer <token>' \
     'https://<your-tenant>.varonis.io/api/v1/system/info' \
     | jq '.version, .deployment'

   Should print your DSP version and deployment descriptor. 401 = wrong token; 404 = wrong base URL (path differs on some older on-prem DSP versions, check your Varonis Public API Guide).

Wire it into Draxis

1. Open Settings → Integrations in your tenant.
2. Click Add integration and pick Data Security Posture (DSPM) as the source type.
3. Pick Varonis Data Security Platform from the vendor dropdown. Draxis pre-fills the auth method and daily schedule.
4. In API Base URL, paste your Varonis tenant URL (SaaS) or on-prem Management Server URL. No trailing slash or path.
5. In API Key / Token, paste the Varonis API token from step 3. Draxis encrypts it server-side with encryption.key before storage.
6. Click Test. Green means Draxis called /api/v1/system/info successfully, the message includes your DSP version.
7. Under KRIs to import, tick the KRIs you want Draxis to manage. All ten varonis_* KRIs are checked by default; uncheck the SaaS-external-shared KRI if you don't have Varonis SaaS connectors on M365 / Google Workspace, and uncheck the UBA KRI if you don't license DatAlert. Selected rows are created on save.
8. Save. The connector runs daily by default.

KRIs produced

Each row is a slug the connector writes to. Draxis creates the matching kri rows automatically when you check them in the KRIs to import section of the integration form, no manual API call or seed script needed. Thresholds shown in the table are the seeded defaults; you can edit them freely in the KRIs tab afterwards.

Vendor quirks

• Endpoint paths vary across DSP versions. The connector uses the conventional paths from Varonis's Public API Guide, but SaaS DSP, on-prem DSP, and older DatAdvantage deployments have slight variations. The connector tolerates 404 per-KRI with warn logs so a path mismatch on one endpoint doesn't abort the run, but you'll see zeros on the affected KRIs. If multiple KRIs return 0 with 404 warns, check your Varonis Public API Guide and adapt the paths in the connector (one-line edits).
• On-prem DSP on a private IP is blocked. Same story as Splunk, Palo Alto on-prem, and GHES: Draxis's SSRF guard rejects RFC1918 addresses. Front with a public-TLS reverse proxy, or switch to SaaS DSP where the hostname is public.
• Module gating. UBA / DatAlert module is required for the anomalies KRI; Varonis SaaS connectors on M365 + Google Workspace are required for the SaaS-external-shared KRI. Unlicensed modules return 403/404, recorded as 0 + warn.
• "Sensitive" means Varonis-classified. The exposure and stale-data KRIs filter on Varonis's own classification tags (PII / PHI / PCI / etc.). Data that isn't classified, either because classification hasn't run yet, or because your org uses custom classification labels, won't count. Review your Classification Policies before interpreting these KRIs.
• Blast radius varies by Varonis version. Newer DSP returns blast radius directly; older DatAdvantage versions computed a similar metric under a different field name. If the KRI always reads 0, verify your DSP exposes the /blast-radius/top-users endpoint (or its equivalent).
• Dormant threshold is Varonis-defined. The connector passes dormant=true to Varonis, which uses its own inactivity threshold (configurable in DatAdvantage policies, typically 30-90 days). Tune your Varonis policy if the threshold doesn't match your compliance requirement.
• External-user classification depends on identity source. Varonis's user_type=external flag is accurate when the identity source (AD / Azure AD / Okta) distinguishes guests from members. Misconfigured tenants might show 0 or misclassify, verify in the Varonis console.
• Privileged excess-access KRI can be noisy on first rollout. Varonis's role analysis needs baseline activity to establish "normal role behavior"; in the first 30 days, every privileged user might show as anomalous. Wait a month of data before thresholding aggressively.
• Alert-severity tier is not split in this KRI. The user spec asked for "unresolved data threat alerts > 4h (by severity tier)", KRIs are single numbers so we aggregate across severities. For per-severity breakdowns, use Varonis's own dashboards, or edit the connector to split into multiple KRIs (one per severity).
• Rate limits are lenient. Varonis DSP typically allows 100+ API calls per minute per token. The connector makes ~11 calls per run, well under the cap.
• Token rotation is manual. Varonis API tokens don't auto-expire unless configured; rotate on a cadence that matches your data-access security policy (typically 90-180 days).

Troubleshooting

• Test returns 401, token is wrong or the service account was disabled. Regenerate in the admin console.
• Test returns 404 on /api/v1/system/info, your DSP version exposes system info under a different path. Check your Varonis Public API Guide for the canonical path; the other KRIs may also need path adjustments.
• Save-time error "host resolves to a private address", on-prem DSP on a private IP. Front with a public-TLS reverse proxy.
• All KRIs return 0 with 404 warns, endpoint paths don't match your DSP version. The connector is built against SaaS DSP's current API surface; older on-prem deployments may need path customization.
• varonis_saas_external_shared_sensitive = 0, you don't have the Varonis SaaS connector deployed on M365 / Google Workspace. Deploy those connectors in the Varonis admin console to populate.
• varonis_uba_anomalies_24h = 0 on a tenant with active UBA, either no anomalies fired in the last 24h (possible on a healthy org), or the DatAlert module isn't licensed for API access. Verify in the Varonis admin console that DatAlert events are queryable via API.
• varonis_blast_radius_max is suspiciously high, likely a service account or shared administrative account with broad access. Investigate the top user in the Varonis blast-radius dashboard; the KRI surfaces what\'s already visible in Varonis's UI.
• rowsSkipped > 0 and rowsWritten = 0, your tenant hasn't imported any KRIs for this integration yet. Open the integration in Settings → Integrations, tick the KRIs under KRIs to import, and save.
• Still stuck? Open a support ticket with the run ID (from Run history) and we'll dig in.