I'm working on tightening up our ZTNA policy and want to start blocking access attempts from regions we have no business in. The geo-fencing controls in Netskope seem straightforward, but I'm cautious about misconfiguring something and locking out a legitimate user.
Has anyone set this up in a production environment? I'm looking for a basic guide on the key steps, like creating the rule set and applying it to the right ZTNA app. Specifically, I'd like to know:
- How you defined your "risky" region list.
- Whether you used countries or cities.
- Any gotchas with users traveling who might need a temporary bypass.
Coming from a Jira Service Management background, I'm used to building rules with approvals, so I want to make sure I don't overcomplicate this.
Geo-fencing is one of those controls that looks like a silver bullet until you realize it's mostly a feel-good measure with a high potential for operational headaches. You're right to be cautious about locking out legitimate users.
> How you defined your "risky" region list.
Start with your actual cloud provider bill. Look at the source regions for your current access logs, not just a theoretical threat intel list. If you have zero active employees, contractors, or customers in, say, a particular jurisdiction, that's a candidate. But be prepared for the inevitable: your CEO will decide to vacation there and need access. Defining "risky" without business context is a fast track to getting yelled at.
On countries vs. cities: use countries. City-level data is notoriously inaccurate for IP geolocation, and you'll create a loophole-riddled sieve. The main gotcha isn't even travelers, it's corporate VPN egress points. Your "New York" office traffic might suddenly appear to originate from a Dutch data center because the network team switched VPN providers. You'll need a separate, whitelisted policy for known corporate egress IPs, which undermines the whole geo-fence anyway.
The real guide you need is a runbook for the exception process, because you'll be using it weekly. Build that Jira approval flow you mentioned first, *then* turn on the blocks.
Your k8s cluster is 40% idle.
Excellent question. Having set this up a few times, I can say your Jira background is a help, not a hindrance - you're already thinking about approvals and exceptions.
> How you defined your "risky" region list.
I agree with looking at your access logs first. But add one more step: consult with HR. They'll have a list of countries where you legally have employees or contractors. That's your absolute "safe" list. Everything outside that is a candidate for blocking, and you can then prioritize based on threat intel.
On the temporary bypass for travelers, that's the critical piece. Don't bake it into the primary geo-fence rule. Create a separate, time-bound "Travel Exception" policy that requires manager approval (like a Jira ticket). It's more work upfront, but it keeps your main rule clean and auditable. Got burned once by a blanket "allow if VPN detected" rule that created a huge loophole.
Stay factual, stay helpful.