Vault Protection and Integrity

The vault is the folder on the storage machine that holds every committed backup. It is designed so that an attacker who holds every domain credential still cannot read, change, or delete a backup over the network, and so that any change to a stored backup is detected before you rely on it. The storage agent also watches the vault and the staging share for activity that no backup job or retention rule explains, and the Manager raises an alert for each finding.

Who can reach the vault

The vault lives under the storage root on a machine that is not joined to the domain. It has no network share. Its permissions are protected from inheritance and grant access only to:

The local system account, under which the storage agent runs.
The local CygnaDR Administrators group on the storage machine.
The local BUILTIN\Administrators group, unless you remove it (see Removing local administrators below).

The per-job accounts that write backups have no rights in the vault at any time. They are members of the CygnaDR Staging Writers group, which exists only so that the staging share can be granted once. Each account reaches only its own staging folder and is deleted before its backup is moved into the vault. For every local group the storage agent creates, see Accounts and Permissions.

The storage agent checks the staging share's permissions at startup and repairs what backups need, without removing entries it did not create. It reports anything else the share lets write, so that you can review it.

The storage machine also keeps the Manager's configuration backups, in <StorageRoot>\manager-backups. The folder has the vault's permissions and is never shared. The backups are encrypted, the storage agent cannot read them, and the Manager cannot delete them: the storage machine keeps at least its own minimum and prunes by its own rules. See Manager Configuration Backups.

No deletion from the network

No API, console action, or command deletes or overwrites a backup. The only way a backup is ever deleted is by the retention rules that run on the storage machine. The deepest of those rules, the retention floor and the minimum number of versions per domain controller, can be set only on the storage machine itself. The console can make retention stricter but cannot weaken it. For details, see Retention.

Read access for a restore

A restore needs to read one backup, so it is given a read lease on that backup only, for the length of the work:

The storage agent verifies the backup's hash (see Verification before a restore).
It creates a local account for this restore only, in its own group, and a read-only share over the single backup's folder. The vault root is never shared.
The machine being restored reads the backup through that share.
When the lease ends, the share, its permission, and the account are all removed.

For a DC state recovery, the domain controller copies the backup to its own disk while Windows is still running, and the lease is released before the machine restarts into Directory Services Restore Mode. The backup is exposed for minutes rather than for the whole restore. For a full system recovery, the recovery environment reads the backup over the share for the whole restore.

Every lease is recorded in the audit trail as Vault read lease issued and Vault read lease revoked, and a refusal as Vault read refused.

Scheduled hash verification

The SHA-256 hash recorded when a backup is committed is the evidence that it has not changed. The storage agent re-reads stored backups on a schedule and checks each one against its recorded hash. This catches silent corruption, such as a failing disk array, and deliberate tampering, such as an attacker encrypting the vault.

Verification is on by default. Each pass reads a limited number of versions, then waits for the next interval, so that verification does not compete with incoming backups.
Each pass checks the least recently verified versions first. A version that has never been verified goes ahead of every version that has.
A version that passed recently is skipped until its result is older than the Re-verify after setting.
A version that failed is re-read on every pass, so you can tell a one-off read error from progressive corruption.
Verification only reads. It never deletes, repairs, or moves a backup. A corrupt backup is kept as evidence.

Each check has one of three outcomes: it passes, it fails because the content no longer matches its hash, or it could not be checked, for example because no hash was recorded or the content could not be read. The Backup verification tab of the Repository screen shows the results and lists every failure with when it started failing. A version whose latest result is a failure also raises the critical alert Vault content whose hash does not match. The pass size, interval, and re-verify window are storage agent settings; see Settings Reference.

Detecting changes to committed backups

After the commit, the only legitimate change to a backup is its deletion by retention. The storage agent therefore treats any other change to a committed backup as a finding: a delete, rename, write, truncation, or change of permissions or attributes, whether it affects one file or thousands. Ransomware and intruders typically go after backups first, and this is how such activity on the storage machine comes to light without waiting for the next verification pass or a restore.

How changes are seen—The storage agent reads the change journal of the volume that holds the vault. The journal records every change on the volume whether or not anything is reading it at the time, so after a restart the storage agent resumes where it stopped and also reports changes made while it was not running. If the volume has no change journal, the storage agent creates one. Changes that the storage agent itself makes, when it commits a backup, applies retention, or sets permissions, are not reported. The record the journal writes when a file is closed repeats what was done to the file while it was open, so it is judged only on what it adds: a backup held open for a long restore does not produce a late finding when it is closed.
When the journal lost records—If the journal was deleted, or records were overwritten before the storage agent read them, the storage agent compares every committed backup with its commit record for the stretch of time it could not read, and reports what the comparison finds.
Who made the change—The storage agent puts an audit entry on each committed backup's folder, so that the Security log records deletes, writes, and permission changes to it. Whether anything is logged depends on the storage machine's audit policy, which Cygna Forest Recovery reads and never changes. With File System auditing on, a finding names the account and process; with Detailed File Share auditing on as well, a change made over SMB also names the client address. See Audit policy on the storage machine.

