Security & Hardening Guide¶
This is the security, hardening, and operations reference for the Cloud Connector — how to deploy and run it safely on-site. It is written for the IT and information-security teams responsible for the Connector.
Document control
Version 1.0 · Last updated 2026-07-09 · Applies to Cloud Connector 0.3.x and later
Identity & Credentials¶
The Connector needs exactly one secret to operate:
| Item | Details |
|---|---|
| Cloud credential | A single OAuth2 client (client-credentials grant) — a client_id and client_secret issued by Unomed. This is the only credential an operator handles. It can be revoked or rotated by Unomed at any time. |
| Storage | Saved locally and readable only by the owning user account (mode 0600 on Linux/macOS; user-profile ACL on Windows), written atomically. The secret is never displayed after entry and never leaves the host except to authenticate to the Unomed cloud. |
| Access tokens | Short-lived tokens are cached locally in the same protected directory and refreshed automatically. |
| TLS material | A certificate and key are needed only if DICOM-over-TLS is enabled for the local network link. |
The Connector uses no passwords, shared secrets, or DICOM user identities. Access is authorized by the cloud credential (to the cloud) and by AE-title authorization (for on-site equipment).
Local Users & Privileges¶
- No dedicated operating-system user is created, and no administrator/root privileges are required.
- The Connector runs as an ordinary, unprivileged user. We recommend a dedicated, non-interactive service account on the host.
- It runs in the foreground or as a background service (managed with
start/stop/status), tracked by a local PID file. - It uses no database and requires no additional local accounts.
Privileged ports
Running as an unprivileged user is sufficient for standard DICOM ports (≥ 1024). Only if a privileged port (< 1024) is assigned would the host need to grant that specific capability.
Network¶
| Direction | Description |
|---|---|
| Outbound (to cloud) | A single authenticated, encrypted (TLS) connection to the Unomed cloud. No inbound ports need to be opened at the site firewall. |
| Inbound (local only) | Standard DICOM (DIMSE) on the assigned port, for on-site modalities and workstations. Optionally protected with DICOM-over-TLS. |
| Discovery | The Connector advertises itself over mDNS (_dicom._tcp) on the local network. This can be ignored or suppressed by network segmentation. |
Data Handling¶
- The Connector is a gateway, not an archive. Images and worklist data pass between on-site equipment and the cloud; instances are buffered transiently in memory during transfer and are not retained.
- An optional local backup path can be configured by the operator to keep a copy of forwarded studies. It is off unless explicitly set; if enabled, secure that location like any other store of patient data.
Logging & Audit¶
- The Connector writes an operational log file on the host, viewable with
dicom-router logs(-fto follow). - Entries record association and operation events — peer AE title, service, and outcome — as operational metadata only. Logs contain no pixel data and no patient images.
- To retain logs centrally or for audit, point a host log agent (syslog, or your SIEM's collector) at the log file. The Connector does not transmit logs to third parties.
Operations¶
| Task | Command |
|---|---|
| Start (foreground) | dicom-router start |
| Start (background service) | dicom-router start --daemon |
| Status | dicom-router status |
| Stop | dicom-router stop |
| View logs | dicom-router logs (-f to follow) |
Configuration — listen port, AE title, and TLS settings — is fetched from the cloud after authentication, so there is no local configuration file to protect beyond the credential store.
Updates & Patching¶
- The Connector checks for new releases and can update itself, so hosts receive security fixes promptly. Updates are distributed only through Unomed's official release channel; macOS builds are code-signed and notarized.
- Allow the Connector to apply updates, or apply them promptly if you manage the rollout centrally.
- Keep the host operating system patched — that remains the operator's responsibility.
Decommissioning¶
When retiring a host or modality:
- Stop the service (
dicom-router stop) and remove the Connector. - Delete the local credential store and token cache so no secret remains on the host.
- Ask Unomed to revoke the associated cloud credential (and any AE titles that are no longer needed).
- If a local backup path was enabled, securely erase its contents per your data-retention policy.
Because the Connector keeps no permanent local archive, no patient images remain on the host once any configured backup location is cleared.
Vulnerability Reporting¶
Report suspected security issues to info@unomed.ch. We ask that you practice coordinated disclosure — give us a reasonable window to release a fix before any public disclosure.
Hardening Checklist¶
- Run under a dedicated, non-login service account with least privilege.
- Restrict the DICOM port with host/network firewalling and segmentation so only known modalities can reach it.
- Enable DICOM-over-TLS for the local link where the network is not fully trusted.
- Keep the credential store restricted to the owning user account (
0600on Linux/macOS) and back it up securely; rotate or revoke the cloud credential via Unomed if a host is decommissioned or compromised. - Provision each modality's AE title in the cloud with only the permissions it needs (store, worklist query, MPPS).
- Keep the host OS patched and allow the Connector to apply updates.
- If a local backup path is enabled, protect it as patient data (access control, encryption at rest, retention policy).