I have a number of seemingly contradictory requirements:
1) We obtain content for users from third parties; content for certain users should be stored encrypted at rest for compliance reasons
2) The user should be able to decrypt and display their content via a secured webapp/api
3) There are many users on a given account, and all should be able to decrypt and view each other's content (implying a shared key)
4) A backend worker process should be able to decrypt and reprocess the user's content at any time, if we want to (for example) improve our analytics
If we had to, we could sacrifice #4 (or perhaps have the user authenticate to allow it.)
Naturally I don't want to store the encryption key in plaintext anywhere. It would be most convenient to store it at the user level, encrypted by a hash PBKDF2'ed from their password - but that introduces a cumbersome workflow if they forget their password and need to reset it (since we now no longer can derive the key.)
I can't just use the password either, because access to content that was encrypted already should survive change password requests. Also, of course we don't have access to the plaintext password in async backend worker jobs.
Is there a generally accepted way of doing this? E.g. could I use some kind of 2FA-ish workflow to retrieve a user-secret that I never store locally, but which is used to protect the key?