0

In the company I'm working for we have a certain service where users can upload documents (text, sometimes document scans), it's nothing confidential but if those documents will be leaked, I'll get a lot of headache explaining why all of them are publicly available. Recently we had a breach of out network and while this time no one managed to get anything it raised some security concerns.

It's a vast legacy system, replacing it right now is out of the question. It exists within our corporate network and users can't access this data storage directly due to specific AD and Network security policies. As practice shows those policies can be overridden because of our IT dept negligence. So what I want is to add an additional layer of security by encrypting everything within the storage.

The storage acts as an archive. People dump old documents into it and those documents are rarely if ever accessed. Placing all of the incoming files into some encrypted containers is not an issue, easy to implement. The question is - how do I store keys for those containers? If I'll put them inside of the general service database, anyone who'd like to access those documents in an unauthorized manner will be able to do so by simply gaining access to the database (SQL Server, used by many apps, possibly compromised due to badly designed legacy services in the company).

I can theoretically store keys in some other database (dedicated server with a proper setup of SQL Server\ PostgreSQL), physically disconnected from the main one and send keys from there only when requested and prevent attempts to dump all of the keys, any 'unusual' behavior is very easy to detect because people rarely request anything. And I don't care how long it'll take to restore and decrypt those containers, 1ms or 1 hour don't make any difference when taking in account the overall system processes. However, this approach feels a bit convoluted.

Are there any sort of 'best practices' for solving such problems?

  • Have you considered asymmetric cryptography? In the simplest case, you could use a single public key (known to most employees) to encrypt documents when adding them. Only a small number of people know the private key which allows them to read the documents. (That's the basic idea, anyway; there are many pitfalls with public-key cryptography so I'd advise asking cryptographers like on crypto.SE.) – nomadictype Sep 16 '16 at 21:14
  • Are you looking to store files on a file system of some sort (NTFS etc) or in a database (SQL Server ETC). Also is it a web app or are users uploading files to a network share? Those questions are going to be key to an answer – RubberChickenLeader Sep 16 '16 at 21:36
1

If you are storing the files on NTFS, they may already be encrypted via EFS. If you are thinking of encrypting the files within the encrypted filesystem, you gotta ask yourself why?

Encryption is not a panacea, as you have discovered. Your files are already encrypted but you failed to guard the means of decrypting the files properly. What makes you think that won't happen again?

All you're doing is making it harder to maintain good processes because you are increasing their overall complexity by doubling up on the cryptography.

You asked what the best practice is. Here it is: Put the file in a secure location. Guard the location with sound IT and administration processes. That is it.

Same applies to database storage. Encrypt the database, and guard access via sound DBA practices.

If you can't do that, there's no point in building anything else. You can't fix this by building more crap on top of crap.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.