Security and Encryption in NCache

NCache provides a robust set of security features designed to protect distributed caching environments without compromising performance. For instance, the Access Controls it offers let you define user permissions for specific caches and nodes, ensuring that only authorized users can perform certain operations. Additionally, LDAP Integration enables centralized authentication, making it easier to manage secure access across the system.

Moreover, to protect sensitive data, Data Encryption secures it both in memory and during transmission using algorithms like AES, 3DES, and AES FIPS. However, it does come with an added performance cost. For more efficient network security, TLS Encryption secures communication between clients, servers, and bridges with less overhead, and allows you to choose which communication paths to protect. Additionally, HTTPS Support secures access to the NCache Management Center on both Windows and Linux using TLS certificates, ensuring safe and encrypted administrative access. These security features in NCache are categorized into the following three main areas:

1. User Security
2. Encryption
3. Transport Layer Security

Role-Based Access Control (RBAC) & User Authentication

User Security in NCache ensures secure access control by managing authentication and authorization for users interacting with cache clusters.

Authentication and Authorization

NCache provides security with authentication and authorization built into the product. NCache categorizes the users based on the two different levels of security as follows:

1. Node Administrators: Node Administrators are super-users with full control over the cache. They can create, modify, and remove caches, as well as perform any cache management tasks. They have the ability to save or discard security configurations and can inherit the capabilities of Cache Users to interact with caches using the NCache API.
2. Cache Users: If you want to restrict users to only cache API access without node management privileges, you can configure them as Cache Users, limiting them to data operations like Add, Remove, Update, and Retrieve through the relevant APIs on the cache they have access to. However, if you prefer all users to have full access to perform operations on the node and the configured caches, there's no need to set up Cache Users, as Node Administrators already have complete control over the cache.

NCache Details

NCache Security

Security API

Authentication

NCache implements Role-Based Access Control (RBAC) to ensure only authorized users access or administer the cluster. By integrating natively with LDAP-supported Directory Services (such as Microsoft Active Directory), NCache enforces centralized authentication, allowing organizations to manage security policies within their existing identity infrastructure. When NCache security is enabled, all the connections to the cache cluster must be authenticated first against the LDAP Directory at the cache server. During this process, users must provide their User Name, Distinguished Name (DN), and Password. If these credentials fail authentication, the connection request is rejected.

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 through Service config file. You need to specify user credentials in the following places based on the security level. For further details please refer to the NCache Documentation.

• Node Administrators: Add the node administrators as follows:

  Add-NCacheUserOrGroup -Server 20.200.20.40 -AccessLevel Admin -AdminCredentials(Get-Credential john_smith) -UserOrGroupName john_smith -UserOrGroupDN "CN=John Smith,OU=engineers,DC=example,DC=com" -DomainController test_domain

  Then you can enable security as you can see below:

  Enable-NCacheSecurity -Server 20.200.20.40 -AdminCredentials(Get-Credential john_smith) -WriteCredentialsToServiceConfig

  You can also configure node level security using the NCache Management Center.

• Cache Users:

  You've successfully secured your node and its caches. As previously discussed, to restrict certain users to cache operations without full management rights, add them as Cache Users. Use the same cmdlet for Node Administrators, by specifying AccessLevel as Cache and CacheName (the name of the cache you want the user to access). Run the following command:

  Add-NCacheUserOrGroup -Server 20.200.20.40 -AccessLevel Cache -CacheName demoCache -AdminCredentials(Get-Credential john_smith) -UserOrGroupName john_smith -UserOrGroupDN "CN=John Smith,OU=engineers,DC=example,DC=com" -DomainController test_domain -EnableSecurity Yes

  You can also configure the credentials programmatically. An example of how to call this method with the required user credentials is shown below:

  // Specify cache name and user credentials
  string cacheName = "demoCache";
  string userId = "userid";
  string password = "mypassword";
  
  // Initialize the CacheConnectionOptions
  var options = new CacheConnectionOptions();
  
  // Enter the credentials
  options.UserCredentials = new Credentials(userId, password);
  
  // Connect to the cache using the security credentials
  ICache cache = CacheManager.GetCache(cacheName, options);

Homogenous 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.

Authorization

After NCache authenticates a connection to the cache successfully, it checks NCache configuration files at the cache server to authorize this connection. Once a connection is authenticated against the active directory, it is authorized either from the security.ncconf file or the client.ncconf based on whether you are using node level or cache level security, respectively.

Encryption

If your application deals with confidential and sensitive data that you want to secure, and you're using an in-memory distributed cache, you need to ensure that your distributed cache protects this sensitive data from unwanted access through encryption.

Data Encryption

