Security

Go to the contents

24.1 Transport: TLS and pinning#

Every connection between agent and bkp_target is TLS-encrypted. The agent checks the server against exactly the certificate given with --tls-ca (pinning), not against the certificate authorities of the system. If the certificate differs, the agent aborts (status code -8, Chapter 26). This protects against a substituted server, but requires that target.crt reaches the clients safely.

24.2 Authentication: API keys and ACL#

• An API key is a random 256-bit value that the server only keeps in memory as a SHA-256 hash.
• Every key is bound to one or more directories. An agent can only write and read there.
• Make key files on the clients readable only for the executing user (chmod 600).
• One key per client; revoking a key means deleting its line from the ACL and restarting the server.

24.3 Updates: Ed25519 signature#

An update is code that runs as root/SYSTEM. Therefore:

• The manifest is signed with Ed25519 (the signature covers a fixed prefix plus the exact manifest bytes). The updater only trusts the built-in or configured public keys.
• TLS with certificate and host check is mandatory (no HTTP, not even through redirects). But it only protects the transfer; the content is protected by the signature. Packages are bound through SHA-256 and size from the signed manifest.
• The manifest has an expiry date and an increasing number: an old, validly signed state (“replay”) is refused, an expired manifest as well.
• Packages are unpacked strictly: only regular files and directories, no .. or absolute paths, no links or devices, size limits; PACKAGE.json must confirm the files and the version promised in the manifest exactly.
• blocked_versions blocks a version; a downgrade is only possible with --allow-downgrade --to <version>.
• The updater only installs packages with allow_package_install = yes; the names come from the signed manifest and are checked strictly.

24.4 Data at rest#

Without encryption the data lies in the store only compressed: whoever has access to /srv/backups can read it. With encryption= and key= in the sink (Chapter 6) the agent encrypts every chunk before it leaves the machine; the server then only sees structure and sizes, never contents, and never needs the key. The encryption is authenticated: tampered data is detected on reading and never written back unnoticed.

• Without encryption protect the storage directory through file permissions, an encrypted file system (for example LUKS) or an encrypted volume.
• Shared stores: whoever may write into a store can tell through deduplication whether a certain chunk already lies there, and with the matching key read all runs in it. Machines that do not trust each other therefore get their own directories (ACL) or their own stores and keys. For shared stores choose sha256 or blake3 as ID hash, never xxh3-128 (Chapter 3).
• WORM locks (--worm, Chapter 10) protect runs from being deleted by maintenance commands. Against an attacker with root rights on the server only a second copy at another place (mirror, archive) helps on a local file system.

24.5 Checklist#

• Server key target.key and ACL readable only for root or the service account aegisgrid.
• A key of its own per client with a directory binding as narrow as possible.
• Encryption key backed up at a second place; without it the data is lost.
• release.key offline, backup copy at a second place.
• Access to bkp_restore, target.crt, API key and encryption key also available outside the backed-up system.
• Regular restore test, regular scrub and a second copy (sink or mirror).