Overview

This article contains the Syniti Knowledge Platform (SKP) Connector Security and Requirements information. The following documentation is also available for the SKP Connector:

• SKP Connector Requirements and Installation

• SKP Connector Troubleshooting

• Scanning Authorizations for Technical Users

What Is the SKP Connector?

The SKP Connector is an on-premise service that maintains outbound WebSocket connections to the Syniti Gateway and uses those connections to carry multiplexed TCP streams to approved customer-side services such as databases and applications. The connector is installed inside the customer network and initiates all cloud connectivity itself.

The SKP Connector provides a secure and seamless way to establish and maintain connectivity between remote networks and SKP (see Figure 1).

At a high level, the runtime flow is:

1. The connector starts on a customer-managed Linux or Windows server.

2. The connector opens a secure WebSocket connection to the Syniti Gateway.

3. The connector authenticates with its assigned connector credentials.

4. The Gateway reuses that WebSocket session to request logical TCP tunnels.

5. The connector opens outbound TCP connections to the requested customer-side targets and forwards traffic over binary WebSocket frames.

The transport is an application-layer tunnel carried over secure WebSocket connections.

Why Did Syniti Create the SKP Connector?

Syniti created the SKP Connector to enable secure connectivity between Syniti Platform and customer-managed systems that are not exposed directly to the internet. Many SKP use cases require access to internal databases, APIs, and other services that remain inside the customer network boundary. The connector addresses that requirement by running inside the customer environment and establishing a secure outbound connection to Syniti, avoiding the need for inbound internet-facing access into customer systems.

The SKP Connector was also designed to align with standard enterprise security and deployment practices. It allows connectivity to be limited to the specific internal hosts and ports required for approved SKP workflows, while remaining subject to the customer’s existing network segmentation, monitoring, hardening, and credential-management controls. In practical terms, the connector provides a controlled way to extend Syniti Platform connectivity into protected customer environments without requiring customers to weaken their existing security posture.

As shown in the above diagram, the SKP sends commands and queries to the SKP Connector. These commands include instructions such as RESTful API calls to local services and data quality queries.

The key to successful processing via the SKP Connector is that, from the SKP Connector instance itself, communication pathways are open to the data storage and processing systems that will be scanned for metadata, queried for data quality concerns, used to execute data migrations, and integrated with the SKP.

SKP Connector Changes: WireGuard to WebSocket

The following is an explanation of changes between the legacy WireGuard-based SKP Connector and the current WebSocket-based SKP Connector. It is intended to support migration planning, customer communication, and eventual retirement of the older connector. The WebSocket-based SKP Connector uses enhanced security technologies, standard networking (IPv4), includes easy update capabilities, and boasts a better performance and experience.

The major change is a shift from a VPN-style WireGuard transport to an application-layer WebSocket tunnel. This changes installation, authentication, network requirements, and customer guidance, while preserving the core goal of secure outbound connectivity from customer-managed environments to Syniti workflows.

Purpose

The legacy connector and the current connector solve the same high-level problem: secure connectivity from Syniti services to customer-managed systems without requiring customer-side services to be exposed directly to the public internet.

What changed is the transport and operating model used to provide that connectivity.

Executive Summary

The legacy connector relied on a WireGuard-based VPN model. The current connector relies on secure outbound WebSocket connections to the Syniti Gateway and multiplexes TCP streams inside those WebSocket sessions.

The practical result is:

• no WireGuard interface,

• no UDP tunnel to Syniti,

• no VPN key exchange workflow,

• a simpler outbound network requirement based on HTTPS/WSS, and

• connector registration based on a Syniti-issued connector key.

Side-by-Side Comparison

What Was Removed

The current connector removes several concepts that were specific to the legacy design:

• WireGuard interface creation on the connector host.

• WireGuard public/private key management as the primary connectivity primitive.

• Syniti-controlled VPN peer configuration distribution.

• UDP-based tunnel establishment to WireGuard edge nodes.

• Network documentation centered on VPN tunnel addresses and WireGuard listener behavior.

What Was Introduced

The current connector introduces a new operating model centered on a persistent WebSocket connection pool.

Key additions are:

• connector key bootstrap through the key generated in SKP during connector registration,

• hash-based authentication using a timestamp and shared secret,

• standby WebSocket sessions that can be reused for future work,

• connector-managed heartbeat traffic to keep the gateway session alive, and

• package-driven service configuration in the config.yaml file.

Networking Changes

Legacy Model

The legacy connector required a mixed network profile:

• outbound TLS for control-plane requests,

