NCache Cloud Security

NCache Cloud is a managed service that never takes possession of your infrastructure. It runs inside your own cloud subscription, authenticates through your cloud identity provider, and gives NCache support no automatic access of any kind.

• Runs 100% inside your Cloud Subscription
• Integrated Security for Management tools inside your cloud
• Security for Client Applications
• Audits and Logging
• Compliance and Data Handling
• Patching is automatic and without exposure to NCache support
• Temporary access for NCache Support only when you grant it
• BYOL Plan is fully managed but works offline, without public Internet access

Runs 100% inside your Cloud Subscription

NCache Cloud is deployed 100% inside your cloud subscription, network, and resource group. Nothing lives outside it.

• Servers deployed in a dedicated subnet in your VNET/VPC: isolated by your own security rules
• Client applications run in the same VNET/VPC: all traffic between clients and servers is private
• Management tools run inside your cloud on the servers: NCache Cloud Portal, Management Center, Monitoring Dashboards.
• Data, metrics, logs, traces, and telemetry stay in your cloud environment: none of it is copied anywhere else

Because nothing of yours sits outside your own cloud environment, there is nothing outside it for an assessment to examine. See Compliance and Data Handling.

Your Access to the Deployed Resources is Restricted

Both Azure and AWS restrict your access to the deployed resources by default. They only differ in whether you can lift the restriction.

Integrated Security for Management tools inside your cloud

The management tools run on your own servers, and both authentication and authorization come from your cloud.

• Management endpoint with port 9900: both public and private endpoints provided by default. The private endpoint is only accessible from inside your network over a VPN or a jump box. The public endpoint requires an IP allowlist you define, and you can disable the endpoint as well. Sign-in is required.
• Authentication from your cloud identity provider: Sign-in uses your cloud’s integrated authentication mechanism that is Microsoft Entra ID on Azure and Amazon Cognito on AWS. The same sign-in covers all the management applications, including NCache Cloud Portal and NCache Management Center.
• Authorization from your cloud security:
  • Azure: Owner or Contributor of the Managed Resource Group (MRG)
  • AWS: NCacheManagement IAM role, configured by you, created at deployment

Security for Client Applications

Applications reach the cache on a private endpoint, with TLS on by default and two ways to authenticate when the network boundary is not enough on its own.

• Private DNS endpoint + port 9800. No public endpoint.
  • Private DNS: applications connect to a private DNS name, not to individual servers. It resolves to every live server and stays current as the environment scales, so there is nothing to reconfigure.
  • No public endpoint: nothing is publicly exposed, in any deployment shape — not as a configuration option, and not behind a firewall rule you could open by accident. It is reachable only from inside your VNET/VPC.
  • Dedicated subnet: The cache subnet is isolated by NSG rules on Azure and security group rules on AWS, and you scope which source subnets can reach it.
• Data Security
  • In transit: TLS. On by default, with NCache-provided certificates pre-installed, so your applications need no configuration at all. Covers client-to-server and server-to-server traffic. One-way by default; mutual TLS configurable. Use the NCache-provided certificate or install your own custom certificates.
  • At rest: Data Encryption (AES / AES-FIPS) — 256, 192, and 128-bit keys. NCache client automatically encrypts cached values before sending them, so values are unreadable in server memory and persisted data on disk is encrypted too. A FIPS-validated variant is available where your environment requires it. You hold the key — it is never generated, stored, or escrowed by us, and if it is lost, the data is unrecoverable by anyone, because no copy exists outside your control.
  • Index metadata is not encrypted: Indexing and SQL-like queries keep working on encrypted caches, because index data is extracted by the client and sent as metadata alongside the encrypted value. The server indexes and queries without decrypting anything.
