Access Controls & Vendor Data Policy

Nodinite is designed with a clear principle: the vendor has zero remote access to customer installations. This security hardening guide explains access control, vendor access boundaries, data isolation, product key handling, and version check behavior so administrators and auditors can understand what traffic is possible and which systems remain customer-controlled.

Understanding the Access Boundary

Before you answer a compliance questionnaire or review firewall rules, establish the access boundary. Nodinite runs on customer-managed infrastructure, keeps runtime data on customer-hosted services and SQL Server databases, and limits outbound communication to administrator-initiated actions such as a version check or software download workflow.

Diagram: Access boundary for Nodinite showing customer-hosted runtime components, the administrator-triggered version and download workflows, and the explicit absence of vendor remote access into services or SQL Server.

Communication Paths

Responsibility Model

Backend Access Restrictions

Vendor Access Policy

Nodinite has no remote access mechanism to customer installations:

• No remote desktop, SSH, or VPN connectivity to customer servers
• No back-channel or management API that bypasses customer authentication
• A Nodinite installation does not activate or renew licenses through an outbound service call
• Administrators can optionally perform a version check from the Administration pages
• Administrators use the Nodinite Portal to download new versions and obtain renewed product keys when required. The encrypted product key contains feature flags such as Mapify, Repository, Logging, Monitoring, and BPM

See Install Nodinite v7 Prerequisites for the current outbound host allowlist required for version checks, portal downloads, and optional direct MSI downloads for remote servers.

These communication paths do not provide vendor access to customer-hosted log data, message payloads, or SQL Server databases.

Application-Level Access Controls

All Nodinite backend components enforce authentication and authorization:

Network-Level Recommendations

Network-level backend access is the customer's responsibility. Apply these controls on your infrastructure:

• Firewall – Allow inbound port 443 (HTTPS) only. Block all other inbound ports including 1433 (SQL Server), 80 (HTTP), and RDP (3389) from untrusted networks
• SQL Server isolation – SQL Server must not be reachable outside the application server network segment. No direct SQL access from end-user workstations or external networks
• Server access – Remote administration (RDP/SSH) should require VPN or a dedicated jump host, controlled by the customer's IT security team, not managed by Nodinite
• Service accounts – Use Group Managed Service Accounts (gMSA) where possible to eliminate password management risk. See Secret Management

Tip

See Post Installation Steps for the recommended post-deployment checklist, including firewall and service account configuration.

Access Authorization & Access Control

Do you prevent unauthorized access to data and limit access to only employees with valid access requirements? — Yes. Nodinite enforces role-based access control at multiple layers:

• Role-based authorization – Access to log data, repository configuration, and monitoring is controlled through roles assigned by administrators. Each user has specific permissions based on their role (Editor, Viewer, Administrator)
• Authentication prerequisite – All backend APIs require authentication (Windows Integrated or OAuth 2.0) before authorization rules are applied
• Data filtering – Authorized users can only view data their role permits — search results are filtered server-side based on permissions, preventing unauthorized data leakage
• Least-privilege defaults – New users have minimal permissions by default. Administrators explicitly grant access through role assignment
• Session validation – Each request is validated against current user permissions. Access is revoked immediately when roles are changed or users are disabled

See Roles and Users documentation for detailed permission matrices and role assignment procedures.

Vendor & Third-Party Data Access Policy

For compliance assessments requiring confirmation of vendor access, third-party storage, and NDA coverage, here are the definitive answers:

Vendor and Contractor NDA Requirements

Do all vendor contractors, subcontractors, and 3rd parties with access need NDA? — Not applicable. Nodinite as the vendor, and all its sub-contractors, have zero access to any customer data. No NDA is required for vendor access to runtime data because that access does not exist.

• Nodinite employees have no remote access to customer installations
• Nodinite sub-contractors (sales, marketing, support) never access production data
• No "master key" or back-channel access mechanism bypasses customer infrastructure

Outbound communication from the installed product is limited to administrator-initiated version and download workflows. See Install Nodinite v7 Prerequisites for the current outbound host allowlist required by version checks, portal downloads, and optional direct MSI downloads. Neither flow provides vendor access to customer-hosted log data, message payloads, or SQL Server databases.

Third-Party Storage

Do you use 3rd party cloud providers to store customer data? — No. Nodinite does not store any customer business data on Nodinite-controlled infrastructure or third-party providers.

What the Portal Stores

The only customer and licensing information stored in the Nodinite Portal is essential for the vendor-customer relationship:

• Customer name (organization)
• Contact information (email, phone)
• Billing and accounting details (for licenses and support contracts)
• Encrypted product key data that defines licensed feature flags such as Mapify, Repository, Logging, Monitoring, and BPM

This information is stored in the Nodinite Portal for product key management, software downloads, and customer management purposes only.

What Stays on Customer Infrastructure (Business Data)

All business transaction data remains exclusively on the customer's infrastructure:

• Log events (transaction records)
• Message payloads and context
• Monitor results and alerts
• Repository configuration
• All user-generated data

No Third-Party Storage

• No business data is replicated to Nodinite-controlled cloud infrastructure
• No business data is backed up to vendor-controlled systems
• No data is transmitted to third-party SaaS platforms for processing or analysis
• No business data leaves the customer's own infrastructure (on-premise or their own cloud tenant)

Data isolation is enforced by architecture: each Nodinite instance is dedicated to a single customer environment with isolated databases.

Data on Contractor Equipment

Do you allow storing data on contractors' equipment? — No. Contractor equipment is not involved in data storage. Nodinite is deployed on customer-owned or customer-managed infrastructure only.

• Customer deploys Nodinite on their own servers, VMs, or cloud subscription
• No component of Nodinite is hosted on Nodinite-provided or contractor-provided hardware
• No data is cached on vendor-controlled devices

Device Encryption and Management

Are those devices fully encrypted and managed? — Customer responsibility. Because Nodinite is deployed entirely on customer-owned infrastructure, device encryption and management are governed by the customer's own policies:

• On-premise SQL Server → Customer's data center encryption, disk management, backup policies
• Customer's Azure/AWS subscription → Customer's cloud provider encryption (SSE, TDE), managed by customer's cloud administration
• Customer-managed VMs → Customer applies their own encryption and device management standards

Nodinite can optionally encrypt data at rest in the SQL database using TDE (Transparent Data Encryption), configured at the customer's discretion. See Logging Service - Data Management for encryption options.

Tip

For on-premise deployments, enable:

• BitLocker on all SQL Server drives
• Windows Firewall with appropriate inbound/outbound rules
• Active Directory security hardening (gMSA for service accounts)
• Periodic firmware updates on physical servers/network equipment

Security Controls Equivalent to Customer's Organization

Do you ensure data in external cloud services has protection equivalent to your organization? — Not applicable. No customer data is stored in external cloud services.

However, if the customer chooses to deploy Nodinite in their own cloud subscription (Azure, AWS, GCP), they control all security:

• Azure: The customer's subscription, their RBAC policies, their encryption at rest, their network isolation
• AWS: The customer's account, their IAM policies, their KMS encryption keys, their VPC configuration
• On-premise: The customer's data center, their firewall, their SQL Server security hardening

Next Step

• TLS Hardening

Related Topics

• TLS Hardening – Configure HTTPS/TLS for Nodinite v7
• HTTP Security Headers – HSTS, CSP, Permissions-Policy, Cache-Control IIS configuration
• Key Management, Backup & Data Residency – NIST key lifecycle, backup encryption, GDPR compliance
• Manage License – Review product key details and renewal behavior
• Secret Management
• Roles
• Users
• Post Installation Steps