-1

I have been requested to create a backup of a server. The server is Linux Ubuntu 22.04.2 where the core application (nodejs) + management software (nodejs / bash scripts) + monitoring (nodejs / net-snmp) are running. A second server will be present ready to take over (still under design by others in the team).

Due to imposed constraints by the final customer the backup is a single .zip file, which includes everything (files and folder), that must be uploaded to a backup server somewhere in the customer's network via sftp.

The backup must contains: configuration files/folder of running softwares (core app/management/monitoring) + dump of the database. The backup must be restored in the server (or its twin) in order to have it working again if something happen. I guess the backup process and the restore process will be executed as root user.

Some configuration files contain passwords which have been encrypted with a symmetric key algorithms. Those passwords concern external services the server must connect to. The key is a random string, called "secret", stored in a single file placed in a specific path outside all running softwares (es: /etc/secret). The file with the secret is owned by root user and it's read only. The file secret is accessed by more than one softwares.

My dilemma concerns if the file with the secret must be included in the backup or not. I'm facing two options/considerations:

  • if the file with the secret is not included in the backup, the backup must be restored only in the same server where it was generated. Moreover, if the server will not work anymore the backup can't be restored at all.
  • if the file with the secret is included in the backup, the backup can be restored to different servers, but the backup contains both the encrypted passwords and the key to decrypt them. (So I guess it is less secure from a cybersecurity point of view)

Can someone give me an advice/best practise? Or point me to some documentation? The file which holds the secret must be included in the backup (with all other files) or no?

Thanks!!

Vince
  • 1

2 Answers2

1

There is no golden rule with regards to backup and restore procedures other than:

Nobody truly cares about back-ups. The only truly important thing is the ability to successfully restore applications and data when needed.

That's why people test backups; to be certain the restore procedure is complete and can be used to restore the system to full functionality in the required timeframe to ensure business continuity.

When you can't restore your system, or you can't do it in the allotted time, then your back-up and restore procedure is broken. Rethink and rewrite the procedure and try again.

It is not incorrect if your restore procedure contains more than 1 step and includes a special instruction to re-create / restore something like /etc/secret when that file (or any other data) isn't included in a data backup.

If such an instruction won't/can't be part of the restore procedure, then /etc/secret should be part of your data backup. It's as simple as that.

(There's plenty of people whose recovery strategy is to restore an full image of an original server that includes the OS, all applications, settings and configuration as well as all data and secrets. Others redeploy rather than restore and will deploy a blank OS, re-apply all settings with their configuration managent tooling, redeploy their application(s) and configure them with secrets from their configuration management tooling and only restore backup data to the application if the application can't recover the data it needs via replication. )

Just be aware that in general a team will be stressed and under high pressure when a real disaster recovery is necessary and every system and application that can't be restored automatically, every application that requires special hand holding will take additional time and runs the risk of people making mistakes.

That is less of an issue when a team only manages a single application, but tends to become impossible to manage when a team needs to restore dozens or more applications and systems.

Your backup is just as value as the data it contains and backups require the same level of data protection as the original data.

If you can't control access to the back-up, like when you copy the back-up to a third party as zip file, and even when you do, a common protection mechanism is to encrypt the back-up.

(That leads to different issues, key management for example.)

HBruijn
  • 84,206
  • 24
  • 145
  • 224
0

Due to imposed constraints by the final customer the backup is a single .zip file

If there is a golden rule here, it is DO NOT REPLICATE TO YOUR FAILOVER USING ZIP FILES. Its not really clear from your question if this is a deployment, or a backup or failover replication. However there are varying degrees of badness depending on which this really is.

There are many different ways to implement secrets management. However the majority of the implementation is already in place (and presumably difficult to change). But again, its not clear from your post what's actually going on here. Are you providing the same secrets to all your customers? Is there an expectation that your customers should be able to use these secrets without knowing what they are? Again, is this really a backup?

The simplest solution would be to encrypt the SECRETS file with a symmetric key nd have a copy at both ends. A slightly more sophisticated solution would be to use a key pair with the pair split across the origin / destination.

symcbean
  • 23,767
  • 2
  • 38
  • 58