Plate-forme NinjaOne Relay

Sujet

Cet article décrit NinjaOne Relay pour les environnements déconnectés et isolés physiquement.

Environnement

Plateforme NinjaOne

Description

NinjaOne Relay offre des fonctionnalités de gestion des terminaux pour les environnements totalement déconnectés et isolés physiquement. Relay permet un contrôle étendu pour la gestion de l’inventaire, l’application de correctifs, la création de rapports et l’analyse des terminaux qui, sans cela, ne seraient pas gérés. Cliquez sur les sections ci-dessous pour plus d’informations.

• Serveur NinjaOne Relay
• Modes de fonctionnement
• Écouteurs et surfaces réseau
• Interface utilisateur (UI)
• Sécurité
• Flux de travail
• Durabilité des données
• Conformité
• Ressources supplémentaires

Serveur NinjaOne Relay

Le serveur relais NinjaOne étend la couverture de NinjaOne aux terminaux qui ne peuvent pas se connecter directement à la plateforme SaaS de NinjaOne. NinjaOne Relay s'exécute en tant que service sur un hôte géré et fait office d'intermédiaire de confiance. Un petit agent spécifique à la plateforme, installé sur chaque terminal, transmet les données au relais. De là, les données sont soit envoyées à NinjaOne (mode A), soit conservées localement et affichées via l’interface utilisateur (UI) de l’opérateur dans les modes B, C ou D. Plusieurs relais peuvent partager une seule autorité de certification via une configuration de confiance entre pairs, ce qui permet aux déploiements de grande envergure ou redondants de répartir les agents sur plusieurs relais qui se font mutuellement confiance.

Modes de fonctionnement

La clé de configuration `operating_mode`, définie lors de l’installation, détermine quels sous-systèmes démarrent et quelles surfaces réseau s’ouvrent. Chaque mode utilise le même transport mTLS de l’agent. Ce qui change d’un mode à l’autre, c’est ce qui circule au-dessus de cette couche, et dans quelle direction. Reportez-vous au tableau suivant pour plus de détails sur les modes de fonctionnement. Cliquez sur le nom d’un mode pour plus d’informations.

Mode A : en pont

Pour les clients dont l’hôte de relais peut accéder à NinjaOne et qui préfèrent piloter leurs terminaux depuis la plateforme NinjaOne qu’ils utilisent déjà. L’accès à l’API NinjaOne n’est nécessaire qu’au moment de l’installation, mais vous pouvez révoquer les autorisations par la suite ; le relais continue alors de se synchroniser à partir de ses mappages de rôles mis en cache.

Mode B : Unidirectionnel : paire protégée par une diode

Pour les environnements qui ont besoin que NinjaOne transmette des fichiers et des tâches au-delà d’une frontière de confiance sans qu’aucune donnée ne revienne. NinjaOne associe deux relais via une diode de données matérielle (Guard) ; le relais isolé communique avec ses terminaux mais ne peut pas communiquer en retour avec NinjaOne ni avec le relais connecté.

Mode C : Air-gap : entièrement autonome

Pour les enclaves n’ayant absolument aucun accès à NinjaOne. Le relais constitue l’intégralité de la surface de gestion, pilotée via l’interface utilisateur locale. 

Mode D : paire « Sneakernet » : connecté ↔ air-gap ↔ isolé

Pour un véritable air-gap physique, relié par un support scellé, un opérateur fait la navette entre deux relais appariés : le côté connecté regroupe les paquets, le côté isolé les retransmet, puis renvoie les résultats de la même manière.

Écouteurs et interfaces réseau

Le relais NinjaOne fonctionne sous Windows Server 2019 ou version ultérieure, macOS 12 ou version ultérieure et les versions récentes de Linux, avec une variante FIPS disponible pour les déploiements soumis à une réglementation. Il expose jusqu’à trois écouteurs TLS entrants, selon le mode. Les agents accèdent toujours au relais sur le port 8443 ; les deux autres sont conditionnés par le mode. La seule connexion sortante établie par un relais est une connexion HTTPS vers l’API NinjaOne, et uniquement à partir du relais qui fait face à NinjaOne (mode A), ainsi que du côté connecté des paires en mode B et mode D. Le relais en isolation physique (mode C) et les relais isolés n’établissent aucune connexion sortante. Le tableau suivant décrit chaque option d’écoute.