• outbound UDP for WireGuard tunnel establishment,

• and traffic encapsulated inside the VPN tunnel for Syniti-driven operations.

This meant customer reviews typically focused on WireGuard ports, edge IP ranges, tunnel addresses, and VPN interface behavior.

Current Model

The current connector simplifies the external network profile:

• outbound HTTPS/WSS to the Syniti Gateway,

• outbound TCP from the connector to approved internal targets,

• and optional restricted local API access for support and operations.

There is no Syniti-facing UDP requirement in the current model.

Installation and Bootstrap Changes

Legacy Model

The legacy connector documentation focused on package installation plus a registration flow that ultimately produced and consumed WireGuard configuration.

Current Model

The current connector is installed as a standard service and configured directly with a connector key generated in SKP.

This shifts customer onboarding away from VPN configuration concepts and toward a simpler service installation and connector-based bootstrap flow.

Authentication Changes

Legacy Model

The legacy connector centered trust on the VPN peer model and control-plane configuration used to establish the WireGuard session.

Current Model

The current connector uses a SHA-256 hash derived from tenant-specific, time-bound connector secret material during WebSocket connection establishment. The secret itself is not sent directly over the wire.

Runtime Behavior Changes

Legacy Model

The legacy connector maintained a VPN-based communication path and then exposed the needed local services or proxies through that model.

Current Model

The current connector maintains outbound WebSocket connectivity to the Syniti Gateway and uses that connection to broker access to approved customer-side targets when needed.

This is a narrower, application-level tunneling model rather than a general VPN construct.

Architecture Summary

The main components are:

• Connector—customer-side service installed in the customer network

• Gateway—Syniti cloud-side service that accepts WebSocket connector sessions and TCP client traffic

• SKP Workloads—Syniti services that request tunneled access to customer-side systems

Security Model

Security is a fundamental consideration for all software written at Syniti and the SKP Connector is no exception. A core design principle of this system is that Syniti prioritizes confidentiality and integrity over availability when these tenets of the CIA triad come into conflict. If the system cannot operate securely, it must never revert to some less secure mode of operation to maintain availability; in such situations Syniti would expect to compromise availability to maintain confidentiality and integrity of the data and systems it can access.

Encrypted Communication

All cloud communication between the connector and Syniti is carried over TLS-protected HTTPS/WSS sessions. The connector establishes outbound secure WebSocket connections to the Syniti Gateway and keeps them alive with heartbeat traffic.

Certificate validation relies on the operating system and platform trust store behavior for the target wss:// endpoint. Customers should validate that this model is compatible with their own endpoint security, egress, proxy, and inspection requirements in the environment where the connector is installed.

Authentication

The connector authenticates each WebSocket connection attempt by using the connector credentials assigned during setup. Those credentials are stored locally on the connector host and should be treated as sensitive configuration.

The current protocol is a shared-secret, one-way connector authentication flow. For each WebSocket connection attempt, the connector sends:

• tenant_id

• connector_id

• timestamp

• hash = HMAC-SHA256(secret, tenant_id + "\n" + connector_id + "\n" + timestamp)

The secret itself is not sent over the wire. The Syniti Platform validates the request by recomputing the expected HMAC from the stored connector secret and comparing the result.

Replay protection is based on the timestamp included in the HMAC input. The Syniti Platform enforces a configurable timestamp validation window, with a default window of 5 minutes. This is not mutual authentication at the connector application layer; server authentication is provided by TLS certificate validation for the wss:// endpoint. Failed authentication attempts return an authentication error to the connector and are logged through Syniti Platform service logging and audit paths.

Traffic Scope

The connector does not expose a public listener to the internet for Syniti traffic. Instead, Syniti reuses the outbound connector-initiated WebSocket connection. The connector then creates outbound TCP connections only to customer-side targets needed for SKP use cases.

The connector opens TCP connections to the target address requested by the authenticated Gateway workflow. The effective traffic boundary is enforced primarily through customer-controlled network segmentation, firewall rules, and placement of the connector host. Customers should therefore allow only the exact internal hosts and ports required for the intended SKP use cases.

Customer Control Boundaries

Customers should continue to enforce network segmentation and allow-listing on the connector host. The connector should only be permitted to reach:

• Syniti Gateway endpoints over HTTPS/WSS.

• Internal databases, APIs, and services that are intentionally in scope for SKP.

Control Plane Trust

The connector provides application-level TCP tunneling for approved SKP connectivity scenarios. The Syniti Gateway can request tunnel establishment to a target address, and the connector responds by opening only the TCP connection needed for that request path.