• Authentication/Authorization
  • Mutual TLS. Client applications are identified by the application rather than by a user, so the question the cache has to answer is: may this application connect? Additionally, all caches in one environment are accessible to all clients connecting. You ask the environment to issue a TLS certificate for a specific client application and place it with that application. The server admits only certificates it issued, so the certificate is the identity and the authorization at once — an application without one is refused at the handshake rather than at a later check. No password in a connection string and no shared secret in configuration.
  • LDAP RBAC. Configured through the Management Center against your own LDAP or LDAPS server. Clients authenticate with credentials and roles come from your directory, so different clients can be permitted different operations.

Audits and Logging

A security audit trail for NCache Cloud, separate from error logging, written on your servers and published to your own monitoring service.

• Audit logs are created for important events:
  • Admin and client login success/failure
  • Tech support access granted — and, where available, also used. See Temporary access.
  • Servers start/stop, member join/leave — the lifecycle of the environment itself
  • Client connect/disconnect
  • Maintenance schedule updated, with the old and new information included, so a change is reviewable rather than merely noted
  • OS patch, NCache PATCH, MINOR and MAJOR upgrade success/failure, with further detail of the steps
  • New NCache PATCH, MINOR and MAJOR version made available
• Audit logs are saved on the local servers and also published through OpenTelemetry: they arrive in your own Azure Monitor or Amazon CloudWatch alongside the rest of your telemetry, under your own retention policy. It is your record, in your account, rather than one you have to ask us for.

Compliance and Data Handling

This is a security audit trail for NCache Cloud, separate from error logging, written on your servers and published to your own monitoring service.

• Data residency is inside your cloud environment, away from the vendor. Your environment runs in the region you choose, in your own subscription. Cache data does not leave it; there is no vendor-side storage, and nothing replicates to infrastructure outside your account.
• No third-party sub-processors involved. A flat zero, where most vendor assessments expect a list. It follows from where the product runs: the cache is in your subscription, the management tools are on your servers, and telemetry goes to your own monitoring workspace over your provider's private network. There is no point in the path where your data is handed to anyone.
• No certifications needed for NCache Cloud, like SOC 2, ISO 27001, and FedRAMP authorization — because nothing lives outside of your cloud environment.

Your compliance posture is your cloud provider's, including FedRAMP authorization, where your account is in an authorized environment.

Patching is automatic and without exposure to NCache Support

Every patch and upgrade is either automatic or started by you but fully automated — and none of them require NCache support to be let into your environment.

• Patching is automatic and fully automated: all patching and upgrades are either automatic or initiated on-demand, but fully automated. This includes OS patching, NCache PATCH, MINOR, and MAJOR upgrades. Even for MAJOR upgrades, the cache servers are upgraded on-demand but fully automated, whereas the client applications are upgraded by you.
• Monthly OS security patches to address vulnerabilities
• Patching does not involve NCache support: there is no exposure. Support gets involved only if something fails.

Temporary access for NCache Support only when you grant it

The routine lifecycle of the cache - patching, upgrades, replacement of failed servers - needs nobody from NCache inside your environment at all. That is why NCache support has no automatic access to your environment.

There are two support models, and under both, support only ever works while in an online meeting with you.

Model 1 — Grant temporary access to NCache Support

• Temporary access is granted per incident, using JIT on Azure and the NCachePublisherSupportRole on AWS.
• Access includes using the Azure or AWS portal to analyze inside the VMSS/ASG VMs - identifying issues, capturing error logs, traces, and metrics for debugging, and taking memory dumps of NCache server processes to identify bugs.
• NCache Support holds an online meeting with you while diagnosing and fixing issues. There is no unattended session.
• A memory dump contains cached data. So, during an approved session, an engineer can see cached data. So, if you don’t want NCache support to see it, then memory dumps are not used in diagnosing the problem. We say that plainly: nothing happens without your grant; the session is held with you present, and you see it as it happens.
• SSH may be involved. SSH is not the first option. But in some cases, an SSH login may be involved to the cache servers.
• NCache Support has no access to Management tools: you do, and you show them to support during an online meeting.

Model 2 - Do not grant any access to NCache Support

