Configure Security

NCache understands the need for any enterprise-level software to have airtight security and, therefore, offers a variety of features to ensure that users don't sacrifice their security for performance. These features include defining access permissions for caches/nodes, encryption, network security, and more.

Authentication and Authorization

NCache offers the LDAP-integrated security to secure cache nodes. Once a node is secured, there are two access levels defined on that node. One is related to management operations along with other cache operations, while the other is limited to cache API access.

Note

All the caches on a secured node are automatically secured.

To get the complete benefits of these access levels, NCache supports two types of LDAP users: Node Administrators(Users/Groups) and Cache Users(Users/Groups). Since NCache does not have its authentication mechanisms, all the added users are first authenticated against their LDAP credentials. When a registered LDAP User gets added to the NCache, there is always a validation check through the domain controller to verify whether this user is registered with the domain or not. In this scenario, if the connection with the domain controller breaks, validation fails, and the user cannot perform any operation.

To avoid this, NCache offers Credential Caching where the user's credentials are stored in NCache so that an already authenticated user does not have to be authenticated repeatedly during the life of the process. It is disabled by default and the user can enable it by setting the NCacheServer.EnableCredentialCaching tag as True in the Service config file.

Node Administrators

Node Administrators are Super-Users and have complete control over the cache - they can create, modify, remove caches, and perform any other cache management operations. Node Administrators can save or discard security configurations if previously established. They are also able to inherit the capabilities of Cache Users to access and interact with caches using the NCache API.

Cache Users

However, if you want to limit some users to having cache API access only, and don't want them to perform any management operations, then configuring Cache User is your go-to option. Where you can restrict the user to perform data operations including Add, Remove, Update, and Retrieve through the relevant APIs only.

But, if you don't want to define different access levels for your users and allow all of them to perform all types of operations on cache. Then, there is no need to configure Cache User, as your Node Administrators have all the rights to manage and operate the cache smoothly.

Homogeneous Security Settings

After establishing security settings for one node, you need to ensure that all the nodes in that cluster have similar security settings on them. The user acting as Node Administrator on one node should be the administrator on all the other nodes in that cluster. Similarly, the user acting as a Cache User on one node should be a Cache User on the rest of the nodes.

If homogeneous security settings are not ensured on all nodes of a cluster, you may encounter different issues while managing and operating cache.

Note

A secured node as the first node in a cache cluster should prevent the addition of vulnerable nodes.

Note

A vulnerable node as the first node in a cache cluster shall prevent the addition of secured nodes.

Data Encryption

In distributed caching systems, communication mostly occurs over the network channels. The data travels and resides in the cache in its serialized form, and anyone eavesdropping on your connection can intercept your data easily if it is not encrypted. NCache Data Encryption allows for information to be converted into ciphertext. Only authorized people (i.e., with the appropriate key) can decipher the code and access the original information. NCache supports AES, 3DES, and AES FIPS encryption algorithms.

Data Encryption Workflow

When you add data to the cache, it is encrypted on the client-side using the configured encryption algorithm and encryption key. The encrypted data is stored in the cache, ensuring that data remains secure. Now when the encrypted data is fetched, it is retrieved from the cache and decrypted on the client-side before usage. This end-to-end encryption approach ensures that data remains protected, both in transit and at rest, making NCache a secure solution for caching sensitive information.

Encryption Key Management

Encryption key management in NCache involves securely handling all encryption keys, including the Key Encryption Key (KEK), Data Encryption Key (DEK), and Credentials Encryption Key (CEK), as discussed below.

  • Key Encryption Key (KEK): The Key Encryption Key (KEK), based on AES 256 encryption, secures the Data Encryption Key (DEK) by encrypting it. This key must be configured in the NCache Service configuration file on the server. To ensure consistency and security across all cache servers in a distributed environment, the same Key Encryption Key (KEK) must be used on each server.

  • Data Encryption Key (DEK): The Data Encryption Key (DEK) is responsible for encrypting user data before it is stored in the cache. This DEK is itself encrypted using the KEK. This approach ensures that only authorized tools or processes can retrieve and use encryption keys.

  • Credentials Encryption Key (CEK): NCache encrypts the user credentials stored in the client configuration file (client.ncconf) using a Credential Encryption Key (CEK). This key must be configured in the NCache Service configuration file. Similar to KEK, the same Credentials Encryption Key (CEK) must be used on each server. This ensures consistency and secures client credentials effectively in distributed environments.

How to Add or Change KEK and CEK

You can add or change KEK and CEK for both, the remote client and cache server as follows:

  • To add or change KEK, update the NCache Service configuration file using the following key-value pair: 
<add key="NCacheServer.KeyEncryptionKey" value="[Valid AES 256 KEY]"/>
  • Similarly, to add or change CEK, update the NCache Service configuration file using the following key-value pair: 
<add key="NCacheServer.CredentialsEncryptionKey" value="[Valid AES 256 KEY]"/>
Important

