[infinispan-dev] Infinispan security?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Infinispan security?

Joni Hahkala
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan security?

Manik Surtani
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> --
> Manik Surtani
> [hidden email]
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan security?

Pete Muir
Regarding fine grained security it might be interesting to see if we can't leverage the work Shane has done with Seam Security 3, as it has a lot of parallels.

I'm not sure how separate the Seam Security model is from JPA?

On 2 Sep 2011, at 11:01, Joni Hahkala wrote:

>
> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> --
>> Manik Surtani
>> [hidden email]
>> twitter.com/maniksurtani
>>
>> Lead, Infinispan
>> http://www.infinispan.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan security?

Joni Hahkala
Is there any performance numbers for infinispan? What kind of response
times would be required from secure version and what they are now etc?

On 02/09/11 13:31, Pete Muir wrote:

> Regarding fine grained security it might be interesting to see if we can't leverage the work Shane has done with Seam Security 3, as it has a lot of parallels.
>
> I'm not sure how separate the Seam Security model is from JPA?
>
> On 2 Sep 2011, at 11:01, Joni Hahkala wrote:
>
>> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> --
>>> Manik Surtani
>>> [hidden email]
>>> twitter.com/maniksurtani
>>>
>>> Lead, Infinispan
>>> http://www.infinispan.org
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan security?

Manik Surtani

On 2 Sep 2011, at 13:04, Joni Hahkala wrote:

> Is there any performance numbers for infinispan? What kind of response
> times would be required from secure version and what they are now etc?

No had requirements as such, since I think anyone expecting to deploy a secure data grid will expect performance tradeoffs.  What sort of factors do you envisage with the approaches you outlined below?

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan security?

Joni Hahkala
On 07/09/2011 18:04, Manik Surtani wrote:
> On 2 Sep 2011, at 13:04, Joni Hahkala wrote:
>
>> Is there any performance numbers for infinispan? What kind of response
>> times would be required from secure version and what they are now etc?
> No had requirements as such, since I think anyone expecting to deploy a secure data grid will expect performance tradeoffs.  What sort of factors do you envisage with the approaches you outlined below?

For ssl, you would have the problem of the handshake, you have two
request-response cycles before you can even start to send the actual
data. So, with anything else than intra cluster networking, you get
bitten by the network latency. You can resume old ssl sessions, which
save one request-response cycle, or you can keep the sockets open, and
only do the handshake once, but at least keeping the sockets open
doesn't scale so far. Then there is also the certificate checking, but
that shouln't be that big of an issue unless you want to go for ultimate
speed.

With everything there is the overhead of encryption and possibly the
signing, but that shouldn't be such a big slowdown.

The Seam framework seems to be more of user authentication, and would
probably be good for managing the authorization information. But for
authentication between the nodes and clients maybe keys would be better,
kind of like ssh is doing.

Cheers,
Joni

>
> --
> Manik Surtani
> [hidden email]
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan security?

Manik Surtani

On 11 Sep 2011, at 16:40, Joni Hahkala wrote:

> On 07/09/2011 18:04, Manik Surtani wrote:
>> On 2 Sep 2011, at 13:04, Joni Hahkala wrote:
>>
>>> Is there any performance numbers for infinispan? What kind of response
>>> times would be required from secure version and what they are now etc?
>> No had requirements as such, since I think anyone expecting to deploy a secure data grid will expect performance tradeoffs.  What sort of factors do you envisage with the approaches you outlined below?
>
> For ssl, you would have the problem of the handshake, you have two request-response cycles before you can even start to send the actual data. So, with anything else than intra cluster networking, you get bitten by the network latency. You can resume old ssl sessions, which save one request-response cycle, or you can keep the sockets open, and only do the handshake once, but at least keeping the sockets open doesn't scale so far. Then there is also the certificate checking, but that shouln't be that big of an issue unless you want to go for ultimate speed.

Well, for inter-node traffic, this could be a problem since there will be a lot of chatter.  And if we need to perform a handshake each time, that will kill performance.  Unless, as you say, persistent connections can be maintained.  In which case your real overhead is then just the encryption and signing.

> With everything there is the overhead of encryption and possibly the signing, but that shouldn't be such a big slowdown.
>
> The Seam framework seems to be more of user authentication, and would probably be good for managing the authorization information. But for authentication between the nodes and clients maybe keys would be better, kind of like ssh is doing.
>
> Cheers,
> Joni
>
>>
>> --
>> Manik Surtani
>> [hidden email]
>> twitter.com/maniksurtani
>>
>> Lead, Infinispan
>> http://www.infinispan.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev