A resilient IT infrastructure is bound to need some form of periodic backups along with a restoration plan. However, the trove of data is a security risk as it is likely to bundle sensitive information within it. In deployments of services where the service itself is running with more relaxed security policies than the backups (e.g if the periodic backups can be used to reconstruct a much richer history than a snapshot of the service would), then it would not make sense to let this same service also hold a symmetric key for encrypting the backups because compromising the service would also cause all the backups to be compromised. Under such constraints, one solution could be to use a second service to access the first service for periodic backups but this is a bit unwieldy.

The simpler solution will be to use asymmetric encryption to perform the backups. The service can hold a public key to periodically generate the backup snapshots, while the private key can be kept securely in cold storage only to be used when performing a restoration.

The gpg keys must be generated in a one-time operation.

gpg --full-generate-key

The generated keys can be listed for inspection.

user@usvm-1:~$ gpg --list-keys --keyid-format=long
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
/home/user/.gnupg/pubring.kbx
-----------------------------
sec   rsa1024/980AF382891E6A99 2021-09-26 [SC]
      3CB4439F0AE6CE2FC1D38068980AF382891E6A99
uid                 [ultimate] Tan Zheng Jie (For signing backups) <[email protected]>
ssb   rsa1024/9BA5E745FDF6F8A9 2021-09-26 [E]

The private keys can be backed up and restored.

gpg --output priv_keys_backup.gpg --armor --export-secret-keys --export-options export-backup [email protected]
gpg --delete-secret-key [email protected]
gpg --delete-key [email protected]
gpg --import priv_keys_backup.gpg

The public keys can be passed to another service, or the gpg store purged (like in above code block).

gpg --output public_key.gpg --armor --export [email protected]
gpg --import public_key.gpg

With the public key, some directory can be encrypted (src).

tar -cvpz ./my_data | gpg -er [email protected] -o backup.tgz.gpg

Only a holder of the private key can unecrypt the file.

gpg -d backup.tgz.gpg | tar -xz

With this encryption scheme, a large number of backup snapshots can be created without much worry that these backups can be compromised even when the key from the main service has leaked.