0

I've got a situation and am uncertain how to approach it most effectively. A clients existing system which is built to alter, stamp, sign, etc. PDFs -which also converts the PDFs pages to images (pngs) for display/review, is needing to be 'secured' to handle medical/legal documents and docs which might contain personal information.

We're not going to be writing anything to disk directly if we can avoid it, keeping as much as possible in the DB. I'm familiar with using mcrypt for hashing passwords, etc -would this be a reasonable approach to storing the page images and the resultant PDFs until retrieval? Am I looking at serious processing overhead? Is there a better approach?

jbrain
  • 561
  • 3
  • 7
  • 18
  • If you're in the US, HIPAA is going to be a huge legal compliance pain in your ass. – ceejayoz Aug 21 '12 at 14:58
  • If you don't want to save to disk, why use PDF at all? Just use a secure web document to interface directly with your db. – user1477388 Aug 21 '12 at 15:00
  • Yes, yes it is, one of the reasons we are trying to approach this one as cautiously and prudently as possible. – jbrain Aug 21 '12 at 15:01
  • 147388: Clients request, user will want to download copies of these documents, and not all of them will be sensitive. – jbrain Aug 21 '12 at 15:02
  • As long as those images wont be saved to the hard-disk during processing (because of a lazy programmer or because main memory is to small) and you save the generated pngs into the database it is mostly a database related permission problem (is user X allowed to retrieve the blob Y containing the png?) – Najzero Aug 21 '12 at 15:03
  • Najzero: True, maybe a bit more about the situation would help: the components of this service are spread across 3 separate servers, each housed and maintained by different security minded personnel representing different aspects of the process, each with their own methods, approaches, and interest to securing the data which they hold, though no any one entity holds the 'keys' to the other. The idea here as it was designed a while back, is that all three systems would have to be compromised before any usable information could be retrieved. – jbrain Aug 21 '12 at 15:24

1 Answers1

1

Securing a system is a quite wide topic, but you seems to focus on securing the persistent storage of sensitive data against unauthorized access. In other words, you want make it more difficult for an intruder or illojal employee with access to the database to look at pdf documents he should not look at. One approach is, as you suggest, to encrypt the documents in the database. The important and difficult decision here is how to manage the encryption key(s). Questions you should ask yorself is:

1) How can I store the encryption keys so that the application have access to them but an intruder or illojal employee do not? You can of course not store them in the database (you didn't have to encrypt the documents at all if you could trust the database). One secure but cumbersome solution is to let a trusted employee type in the keys when you start the application and only store them in memory. Another approach is to create a special, protected subsystem that only encrypt and decrypt documents.

2) What encryption algorithm is strong enough? You should probably protect against a scenario where the attacker can copy many or all of your documents to his own system and use different techniques to crack the encryption. All algorithms are in theory breakable given enough time and hardware, so the tradeoff here is to use an algorithm and keylength that makes it virtually impossible to crack the encryption and at the same time has an acceptable processing overhead (the less processing power you need to decrypt a document, the less processing power an attacker will need to crack your encryption).

3) For how long do the documents live? Encryption schemes and keys should not live forever. You should design for a system where you change your keys at regular intervals and also change encryption algorithm when they become outdated. You must also be able to handle a situation where you discover that the encryption key is compromised. In other words, it must be easy to change the key and re-encrypt all documents with the new key.

Securing a system will of course require you to do a lot more than encrypting the documents, but protecting your persistent data is not a bad start.

Good luck

sstendal
  • 3,148
  • 17
  • 22