Air-gapped Remote Access
You set up air gapped remote access by routing approved traffic through controlled network zones. You must verify user roles and inspect every transfer before data enters the closed network. Teams often build a middle zone that holds strict firewall rules and local directories. When local roles are too broad, one bad script can harm the whole isolated site. How air gapped remote access works in practice An air gap keeps critical servers off the public internet and office networks. No outside
Remote Browser Isolation (RBI): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up air gapped remote access by routing approved traffic through controlled network zones. You must verify user roles and inspect every transfer before data enters the closed network. Teams often build a middle zone that holds strict firewall rules and local directories. When local roles are too broad, one bad script can harm the whole isolated site.
How air gapped remote access works in practice
An air gap keeps critical servers off the public internet and office networks. No outside machine can talk to these isolated hosts over a direct wire. Still, engineers must fix bugs, apply patches, and read system logs from afar. To allow this, teams build a step-by-step path across separate network zones.
First, an engineer logs in to an outer staging host from a managed laptop. This outer host checks the user identity against a central directory and multi-factor token. Next, the user moves files or commands into a middle inspection zone. Automated scanners in this middle zone check files for malware and verify digital signatures.
Inside the isolated zone, a separate local directory holds its own accounts and keys. A one-way data diode or controlled relay pulls approved work across the boundary. Once inside, the engineer or script uses a local role to run the task. System logs then flow back out through a one-way path for central review.
What native network controls solve and what they miss
Strict perimeter rules and network diodes keep random internet attacks out of your core hosts. They make sure only known staff and signed packages cross into the isolated zone. Network firewalls also limit which ports and protocols can talk between internal segments. This design stops broad network scans and blocks unapproved tools at the border.
Still, network walls only check who crosses the border and which port they use. Once a session starts on an inner host, the firewall cannot read the commands. A technician with a local admin role can run any query or shell script. They can drop a database table or read raw card numbers by mistake.
Remote Browser Isolation (RBI): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Shared local accounts make this problem much worse during an urgent outage. Multiple operators often use the same root key when central identity servers are unreachable. Network logs will show that an inner host ran a task at midnight. They will not show which person typed the command or what data came back.
Closing the gap at the command and query layer
To keep isolated systems safe, teams must control actions after the user logs in. Each operator needs a unique identity that maps to fine-grained rules inside the enclave. Instead of granting full shell or database admin rights, teams should check every command. High-risk actions should pause and wait for a second human to approve them.
Data responses also need active filtering before they leave the target database or host. When a user runs a select query, masking rules can rewrite sensitive fields. The system replaces emails, phone numbers, and national IDs with safe placeholder text in results. This approach keeps daily maintenance safe even inside your most sensitive network zones.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How is an air gap different from a standard firewall?
A standard firewall filters traffic on a shared wire using port and address rules. An air gap separates networks by removing direct routing paths between the two zones. Data only crosses an air gap through physical media, diodes, or staged relay zones.
How do teams patch servers in an isolated network?
Teams download update packages in an outer zone and check their cryptographic signatures. After malware scans pass, they move the verified files into an internal staging server. Internal automation tools then pull the updates from that local server and install them.
Why are shared admin accounts risky inside closed networks?
Shared accounts erase individual accountability when someone changes a rule or deletes a file. If an insider makes a bad change, logs only show the shared account name. Tying every command to a single verified person makes audits clear and fast.