The NCache Service will not start unless valid KEK and CEK are provided in the NCache Service configuration file.

By default, the NCache installer adds default keys (predefined encryption keys) to the configuration file. For enhanced security, it is recommended to update the KEK and CEK in the NCache Service configuration file for remote clients or cache servers. After updating the keys, restart the NCache Service and cache processes for the changes to take effect.

Important

The KEK and CEK on a remote client can be different from the server nodes, but all server nodes must use the same KEK and CEK.

User Credential Authentication

By utilizing RSA-based cryptographic techniques, NCache secures user credential transmission during authentication. When a management tool or client needs to authenticate these credentials, it requests the server’s RSA-256 public key. The server generates a fresh public/private key pair for each process's lifecycle. Tools and clients encrypt user credentials (like username and password) with the server’s public key before transmitting them. The server decrypts these credentials using its private key to validate the user. This process ensures that credentials remain secure during transmission and are not vulnerable to interception or misuse.

Key Exchange and Authentication Mechanisms for Management Tools

NCache employs advanced cryptographic techniques for secure key exchange and authentication for management tools, like NCache Management Center, PowerShell, etc., as discussed below.

Key Encryption Key Management

For management tools, the key exchange process involves generating an RSA-256 public/private key pair during the process's lifecycle. The tool shares its public key with the server. The server then encrypts the KEK using this public key and shares the encrypted KEK with the tool. The management tool decrypts the KEK using its private key. This RSA key pair remains valid only for the duration of the tool’s lifecycle, ensuring short-lived and secure exchanges. When User Access Control (UAC) is enabled, only authorized tools and clients are permitted to fetch the KEK from the server.

Credentials Encryption Key Management

The management tools fetch the CEK from the cache server using RSA-based secure key exchange. Similar to KEK management, the tool generates an RSA-based 256 public/private based key pair during its lifecycle. The public key is shared with the server, which encrypts the CEK using the tool’s public key and shares the encrypted CEK with the tool. The management tool then decrypts the CEK using its private key and uses it to encrypt user credentials in the client.ncconf file.

Key Exchange for Clients

Similarly, clients connect to the server and request the CEK using RSA-based secure key exchange. The server encrypts the CEK with the client’s public key, and the client decrypts it using its private key, enabling it to decrypt stored credentials in client.ncconf.

TLS Encryption

While NCache includes a Data Encryption feature, it secures data in memory and during transmission over the network. However, Data Encryption comes with an additional performance cost. On the other hand, Transport Layer Security (TLS) provides a more comprehensive approach to securing data during network transmission, following industry-standard practices.

Although TLS also has a performance impact, it tends to be less resource-intensive than the alternative, i.e., Data Encryption. As such, it is more crucial to NCache operations, which involve data traveling over the network in a variety of ways:

  • Between servers and clients
  • Between different servers
  • Between caches and bridges

In NCache, you can decide what type of communication you want to encrypt, as it travels over the network, using TLS. This choice gives you complete control over your data security. Usually, people encrypt traffic over the public internet, such as Bridge communication for Geo Replication. However, for security-sensitive applications, you should probably encrypt traffic between clients and servers and between different servers.

TLS Certificate Considerations

When implementing TLS, certificates are stored in either the Personal or the Trusted Root Certificate Authority Store and are available at both the user and local machine levels. Certificates placed at the local machine level are accessible to all users, whereas user-level certificates are limited to specific users.

Additionally, these certificates require validation. Server-side certificates must be validated at the client end for TLS, verifying whether the client trusts the certificate issuer authority. If you're using a publicly recognized certificate issuer, you may not need to install the issuer's certificate in the client's Trusted Root Certificate Authority store. However, for self-signed or private certificates, you must ensure that the issuer's certificate is installed in the Trusted Root Certificate Authority store on the client end to avoid any chance of TLS handshake failures.

For mutual TLS between clients and servers, the client must also share its certificate with the server. In this case, the server must trust the client's certificate issuer authority, which the client should place in the server's Trusted Root Certificate Authority store. Similarly, when enabling TLS between servers, the other servers involved in communication must validate each other's certificates.

NCache follows a specific order when searching for certificates on the server box:

  • Local Machine: Trusted Root
  • Local Machine: Personal
  • User: Trusted Root
  • User: Personal

Understanding these considerations will ensure your deployment of NCache TLS encryption goes smoothly.

HTTPS for NCache Management Center

Similar to TLS, HTTPS (Hypertext Transfer Protocol Secure) is a widely used protocol to secure communication over a network. As such, NCache supports HTTPS for NCache Management Center in Windows and Linux using TLS certificates.

In This Section

Configure Authentication and Authorization
Explains how to configure the Security for nodes and caches.

Configure Encryption for Cache
Describes how to enable and configure Encryption for cache.

Configure TLS Encryption
Describes how to enable and configure SSL Encryption for cache in Windows and Linux.

Configure HTTPS for NCache Management Center
Describes how to enable and configure HTTPS for NCache Management Center.