Security and auditing

Wondering what's encrypted, what gets logged, and whether an attacker can erase their tracks?

This article describes what Core encrypts on disk, what the server records when someone logs in over SSH, what Core records about every change anyone makes, and how to limit API access to specific IP addresses.

The short answers

Encryption at rest

"At rest" means the data as it sits on disk, when nobody is reading it.

Databases

MariaDB databases can be encrypted at rest. It is a cluster-level setting called 'MariaDB encryption keys'. Once on, every InnoDB table on the cluster is encrypted on disk: existing tables in a background pass, new ones automatically.

Nothing changes in how you use the database. Queries, mysqldump dumps, restores and phpMyAdmin all see the same content. See All about databases for the performance impact and how to check progress.

PostgreSQL databases are not encrypted at rest.

Files

Website files, uploads, logs and mailboxes are not encrypted at rest. The nodes do not use full-disk encryption.

What full-disk encryption would protect against: someone gets hold of the physical disks, or of the virtual machine's disk image, and reads the files directly instead of logging in. To do that they would have to break into the data centre and physically carry the disks out, or get access to the virtualisation platform. Data is spread across multiple disks, so taking one disk gets fragments, not a usable copy of anyone's files — you would need all of them. Only a small number of people can enter the data centre at all.

What it would not protect against, which is far more common: while a node runs, its disks are unlocked and the filesystem is mounted, because that is the only way the web server can read the files it serves. Anyone who logs in reads exactly the same files whether the disk is encrypted or not. That includes someone using a leaked SSH key or password, and someone who got in through a vulnerability in a website. Those are the realistic ways files get stolen, and encryption at rest does nothing about them.

What it costs: encrypting and decrypting happens on every read and write, so every file operation uses extra CPU and sites get slower across the board. You pay that continuously, in exchange for protection against a data-centre break-in.

If you do need data encrypted on disk, for example because a compliance rule says so: encrypt it in your application before you write it, or keep it in MariaDB on a cluster with encryption enabled.

SSH logins on a node

What is recorded

Every SSH login: the time, the account that was logged in to, the IP address the connection came from, and — for key-based logins — the fingerprint of the key used.

The fingerprint is what traces a login back to a person. With one key per person, the fingerprint says exactly whose key it was. With a shared key, or a password login, the log only shows that someone logged in as that account.

Give every person their own SSH key and never share one. See All about UNIX users for adding keys.

What a normal user can and cannot erase

Commands typed in an interactive shell go into a shell history file, usually ~/.bash_history. That file belongs to the account itself, so whoever is logged in can empty it — and an attacker who gets in usually does.

Clearing the shell history does not remove the login record. The system writes that record outside the account's own files, so an ordinary login cannot change it. Even after a history wipe you can still see that the account was logged in to, from which IP address, and with which key.

The limit: root access

Anyone with root access on the node can edit or delete any file on it, including the system log files holding the login records.

So the server's own logs are reliable evidence about what an ordinary login did, but not about someone who became root.

Cyberfusion is looking into central log aggregation: the node would send its log lines to a separate system as it writes them, so a copy exists where the node has no control over it. Someone with root could still wipe the local copy, but the remote copy would survive. Not available yet.

What changed in Core, and who changed it

Core keeps two separate records, both written on Cyberfusion's own infrastructure, not on your cluster.

Object logs: what changed

Every create, update and delete of an object. Each entry holds:

• Which object changed, and what kind of object it is.
• Whether it was a create, an update or a delete.
• For updates, the old and new value of every field that changed.
• Which API user made the change, and which request it belonged to.

Before storing an entry, Core replaces the values of sensitive fields with ******** — passwords, private keys, tokens and passphrases. The log never holds a usable secret.

Changes are recorded the same way whether you made them in the interface or by calling the API directly.

Request logs: who called what

Every call to the Core API: the time, the API user, the HTTP method and path, the source IP address, and the request and correlation IDs that tie related calls together.

Neither can be deleted

There is no way to delete an object log or a request log — not in the interface, not through the API, for any user, including you.

Someone who takes over your Core account can make changes, but cannot remove the record of having made them.

Core keeps both for 45 days, then removes them automatically.

Getting at them

• Object logs — through the Core API at /api/v1/object-logs, filtered to your own objects.
• Request logs — not shown in the interface for customer accounts. Ask Cyberfusion support if you need them, for example while investigating an incident.

Restricting Core API access to specific IP networks

An API user signs in with a username and password and gets back an access token valid for 30 minutes.

An API user can also be restricted to one or more IP networks. Core then refuses any sign-in attempt from another address with a 403, so a correct password on its own is not enough.

Useful for API users your own automation signs in as, since those normally connect from a fixed set of addresses.

This is not a self-service setting. Ask Cyberfusion support to set the allowed IP networks for an API user.