The connector does not execute shell commands or arbitrary scripts received from Syniti. The main trust boundary is whether the authenticated Syniti control plane is permitted to request a TCP connection to a given customer-side target. If the customer allows the connector host to reach broad internal networks, the connector can be used to reach those destinations through its normal tunneling behavior, so connector placement and egress controls should be treated as the primary restriction on request scope.

Threat Scenarios

When deploying SKP Connector, there are several common threat scenarios that are typically considered. The following scenarios are common considerations when reviewing the security posture of the WebSocket-based SKP Connector.

Threat Scenario 1: An attacker attempts to intercept or spoof Syniti connectivity

The connector establishes outbound HTTPS/WSS connections to Syniti and authenticates with connector credentials assigned during setup.

Recommended mitigations include:

• Permit outbound connectivity only to approved Syniti endpoints.

• Inspect certificate and TLS policies according to customer security standards.

• Protect connector credentials and rotate them through the supported SKP rotation workflow.

Threat Scenario 2: An attacker gains access to the connector host or local configuration

The connector stores sensitive configuration locally, so host compromise could expose connector credentials or allow misuse of the installed service.

Recommended mitigations include:

• Restrict administrative access to the connector host.

• Apply strict filesystem permissions to the connector configuration.

• Use standard host hardening, patching, endpoint protection, and disk-protection controls.

Threat Scenario 3: The connector is allowed to reach more internal systems than intended

The connector can open outbound TCP connections to customer-side targets required by SKP workflows. If network controls are too broad, the connector host may have more reach than necessary.

Recommended mitigations include:

• Restrict outbound access from the connector host to approved internal systems and ports only.

• Segment connector deployments according to network boundaries when needed.

• Avoid exposing unnecessary services on the connector host.

• Review connector-related firewall rules regularly as SKP use cases change.

System Requirements

The exact sizing depends on workload volume, concurrency, and the number of scanned or queried systems. At minimum, the deployment should satisfy the following platform requirements.

Supported Operating Systems

The SKP Connector supports both Linux and Windows deployments.

Supported Linux distributions include:

• Amazon Linux 2023

• Red Hat Enterprise Linux

• SUSE Linux Enterprise Server

• Ubuntu

Windows deployments are also supported through the Windows installer package provided by Syniti.

Refer to SKP Connector Requirements and Installation for a list of supported versions.

Host Requirements

• A customer-managed physical or virtual server running a supported Linux distribution or Windows.

• Outbound network access to the Syniti Gateway over HTTPS/WSS.

• Outbound network access to in-scope internal data sources.

• Sufficient local permissions to install software and manage the connector service.

• Standard host hardening appropriate for a network-adjacent integration service.

Software Requirements

• For Linux: package manager access for the chosen distribution and systemd for service control.

• For Windows: ability to run the Syniti-provided Windows installer with administrative permissions.

• Ability to install the syniti-connector software package provided by Syniti.

Detailed Description of SKP Connector Communication

Installation Inputs

The WebSocket connector is configured by using the connector key generated during registration of a new SKP Connector in the SKP Connectors administration page in SKP.

The installation scripts use that generated key to populate the local connector configuration.

Installation Process

The installation process depends on the operating system used for the connector host.

Linux Installation

The simplest Linux installation path is to use the platform-specific install script provided with the Syniti Connector package.

Available scripts include:

• syniti_connector_install_al2023.sh

• syniti_connector_install_ubuntu.sh

• syniti_connector_install_rhel.sh

• syniti_connector_install_suse.sh

These scripts perform the following steps:

1. Add the Syniti package repository.

2. Install the syniti-connector package.

3. Stop the service during configuration.

4. Apply the generated connector key.

5. Update /etc/syniti-connector/config.yaml.

6. Enable and start the syniti-connector systemd service.

7. Optionally configure automatic package updates via a systemd timer.

Example for Ubuntu:

chmod +x syniti_connector_install_ubuntu.sh
sudo ./syniti_connector_install_ubuntu.sh \
  --key "<connector-key-generated-in-skp>"

Example with automatic updates enabled:

sudo ./syniti_connector_install_ubuntu.sh \
  --key "<connector-key-generated-in-skp>" \
  --enable-auto-update daily

Windows Installation

Windows deployments use the Syniti-provided Windows installer package.

The typical Windows installation flow is:

1. Obtain the Windows installer package from Syniti.

2. Run the installer with administrative permissions.

3. Provide the connector configuration values during setup or update the installed configuration as directed by Syniti.

