Security in Hazelcast community edition

[Ian Bigstaff]

Hi,

I would like some advice on implementing securities in Hazelcast community edition.

We are evaluating the community edition for an application. Some of the data we process is sensitive.

Our company's security people expressed concerns on using the software due to the fact that the community edition has no mechanisms for authentication and authorization. 

I understand that it's only the Enterprise edition which will provide such security features. Unfortunately, we don't have a budget for the enterprise edition this year. I wonder if it is possible to implement some preliminary authentication/authorization ourselves. Does anyone have such experience here to share?

Our system consists of multiple services, one idea being proposed is to deploy Hazelcast nodes as embedded within our services so that we can use our services to do authentication/authorizations. Is that actually secure? Will an attacker be able to start a Hazelcast node of their own and be able to join the cluster of nodes which are embedded in the services and then get hold of the data directly that way?

Our application is purely for internal users, and will run in a data center. And there will be potentially multiple GB of data so will need quit a few Hazelcast nodes. Any advice/suggestions will be greatly appreciated.

Regards,

Ian

[Josef Cacek]

Hi Ian,

you should always run Hazelcast in trusted environments. In the cloud,
it can be simpler as it usually allows defining security rules and
allowed data flows.

I wouldn't personally use the embedded mode, but rather stick to
client/server one and just connecting to it through a Hazelcast
client.

So, What you can do on the Hazelcast configuration level?
* specify custom cluster-name
* disable binding to all network interfaces (Hazelcast's default behaviour)
* specify which IP addresses should be used to bind Hazelcast protocols
* enable advanced networking and specify different port numbers for
member-to-member protocol and client-to-member protocol

What you should be able to define in the cloud configuration:
* Hazelcast members can access each other's port for member-to-member
communication
* Hazelcast's port for client protocol is accessible from hosts
running your microservices
* Hazelcast's ports are not open to any other connection

Regards,
-- Josef

> --
> You received this message because you are subscribed to the Google Groups "Hazelcast" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/568472e8-af4d-409a-8ebb-60bf15aa29b7n%40googlegroups.com.

--
This message contains confidential information and is intended only for the
individuals named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message, which arise as a result of e-mail
transmission. If verification is required, please request a hard-copy
version. -Hazelcast

[Nick Pratt]

To answer your question, I dont think its secure since the HZ cluster will be wide open outside the cluster to anyone connecting.

What version are you using?  I implemented auth and SSL for our internal deployment of the 3.x line.  I think the service endpoints changed (methods/signatures, maybe interface names) in the 4.x release, but I've not checked that.  While the service endpoints aren't documented (or at least they weren't) the interfaces are present (since the non-SSL endpoints are in the community edition).  All the hooks should be there on startup if you dig around and are willing to figure it out, write the code and then maintain it.  You can also hook the MapStore and encrypt that as well if you want - but be careful here since depending on your update rate, this might have to deal with a lot of data.  The other option I've employed is to have a public key exchange between services and some central service where the data packets are encrypted (so a request/response protocol where each joining service/node needs to contact an auth service with a signed packet, the auth service can verify, and return creds for connecting to other services, or it can work as a registration system), but you're still going to be limited by anyone having root access to the nodes in the cluster.  Be careful with this approach if you lock the auth down to known keys on known IPs - you lose some dynamic cluster management abilities (if new nodes are spun up with a known/registered service then the IP will be different and authn will be rejected)

As for the data size - that should be easy for HZ, even with SSL channels and/or encryption on the MapStore and/or on each endpoint accessor. Depending on the multiple of GB you're talking about, you might be able to run this on 3 AWS nodes depending on how much RAM your nodes have :-)  Be sure to factor in fault tolerance requirements, how much data per node will be stored (don't forget the backups), and how long it will take to resync/rebalance the cluster if a node dies.  Then for your own sanity, run that calc again with N-1 nodes - the percentage data resync goes up as you reduce the number of nodes (so the impact of a further node loss is more significant).

Nick

[David Brimley]

I think the question should be "Can you implement a proper security system in Hazelcast cheaper than the Enterprise edition?".  I'd say the answer is No, thousands of hours of work over six years have gone into the Enterprise Security features.  A security company auditor worth their title is highly unlikely to sign off on a "quick" and "cheap" internal security solution.  I'd be willing to wager it would ultimately cost the company a lot more to go around this cycle of review/engineer/review multiple times than just go with an Enterprise solution that comes with 3rd party audited reports that are in most cases instantly signed off by internal company security teams.

If the issue is around "budget timing" it might be worthwhile opening up a conversation with Sales.  For example, if you know you're going to be developing for a bulk of the year and going into production at some point (near the next budget period), you might be able to get trial keys of enterprise for this time.

Let me know if you'd like to discuss this option further.