NCache supports a rich set of industry-standard encryption algorithms, including AES-256 and FIPS-compliant AES, to help organizations meet regulatory requirements such as PCI-DSS, HIPAA, and GDPR. This ensures that your sensitive data remains protected using NIST-recommended cryptographic standards. NCache supports the following encryption algorithms:

• Triple Data Encryption Standard (3DES)
• Advanced Encryption Standard (AES)
• Advanced Encryption Standard - Federal Information Processing Standards (AES-FIPS)

Below are details of each algorithm and its supported variations:

Triple Data Encryption Standard (3DES)

Triple Data Encryption Standard (3DES) is a symmetric-key block cipher algorithm, which applies the DES cipher algorithm three times to each data block. Different variations of the 3DES algorithm supported by NCache are:

• 3DES-128: 128-bit encryption
• 3DES-192: 192-bit encryption

Advanced Encryption Standard (AES)

Advanced Encryption Standard (AES) is a symmetric block cipher algorithm with a block/chunk size of 128 bits. It converts these individual blocks using keys of 128, 192, and 256 bits. Once it encrypts these blocks, it joins them together to form the ciphertext. Different variations of the AES algorithm supported by NCache are:

• AES-128: 128-bit encryption
• AES-192: 192-bit encryption
• AES-256: 256-bit encryption

Data Encryption Workflow

NCache data encryption and decryption occur inside the NCache client application process. Hence, all data traveling over the network between your application and the cache cluster is already encrypted. Similarly, only encrypted data is stored in the cache store. You provide an encryption key that NCache uses, which is kept inside NCache security configuration files at each cache server in an encrypted manner. The encryption key is automatically sent to clients to be used in memory upon a successful connection.

You can enable encryption through the NCache Management Center without any programming effort on your part. Once encryption is enabled, the NCache client automatically starts encrypting your objects before sending them to the cache cluster. And, it automatically decrypts objects fetched from the cache before delivering them to your application.

NCache Details

NCache Security

Security API

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.

RSA Encryption (Public/Private Key Transport)

To securely exchange encryption keys and user credentials, NCache employs RSA-based public/private key encryption. RSA encryption is used only for key and credential transport during communication between clients and servers, as well as server-to-server exchanges.

• RSA protects the transmission of user credentials, KEK, and CEK during the key exchange process.
• Each participating component dynamically generates a public/private RSA key pair at runtime to perform secure key exchange.
• This ensures that sensitive keys and credentials never travel in plaintext, even before Transport Layer Security (TLS) encryption is applied.

Transport Layer Security

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.

Regular TLS

Transport Layer Security (TLS) encryption secures data exchange between servers and clients, different servers, caches, and bridges. Users can enable any issued or self-signed certificate for connections with the client(s) or can enable component-to-component connections in NCache. This guarantees encrypted data transmission, which is separate from TLS-secured data.

NCache provides robust Transport Layer Security (TLS 1.2 and 1.3) to secure data-in-motion. This includes support for Mutual TLS (mTLS), providing two-way authentication between clients and servers. This ensures encrypted communication across all channels, including client-to-server, server-to-server, and across WAN bridge connections. To establish these secure channels, TLS relies on digital certificates for authentication. These certificates can be installed in either the Trusted Root or Personal (My) store, providing flexibility for environments where group policy may restrict Root store usage. Public CA-issued certificates are recommended to avoid additional trust configuration. However, private CA certificates can also be used, provided that the issuing authority is added to the Trusted Root store on all servers and clients.

Mutual TLS

NCache supports both Regular TLS and Mutual TLS for secure authentication. In Regular TLS, a server certificate is installed on each NCache server, allowing clients to verify the identity of the server during the handshake. Mutual TLS further strengthens this process by requiring client certificates as well, ensuring that both the client and server authenticate one another before establishing a secure connection. For secure communication across the entire distributed caching environment, TLS now protects not only client-to-server interactions but also server-to-server communication and data exchanged over bridge connections.

Configure TLS Cluster Wide

NCache offers a seamless way to configure Transport Layer Security (TLS) through the new Enable-NCacheTLS and Disable-NCacheTLS cmdlets. Once certificates are installed and TLS is enabled, secure communication is enforced across all participating nodes. Configuration changes require an NCache service restart to take effect, and users can verify encryption status through Management Center or logs indicating successful TLS handshake operations.

To configure TLS encryption in Windows or Linux, follow the documentation on Configure TLS Encryption in NCache

NCache Details

NCache Security

Security API

NCache Security: FIPS & RBAC Matrix

What to Do Next?

• NCache Details
• Download Free 30 Day Install Key
• Request a Personalized LIVE Demo
• Read Product Documentation