As a preface to my question, let me state that I'm a relative newbie in the field of security.
I work for a back-office financial software provider that is responsible for processing, generating, and exchanging 1000's of files with 100's of 3rd parties each day. According to our most recent security audits, those files have to be encrypted whenever they aren't in use.
I can solve that problem pretty simply by using PGP encryption when we receive/build the file, and decrypting it when we need to read it/deliver it.
What I'm struggling with is how to do this in a secure fashion, given that the same environment needs to both encrypt and decrypt the files. I understand the paradox of what I'm trying to do...I'd like the same server to both encrypt and decrypt a file, but not allow a user that gets onto that server to do the same. I've contemplated the idea of having an administrator enter the decryption password upon the starting of the service, but that seems clunky.
Do I need a whole other route?
Here's the exact scenario that I'm wondering about...I realize it's counter-intuitive, but I'm hoping that the security community is brilliant enough to have solved this problem.
08:15 - Business Partner delivers a file of transactions for processing. 08:16 - File is decrypted using the keypair assigned to that business partner. 08:17 - As batch processing window has expired, file is encrypted until required later. 20:00 - Batch processing window is active, file is decrypted and transactions are processed.
We are wondering if there's a way to have an application handle all those (which we already have) and at the same time prevent Joe User from logging into the environment and decrypting the file at (e.g.) 14:03?
The reason it seems counter-intuitive to me is that if the application/server/environment has all the required information to both encrypt and decrypt, it would seem that any user that can get into the environment would also have access to that information. I'm hoping there's some fancy way of doing it that might avoid that case.