[infinispan-dev] Infinispan security?

[Joni Hahkala]

Hi,

Just a couple of ideas fron the top of my head. Sorry for the long mail, 
your mail covers a lot of things. :)

the easiest off the shelf solution of course is SSL everything. But this 
would probably have some significant performance hit, even with mostly 
keep-alive connections. Also there would be the overhead of getting a 
certificate from some certificate authority whenever a new service 
instance (VM) is created.

In this system the parts you mention would be covered by:
1) wire encrytion - SSL does this
2) inter-node comm authn - could use the host cert to authenticate to 
other services. Somebody would need to add the nodes to the ACL and 
distribute it or distribute the addition message.
3) remote client authn - the remote clients are usually services too, 
right? then they would probably also have a host certificate available 
and could use that for authentication. Somebody would need to add the 
clients to the ACLs.
4) in-VM authentication - would this be really necessary? Separating the 
services into different user accounts and then using authentication when 
they talk to eachother would add security, and in principle is a good 
thing, but careful cost-benefit analysis should be done. Probably 
something to keep in mind, plan and implement later?
5) ACLs for data - entire named cache level, yes definitely should do. 
Individual entries or key patterns: this is a bit tricky, the 
performance hit and need should be evaluated. Could be easier to just 
deploy another pool of infinispan servers than partition the keys by 
ACLs. The fine grained access to the data is also often pretty 
application specific, for example in facebook the privacy controls etc 
seem to change every other month. So, the fine grained access could be 
better left to the applications? Do you have some use case in mind?

I would also add:
6) authorization in general - ACLs probably, but who manages these? For 
example automatic provisioning of additional servers when load increases 
could be a bit complicated. (obtain certificate, put into the server, 
add to the ACLs - by gossip?)


Another, probably more performant, flexible and interesting way would be 
to just use encryption keys and just send encrypted messages allowing 
more asynchronous kind of communication, more flexible node provisioning 
etc.

In this system the points would be as follows:
1) wire encrytion - each message is encrypted.
2) inter-node comm authn - each host would have a key for encryption and 
authentication to other services (created during creation of the 
service). Somebody would need to add the keys to the ACL and distribute 
it or distribute the addition message.
3) remote client authn - remote clients would have keys too (generated 
like ssh keys at server creation). Somebody would need to add the client 
keys to the ACLs.
4) in-VM authentication - same as above.
5) ACLs for data - same as above
6) authorization - same as above, but no need to obtain certificates, 
just generate a key and add it to the ACLs.


Then there is the question whether the data stored in the infinispan 
even needs to be cleartext. AFAIK it's just a data blob and thus could 
be encrypted data. This way only the clients with proper encryption keys 
could see the actual data and in case of break-in in the infinispan the 
loss would be less.

Cheers,
Joni

On 31/08/11 10:57, Manik Surtani wrote:
> Hi Joni
>
> There are no plans as such at this stage, however we realise this is an area we'd like to address.  Specifically, what is interesting to me is:
>
> * Encrypting wire protocols: both inter-node communication (JGroups) as well as client/server comms (mainly Hot Rod)
> * Authentication for inter-node comms (JGroups)
> * Authentication for remote client connections (mainly Hot Rod again)
> * Authentication for in-VM connections (via embedded API)
> * ACLs for actual data.  Perhaps read/write/update/delete permissions.  Haven't thought too hard about granularity here (individual entries, entire named caches, or even a pattern of keys).
>
> So fairly hazy at this stage, perhaps with your background in grid security you could propose something?  :-)
>
> Cheers
> Manik
>
> PS: cc'ing Darran Lofthouse who may have an opinion here to share as well.  :)
>
>
> On 22 Aug 2011, at 15:33, Joni Hahkala wrote:
>
>> Hi,
>>
>> I was reading and watching presentations of Infinispan and it seems that
>> currently it is intended for use in secure environment, like data center
>> behind a firewall with other datacenters connected through secure links,
>> if I understood correctly. But deploying it in more open environment,
>> e.g. public cloud, could pose security risks. Manik said in a
>> presentation that the underlying Jgroups uses certificates (or can be
>> configured to use), and I would assume SSL. So, there is at least some
>> security in the Infinispan joins, leaves etc. Manik also told that there
>> has been some talk/plans already about the security in general.
>>
>> I would be interested in hearing about these plans for security and to
>> see if there is possibilities for cooperation. I'm currently searching
>> for a PhD subject, I have background in grid security, and this work
>> sounds like it could be useful and interesting.
>>
>> Cheers,
>> Joni
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev