Piattaforma NinjaOne Relay

Argomento

Questo articolo descrive NinjaOne Relay per ambienti disconnessi e isolati.

Ambiente

Piattaforma NinjaOne

Descrizione

NinjaOne Relay offre funzionalità di gestione degli endpoint per ambienti completamente disconnessi e isolati (air-gapped). Relay consente un controllo esteso per la gestione dell’inventario, l’applicazione delle patch, la generazione di report e la scansione di endpoint che altrimenti rimarrebbero non gestiti. Clicca sulle sezioni sottostanti per ulteriori informazioni.

• Server NinjaOne Relay
• Modalità operative
• Listener e superfici di rete
• Interfaccia utente (UI)
• Sicurezza
• Flussi di lavoro
• Durabilità dei dati
• Conformità
• Risorse aggiuntive

NinjaOne Relay Server

Il server NinjaOne Relay estende la copertura di NinjaOne agli endpoint che non possono connettersi direttamente alla piattaforma SaaS di NinjaOne. NinjaOne Relay viene eseguito come servizio su un host gestito e funge da intermediario affidabile. Un piccolo agente specifico per la piattaforma su ciascun endpoint invia i dati al relay. Da lì, i dati vengono inviati a NinjaOne (Modalità A) oppure rimangono in locale e vengono visualizzati tramite l’interfaccia utente (UI) dell’operatore nelle Modalità B, C o D. Più relay possono condividere un’unica Autorità di Certificazione tramite una configurazione peer-trust, consentendo a implementazioni più grandi o ridondanti di distribuire gli agenti su diversi relay che si fidano l’uno dell’altro.

Modalità operative

La chiave di configurazione `operating_mode`, impostata al momento dell’installazione, determina quali sottosistemi vengono avviati e quali superfici di rete vengono aperte. Ogni modalità utilizza lo stesso trasporto mTLS dell’agente. Ciò che cambia tra una modalità e l’altra è ciò che fluisce al di sopra di quel livello e in quale direzione. Fare riferimento alla tabella seguente per i dettagli sulle modalità operative. Fare clic sul nome della modalità per ulteriori dettagli.

Modalità A: collegato in ponte

Per i clienti il cui host di relay può raggiungere NinjaOne e che preferiscono gestire gli endpoint dalla piattaforma NinjaOne che già utilizzano. L'accesso all'API di NinjaOne è necessario solo al momento dell'installazione, ma è possibile revocare le autorizzazioni in seguito, e il relay continua a sincronizzarsi dalle mappature dei ruoli memorizzate nella cache.

Modalità B: Unidirezionale: coppia protetta da diodo

Per ambienti in cui NinjaOne deve inviare file e attività oltre un confine di fiducia senza ricevere alcun riscontro. NinjaOne accoppia due relay tramite un diodo dati hardware (Guard); il relay isolato comunica con i propri endpoint ma non può ricontattare NinjaOne né il relay collegato.

Modalità C: Air-gap: completamente autonomo

Per enclave prive di qualsiasi percorso di comunicazione con NinjaOne. Il relay costituisce l’intera superficie di gestione, gestita tramite l’interfaccia utente locale. 

Modalità D: Coppia "Sneakernet": connesso ↔ air-gap ↔ isolato

Per un vero air-gap fisico, collegato tramite supporti sigillati, un operatore trasporta i dati tra due relay accoppiati: il lato connesso impacchetta i bundle, il lato isolato li riproduce e restituisce i risultati nello stesso modo.

Listener e interfacce di rete

Il relè NinjaOne funziona su Windows Server 2019+, macOS 12+ e Linux moderni, con una variante FIPS disponibile per le implementazioni soggette a normative. Espone fino a tre listener TLS in entrata, a seconda della modalità. Gli agenti raggiungono sempre il relè sulla porta 8443; gli altri due dipendono dalla modalità. L’unica connessione in uscita che un relay effettua è HTTPS verso l’API NinjaOne, e solo dal relay che si affaccia su NinjaOne (Modalità A), oltre che dal lato connesso delle coppie in Modalità B e Modalità D. Il relay in air-gap (Modalità C) e i relay isolati non effettuano alcuna connessione in uscita. La tabella seguente descrive ciascuna opzione di ascolto.

Interfaccia utente (UI)

Le modalità B, C e D dispongono di una console operatore ottimizzata integrata direttamente nel binario del relay. Sono presenti cinque aree di lavoro di primo livello: 

Stato: integritàdei worker , profondità delle code, verifica della catena di audit.

Inventario: cronologia hardware, software e di rete per ogni endpoint.

Libreria: pacchetti , patch, contenuti SCAP, linee guida di conformità, file in fase di preparazione e bundle.

Configurazione: utenti e ruoli, autenticatori, TLS e PKI esterna.

Destinazione: Scegli un insieme di destinazioni e un’azione, quindi osserva la griglia dei lavori in tempo reale.

Sicurezza

NinjaOne Relay include le seguenti funzionalità di sicurezza:

Trasporto e identità

TLS reciproco tra ogni agente e il Relay, utilizzando un'autorità di certificazione ECDSA P-256 integrata generata al primo avvio. Ogni agente riceve un certificato client valido 90 giorni tramite un token di registrazione monouso. I certificati si rinnovano automaticamente 30 giorni prima della scadenza. NinjaOne Relay supporta la revoca tramite CRL e un responder OCSP RFC 6960 con AIA incorporato. Gli agenti memorizzano l’impronta digitale della CA di Relay durante la prima registrazione (TOFU) e rifiutano qualsiasi successiva discrepanza relativa alla CA.

Autenticazione dell’operatore

L’interfaccia utente dell’operatore supporta account locali con archiviazione delle password tramite Argon2id, autenticazione multifattoriale (MFA) TOTP con recupero a tre livelli (codici per utente, reimpostazione da parte dell’amministratore con firma congiunta di due amministratori e una chiave di emergenza generata al momento dell’installazione). L’autenticazione CAC/PIV opzionale convalida l’intera catena di certificati rispetto agli anchor di fiducia importati dall’operatore con revoca OCSP e CRL in tempo reale (hard-fail per impostazione predefinita; soft-fail e override del responder OCSP interno disponibili per l’air-gap).

Difesa a più livelli

Elenchi IP di autorizzazione/rifiuto, filtraggio per paese tramite GeoIP e limitazione della frequenza tramite token bucket per endpoint e a livello globale. Gli indirizzi IPv6 di origine sono aggregati a /64 per impostazione predefinita (limite host RFC 4291), in modo che un peer ostile con un prefisso instradato non possa esaurire il limite del bucket per chiave. L’intestazione X-Forwarded-For viene presa in considerazione solo quando il peer è presente nell’elenco dei proxy fidati. I dati di inventario forniti dall’agente vengono sottoposti a escape HTML prima di essere visualizzati nei campi WYSIWYG di NinjaOne, il che elimina la vulnerabilità XSS memorizzata.

Audit a prova di manomissione

NinjaOne Relay registra ogni registrazione, emissione di certificati, revoca, invio di attività, modifica di configurazione e azione amministrativa in un registro di audit basato su SQLite con una catena di hash parallela ( SHA-256(canonical(row) ‖ prev_hash) ). Un endpoint di verifica percorre la catena e individua la prima interruzione, il che è utile per le analisi forensi in caso di incidenti e per l’attestazione tra relay in Modalità D.

Credenziali inattive

