Jumpserver Architecture
You set up a jumpserver architecture by linking a central control node to protocol connectors. These parts check user roles and route traffic to internal Linux or Windows servers. Most teams group hosts into shared folders and assign broad role rules to save time. When roles are too wide, one engineer can run risky commands across many production servers. How a jumpserver architecture works in production A standard jumpserver architecture splits work across four main software parts. The core
Zero Trust Architecture: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a jumpserver architecture by linking a central control node to protocol connectors. These parts check user roles and route traffic to internal Linux or Windows servers. Most teams group hosts into shared folders and assign broad role rules to save time. When roles are too wide, one engineer can run risky commands across many production servers.
How a jumpserver architecture works in production
A standard jumpserver architecture splits work across four main software parts. The core API service stores user accounts, server lists, and role rules. This core app talks to a backend database where all state records live. A cache service holds temporary login states and active task queues for fast lookups.
Protocol connectors sit between the user and the target server. One connector handles Linux shell traffic, while another manages Windows desktop sessions. When an engineer logs in, the web front end checks their identity with the core service. Once approved, the connector opens a network path to the destination host.
Admins do not hand out direct server keys to every person on the team. Instead, the central system holds the host keys in its encrypted database store. The connector reads the right key and logs into the server for the user. This setup stops people from saving raw private keys on their laptops.
Where host-level access leaves gaps for data security
This native setup works well when you just need to control who logs in. It keeps a clean list of servers and stops direct network exposure to the public internet. Admins can group machines by project and revoke a user account in one place. For basic server tasks, this perimeter model solves the initial login problem.
The main gap appears after the user opens a valid session on the host. Host-level tools decide who can enter, not what individual statements or queries do in flight. Once inside a server or database shell, an engineer holds full power for that role. A valid user can still run a bad query that drops a table.
Teams also struggle with sensitive customer fields during live fixing work. When an engineer runs a database query, the output returns raw emails, phone numbers, and card numbers. Basic host connectors pass that raw text right back to the user screen. Only dynamic data masking rewrites matched fields in results before they reach the client.
Zero Trust Architecture: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Scaling the setup across multiple cloud networks
Large teams often run servers across more than one cloud or data center. In this case, you place remote protocol connectors inside each private network zone. These remote nodes talk back to the main core service over an encrypted link. Users still log into one main web portal to reach any allowed server.
You must watch the load on the central database and cache nodes as you grow. Every active shell or desktop stream sends status updates back to the core service. Putting two core nodes behind a load balancer helps keep the login portal online. If one node fails, the second node takes over the incoming web traffic.
Even with a big cluster, you still face the problem of static role assignments. People keep permanent access to production systems long after they finish a support ticket. You need a way to approve single actions and filter sensitive data on the fly.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What are the main parts of a jumpserver architecture?
The setup uses a core API service, a web front end, and protocol connectors. It also needs a relational database and a cache store to save state.
How do protocol connectors handle server keys?
The core database stores the server keys in an encrypted format. The connector fetches the key at login time so users do not hold raw credentials.
Does a jumpserver filter sensitive fields inside database query results?
No, it manages the login path and logs the raw session stream. It does not rewrite emails, phone numbers, or national IDs inside live query outputs.