Here’s an interesting problem, and I’m looking for a pattern that will keep it all workable.
I am building a smart-client app for a school system. It will contain information about students including their report cards, sick days, and so forth. it will generate student-level reports, including their report cards, each rich with very personal commentary by their teachers. The app will retrieve data from the remote server via web services.
So the data is quite confidential. I will encrypt it in the database, and decrypt it on retrieval – no problem there.
The problem is that my team and I should really never see the production plaintext data. An interesting problem emerges then for investigating production bugs! We’ll want to open the same record as the user to see what they’re seeing. But if we DO we’re violating confidentiality.
My thought is this, and it’s not perfect.
- First, encrypt the data before storing in the database, decrypt it at the UI. Nothing new there.
- Second, put a mechanism in the UI to obfuscate privileged data. (i.e., names and teacher narrative are privileged; grade level is not.) I won’t encrypt it, but obfuscate it – even a simple key-shift would suffice. The reason being, these reports are full of text. If I encrypt a paragraph and show the result in a report, it will be a solid wall of uppercase characters, looking nothing like the original text. If I do a key-shift on the alphabetic characters, it will be unreadable, but will still look like paragraphs, sentences, bulleted lists and the like. It will be easier to see what’s going wrong without adding visual complication.
- Third, I put in a configuration setting to perform this UI obfuscation just for members of say, the SysAdmin role, not the Teacher or SchoolAdmin. During development, I set this configuration to False, and we develop against fake plaintext. For production, we set it to True, and from that point forward, we only see obfuscated text.
Finally, for those cases where we absolutely MUST see the plaintext of a student’s records, we have an override setting in the UI that countermands the configuration setting, and presents the plaintext. And we manage that at the human level – informing the school administration that on THIS date for THIS reason we will need to see THIS student’s record, etc. Sign offs are signed, grumbling consent is given, lawyers are scrambled to their jets, rinse and repeat.
Thoughts? I feel like this must be well-trodden ground. Please help me improve on this plan, if possible.
Actually, you don’t need to decrypt the data at the UI. SQL Server has tools for doing real-time encryption for you. If someone needed to see the plaintext, they could be dropped into a role that would given them that permission (and taken out when they were done).
However, if seeing the data breaks confidentiality then clearly you can never see the production data. The only solution is a copy of the data with either munged data or completely random data.