Configure Security

NCache provides a security framework to protect cache server nodes through authentication, authorization, and encrypted communication. It supports LDAP/Active Directory-based user validation, role-based access for NCache operations, RSA-based credential exchange, and TLS encryption for secure communication. This multi-layered approach decouples administrative management from data-tier access, ensuring that only authenticated actors can interact with the cache while maintaining line-rate throughput.

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:

  • Machine Level authorization: It is performed by an OS-level administrator on the target server.
  • NCache-level Authorization: This controls who can manage NCache and who can access secured caches.
Note

All the caches on a secured node are automatically secured.

Once NCache security is enabled on a node, NCache uses registered security users to authorize management and cache operations. NCache supports the following types of security users:

  • Node Administrators
  • Cache Users
  • gMSA Cache Users

Machine Administrators

A Machine Administrator is an OS-level user with local administrator privileges on the server where NCache security is being enabled or disabled. This user does not have to be an LDAP or Active Directory user. If the Machine Administrator is not added to NCache security, the user is not treated as a Node Administrator or Cache User. Such a user can only authorize enabling or disabling NCache security..

A Machine Administrator is not automatically granted NCache management or cache access rights. To perform NCache management operations after security is enabled, the user must also be added as a Node Administrator in NCache security.

If the Machine Administrator account cannot query the LDAP or Active Directory directory, you can provide separate directory browsing credentials to validate the Node Administrator identity.

Node Administrators

Node Administrators are Super-Users and have complete control over the cache node - they can create, modify, remove caches, and perform any other cache management operations.

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.

gMSA Cache Users

NCache supports gMSA as a special type of cache user for applications that operate under a Windows gMSA identity. Unlike standard LDAP users, gMSA does not require a password to be provided or stored, instead, the NCache Client SDK automatically retrieves a Kerberos token from Windows at runtime, delegating authentication to Windows Authentication (SSPI/LSA) which obtains Kerberos tickets from the Kerberos Key Distribution Center (KDC). gMSA can be added as cache users (not node administrators) and are authenticated against Active Directory the same way as standard LDAP users. The '$' suffix must be used when specifying the account name (e.g., user1gmsa$).

Note

gMSA issupported as cache users only. gMSA support requires NCache 5.3.7 or above.

Credential Validation and Caching

NCache validates LDAP and Active Directory users through the configured domain controller. When a user or group is added to NCache security, NCache verifies that the identity exists in the directory.

If the domain controller is unavailable during validation, the operation fails and the user cannot be added or authenticated.

To reduce repeated authentication during the lifetime of a process, NCache provides Credential Caching. When enabled, credentials of an already authenticated user are cached by NCache so the user does not have to be authenticated repeatedly during the same process lifecycle.

Credential Caching is disabled by default. To enable it, set the NCacheServer.EnableCredentialCaching tag to True in the NCache Service configuration file.

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

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 WAN 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
  • Current User: Trusted Root
  • Current 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 Group Managed Service Account (gMSA)
Describes how to add a gMSA cache user or group using the NCache Management Center and PowerShell commands.

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.