Interface utilisateur (UI)

Les modes B, C et D disposent d’une console opérateur aboutie intégrée directement dans le binaire du relais. Il existe cinq espaces de travail de premier niveau : 

État : santédes nœuds de travail , profondeur des files d’attente, vérification de la chaîne d’audit.

Inventaire : historique du matériel, des logiciels et du réseau par point de terminaison.

Bibliothèque : paquets , correctifs, contenu SCAP, référentiels de conformité, fichiers préparés et paquets.

Configuration: utilisateurs et rôles, authentificateurs, TLS et infrastructure PKI externe.

Ciblage : sélectionnez un ensemble de cibles et une action, puis observez la grille des tâches en temps réel.

Sécurité

NinjaOne Relay intègre les fonctionnalités de sécurité suivantes :

Transport et identité

TLS réciproque entre chaque agent et le Relay, à l’aide d’une autorité de certification ECDSA P-256 intégrée générée au premier démarrage. Chaque agent reçoit un certificat client valable 90 jours via un jeton d’inscription à usage unique. Les certificats sont renouvelés automatiquement 30 jours avant leur expiration. NinjaOne Relay prend en charge la révocation via CRL et un répondeur OCSP conforme à la norme RFC 6960 avec intégration AIA. Les agents enregistrent l’empreinte digitale de l’autorité de certification du Relay lors de la première inscription (TOFU) et rejettent toute divergence ultérieure avec cette autorité de certification.

Authentification de l’opérateur

L’interface utilisateur de l’opérateur prend en charge les comptes locaux avec stockage des mots de passe via Argon2id, ainsi que l’authentification multifactorielle (MFA) TOTP avec une procédure de récupération à trois niveaux (codes propres à chaque utilisateur, réinitialisation par l’administrateur nécessitant la cosignature de deux administrateurs, et une clé d’urgence générée lors de l’installation). L’authentification CAC/PIV en option valide la chaîne de certificats complète par rapport à des ancrages de confiance importés par l’opérateur, avec révocation OCSP et CRL en temps réel (échec définitif par défaut ; échec temporaire et remplacement par un répondeur OCSP interne disponibles pour les environnements en isolation physique).

Défense en profondeur

Listes d’autorisation/de refus d’adresses IP, filtrage par pays via GeoIP et limitation de débit par « token bucket » par terminal et à l’échelle globale. Les adresses source IPv6 sont agrégées par défaut en blocs de /64 (limite d’hôte RFC 4291), de sorte qu’un pair hostile disposant d’un préfixe routé ne peut pas épuiser le plafond du « token bucket » par clé. L’en-tête X-Forwarded-For n’est pris en compte que lorsque le pair figure sur la liste des proxys de confiance. Les données d’inventaire fournies par l’agent sont soumises à un échappement HTML avant d’être affichées dans les champs WYSIWYG de NinjaOne, ce qui élimine la surface d’attaque XSS stockée.

Audit inviolable

NinjaOne Relay enregistre chaque inscription, émission de certificat, révocation, envoi de tâche, modification de configuration et action administrative dans un journal d’audit basé sur SQLite avec une chaîne de hachage parallèle ( SHA-256(canonical(row) ‖ prev_hash) ). Un point de terminaison de vérification parcourt la chaîne et met en évidence la première rupture, ce qui convient à l’analyse forensic en cas d’incident et à l’attestation inter-relais en mode D.

Identifiants au repos

