NinjaOne Relay

Thema

Dieser Artikel beschreibt NinjaOne Relay für nicht vernetzte und isolierte Umgebungen.

Umgebung

NinjaOne-Plattform

Beschreibung

NinjaOne Relay bietet Endpunktverwaltungsfunktionen für vollständig isolierte und Air-Gapped-Umgebungen. Relay ermöglicht eine erweiterte Kontrolle über Bestandsverwaltung, Patching, Berichterstellung und das Scannen von Endpunkten, die andernfalls nicht verwaltet würden. Klicken Sie auf die folgenden Abschnitte, um weitere Informationen zu erhalten.

• NinjaOne Relay-Server
• Betriebsmodi
• Listener und Netzwerkschnittstellen
• Benutzeroberfläche (UI)
• Sicherheit
• Workflows
• Datendauerhaftigkeit
• Compliance
• Weitere Ressourcen

NinjaOne Relay-Server

Der NinjaOne-Relay-Server erweitert die NinjaOne-Abdeckung auf Endpunkte, die keine direkte Verbindung zur SaaS-Plattform von NinjaOne herstellen können. NinjaOne Relay läuft als Dienst auf einem verwalteten Host und fungiert als vertrauenswürdiger Vermittler. Ein kleiner plattformspezifischer Agent auf jedem Endpunkt meldet sich beim Relay. Von dort aus werden die Daten entweder an NinjaOne gesendet (Modus A) oder bleiben lokal und werden über die Benutzeroberfläche (UI) des Operators in den Modi B, C oder D angezeigt. Mehrere Relays können sich über eine Peer-Trust-Konfiguration eine einzige Zertifizierungsstelle teilen, wodurch größere oder redundante Bereitstellungen Agenten auf mehrere Relays verteilen können, die sich alle gegenseitig vertrauen.

Betriebsmodi

Der bei der Installation festgelegte Konfigurationsschlüssel „operating_mode“ bestimmt, welche Subsysteme gestartet werden und welche Netzwerkflächen geöffnet werden. Jeder Modus nutzt denselben mTLS-Transport des Agenten. Was sich zwischen den Modi unterscheidet, ist, was oberhalb dieser Schicht fließt und in welche Richtung. Einzelheiten zu den Betriebsmodi entnehmen Sie bitte der folgenden Tabelle. Klicken Sie auf den Modusnamen, um weitere Details zu erhalten.

Modus A: Überbrückt

Für Kunden, deren Relay-Host NinjaOne erreichen kann und die es vorziehen, Endpunkte über die bereits von ihnen genutzte NinjaOne-Plattform zu steuern. Der Zugriff auf die NinjaOne-API ist nur bei der Installation erforderlich, Sie können die Berechtigungen jedoch anschließend widerrufen; das Relay synchronisiert sich weiterhin anhand seiner zwischengespeicherten Rollenzuordnungen.

Modus B: Einweg: diodengeschütztes Paar

Für Umgebungen, in denen NinjaOne Dateien und Aufträge über eine Vertrauensgrenze hinweg übertragen muss, ohne dass Daten zurückgesendet werden. NinjaOne koppelt zwei Relais über eine Hardware-Datendiode (Guard); das isolierte Relais kommuniziert mit seinen Endpunkten, kann jedoch weder zu NinjaOne noch zum verbundenen Relais zurückkommunizieren.

Modus C: Air-Gap: vollständig eigenständig

Für Enklaven, die überhaupt keinen Zugang zu NinjaOne haben. Das Relay bildet die gesamte Verwaltungsoberfläche und wird über die lokale Benutzeroberfläche gesteuert. 

Modus D: „Sneakernet“-Paar: verbunden ↔ Air-Gap ↔ isoliert

Für eine echte physische Luftlücke, die durch versiegelte Datenträger überbrückt wird, transportiert ein Bediener Daten zwischen zwei gekoppelten Relais: Die verbundene Seite bündelt die Datenpakete, die isolierte Seite gibt sie wieder und sendet die Ergebnisse auf demselben Weg zurück.

Listener und Netzwerkschnittstellen

Das NinjaOne-Relay läuft unter Windows Server 2019+, macOS 12+ und modernen Linux-Distributionen; für regulierte Bereitstellungen ist eine FIPS-Variante verfügbar. Je nach Modus stellt es bis zu drei eingehende TLS-Listener bereit. Agenten erreichen das Relay immer über Port 8443; die beiden anderen sind modusspezifisch. Die einzige ausgehende Verbindung, die ein Relay herstellt, ist eine HTTPS-Verbindung zur NinjaOne-API, und zwar ausschließlich von dem Relay aus, das mit NinjaOne verbunden ist (Modus A), sowie von der verbundenen Seite der Paare in Modus B und Modus D. Das Air-Gapped-Relay (Modus C) und die isolierten Relays stellen überhaupt keine ausgehenden Verbindungen her. Die folgende Tabelle beschreibt die einzelnen Listening-Optionen.