NinjaOne Relay memorizza i token di registrazione come hash SHA-256, e sia la chiave dell’API di comando che il token di registrazione vengono aggiornati automaticamente secondo una pianificazione configurabile. NinjaOne Relay memorizza la chiave in un campo personalizzato sicuro TEXT_ENCRYPTED con autorizzazione di sola lettura (READ_ONLY) per l’automazione. I segreti a livello di colonna (chiavi private dei bundle, segreti MFA) sono protetti da una chiave di crittografia generata al momento dell’installazione e archiviati in un file con permessi chmod 0600 accanto al database. Tutti i segreti su disco hanno permessi 0600; il servizio Linux viene eseguito come utente dedicato con rafforzamento della sicurezza tramite systemd.

Opzione FIPS 140-3

Una modalità di compilazione FIPS opzionale limita le suite di cifratura TLS e convalida i tipi di chiave per le implementazioni soggette a normative. L’involucro del bundle supporta sia le suite Ed25519/X25519 (predefinite) che ECDSA-P256/ECDH-P256 (conforme a FIPS); in modalità FIPS, l’hash delle password passa da Argon2id a PBKDF2-HMAC-SHA512 con 600.000 iterazioni.

Flussi di lavoro

Oltre alle primitive originali di inventario e comando, le modalità B, C e D aggiungono i seguenti flussi di lavoro per le attività quotidiane degli operatori che in precedenza richiedevano automazioni personalizzate di NinjaOne: 

• Patch: importazione dei pacchetti di patch, distribuzione alle destinazioni, monitoraggio dello stato di installazione per singolo endpoint, visualizzazione della baseline delle patch installate nell’inventario. 
• Pacchetti software: installazione/disinstallazione/verifica con comandi specifici per piattaforma; elenco dei pacchetti come inventario. 
• Scansione SCAP: gestione dei contenuti di scansione, dei motori e delle personalizzazioni; avvio delle scansioni; acquisizione dei risultati ARF/XCCDF; risultati per regola visualizzati nell’interfaccia utente. 
• Linee di base di conformità: pacchetti denominati contenenti patch e pacchetti obbligatori, oltre a un profilo SCAP; assegnazione agli endpoint; una griglia endpoint × linea di base mostra a colpo d’occhio lo stato di conformità/non conformità/sconosciuto. 
• Trasporto dei pacchetti (Modalità D): il lato produttore raggruppa tutto quanto sopra in operazioni di pacchetti firmati; il lato consumatore le riproduce.

Durabilità dei dati

A prova di crash per impostazione predefinita. Tutti gli stati autorevoli persistono in un database SQLite in modalità WAL con commit sincroni e permessi 0600, inclusi certificati emessi, record degli endpoint, istantanee dell’inventario, il log di audit, i token di registrazione, i file in fase di elaborazione, la cache dei ruoli di NinjaOne, le code dei pacchetti, gli account utente e le sessioni, i risultati SCAP e le linee guida di conformità. Un riavvio improvviso dell’host comporta al massimo la perdita di ciò che era in fase di commit; SQLite esegue il rollback al momento della riapertura. Non è richiesta alcuna procedura speciale di spegnimento. Lo stato in memoria è effimero e la sua perdita al riavvio è sicura, mentre i processi di pulizia periodici (conservazione, potatura delle istantanee, scadenza di token e file) vengono eseguiti automaticamente senza l’intervento dell’operatore.

Conformità

Il prodotto viene fornito con tre documenti relativi alla conformità: un’attestazione STIG (Security Technical Implementation Guide) per la sicurezza e lo sviluppo delle applicazioni (ASD), una matrice dei controlli NIST SP 800-53 (rev. 5) e una guida al rafforzamento della sicurezza per gli operatori. Il registro di audit viene conservato per 90 giorni per impostazione predefinita ed è esportabile. NinjaOne Relay non conserva dati dei clienti oltre all’inventario degli endpoint e alla cronologia dei processi; tutti i dati rimangono sull’infrastruttura del cliente a meno che non vengano esplicitamente sincronizzati con NinjaOne (Modalità A).

Risorse aggiuntive

Per ulteriori informazioni su NinjaOne Relay, consultare NinjaOne Endpoint Management: Requisiti di sistema e compatibilità.