> > I think you could probably add transparent encryption/decryption at the > Lucene level in a custom codec. That probably has implications for > being able to read the older index when it's time to upgrade Lucene, > with a complete reindex being the likely solution. Others will need to > confirm ... I'm not very familiar with Lucene code, I'm here for Solr. >
Thanks, that sounds interesting, and an avenue I will investigate further... Any verification of user identity/permission is probably best done in > your own code, before it makes the Lucene query, and wouldn't > necessarily be related to the encryption. > Okay, but somehow my codec is going to need to know the key to use to encrypt/decrypt the data, only the user has that, so they will need to pass it in somehow I imagine. Requirements like this are usually driven by paranoid customers or > product managers. I think that when you really start to examine what an > attacker has to do to actually reach the unencrypted information (Lucene > index in this case), they already have acquired so much access that the > system is completely breached and it won't matter what kind of > encryption is added. > > I find many of these requirements to be silly, and put an incredible > burden on admin and developer resources with little or no benefit. > Your preaching to the converted ;-) I already tried pointing out that futility of this approach and that it really doesn't bring much if anything to the security of the system. I also suggested just using an encrypted filesystem. Unfortunately, as you have most likely experienced, customers and their requirements whether wrong or right often have to be fulfilled if you want to get paid by them. -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk
