I've been tasked with helping our team implement a more granular Zero Trust Network Access policy using Netskope, specifically to delineate access between our development and finance departments. The goal was to move beyond a simple "allow/deny" for SaaS applications and get into the specific actions each group can perform, all while ensuring the audit trail is comprehensive enough for our SOX and internal compliance requirements.
Our starting point was a single, overly permissive policy that allowed all "corporate users" access to both GitHub and NetSuite. The finance team had no need for GitHub, and the devs certainly shouldn't be initiating payments in NetSuite. Here's a breakdown of the high-level approach we took, focusing on the loggable events.
First, we structured our Users and Groups in IdP (Okta in our case) meticulously. We created groups like `idp_finance_us` and `idp_developers_backend`. This granularity at the source is critical for clear policy creation and, later, for unambiguous audit log entries. In Netskope, we then created corresponding Internal Network Entities based on these IdP groups, which become the building blocks for our ZTNA rules.
The core of the work was in the Netskope Private Access (NPA) policy. We broke it down into separate rules. For the finance team's access to NetSuite, we needed to be extremely precise. We didn't just allow "NetSuite"; we specified the exact URL (e.g., ` https://1234567.app.netsuite.com`), and crucially, we used the "Activities" filter to restrict them to specific functions. The policy allows only activities like "View Report," "View Transaction," and "Download Financial Report." Activities like "Create Payment," "Edit Vendor Record," or "Run SuiteScript" were explicitly denied in a higher-priority rule for a subset of finance users without those duties.
For the developers' GitHub access, we again moved beyond just the domain. We created a rule allowing the `idp_developers_backend` group to `github.com` and `githubenterprise.example.internal`, but with a key activity restriction: we blocked the "Delete Repository" activity universally. Furthermore, we leveraged Netskope's ability to inspect the path to create a sub-policy: a smaller group of senior leads was granted access to the `settings` pages of repositories (`/orgs/OurCompany/settings`), while the broader developer group was limited to code and project management paths.
Here is a simplified, anonymized example of what the NPA policy configuration looks like for one of these rules:
```
Rule Name: Finance_US_NetSuite_ViewOnly
Description: Allow US Finance team read-only access to specific NetSuite account.
Status: Enabled
Users and Groups: Internal_Network_Entity:idp_finance_us
Resources:
- Type: Host
Value: 1234567.app.netsuite.com
Port: 443
Protocol: TCP
Activities: [View Report, View Transaction, Download Financial Report]
Action: Allow
Logging: Enabled (Verbose)
```
The audit log is where this pays off. When configured with verbose logging, queries in our SIEM (Splunk) now show entries with clear context:
- `user: jane.doe@company.com`
- `user_group: idp_finance_us`
- `accessed_resource: 1234567.app.netsuite.com/app/accounting/transactions/journal.nl`
- `activity: View Transaction`
- `policy_applied: Finance_US_NetSuite_ViewOnly`
- `result: allowed`
Conversely, an attempt by a developer to access that same NetSuite URL would log a `result: denied` with the denying rule name, and an attempt by a junior finance user to initiate a payment would show a denial on the "Create Payment" activity. This level of detail is invaluable for compliance audits and security incident investigations.
Some pitfalls we encountered:
* The initial sync of IdP groups and the mapping to Internal Network Entities requires careful timing to avoid policy mismatches.
* Defining "Activities" is application-specific and requires testing; not all SaaS apps have the same granularity of actions that Netskope can recognize.
* The order of rules is paramount. We place the most specific deny rules (e.g., "Finance_Junior_NoPayments_Deny") above broader allow rules.
* Ensuring the logs are forwarded completely to our SIEM was a separate project; we needed to validate that all fields (especially the `activity` and `policy_applied` fields) were being parsed correctly for reporting.
The outcome has been a much tighter security posture and, frankly, a much easier time during audit periods. We can now produce reports showing exactly who can perform sensitive actions and, more importantly, provide evidence of those policies being enforced in practice through the detailed audit logs.
Logs don't lie.