NineData Private Deployment Security Best Practices: Protect the Internal Management Entry

A private NineData deployment runs in a network managed by the organization. Protect its management entry by keeping it on a private network, enabling HTTPS, identifying trusted source IPs, and using NineData’s built-in access IP whitelist when the deployed version provides it.

Follow the sequence below for standalone and high availability private deployments. Confirm node communication, ports, and components in the guide for the selected deployment option.

Step 1: Keep the management entry on a private network

Place the NineData console on the organization’s private network. Administrators on the corporate network can use its internal address directly. Administrators outside the network must connect to the corporate VPN first, then use the same internal address. Do not place the management console on a publicly reachable network.

Connect to the private network over VPN from outside

Remote access requires a company VPN that can reach the network hosting NineData. The company IT administrator provides the approved VPN client, account, and connection settings.

1. Get the approved VPN client, account, and connection settings from IT, then install the client according to the company instructions. If it is already installed, continue to the next step.
2. Open the VPN client, sign in, and connect to the corporate network. Confirm that the client reports a successful connection.
3. Open the internal NineData address, such as https://ninedata.intra.example. Use the same internal address from outside the office network.
4. Disconnect from the VPN when you are finished.

If the VPN is connected but the NineData page does not open, ask IT to confirm that the VPN allows access to the private network hosting NineData and that internal DNS resolution is available.

Plan network communication for the management entry, NineData nodes, business data sources, and external dependencies according to the actual deployment topology. Keep only the traffic required by the deployment and its tasks. Follow the deployment guide for node-to-node communication in high availability deployments.

Step 2: Enable HTTPS with an internal hostname and certificate

HTTPS encrypts login details and management traffic between the browser and the management entry. For internal use, an enterprise certificate authority (CA) can issue the certificate. Administrator devices must trust the CA, and the certificate hostname must match the hostname used in the browser.

The following example uses NGINX on Ubuntu as the HTTPS entry. Prepare an internal hostname such as ninedata.intra.example, and configure internal DNS to resolve it to the NGINX host’s private address.

1. Install and start NGINX.

   sudo apt update
   sudo apt install -y nginx
   sudo systemctl enable --now nginx

2. Install the certificate and private key provided by the enterprise CA. Replace the sample source paths with the paths to the files delivered by your CA. Limit access to the private key to administrators who need to manage NGINX.

   sudo install -d -m 750 /etc/nginx/certs
   sudo install -o root -g root -m 644 /path/from-ca/fullchain.pem /etc/nginx/certs/fullchain.pem
   sudo install -o root -g root -m 600 /path/from-ca/privkey.pem /etc/nginx/certs/privkey.pem

3. Configure HTTPS and the reverse proxy. Create /etc/nginx/conf.d/ninedata.conf and replace server_name with your internal hostname.

   server {
       listen 80;
       server_name ninedata.intra.example;
       return 301 https://$host$request_uri;
   }
   
   server {
       listen 443 ssl;
       server_name ninedata.intra.example;
   
       ssl_certificate     /etc/nginx/certs/fullchain.pem;
       ssl_certificate_key /etc/nginx/certs/privkey.pem;
       ssl_protocols       TLSv1.2 TLSv1.3;
   
       location / {
           proxy_pass http://127.0.0.1:9999;
           proxy_set_header Host $host;
           proxy_set_header X-Forwarded-For $remote_addr;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

   This example forwards requests to port 9999 on the same host. If the deployment guide provides a different console address or host mapping, update the proxy_pass target to that private address and port. If NGINX and NineData run on different hosts, use the NineData host’s private address.

4. Check and load the configuration.

   sudo nginx -t
   sudo systemctl reload nginx

5. Verify access. From an administrator device on the corporate network, open https://ninedata.intra.example. Confirm that the console opens and the browser shows no certificate warning. Plan certificate renewal before it expires.

Step 3: Let NineData identify the trusted source IP

When a proxy such as NGINX sits in front of NineData, the connection received by NineData comes from the proxy. The proxy must place the actual visitor source in a request header so NineData can record it. The NGINX example above overwrites X-Forwarded-For with the client address NGINX sees, instead of trusting the same-named header supplied by the client.

NineData reads X-Forwarded-For by default. In this Docker example, the container is named ninedata:

1. Enter NiUP and check the current setting:

   docker exec -it ninedata niup

   niup> console config get website.realip.headers

2. If the result is X-Forwarded-For, no change is needed. If it is <no value>, the setting has not been explicitly overridden and NineData still uses X-Forwarded-For by default. If another name is returned, set it to match NGINX:

   niup> console config put website.realip.headers X-Forwarded-For

3. If you changed the setting, restart Console to apply it. This briefly interrupts console access, so choose an appropriate maintenance window:

   niup> console restart

Access NineData through HTTPS and perform an operation that creates an audit record. Check that the source IP in the audit log matches the actual access source. When accessing a Docker-published port directly, no trusted proxy has written the source header, so NineData cannot obtain the actual visitor IP from that header.

If another proxy sits in front of NGINX, first confirm the connection source NGINX sees and trust only the verified upstream proxy.

Step 4: Enable NineData’s built-in IP whitelist when the version supports it

NineData’s organization-level access IP whitelist can limit where organization members can sign in from. The system administrator role is exempt, so the whitelist does not replace the private network as the boundary for administrator access.

caution

Availability depends on the private deployment version. Check the feature guide and confirm that the setting appears in the deployed console. If it is not present, do not assume that the version supports it.

1. Sign in with a system administrator account, then select Account > Organization in the left navigation.
2. Locate NineData’s built-in access IP whitelist setting on the organization information page, enable it, and enter the office or VPN egress address allowed by the current page. Check the source IP in the audit log before adding it. Follow the current page for the required address format and how to enter multiple addresses.
3. Save the configuration. First verify sign-in from an allowed private-network source with a regular organization member account, then use a dedicated test account to verify that access from an unlisted source is blocked. System administrator accounts are exempt, so do not use one to test the block. Before testing, make sure an administrator can still restore the configuration.

For field and operation details, see Manage Access IP Whitelist.

Step 5: Include security in routine maintenance

Maintain the version. Review release notes for the deployed version and apply relevant fixes using the official upgrade steps.

Prepare for recovery. Back up the actual persistent data and configuration before upgrading. If the deployment uses external services such as a metadata database or object storage, back them up according to their own procedures and verify that recovery works.

Limit access to SSH, Docker administration, databases, and cluster management interfaces to the administrators or NineData nodes that need them. Grant database accounts only the permissions required by their tasks. Regularly review access paths, member permissions, software versions, and backup recovery.

Deployment guides

• Community Edition deployment and upgrade
• Private deployment guide