NinjaOne Relay stocke les jetons d’inscription sous forme de hachages SHA-256 ; la clé de l’API de commande et le jeton d’inscription font tous deux l’objet d’une rotation automatique selon un calendrier configurable. NinjaOne Relay stocke la clé dans un champ personnalisé sécurisé de type TEXT_ENCRYPTED, avec une autorisation d’accès en lecture seule (READ_ONLY) pour l’automatisation. Les secrets au niveau des colonnes (clés privées de paquets, secrets MFA) sont encapsulés à l’aide d’une clé de chiffrement générée lors de l’installation et stockés dans un fichier avec les permissions chmod 0600 à côté de la base de données. Tous les secrets sur le disque ont les permissions 0600 ; le service Linux s’exécute sous un utilisateur dédié dans le cadre du renforcement de la sécurité systemd.

Option FIPS 140-3

Un mode de compilation FIPS optionnel restreint les suites de chiffrement TLS et valide les types de clés pour les déploiements soumis à une réglementation. L’enveloppe du bundle prend en charge à la fois les suites Ed25519/X25519 (par défaut) et ECDSA-P256/ECDH-P256 (conformes à la norme FIPS) ; en mode FIPS, le hachage des mots de passe passe d’Argon2id à PBKDF2-HMAC-SHA512 avec 600 000 itérations.

Flux de travail

Au-delà de l’inventaire initial et des primitives de commande, les modes B, C et D ajoutent les workflows suivants pour les tâches quotidiennes des opérateurs qui nécessitaient auparavant des automatisations NinjaOne personnalisées : 

• Correctifs: importation de paquets de correctifs, déploiement sur les cibles, suivi de l’état d’installation par terminal, affichage de la base de référence des correctifs installés dans l’inventaire. 
• Progiciels: installation/désinstallation/vérification à l’aide de commandes spécifiques à chaque plateforme ; liste des progiciels intégrée à l’inventaire. 
• Analyse SCAP: gestion du contenu des analyses, des moteurs et des paramétrages ; déclenchement des analyses ; importation des résultats ARF/XCCDF ; affichage des résultats par règle dans l’interface utilisateur. 
• Référentiels de conformité: ensembles nommés de correctifs et de paquets requis, ainsi qu’un profil SCAP ; attribution aux terminaux ; une grille « terminal × référentiel » permet de voir d’un seul coup d’œil les statuts « conforme », « non conforme » ou « inconnu ». 
• Transport de paquets (Mode D) : côté producteur, l’ensemble des éléments ci-dessus est regroupé sous forme d’opérations de paquets signées ; côté consommateur, celles-ci sont reproduites.

Durabilité des données

Protection contre les pannes par défaut. Tous les états faisant autorité sont conservés dans une base de données SQLite en mode WAL avec des validations synchrones et des autorisations 0600, y compris les certificats émis, les enregistrements de terminaux, les instantanés d’inventaire, le journal d’audit, les jetons d’inscription, les fichiers en attente, le cache de rôles NinjaOne, les files d’attente de paquets, les comptes utilisateurs et les sessions, les résultats SCAP et les référentiels de conformité. Un redémarrage soudain de l’hôte entraîne au pire la perte de ce qui était en cours de validation ; SQLite annule ces modifications à la réouverture. Aucune procédure d’arrêt particulière n’est requise. L’état en mémoire est éphémère et peut être perdu sans risque au redémarrage, et des tâches de nettoyage périodiques (rétention, élagage des instantanés, expiration des jetons et des fichiers) s’exécutent automatiquement sans intervention de l’opérateur.

Conformité

Trois documents de conformité sont fournis avec le produit : une attestation STIG relative à la sécurité et au développement des applications (ASD), une matrice de contrôles conforme à la norme NIST SP 800-53 (rév. 5) et un guide de renforcement de la sécurité à l’intention des opérateurs. Le journal d’audit est conservé pendant 90 jours par défaut et peut être exporté. NinjaOne Relay ne conserve aucune donnée client au-delà de l’inventaire des terminaux et de l’historique des tâches ; toutes ces données restent sur l’infrastructure du client, sauf si elles sont explicitement synchronisées avec NinjaOne (Mode A).

Ressources supplémentaires

Pour plus d’informations sur NinjaOne Relay, consultez la documentation « NinjaOne Endpoint Management : Configuration système requise et compatibilité ».