Plate-forme NinjaOne Relay

Rubrique

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

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 génération de rapports et l'analyse des points de terminaison 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 de réseau
• Interface utilisateur (UI)
• Sécurité
• Flux de travail
• Durabilité des données
• Conformité
• Ressources complémentaires

Serveur NinjaOne Relay

Le serveur relais NinjaOne agrandit la couverture de NinjaOne aux points de terminaison 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, envoie ses rapports au relais. De là, les données sont soit transmises à 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 tous 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 obtenir 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 points de terminaison 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 points de terminaison mais ne peut pas communiquer en retour avec NinjaOne ni avec le relais connecté.

Mode C : Air-gap : entièrement autonome

Pour les enclaves ne disposant d’aucun chemin d’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 des supports scellés, un opérateur fait la navette entre deux relais appariés : le côté connecté regroupe les groupes, 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 et versions ultérieures, macOS 12 et versions ultérieures, ainsi que sous les versions modernes 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 de l’appareil tourné vers 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 : 

Statut : santédes nœuds de travail , profondeur des listes 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 groupes.

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 contient les caractéristiques 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 au niveau de l’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 par 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 facultative 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 point de terminaison et à l’échelle globale. Les adresses source IPv6 sont agrégées en /64 par défaut (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 ferme 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 les automatisations. 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 facultatif restreint les suites de chiffrement TLS et effectue la validation des types de clés pour les déploiements soumis à une réglementation. L’enveloppe du groupe 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 vers les cibles, suivi de l’état de l’installation par point de terminaison, affichage de la base de référence des correctifs installés dans l’inventaire. 
• Logiciels: installation/désinstallation/vérification à l’aide de commandes spécifiques à chaque plate-forme ; liste des logiciels intégrée à l’inventaire. 
• Analyse SCAP: gérer le contenu des analyses, les moteurs et les paramétrages ; déclencher les analyses ; importation des résultats ARF/XCCDF ; affichage des résultats par règle dans l’interface utilisateur. 
• Référentiels de conformité: groupes nommés de correctifs et de paquets requis, ainsi qu’un profil SCAP ; assigner aux points de terminaison ; une grille « terminal × référentiel » permet de voir d’un seul coup d’œil les statuts « conforme », « non conforme » et « inconnu ». 
• Transfert de groupes (Mode D) : côté producteur, l’ensemble des éléments ci-dessus est regroupé sous forme d’opérations de groupes 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 mis 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 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 points de terminaison 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 complémentaires

Pour plus d’informations sur NinjaOne Relay, consultez la documentation « NinjaOne Gestion des terminaux : exigences du système et compatibilité ».