Skip to main content
OMNINET VISION OmniNet Vision LLC — home
Technical brief

Edge node security architecture

ONV-WP-2026-V1 · Public

1Summary

Putting a physical node on an internal segment is a meaningful ask, and the honest way to answer it is to document what the node can and cannot do rather than assert that it is safe. This brief covers the transport model, what happens to data before it leaves your site, how clients are kept apart, how the runtime is isolated, and how long data is kept.

2Transport: outbound only

The node accepts nothing from the internet. It establishes an encrypted WireGuard tunnel outward to the collection platform and sends everything over it. Your perimeter firewall needs no new rule, no port forward, and no NAT exception — one outbound UDP flow.

On your internal network it accepts only what your own devices send it: syslog, SNMP traps, and Wazuh agent traffic if you run agents, from the subnets you name. Its management access arrives through the tunnel, not from your LAN.

Each node has its own WireGuard key, issued centrally and never generated or shared on site, and the platform accepts traffic from it only at the single tunnel address assigned to it.

3Redaction before transmission

The collector on the node redacts credential-shaped values — passwords, secrets, tokens, API keys, bearer authorisation headers — from every event before it leaves your site. They are never transmitted, so they are never stored.

This is pattern-based redaction of credentials, not a classifier for regulated data. Where logs may carry patient or cardholder data, the collection itself is scoped at deployment: which sources the node reads, and which it does not.

4Client separation

Telemetry from every client lands on a shared collection platform, so separation is the property that matters most. The platform identifies a client by the tunnel address a node sends from — which the node cannot choose, because its tunnel accepts it only at its own address — and overwrites any identity the node claims. Ingest is write-only: nothing a node can reach will return data.

This is tested rather than asserted. Every deployment of the platform ends by attempting a forged write, a read through the ingest path, and a query of one client's test data as another; any success stops the deployment.

5Runtime isolation

Services run as Podman containers under systemd with no-new-privileges. Only the sensors that capture packets hold the capabilities to do it, and they read a mirror port: none of them sits inline, so none can drop or alter your traffic, and nothing on the node has write access to your infrastructure.

Databases sit on container networks with no route off the host. The node is stateless: it can be rebuilt from its deployment definition, which turns a suspected compromise into a re-image rather than an investigation of what changed.

6Storage and retention

Data is stored in Cloudflare R2, encrypted at rest, for a period set by your agreement — by default 31 days of logs and 90 days of metrics — after which the storage engine deletes it. Ending an engagement includes a documented purge.

7Monitoring the monitor

A node that goes quiet raises an alert within fifteen minutes, as does a disk filling, a collection service failing, or a certificate approaching expiry. The alerting path proves itself continuously: a heartbeat leaves the platform every minute to an external service, which pages if it ever stops.

Questions your security team will have

Happy to go through this with them directly, including the parts that are trade-offs rather than wins.

Book a technical review