Security

1. Where your data goes

Asternodis runs on your hardware, at both of your sites. A protected guest's disk blocks travel directly from your source node to your recovery node, over your own network. They do not pass through our servers, our storage, or anyone else's. There is no cloud relay in the design and no bucket to misconfigure.

What does reach us is a periodic licence check-in carrying counts and version strings: how many pairs, guests and nodes, which build. No guest names, no addresses, no configuration, no content. The privacy policy lists the fields.

2. The link between your two sites

Pairing two sites is a deliberate, two-sided act. You generate a pairing code at one site and present it at the other; the accepting side proves it holds the same code by HMAC-signing its response, so neither half can be impersonated by something that merely reached the port. Once paired, each side pins the other's certificate fingerprint and refuses anything that does not present it.

That is one TLS channel, mutually authenticated, carrying control traffic between the two controllers. You do not need a site-to-site VPN. If you already have one (or Tailscale, or WireGuard), it works over that too.

3. The disk-block stream

Replication itself is a second link, node to node: the source node's QEMU streams changed blocks to a qemu-nbd server on the recovery node. Without TLS that traffic is plaintext on your physical network, so Asternodis mints a per-pair certificate authority and a server/client leaf pair, and runs the stream with verify-peer=on. Both ends present certificates; neither accepts an unauthenticated peer.

The recovery side generates the material and keeps the server half. The client half travels to the source over the already-authenticated control channel above, never in the clear. Each pair has its own CA, so compromising one pair's material tells an attacker nothing about another's.

Deleting a pair removes its key material with it (the per-pair TLS certificates and any ZFS encryption key) rather than leaving credentials for a peer relationship that no longer exists sitting in the database. The operation history of the guests that were protected across it is kept.

4. Secrets at rest, and secrets in logs

Pairing secrets, SSH private keys and Proxmox API token secrets are encrypted at rest in the controller's database, under a key held in the data directory.

Logs get separate treatment, because that is where credentials actually escape. Asternodis strips PEM blocks, bearer tokens, Proxmox API token secrets and password-shaped assignments from error text and operation logs before storing them, and again on the way out into a support bundle. Redaction is applied at both boundaries, not one.

5. Diagnostics you can read before you send them

asternodis support-bundle produces the archive we ask for when you report a problem. It is built from an allowlist (each field copied deliberately) rather than by dumping tables, so it carries no licence key, pairing secrets, API token secrets, SSH keys or passwords, and no guest disk contents. It is plain JSON in a .tar.gz with a manifest listing what was held back. Open it.

It is deliberately not the controller backup. A backup restores your controller, keys included. That one should never be sent to a vendor, including us.

6. Licensing cannot strand you

An activation key is an Ed25519-signed token the controller verifies against a public key compiled into the binary. There is no license server in the path: the check itself needs no network. The controller refreshes its activation daily; if it cannot reach us for about a month it warns you, then runs a 7-day grace period, and only after that stops new protection work. Failover, failback and abort are never gated on licensing: an outage on our side can never stop a recovery on yours.

And the enforcement itself fails safe. If a licence lapses entirely, scheduled replication pauses and new protected workloads are refused, but failover, failback and abort keep working. A billing problem must never become a recovery problem, and in this product it cannot.

7. Access to the controller

The web UI is served over TLS with local accounts, or against your existing directory over LDAP/AD. Destructive recovery actions can require two-person approval, and every operator action is written to a hash-chained audit log where each entry commits to the one before it, so a deletion or edit does not go unnoticed. See compliance evidence.

8. What we do not claim

Asternodis holds no security certification. It is not FIPS 140-3 validated, not VS-NfD approved, and not STIG-accredited, and we will not imply otherwise: those are approvals granted by a body against a defined profile, not properties a vendor can assert about itself. If a control matters to you, ask us directly and we will tell you exactly where we stand.

9. Reporting a vulnerability

Email security@irruptiv.com. Tell us what you found and how to reproduce it; we will confirm receipt, keep you updated while we fix it, and credit you if you would like that. Please give us a reasonable window before disclosing publicly. This is disaster-recovery software, and the people running it need time to update.