GPG key management

Using GPG keys to manage encrypting backups/sensitive data stored in S3.

Jotting down notes

Remote key(s)

• Depending on team size, machine/data separation, multiple keys may be necessary
• Unattended key(s)
  • Encrypt and store remotely, allowing multi user management (store offline if not)
  • If better method for distribution use that, this is low effort to get started
• Download key, decrypt and pipe/scp upload to servers that will decrypt backups/sensitive data
  • Ideally only being unencrypted on the remote machine and never on user machine if possible, just precautionary
• Once all files needed for a migration/restore are decrypted, remove key, keeping only the intended recipients pubkeys

Decrypting unattended key

• Should be very short list, production ops etc.
• After a better method of key distribution becomes more robust, adopted, and refined, use that

Updating who can decrypt unattended key

• Only time it should be stay unencrypted locally for a brief time (if its necessary) would be to re-encrypt with more/less recipients
  • See comment on updated version with explanation of this.
• Keep locked down but public (at least easily accessible) list of pubkeys for tracking
  • Fundamentally only a very small set of users should have access to decrypt the key
• Obviously only those allowed to decrypt unattended key will have more robust procedures on management

Decrypting encrypted files

• TODO: Revisit how to best update the recipient list per set of data to be encrypted securely, below is incomplete
• Download locked down but public (at least easily accessible) list of pubkeys allowed to access decrypted info, onto servers that will encrypt data
  • The idea being the decrypted unattended key is more valuable then the data as the key gives access to ALL the data (or narrowly defined subset per unattended key), and we do not want to store the unencrypted key anywhere it shouldn't be.
  • This allows the list to be at a minimum the same as those able to decrypt the key but also additional trusted keys (staging devs with production backups etc.)
  • Also allows for different sets of users to decrypt different sets of data (staging/dev never gets ability to decrypt SSNs/credit card backup data etc.)

Managing different pubkey lists

• SEE: Todo item in Decrypting encrypted files.
  • The method on updating recipients should as/more secure as the list.
• Needs to be locked down to the absolute minimum number of users necessary
• Figure out best method to integrate with Vault once we learn to use it.
• Some lists can be integrated with Vault allowing access to lower level data like private builds etc.