- 0 minutes to read

Access Controls & Vendor Data Policy

Nodinite is designed with a clear principle: Nodinite as a vendor has zero remote access to any customer installation. This page documents application-level access controls, network hardening recommendations, and answers to common compliance questionnaire questions about vendor data handling.

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
  • The only outbound connection from a Nodinite installation is license activation to portal.nodinite.com — which transmits no customer data, log events, or business information

Application-Level Access Controls

All Nodinite backend components enforce authentication and authorization:

Component Access Control
Web API All endpoints require an authenticated session — Windows Integrated (Kerberos) or OAuth 2.0 bearer token. Access is further restricted by role-based permissions
Log API Authentication is configurable. When enabled, requires a valid OAuth 2.0 bearer token from a trusted identity provider
Web Client Browser session required. Unauthenticated users are redirected to the login page
SQL Databases Not network-exposed. Accessed exclusively by local Windows Services using dedicated service account credentials
Windows Services Run under least-privilege service accounts. No interactive login. Service accounts have no broader domain access

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 (the vendor) and all its sub-contractors have zero access to any customer data. No NDA is required for vendor data access because vendor data 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

The only outbound connection from a Nodinite installation is [license activation][] to portal.nodinite.com, which contains no customer data.

Third-Party Storage

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

What Nodinite Stores (Portal/License Data)

The only customer information Nodinite stores is essential for the vendor-customer relationship:

  • Customer name (organization)
  • Contact information (email, phone)
  • Billing and accounting details (for licenses and support contracts)

This information is stored in the Nodinite Portal database for license activation 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's cloud
  • 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)

Customer data segregation 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 Steps

TLS Hardening