Airgapped Data Collection
You set up airgapped data collection by writing local files to one-way hardware or media. Then a staging host reads those files and loads them into your main system. Most teams start by giving admin roles broad read rights on the isolated database. When permissions are too wide, one bad script can pull raw secrets or private data. How airgapped data collection works in practice An airgapped network has no direct link to the outside world or the internet. Teams still need logs, metrics, and re
Evidence Collection Automation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up airgapped data collection by writing local files to one-way hardware or media. Then a staging host reads those files and loads them into your main system. Most teams start by giving admin roles broad read rights on the isolated database. When permissions are too wide, one bad script can pull raw secrets or private data.
How airgapped data collection works in practice
An airgapped network has no direct link to the outside world or the internet. Teams still need logs, metrics, and records from these closed systems for daily checks. To get this data out, you must build a strict path with clear steps.
First, an internal worker app runs on a schedule inside the secure zone. This app uses a local role to read rows from your tables or log files. It bundles the output into flat files and writes them to a local staging folder. Each file gets a cryptographic hash so you can check it for changes later.
Next, you move the files across the physical or one-way boundary. Some teams use a hardware data diode that sends light pulses in one direction only. Other teams use encrypted drives that a human operator walks to an outside kiosk. The kiosk scans the drive for threats and checks the file hashes before import.
Preparing roles and local export rules
Good export workflows start with tight local roles on the source database or host. You should create a dedicated read role that only sees the tables you need. Never reuse a full admin key for a routine export job. If that key leaks inside the zone, anyone there can read all your tables.
You also need clear rules for what goes into each export batch. Set up local views that leave out sensitive columns before the worker reads the table. If a field holds emails or phone numbers, mask or drop it at the source. Keeping raw card numbers or national IDs out of export files lowers your risk.
Finally, log every export run on a separate local host inside the closed room. Record which role ran the query, when it ran, and how many rows it pulled. When an auditor asks what left the room, this local log gives the answer.
Evidence Collection Automation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native setups solve and what they miss
Native roles and hardware diodes solve the network isolation problem well. They stop outside attackers from opening a remote shell into your closed hosts. They also prove that traffic only flows out of the secure room, never back in.
Still, static roles only decide who can log in to the local database. They do not inspect what individual queries or commands do while a session runs. Once an engineer or script logs in, the database trusts every valid query they send.
A user with a broad read role can run a bulk dump by mistake. Static database roles also cannot require a second person to approve a risky query first. And if a table holds raw emails or card numbers, native roles rarely rewrite matched fields in results on the fly. Teams end up building custom scripts to scrub files, which break when schemas change.
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 safest way to move files out of an airgapped room?
A hardware data diode is the safest method for steady data flows. It uses a physical one-way link so no signal can ever travel back in. For smaller setups, use dedicated encrypted media with strict malware scans on a staging kiosk.
Why are static database roles not enough inside an isolated network?
Static roles only check identity at login and grant broad table rights. They do not stop an insider or broken script from pulling too many rows. You still need controls on individual queries and results to protect private fields.
How do we handle private data during an offline export?
You should filter or mask private fields before writing files to disk. When masking rewrites matched fields in results, raw emails and national IDs stay out of your export bundles. This keeps your staging host clean if a file is lost during transfer.