Questions? Feedback? powered by Olark live chat software

Security Suite

Feature of Enterprise HD IMDG, and Enterprise IMDG

Hazelcast Security Suite at a Glance

Hazelcast Enterprise IMDG and Enterprise HD IMDG offer a rich set of JAAS-based (Java Authentication and Authorization Service) security features that you can use to authenticate cluster members and clients, in order to perform authorization checks on client operations. These features include:

  • Socket Interceptor – The socket interceptor allows you to intercept socket connections before a member joins a cluster or a client connects to a member. This provides the ability to add custom hooks to the cluster join operation and perform connection procedures (like identity checking using Kerberos, etc.).
  • Security Interceptor – The security interceptor allows you to intercept every remote operation executed by the client. This lets you add very flexible custom security logic.
  • Encryption – All socket-level communication among all Hazelcast members may be encrypted. Encryption is based on the Java Cryptography Architecture.
  • SSL – All Hazelcast members can use SSL socket communication between them.
  • Credentials and ClusterLoginModule – The Credentials interface and ClusterLoginModule allow you to implement custom credentials checking. The default implementation that comes with Hazelcast uses a username/password scheme.
  • Cluster Member Security – Hazelcast Enterprise and Enterprise HD support standard Java Security (JAAS) based authentication between cluster members.
  • Native Client Security – Hazelcast’s client security includes both authentication and authorization via configurable permissions policies.

The Value of Enterprise-grade Security

In the online trading world, data needs to be accessed securely at low and predictable latencies. To achieve these low latencies, more and more systems are opting for in-memory data grids (IMDG) instead of traditional relational databases (RDBMS). The clients need to be able to execute trades on distributed eTrading platforms. And banks need to ensure that the transaction is accurately executed after appropriate checks are performed. To enable an eTrading application to do this, it needs to store details ranging from credit limits and pricing, through to sensitive client details and authentication within the same memory. This poses a challenge around securing the data and ensuring it isn’t accessed or modified maliciously or otherwise, except for by those with the required authorization.

Hazelcast is a distributed system we make sure that all communications between processes over the network are secure. First, Hazelcast provides Transport Layer Security (TLS) that encrypts on the wire communication between cluster members.

Enterprise Security Architecture Diagram

Then Hazelcast uses what we describe as “process security”. Unlike traditional RDBMS topologies, which remain static, it is common for processes to be started and stopped frequently within a production cluster. This is how Hazelcast provides elastic scalability. By adding extra processes into the running cluster we can increase the memory and compute power available. This in itself presents a stability problem and in this environment we need to ensure that rogue processes do not accidentally or deliberately join the wrong cluster. It would be potentially disastrous for a production cluster to have a process from a developer’s test cluster join together. This is an accidental issue, but it would be just as easy for a hacker to insert another process into the cluster and potentially read sensitive data. To prevent this, Hazelcast provides “process security”, which takes the form of a mechanism that allows the cluster to check any new process joining the cluster. The check is entirely bespoke and takes the form of exchanging secure certificates. Hazelcast provides this feature with Socket Interceptor callback, within which the developer can implement the required security check.

With communication and process security in place, you can now secure the data and also how audit data is accessed. It is at this level of security that you need to integrate with Corporate Information Security (CIS) systems. CIS systems usually store application security metadata backed by data stores such as LDAP or Active Directory. It is the responsibility of the CIS system to authenticate a user and then to provide a set of roles for that user against a business system. Hazelcast has the ability to integrate with CIS systems via its JAAS (Java Authentication and Authorization Service) framework. JAAS is a standard framework that can be used to authenticate and authorize a user’s session against a Hazelcast cluster. When a client of the Hazelcast cluster makes an initial connection attempt, Hazelcast takes authentication tokens from the client connection and passes these to the CIS system. Once authorized as a valid user, the CIS system then returns a set of roles back to Hazelcast. These roles map to a set of data structures and allowed operations within Hazelcast, for example an “admin” role may allow updates to certain trade or counterparty data while a “read-only” role will allow only reads.

This access check provides a security barrier against entire data structures in memory based on client membership of a role. Hazelcast can also allow access to just a few elements or rows of a data structure. For this, you need a more finely grained set of security meta-data and checks. Hazelcast Security Interceptor can provide this entry or row level security check. Security Interceptor provides a Hazelcast cluster with the relevant information required to make a data entry access decision. On request, the pre-authorised client credentials along with the data row requested can be verified in real time against the CIS system. The CIS system would store finer business metadata to determine access rights to an entry. For example, using an inclusion or exclusion mask a client could be allowed access to certain counterparty entries and not others.

There is an ever increasing requirement for data access audit within systems. This presents challenges to latency requirements for many systems, as auditing operations should not affect general system responsiveness. Hazelcast again provides a call-back mechanism allowing bespoke integrations, these can take the form of connections to a central audit system or in its simplest form writing out to a file system.