Security and encryption

This page answers the question a management team asks first: who can read our data once it is in orboto? It says what is encrypted today, what you can switch on yourself, and - just as plainly - what encryption does not protect against.

The short version

On orboto Cloud every customer has an instance of their own with its own database. There is no shared database between customers.

Encrypting your stored files

Added in v0.203.0 Every file orboto stores for you can be encrypted before it is written, with a key that belongs to your instance. This is part of the Enterprise plan.

What you should know before you switch it on:

• You decide, and you can change your mind. Nothing is encrypted behind your back, and switching it off again works the same way in the other direction.
• Nothing is interrupted. Files that are already there keep working. A background run converts them at a pace that leaves the rest of orboto responsive; the status shows how many files are done.
• Nothing is thrown away on the way. Every file is converted, read back and compared before the old version is replaced.
• Each file gets its own key. That key is locked with your instance's main key. Replacing the main key takes seconds and never rewrites a file.
• If a licence expires, your encrypted files stay readable. Only switching another area on is blocked.

How to switch it on is described in Switching encryption on, step by step.

Encrypting your backups

Added in v0.203.0 When you switch backup encryption on, orboto encrypts every backup archive before it leaves your instance. Whatever the destination is - orboto's own storage, your own S3 bucket, or the platform destination we manage for you - the archive arrives already encrypted. Someone who gets hold of the file gets ciphertext and nothing else.

Who holds the key. Normally it is your instance's own key, the same one that protects your files. That is convenient, and it has one consequence you should know: an archive sealed with it can only be restored where that key still exists. If your instance and its key are gone, so is the archive.

The passphrase export. For a backup that survives the instance, every on-demand export can be sealed with a passphrase you choose. An archive sealed that way restores on a brand-new, empty orboto - it needs nothing but the passphrase. Choose at least twelve characters and keep it where you will still find it in two years.

What else to know:

• Switching it on later. You can turn backup encryption on and off whenever you like. orboto converts the archives it still holds in your instance one at a time, checking each before it replaces it. Archives that already went to your own bucket are never touched: they stay as they were written, and the admin page tells you how many those are.
• Mirrored files. Added in v0.230.0 A "Files only" backup job is the exception to the rule above, because its copies converge. It copies a file that orboto keeps encrypted as its ciphertext and never decrypts it for the mirror. While backup encryption is on, it encrypts a plain file with your instance key before the upload. On its next run it replaces the plaintext copies earlier runs wrote, and after a key rotation or a change of key provider the copies that still use the old key. An encrypted copy is never replaced by a plaintext one, even after you switch backup encryption off. See Encrypted file mirror.
• Restoring. Nothing special to do: orboto recognises an encrypted archive and opens it. If it cannot - wrong key, missing passphrase, damaged file - it says so and stops before it changes anything in your workspace.
• Key rotation. Rotating your encryption key re-keys the archives orboto holds without rewriting them. Archives sealed with a passphrase stay on their passphrase; the admin page counts them separately.
• From the command line: orboto encryption enable --scope backups, orboto encryption sweep --scope backups, and orboto backup export --passphrase-stdin for a passphrase-sealed export. The passphrase is read from standard input, never from a flag, and is never written to a log.

Switching encryption on, step by step

Added in v0.203.0 Encryption is your choice, per area: the files you upload and your backup archives are decided separately. The database disk is handled by your host and shown on the same page read-only.

Open Admin -> Encryption. The page shows each area, its state and the fingerprint of the key in use. Switching on is a short guided run:

1. Choose what it should cover: files, backup archives, or both.
2. Read and tick. Every point that comes with the change is shown on its own and you tick it yourself. There is no "accept all". orboto records who ticked it, when, in which language and which version of the text they read - you find that list at the bottom of the page.
3. Start and watch the conversion. Files are re-written one by one in the background. Nothing is lost and orboto keeps working; uploads are a little slower while it runs. On a large workspace this takes hours.
4. Check the result: the counts have moved from "plaintext" to "encrypted" and the key fingerprint is the one you expect.

You can close the page at any time. The run picks up where you left it, on any computer and for any of your admins. Do it with us opens a thread with your current step already in it, and we walk you through the rest.

Switching off works the same way in reverse, with its own points to read. The first of them is the one that matters most: your files become ordinary files again, readable by anyone who can read the storage or a copy of it.

orboto refuses to start a change while your key does not answer, and tells you so, instead of starting a conversion that cannot finish.

When you first set up an orboto that includes encryption, we ask you once whether you want everything encrypted. You can say yes, later, or no. If you say no we never ask again, and you can still switch it on here whenever you want.

From the command line: orboto encryption status, orboto encryption enable and orboto encryption disable (both name each point and ask you to confirm it), orboto encryption flow to see where a half-finished change stands, orboto encryption sweep --watch to follow the conversion, and orboto encryption confirmations for the list of who confirmed what.

Holding the key yourself on orboto Cloud

Added in v0.203.0 You can bring your own key: orboto seals every file, backup archive and stored password with a key your own key service holds, and asks that service to unlock them.

• On orboto Cloud the key lives in your own key service, reachable over HTTPS - HashiCorp Vault, or a small adapter in front of the key management of your cloud provider. If you run orboto yourself you can also use AWS KMS directly or a key file on the server. AWS KMS in your own AWS account for orboto Cloud is being built; this page will name the release that brings it.
• A key is tried before it is saved. orboto locks a test value with it and unlocks it again. If that fails, nothing is saved and your previous key keeps working.
• Taking the key away is your emergency brake. orboto keeps running and everyone can still log in, but every encrypted file answers with an error instead of opening. Nothing is deleted. The encryption page shows since when the key has not answered and what your key service said. Put the key back and the files open again by themselves, without a restart and without a support ticket.
• It takes effect within five minutes. orboto remembers an unlocked file key for up to five minutes, so a withdrawal reaches a file that was just opened within that window, and every other file at once.
• Rehearse losing the key tries all of that on a test file of its own, so you can see it happen without touching your data.
• Changing the key moves passwords, files and backup archives onto the new one in a single pass, and everything stays readable while it runs.

The key settings are a section of Admin -> Encryption; the technical details are on Bring your own key. From the command line: orboto encryption rotate and orboto encryption drill.

What this protects against - and what it does not

Protected: the storage itself, its backups and any copy of them. A stolen disk, a leaked storage bucket or a snapshot that ends up where it should not contains nothing readable.

Not protected: the operator of a running instance. An instance that shows you a file has to hold the key while it does so. Whoever operates the machine the instance runs on could, in principle, read what the instance can read. There are two honest answers to that concern:

1. Run orboto yourself. The self-hosted edition is the same product; then nothing leaves your own servers.
2. Hold the key yourself. With Bring your own key the main key lives in your own key management service. Revoke it there, and everything it protects becomes unreadable - that is your off switch.

One operational area stays unencrypted by design: the safety snapshot taken before a database upgrade, which must remain restorable even when the instance itself is broken.

For your security review

• Encryption: AES-256-GCM, one key per file, files split into blocks so that a large file never has to be held in memory and a part of a file can be read without decrypting all of it.
• Integrity: every block is bound to its file, its position and the file's properties (including its type). Reordered, shortened or spliced files are rejected, never served.
• Key handling: the per-file key is wrapped by the instance's main key through the same mechanism as Bring your own key; rotating the main key re-wraps the per-file keys only.
• Audit: every switch and every conversion run is written to the audit log with the person or agent that started it.
• Hosting and sub-processors are listed in the privacy policy.