Benutzeroberfläche (UI)

Die Modi B, C und D verfügen über eine ausgefeilte Bedienerkonsole, die direkt in die Relay-Binärdatei eingebettet ist. Es gibt fünf Arbeitsbereiche auf oberster Ebene: 

Status: Zustandder Worker , Warteschlangentiefen, Überprüfung der Audit-Kette.

Bestand: Hardware-, Software- und Netzwerkverlauf pro Endpunkt.

Bibliothek: Pakete , Patches, SCAP-Inhalte, Compliance-Baselines, bereitgestellte Dateien und Bundles.

Konfiguration: Benutzer und Rollen, Authentifizierer, TLS und externe PKI.

Zielauswahl: Wählen Sie eine Zielgruppe und eine Aktionaus und verfolgen Sie anschließend die Ausführung in der Live-Auftragsübersicht.

Sicherheit

NinjaOne Relay verfügt über die folgenden Sicherheitsfunktionen:

Transport und Identität

Gegenseitiges TLS zwischen jedem Agenten und dem Relay unter Verwendung einer integrierten ECDSA-P-256-Zertifizierungsstelle, die beim ersten Start generiert wird. Jeder Agent erhält über ein einmaliges Registrierungstoken ein 90-Tage-Client-Zertifikat. Die Zertifikate werden 30 Tage vor Ablauf automatisch erneuert. NinjaOne Relay unterstützt die Sperrung über CRL und einen RFC 6960-OCSP-Responder mit AIA-Einbettung. Die Agenten speichern den Fingerabdruck der Relay-Zertifizierungsstelle bei der ersten Registrierung (TOFU) und lehnen alle nachfolgenden Nichtübereinstimmungen der Zertifizierungsstelle ab.

Authentifizierung des Betreibers

Die Benutzeroberfläche für Betreiber unterstützt lokale Konten mit Passwortspeicherung nach Argon2id sowie TOTP-MFA mit dreistufiger Wiederherstellung (benutzerspezifische Codes, Zurücksetzen durch den Administrator mit Mitunterzeichnung durch zwei Administratoren und ein bei der Installation generierter Notfallschlüssel). Die optionale CAC/PIV-Authentifizierung validiert die gesamte Zertifikatskette anhand vom Betreiber importierter Vertrauensanker mit Echtzeit-OCSP- und CRL-Sperrung (standardmäßig „Hard-Fail“; „Soft-Fail“ und Überschreibung durch einen internen OCSP-Responder sind für Air-Gap-Umgebungen verfügbar).

Mehrschichtige Verteidigung

IP-Zulassungs-/Sperrlisten, GeoIP-Länderfilterung und Token-Bucket-Ratenbegrenzung pro Endpunkt und global. IPv6-Quelladressen werden standardmäßig zu /64 aggregiert (RFC 4291-Hostgrenze), sodass ein böswilliger Peer mit einem gerouteten Präfix die Bucket-Obergrenze pro Schlüssel nicht ausschöpfen kann. „X-Forwarded-For“ wird nur berücksichtigt, wenn der Peer auf der Liste der vertrauenswürdigen Proxys steht. Von Agenten bereitgestellte Bestandsdaten werden HTML-escaped, bevor sie in NinjaOne-WYSIWYG-Felder gerendert werden, wodurch die Anfälligkeit für „Stored-XSS“ geschlossen wird.

Manipulationssichere Protokollierung

NinjaOne Relay protokolliert jede Registrierung, Zertifikatsausstellung, Sperrung, Auftragsvergabe, Konfigurationsänderung und administrative Maßnahme in einem SQLite-gestützten Audit-Protokoll mit einer parallelen Hash-Kette (SHA-256(canonical(row) ‖ prev_hash)). Ein Verifizierungsendpunkt durchläuft die Kette und deckt die erste Unterbrechung auf, was sich für die forensische Untersuchung bei Vorfällen und die relaisübergreifende Attestierung im Modus D eignet.

Speicherung von Anmeldedaten

