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?