• An online meeting where support guides you to perform the actions that diagnose the problem.
• You capture the logs, traces, and metrics, and memory dumps where they are needed, and you perform any upload yourself.
• Nothing enters your environment and nothing leaves it without your own action.

BYOL Plan is fully managed but works offline, without public Internet access

On BYOL, NCache Cloud is deployed with its subnet not configured for outbound networking — and it is still a fully managed cache.

That may sound contradictory. A managed service normally phones home, and a cache that cannot reach its vendor usually cannot be licensed or supported. Here is how each part works without a connection.

• NCache Cloud deployed with its subnet not configured for outbound networking.
• You have access to the Deployed Resources: this allows you to do the offline activation.
• NCache support has no access: all support is provided via online meetings with you.
• Licensing uses the offline activation feature of NCache, so servers are activated without a direct internet connection. They never contact a licensing server over the internet — no check-in, no phone-home, and no dependency on our infrastructure being reachable or on any vendor being in business next year. The mechanism, in full:
  • You generate an activation request code on the server
  • You copy it to another computer that has internet access
  • On that computer, you use the NCache offline activation portal to activate the license and obtain an activation auth code
  • You copy the activation auth code back to the NCache Cloud server
  • You activate the server
• OS patching, PATCH, and MINOR upgrades are still available as automatic and fully automated. MAJOR upgrades require a fresh offline activation of licenses that is manual.
• "No public internet access", not "air-gapped." The servers still reach your own cloud's services, which is normal and is what a government cloud region looks like. Air-gapped has a specific defense meaning that a commercial cloud region does not satisfy, and the accurate term is the one that passes review.

Frequently Asked Questions (FAQ)

Does the vendor have access to our data?

NCache support has no automatic access. You choose whether temporary access can be granted at all. Where it is, access is granted per incident and used only during an online meeting with you.

Where is our data stored?

Inside your own cloud environment - your subscription, your region, in memory on servers in your own VNET/VPC. The one exception is diagnostic material you approve for upload during a support case; see Temporary access.

Is data encrypted in transit and at rest?

Yes. TLS in transit, on by default, for client-to-server and server-to-server traffic. At rest, your client can encrypt cached values with AES-256, AES-192, or AES-128, including an AES-FIPS variant, using a key you hold.

How do applications authenticate to the cache?

By default, they do not, and no credentials are passed — access is controlled at the network layer on a private endpoint. Where authenticated access is required: mutual TLS, where the environment issues a certificate to a named application and admits only applications holding one, or LDAP RBAC against your own directory.

How is administrative access controlled?

Authentication from your cloud identity provider - Entra ID on Azure, Cognito on AWS. Authorization from your cloud - Owner or Contributor of the Managed Resource Group on Azure, the NCachePublisherSupportRole IAM role on AWS. No separate NCache permission system and no local accounts on the servers.

Is there an audit trail?

Yes. Admin and client logins, support access grants, server start/stop, and member join/leave, client connect/disconnect, maintenance schedule changes with old and new values, and patch and upgrade outcomes - saved on the servers and published through OpenTelemetry to your own monitoring service.

What is the uptime commitment?

Your infrastructure carries your cloud provider's own SLA, issued directly to you, at the tier matching your deployment shape. Alachisoft offers no separate uptime SLA, because NCache Cloud runs in your own subscription where your own changes can affect it. What is committed contractually is response time: with Premium 24x7, same or next business day for routine issues and one hour for a production outage.

Are there sub-processors?

No third-party sub-processors are involved.

How are vulnerabilities handled?

OS patching is monthly, automatic, and applied one server at a time. NCache PATCH releases apply the same way. If something cannot wait, you can start it immediately from the NCache Cloud Portal. Report security issues to support@alachisoft.com.

What happens to our data when we terminate?

Delete the deployment and the environment leaves your subscription. Nothing is retained elsewhere, so there is no export process - there is nothing to export.

Can we run this in an isolated or restricted-egress network?

Yes, on the BYOL plan, using offline license activation. See BYOL Plan can work offline.