4. Start or verify the syniti-connector Windows service.

For Windows environments, use the installer and service-management workflow provided with the Syniti package rather than the Linux package repository scripts.

Configuration

The connector reads its configuration from /etc/syniti-connector/config.yaml.

On Windows, the configuration file is stored in the connector installation directory.

Example:

connector:
  connector_id: "skc_def456"
  tenant_id: "tnt_abc123"
  gateway_url: "wss://ws-gateway.syniti.com/ws"
  secret: "super-secret-value"

settings:
  max_retries: 5
  retry_delay_seconds: 10
  heartbeat_interval_seconds: 30
  standby_websocket_check_seconds: 60
  max_standby_websocket_ttl_seconds: 300
  websocket_close_timeout_seconds: 3
  max_log_file_size_mb: 512
  max_backups_log_files: 14
  log_level: "info"

Configuration Notes

• connector.gateway_url must be the full WebSocket endpoint, typically wss://.../ws.

• connector.secret is sensitive and should be protected with strict filesystem permissions.

• settings.heartbeat_interval_seconds controls connector keep-alive traffic to the gateway.

Registration and Connection Lifecycle

Initial Setup

During initial deployment, the operator installs the package, receives the connector key from Syniti, and updates the local configuration.

Service Start

When the service starts:

1. It validates the YAML configuration.

2. It opens a WebSocket connection to the Gateway using the configured connector credentials.

3. It maintains at least one standby WebSocket session for future tunnel work.

4. It sends heartbeat traffic to keep the session alive.

Usage Phase

When SKP needs access to a customer-side service:

1. The Gateway selects an available connector WebSocket.

2. The Gateway requests a connection to the required target address.

3. The connector opens an outbound TCP connection to that target.

4. TCP traffic is exchanged through the secure WebSocket session.

5. When the work finishes, the stream is closed and the WebSocket can return to standby.

Data Handling

The connector is a transport component. It forwards TCP traffic between SKP workloads and customer-side targets over the established tunnel.

The connector does not perform database query execution itself; it forwards application traffic requested through the tunnel. Customer data and query results can traverse the tunnel when an SKP workflow uses the connector to access an in-scope target, but the connector is not intended to persist tunneled payloads as application data at rest. Operational logs and error paths may still contain connection metadata such as target addresses, timestamps, and failure details, so customers should not assume logs are data-free.

Protocols and Networking

The SKP Connector is designed to securely connect on-premises or private network environments to the Syniti Cloud without requiring exposure to the public internet. Its architecture emphasizes outbound-only connectivity, strong network isolation, and flexible deployment across segmented environments.

Network Architecture and Design Principles

The SKP Connector does not require a public IP address, enabling customers to isolate it from direct internet exposure. All communication is initiated outbound from the connector, relying on NAT to handle return traffic. This design eliminates the need for inbound internet-facing connections and significantly reduces the attack surface.

Customers can deploy multiple SKP Connectors across different regions or network segments. For example, organizations with multiple data centers may install a connector in each location rather than configuring cross-region routing.

Required Outbound Traffic

The connector host must be able to initiate:

• Outbound HTTPS/WSS traffic to the Syniti Gateway endpoint

• Outbound TCP traffic to approved internal targets such as databases and APIs

Common internal target examples include:

• Microsoft SQL Server on TCP 1433

• SAP HANA

• PostgreSQL

• Other customer-approved application or database ports required by SKP

Inbound Traffic

For Syniti connectivity, no inbound internet-facing traffic is required. The connector establishes the outbound session and the cloud side reuses that session.

Firewall Guidance

A typical firewall policy for the connector host is:

• Allow outbound TCP 443 to Syniti Gateway endpoints.

• Allow outbound TCP to the specific internal systems and ports required for SKP jobs.

• Deny all other outbound traffic from the connector host unless explicitly required.

• Deny all inbound traffic except tightly controlled administrative access if needed.

Typical enforcement granularity should be host and port based. The connector does not perform application-level authorization of database commands or result sets, so network policy remains the primary enforcement point.

Public IP Address Requirement

The connector does not require a public IP address. It only needs outbound connectivity to the internet through customer egress infrastructure such as NAT or a proxy path that permits WebSocket Secure traffic.

Local Service Operation

The installed service is named syniti-connector.

Typical Linux service commands are:

sudo systemctl enable syniti-connector
sudo systemctl start syniti-connector
sudo systemctl status syniti-connector
sudo journalctl -u syniti-connector -n 200

Typical Windows service management commands are:

