Air Gapped System
An air gapped system stays safe by keeping all machines off the public internet. You build one by removing external network links and moving files on physical drives. Many teams use this setup to protect critical servers and sensitive data stores. Still, once admins step inside the room, they often share broad local accounts. Those wide roles let one mistake wipe out important records or break key apps. How an air gapped system works in practice To build an air gapped system, you cut all phys
Gapped System: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An air gapped system stays safe by keeping all machines off the public internet. You build one by removing external network links and moving files on physical drives. Many teams use this setup to protect critical servers and sensitive data stores. Still, once admins step inside the room, they often share broad local accounts. Those wide roles let one mistake wipe out important records or break key apps.
How an air gapped system works in practice
To build an air gapped system, you cut all physical and wireless links outside. Servers sit in a locked room with no Wi-Fi cards and no internet cables. The local network links only the machines that live inside that closed zone. When an app needs an update, an admin downloads the files on a separate computer. The admin scans the files for bad code and copies them to a drive.
Next, the admin carries that drive into the locked room and plugs it in. A local identity server checks who can log in to the isolated machines. Teams set up local roles that group users by their daily job tasks. A database admin gets a role that allows full read and write tasks. A support worker gets a smaller role that only reads app status logs.
All log files stay on a dedicated storage server inside the same room. Security staff must walk in and read those logs to spot odd activity. Nothing leaves the room unless someone carries it out on an approved drive. This strict flow keeps outside attackers from reaching the machines over the web.
Where physical isolation falls short for local control
Physical walls stop remote attacks, but they do not control local user actions. Once an engineer logs in at a local console, the system trusts that session. Native roles decide who can log in, not what each command does in flight. An admin with database rights can run a bad query that drops a table. That same admin can read full tables that hold emails and card numbers.
Shared local keys make this problem much worse for audit teams. In many closed rooms, several operators use the same root account to fix bugs. When a bad command runs, the local log only shows the shared role name. You cannot tell which person typed the command or why they needed that access. Fixing this gap requires controls that check every single command and mask sensitive fields.
Gapped System: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing updates and audits in isolated networks
Running a closed network takes strict daily habits from the whole tech team. Every software patch must go through a test lab before it enters the room. Engineers check that the new patch will not break existing tools or local scripts. They also write down the exact file hashes to prove the files stayed clean.
Audit teams need a clear record of every change made inside the zone. They review who entered the room and which machines each person touched that day. When query results mask phone numbers and national IDs, audits go much faster. Masking rewrites matched fields in results so admins can fix issues safely. Strong local controls turn a basic isolated room into a well-run operation.
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
What is the main goal of an air gapped system?
The main goal is to block all remote network paths to critical machines. By cutting internet links, teams stop outside hackers from stealing data over the web.
How do teams move software updates into a closed network?
Engineers download updates on an outside machine and scan them for threats first. They then copy the clean files onto a physical drive and carry it inside.
Why do isolated networks still need strict role controls?
Physical walls do not stop mistakes or bad actions from people inside the room. Strict controls check each command and rewrite emails or card numbers in query results.