Each changed backup raises the critical alert Committed vault content changed outside retention, which names the backup, what was done, how many paths, and over how long. The first finding for each backup is also recorded in the audit trail. The alert stays raised until an operator with the backup.manage capability records a review with cdr repository changes review, with a note saying what the review found. cdr repository changes lists the open changes with their paths and who made them. Detection is all that happens: nothing is blocked or reverted, and the changed content is left in place.

A storage machine that cannot watch its vault raises Vaults not being watched for changes with the reason, so that silence is never mistaken for safety. The change journal is a feature of NTFS and ReFS; a vault on another file system or on a network share cannot be watched. The storage agent must also run elevated, as the installed service does.

Watching the staging share

The staging share is the only part of the storage machine that domain controllers reach, and each backup job reaches it with a local account that exists for that job only. The storage agent knows which domain controller each account belongs to and how long it should exist, so it can tell when the share is used in a way no job explains:

A job's account used from an address that is not its domain controller's.
A job's account used before its credential was issued or after it was removed, or an account of that form with no job on the storage machine.
Any other account reaching the staging share, another share over the staging folder, or a file under the staging folder through any share, including an administrative share such as D$.

The storage agent sees this in two ways: it reads logon and share access events (4624, 5140, and 5145) from its Security log as they happen, and every 30 seconds it polls the sessions, share connections, and files open under the staging folder. A connection shorter than the poll is seen only through the Security log, so it depends on the storage machine's audit policy. Cygna Forest Recovery reads that policy and never changes it; see Audit policy on the storage machine.

Each finding raises the critical alert Unexpected SMB connections to the staging share, with the account, the address, and what was wrong, for seven days after it was last seen. The first sighting of each is recorded in the audit trail as Unexpected use of the staging share. The storage agent closes no session and removes no account early. A storage machine whose watch is off or partial raises Storage machines not fully watching the staging share, which says what is missing. For both alerts, see Alerts Reference.

Verification before a restore

Before the storage agent grants read access to a backup for a restore, it verifies that backup. No unverified content is ever exposed to a restore.

By default, the storage agent can rely on its own recent verification instead of reading the whole backup again, as long as the result is a pass, is inside the re-verify window, and nothing in the backup has been written since. Otherwise it reads the backup in full first. To always force a full read, select Re-verify the backup in full before restoring it when you plan a single-DC restore, or Re-verify each backup in full before restoring it in a forest or domain plan. A full read adds minutes per domain controller.

If the backup does not match its hash, the restore is refused with The backup no longer matches the hash recorded when it was committed. If there is no recorded hash to check against, it is refused with The backup could not be checked against a recorded hash. In both cases nothing has been sent to the machine. Choose another restore point.

Removing local administrators

The Remove BUILTIN\Administrators from the vault setting on the storage agents removes the local Administrators group from the vault and staging permissions, leaving the local system account and the CygnaDR Administrators group. It is off by default and takes effect when the storage agent restarts.

This setting is not a barrier: a local administrator can still take ownership of the vault and grant themselves access. It provides evidence: reading the backups then requires a deliberate ownership change.

To keep you from locking yourself out:

The storage agent refuses to apply the setting while the CygnaDR Administrators group is empty.
If the storage agent finds it can no longer write to the vault after applying it, it puts BUILTIN\Administrators back.

Grant access by adding accounts, including a break-glass account for the storage machine, to the CygnaDR Administrators group rather than by editing permissions by hand.

Encrypting the vault volume

Cygna Forest Recovery does not encrypt backups itself. Turn on BitLocker for the volume that holds the storage root, so that the backups stay unreadable if a disk, an array, or a virtual disk file leaves the machine, for example when it is copied, stolen, or decommissioned.

Unlock the volume automatically—The storage agent does not start if it cannot reach the storage root, and a locked volume cannot be reached. Turn on BitLocker for the operating system volume as well, and turn on auto-unlock for the storage volume, so that it is available after every restart.
Keep the recovery key outside the forest you protect—The storage machine is not joined to a domain, so it cannot back up its BitLocker recovery key to Active Directory. Even if it could, that directory may be the one you are recovering. Store the key offline with the other secrets from setup.
Give a virtual storage machine a virtual TPM—Without one, the operating system volume needs a startup password that someone must enter at every restart.

BitLocker protects the backups at rest only. It does not protect them from someone signed in to the running storage machine, as the next section explains.

What this protection does not cover

These measures keep backups out of reach of the directory and of the network. They do not protect the vault from someone who is a local administrator on the storage machine itself, who could also change the storage agent's own retention configuration. Changes such a person makes to committed backups are detected and raised as alerts, as described above, but detection does not stop them. Treat the storage machine as you treat the most sensitive systems in your estate: keep it off the domain, keep its local administrators few, and keep its sign-in credentials separate from any domain credential.