[tptacek]

I understand that you don't retain user emails, and that's good, but do I understand that your service has somewhere a database of OAuth bearer tokens that provide direct access to the email archives of everyone who has signed up for your service? How do you protect that? I would be terrified.

[kkyryl]

yes, that is correct. we actually started without keeping refresh tokens and only using access tokens – but they expire really fast and google api randomly stops accepting them so we had to start keeping refresh tokens as well.

they are encrypted and can only be decrypted by "scan" and "action" (delete, trash, etc) jobs, job servers are not exposed to the outside and can only be accessed via the private network via ssh using access keys and only from a specific node which has those keys. keys are password protected. access to that specific node is restricted to a set of known public ip addresses. database and job servers are different servers of course. database servers are also only accessible within the private network.

the only thing that's publicly exposed is a load balancer. to access anything else we log in to the "gateway" instance which we access by ip only and it does not have any domain name associated with it.

with all that – I am very open to ideas about protecting that further.

[insomniacity]

Encryption at rest? Backups and encryption thereof?

[kkyryl]

All job servers are stateless by design and easily disposable/replaceable with a fresh build so we don't back them up. we don't back up user data either – it's deleted within 24 fours (or immediately on request). the only thing backed up is a table with refresh tokens which are encrypted and decryption keys are not backed up with it.