Test Zscaler
To test zscaler, you check your client app status and send traffic through the cloud edge. You then read the network logs to confirm that your rules block or allow requests. Most teams start this check by routing all test users through one broad group rule. If these roles are too wide, any logged-in user can reach sensitive internal systems. How to test zscaler network and rule setups First, you verify that the client app runs on the user device. The app grabs local network packets and sends
Zscaler: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To test zscaler, you check your client app status and send traffic through the cloud edge. You then read the network logs to confirm that your rules block or allow requests. Most teams start this check by routing all test users through one broad group rule. If these roles are too wide, any logged-in user can reach sensitive internal systems.
How to test zscaler network and rule setups
First, you verify that the client app runs on the user device. The app grabs local network packets and sends them to the nearest cloud edge node. You can open a status page to see if the tunnel is active and healthy. This page shows the user identity, the cloud node location, and the active rule group.
Next, you test private app reach by opening an internal tool or database port. The cloud edge checks the user identity against your central directory groups. If the group matches the rule, the edge connects the user to the internal connector. That connector sits inside your private network and forwards traffic to the target host.
You should also test blocked paths to confirm your deny rules work as planned. Try to reach a restricted host using a test account with low permissions. Then, open the central log viewer to check that the system recorded a block event. Reviewing both allowed and blocked events confirms that your routing rules match your security plan.
Why network checks miss active command risks
Checking your network rules proves that the right users can reach the right internal hosts. It stops outside attackers from scanning your private ports on the public web. It also replaces old network tunnels that used to give full subnet reach to everyone. Still, network routing checks only control who opens a path to a server or database.
Once the network tunnel opens, the user still logs into the database with local keys. Those shared keys often hold broad read and write permissions across every table. The network edge sees encrypted packets passing through, not the exact queries or shell commands. It cannot stop a developer from running a drop table command on a live system.
Zscaler: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Also, network routing does not rewrite sensitive fields inside database query results. If a user runs a broad select statement, raw emails and phone numbers return intact. Teams end up managing static database passwords alongside their network rules. This split setup creates blind spots during audits because network logs lack query details.
How to audit internal sessions beyond the network edge
To close this gap, teams must check what happens inside each active database session. Start by removing shared static database keys from developer laptops and local config files. Map each person to specific actions they can run, rather than just hosts they can reach.
You should also inspect queries and commands in flight before they hit the data store. Set up rules that rewrite sensitive fields like card numbers or national IDs in results. This step keeps raw personal data out of local screens and test logs. Finally, record every statement with the exact user identity so audit teams see full activity.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How do I check if my traffic routes through the cloud edge?
Open the local client app on your device and check the tunnel status screen. You can also visit the built-in browser check page to view your active cloud node.
Why can a user reach a database when the rule blocks them?
Check if the user belongs to another directory group that sits higher in rule order. Rules run from top to bottom, so an early allow rule overrides a lower block.
Does network routing log the exact SQL queries my team runs?
No, network edge tools only log host connections, ports, and byte counts. You need a session-level tool to read, log, or control individual SQL queries and commands.