NinjaOne Relay speichert Registrierungstoken als SHA-256-Hashes, und sowohl der Command-API-Schlüssel als auch das Registrierungstoken werden nach einem konfigurierbaren Zeitplan automatisch rotiert. NinjaOne Relay speichert den Schlüssel in einem sicheren benutzerdefinierten Feld vom Typ „TEXT_ENCRYPTED“ mit der Automatisierungsberechtigung „READ_ONLY“. Geheimnisse auf Spaltenebene (private Schlüsselbündel, MFA-Geheimnisse) werden mit einem bei der Installation generierten Schlüsselverschlüsselungsschlüssel umhüllt und zusammen mit einer Datei mit der Berechtigung „chmod 0600“ neben der Datenbank gespeichert. Alle Geheimnisse auf der Festplatte haben die Berechtigung 0600; der Linux-Dienst läuft als dedizierter Benutzer unter systemd-Hardening.

FIPS 140-3-Option

Ein optionaler FIPS-Build-Modus schränkt TLS-Verschlüsselungssuiten ein und validiert Schlüsseltypen für regulierte Bereitstellungen. Der Bundle-Envelope unterstützt sowohl Ed25519/X25519 (Standard) als auch ECDSA-P256/ECDH-P256 (FIPS-konform) Suiten; im FIPS-Modus wird beim Passwort-Hashing von Argon2id auf PBKDF2-HMAC-SHA512 mit 600.000 Iterationen zurückgegriffen.

Workflows

Über die ursprünglichen Inventarisierungs- und Befehlsprimitive hinaus fügen die Modi B, C und D die folgenden Workflows für alltägliche Aufgaben des Betreibers hinzu, für die zuvor benutzerdefinierte NinjaOne-Automatisierungen erforderlich waren: 

• Patches: Patch-Pakete importieren, auf Zielsysteme bereitstellen, den Installationsstatus pro Endpunkt verfolgen, die Baseline der installierten Patches im Bestand anzeigen. 
• Softwarepakete: Installation/Deinstallation/Überprüfung mit plattformspezifischen Befehlen; Paketliste als Bestandsübersicht. 
• SCAP-Scans: Verwaltung von Scan-Inhalten, Engines und Anpassungen; Auslösen von Scans; Einlesen von ARF-/XCCDF-Ergebnissen; Anzeige der Befunde pro Regel in der Benutzeroberfläche. 
• Compliance-Baselines: benannte Bündel aus erforderlichen Patches und Paketen sowie ein SCAP-Profil; Zuweisung zu Endpunkten; eine Endpunkt-×-Baseline-Übersicht zeigt auf einen Blick „konform“, „nicht konform“ und „unbekannt“ an. 
• Bündelübertragung (Modus D): Die Erstellerseite verpackt alle oben genannten Elemente als signierte Bündeloperationen; die Empfängerseite führt diese wieder aus.

Datendauerhaftigkeit

Standardmäßig absturzsicher. Alle maßgeblichen Zustände werden in einer SQLite-Datenbank im WAL-Modus mit synchronen Commits und 0600-Berechtigungen persistent gespeichert, darunter ausgestellte Zertifikate, Endpunktdatensätze, Bestands-Snapshots, das Audit-Protokoll, Registrierungstoken, zwischengespeicherte Dateien, der NinjaOne-Rollen-Cache, Bundle-Warteschlangen, Benutzerkonten und -sitzungen, SCAP-Ergebnisse sowie Compliance-Baselines. Bei einem plötzlichen Neustart des Hosts gehen höchstens die Daten verloren, die sich gerade im Commit-Prozess befanden; SQLite führt beim erneuten Öffnen ein Rollback durch. Es ist kein spezielles Herunterfahren erforderlich. Der In-Memory-Zustand ist kurzlebig und kann beim Neustart bedenkenlos verloren gehen; regelmäßige Bereinigungsaufträge (Aufbewahrungsfristen, Bereinigung von Momentaufnahmen, Ablauf von Token und Dateien) werden automatisch ohne Eingreifen eines Bedieners ausgeführt.

Compliance

Im Lieferumfang des Produkts sind drei Compliance-Dokumente enthalten: eine ASD-STIG-Bescheinigung (Application Security and Development), eine Kontrollmatrix gemäß NIST SP 800-53 (Rev. 5) sowie ein Leitfaden zur Absicherung durch den Betreiber. Das Audit-Protokoll wird standardmäßig 90 Tage lang aufbewahrt und kann exportiert werden. NinjaOne Relay speichert keine Kundendaten außer dem Endpunktbestand und dem Auftragsverlauf; alle Daten verbleiben in der Infrastruktur des Kunden, sofern sie nicht ausdrücklich mit NinjaOne synchronisiert werden (Modus A).

Weitere Ressourcen

Weitere Informationen zu NinjaOne Relay finden Sie unter „NinjaOne Endpoint Management: Systemanforderungen und Kompatibilität“.