sc.exe query syniti-connector
sc.exe start syniti-connector
sc.exe stop syniti-connector

By default, connector log files are written under /var/log/syniti-connector on Linux and under C:\ProgramData\Syniti Connector\logs on Windows. The effective log path may vary depending on installation choices and host configuration.

Connector log handling is file-based. Log rotation is controlled by maximum file size and maximum backup count. Customers that require centralized retention, SIEM ingestion, or additional log-governance controls should forward these files using their standard host logging tooling.

Associated Services and Host Placement

Syniti recommends placing the connector on a customer-managed host that is dedicated to this integration path or otherwise tightly controlled.

If customers choose to run additional services on the same host, they should evaluate OS user and service-account separation, filesystem permission boundaries, access to the connector configuration and log directories, and whether those co-located services are inside the same trust boundary. Co-locating unrelated services increases the local attack surface and the consequences of host compromise.

Verification After Installation

After installation, verify the following:

1. The configuration file contains the correct gateway URL, tenant ID, connector ID, and secret.

2. The syniti-connector service is running.

3. The connector can reach the Syniti Gateway over WSS.

4. The connector can reach the intended internal target systems over TCP.

Example checks:

sudo systemctl status syniti-connector

Secret Handling and Rotation

The connector secret is stored locally in the YAML configuration file and should be treated as a credential.

Recommended controls:

• Restrict file access to the service account and administrators only.

• Protect the host with standard disk, filesystem, and access hardening controls.

• Rotate connector secrets through the Syniti-managed rotation process.

• Update the local connector configuration promptly when a new connector key is issued.

On the connector host, the secret is stored in the local YAML configuration file and protected by filesystem permissions and host controls. Within the Syniti Platform, connector secrets are stored encrypted at rest by using AWS KMS-backed encryption.

From an operational perspective, customers should define a rotation policy appropriate to the environment. A 30- to 90-day rotation cadence is a common baseline for shared secrets, with immediate rotation on suspected exposure. Emergency revocation should be handled by rotating or replacing the connector secret in SKP and updating the connector host promptly. Customers should also avoid collecting the connector configuration file in unencrypted backups.

Generating a new connector key does not interrupt the currently active connector session. The existing key remains active, and the newly generated key remains on standby until the connector uses it for the first time.

When the connector reconnects with the standby key, the standby key becomes active automatically. This allows customers to prepare the new key on the connector host without immediately disrupting the existing connection.

To rotate the connector key:

1. In the SKP Connectors administration page in SKP, generate or obtain the new connector key for the connector you want to rotate.

2. Run the connector service with the --update-key argument and the newly generated key so the local configuration is updated

   Restart the connector service so it reconnects by using the updated credentials.

3. Verify in SKP and on the connector host that the connector has reconnected successfully.

Existing active sessions are not intended to be preserved indefinitely across rotation events. New connections authenticate by using the currently configured secret during connector reconnect or session establishment.

On both Linux and Windows, use the connector executable with the --update-key argument to update the stored key in the configuration file, then restart the syniti-connector service.

Operational Troubleshooting

Common troubleshooting areas for the WebSocket connector are:

• Invalid connector key format.

• Incorrect gateway_url value.

• Local firewall or proxy blocking outbound WSS traffic.

• Internal firewall blocking TCP access from the connector host to the target system.

• Secret mismatch after a connector rotation.

Useful checks:

sudo systemctl status syniti-connector
sudo journalctl -u syniti-connector -n 200

Failure Behavior

The connector is designed to stop establishing or maintaining tunnel connectivity when authentication or required network connectivity is not available.

If connector authentication fails, the WebSocket connection is rejected and the connector retries according to its retry configuration. If the Gateway or network path is unavailable, the connector cannot establish or maintain new tunnel sessions. If the connector restarts, it must re-establish its WebSocket sessions and authenticate again. If the local secret is changed, the updated value is used after the connector service is restarted with the revised configuration. If customer-side firewall policy blocks a requested target, the tunnel attempt fails at connection time. When a requested target connection cannot be established, the error is returned through the connector session and is surfaced as a failure to the operation that initiated the request.

Summary

The WebSocket-based SKP Connector is a package-installed service for Linux and Windows that:

• authenticates with a Syniti-issued connector key,

• maintains outbound secure WebSocket sessions to the Gateway,

• multiplexes TCP streams over those sessions, and

• connects only to customer-approved internal targets needed for SKP processing.

The required cloud connectivity is outbound HTTPS/WSS, plus outbound TCP to customer-managed target systems.