I'm currently evaluating Zero Trust Network Access solutions for a specific, constrained use case and am seeking feedback from anyone who has deployed Netskope ZTNA in a similar scenario. The architectural goal is to provide a cohort of approximately 50-75 third-party contractors with access to a single, isolated subnet containing only the application servers they require for development work. All other internal corporate resources must be completely invisible and inaccessible, adhering to a true least-privilege model.
My primary interest is in the operational and data-plane realities of Netskope's implementation, particularly when compared to a more traditional VPN concentrator or an open-source ZTNA alternative. The marketing materials, of course, promise seamless segmentation, but I'm looking for concrete details on the following:
* **Policy Granularity:** Can access controls be defined strictly by source user/group (e.g., Active Directory group "Contractor_Project_X") *and* a destination CIDR block (e.g., `10.10.20.0/24`), without resorting to complex application-level definitions? I need network-level isolation, not just URL-based.
* **Client Agent Overhead:** What is the observed performance impact of the Netskope Client on developer machines, specifically regarding latency for TCP connections to on-premises resources? Benchmarks against a baseline (direct connect or standard IPSec VPN) would be invaluable.
* **Audit & Logging Fidelity:** Does the logs and reporting provide unambiguous, connection-level detail (source IP, destination IP:port, user, decision) that can be ingested into a SIEM? Example log schema would be helpful.
* **Subnet Routing Configuration:** On the backend, how is traffic to the designated subnet routed? Does it require a connector/gateway deployed within the target subnet, or can it route cleanly from a centralized gateway? I'm concerned about introducing a new network hop and the associated latency.
Our current proof-of-concept setup uses an open-source alternative, and the configuration for a simple subnet-only rule looks conceptually like this, though the vendor-specific implementation is what I need to compare against:
```yaml
# Conceptual Policy Rule
access_rule:
name: "contractor_subnet_access"
user_group: "ad://CN=Contractors,OU=Groups,DC=corp"
target_resources:
- cidr: "10.10.20.0/24"
protocols:
- tcp:22-23 # SSH, Telnet (for device management)
- tcp:443 # HTTPS
- tcp:3389 # RDP
action: "allow"
logging: detailed
```
Has anyone implemented Netskope ZTNA in this "subnet-as-the-application" paradigm? I am particularly interested in any gotchas related to non-HTTP/S protocols (e.g., SSH, RDP, database ports) and whether the client agent handles them as transparently as promised. Any data on connection establishment times and bandwidth overhead would directly influence our build-versus-buy analysis.
-- elliot
Data first, decisions later.