I need advice on the best way to set up a database that uses document encryption. I have a preexisting application that HR uses to have staff members set goals for the upcoming year. Only the user, their manager and HR are allowed to view the doc. HR creates an encryption key for each user and mails it to that user and their manager who is allowed to view the documents. The doc has readers and authors fields that include the users name and their managers name and a role called HR so that HR can access the docs also. There is a SecretEncryptionKeys field that includes the name of the key that has been mailed so that when the doc is saved it uses that key. The application works perfectly.
Here’s the question. I need to create a similar database that uses encryption but in a different way. This db will store staff evaluations on jobs performed. The creator will obviously need the key but there is no set “manager” as there was in the other database. In this case, the person who is creating the evaluation form for the staff person being evaluated can be anyone. There is already a field on the doc that captures the username that creates the doc (Evaluator). Since I cannot hard code the secretencrptionkey field in this scenario and we cannot mail the keys ahead of time since we do not know who will create evaluations for whom, how should I handle this? My thoughts are to populate the secretencryptionkey, readers and authors field with the contents of another field on the form to create the key name and allowed readers/authors and then somehow “create” the key in the user id’s of the people who would need the key to view the encrypted data. Any advise on how to do this or better ideas? By the way, the person being evaluated will not be allowed to view the evaluation of himself.
Thanks in advance
Subject: Encryption is not the best solution for either of these two applications;
Readers/Authors fields are.
Encryption operates at the field level, and should be used when there are some users who should have access to some fields in the document, but should not have access to other fields in the same document. Or am I missing some reason(s) for field-by-field access control that you didn’t explain?
Your post suggests that you’re already familiar with Readers and Authors fields, so I won’t try to tutor you in them, other than to refer you to the Readers/Authors field troubleshooting document in the forum FAQs if you haven’t yet seen it.
Subject: Document Encryption advice saught
Read up on the PublicEncryptionKey field, and search this forum for my name plus that field. There’s a very straightforward explanation on how to do it.
And by the way, the other respondent suggests that encryption isn’t the right answer. Perhaps, but remember that reader fields can be bypassed by those with Full Access Administration. Because you’re talking about HR information, it probably makes sense to secure that even from system administrators.
Subject: RE: Document Encryption advice saught
Thanks for the response. Yes, I already have readers and authors fields in place so that only users listed in those fields can see the document. We are taking it to the next level with encrypting fields because as you know, anyone who gets there hands on a copy of that users ID can potentially copy the Id and log in as the user, then poof!! they can read the docs. Yes, I know, we also have passwords for the IDs but our It dept also knows the passwords for everyone. With encryption in place, you can’t even look at the document properties and read the contents of the fields if they are encrypted which is why we choose that route.