Distribuire la gestione dei sensori OT ibrida o air-gapped
Microsoft Defender per IoT consente alle organizzazioni di ottenere e mantenere la conformità dell'ambiente OT fornendo una soluzione completa per il rilevamento e la gestione delle minacce, inclusa la copertura tra reti parallele. Defender per IoT supporta organizzazioni in tutti i campi industriali, energetici e di utilità e organizzazioni di conformità come NERC CIP o IEC62443.
Alcuni settori, come le organizzazioni governative, i servizi finanziari, gli operatori nucleari e la produzione industriale, mantengono le reti air-gapped. Le reti air-gapped sono fisicamente separate da altre reti non protette, ad esempio reti aziendali, reti guest o Internet. Defender per IoT consente a queste organizzazioni di rispettare gli standard globali per il rilevamento e la gestione delle minacce, la segmentazione di rete e altro ancora.
Mentre la trasformazione digitale ha aiutato le aziende a semplificare le proprie operazioni e a migliorare le loro linee di fondo, spesso affrontano attriti con le reti con air-gapped. L'isolamento nelle reti air-gapped offre sicurezza, ma complica anche la trasformazione digitale. Ad esempio, le progettazioni dell'architettura come Zero Trust, che includono l'uso dell'autenticazione a più fattori, sono difficili da applicare tra reti air-gapped.
Le reti air-gapped vengono spesso usate per archiviare dati sensibili o controllare i sistemi informatici che non sono connessi ad alcuna rete esterna, rendendoli meno vulnerabili ai cyberattacchi. Tuttavia, le reti air-gapped non sono completamente sicure e possono comunque essere violate. È quindi imperativo monitorare le reti con air-gapped per rilevare e rispondere a eventuali potenziali minacce.
Questo articolo descrive l'architettura della distribuzione di soluzioni di sicurezza ibrida e air-gapped, incluse le sfide e le procedure consigliate per la protezione e il monitoraggio di reti ibride e air-gapped. Invece di mantenere l'infrastruttura di manutenzione di Defender per IoT contenuta in un'architettura chiusa, è consigliabile integrare i sensori Defender per IoT nell'infrastruttura IT esistente, incluse le risorse locali o remote. Questo approccio garantisce che le operazioni di sicurezza vengano eseguite senza problemi, in modo efficiente e facili da gestire.
Suggerimenti per l'architettura
L'immagine seguente mostra un'architettura generale di esempio delle raccomandazioni per il monitoraggio e la gestione dei sistemi Defender per IoT, in cui ogni sensore OT si connette a più sistemi di gestione della sicurezza nel cloud o in locale.
In questa architettura di esempio tre sensori si connettono a quattro router in zone logiche diverse nell'organizzazione. I sensori si trovano dietro un firewall e si integrano con un'infrastruttura IT locale, ad esempio server di backup locali, connessioni di accesso remoto tramite SA edizione Standard e inoltro di avvisi a un sistema SIEM (Security Event and Information Management) locale.
In questa immagine di esempio, la comunicazione per avvisi, messaggi syslog e API viene visualizzata in una linea nera continua. La comunicazione di gestione locale viene visualizzata in una linea viola continua e la comunicazione di gestione cloud/ibrida viene visualizzata in una linea nera tratteggiata.
Le linee guida per l'architettura di Defender per IoT per reti ibride e air-gapped consentono di:
- Usare l'infrastruttura organizzativa esistente per monitorare e gestire i sensori OT, riducendo la necessità di hardware o software aggiuntivi
- Usare le integrazioni dello stack di sicurezza dell'organizzazione che sono sempre più affidabili e affidabili, sia nel cloud che in locale
- Collaborare con i team di sicurezza globali controllando e controllando l'accesso alle risorse cloud e locali, garantendo visibilità e protezione coerenti in ambienti OT
- Migliorare il sistema di sicurezza OT aggiungendo risorse basate sul cloud che migliorano e consentono di migliorare le funzionalità esistenti, ad esempio intelligence sulle minacce, analisi e automazione
Passaggi per la distribuzione
Usare la procedura seguente per distribuire un sistema Defender per IoT in un ambiente ibrido o con air-gapped:Use the following steps to deploy a Defender for IoT system in an air-gapped or hybrid environment:
Completare la distribuzione di ogni sensore di rete OT in base al piano, come descritto in Distribuire Defender per IoT per il monitoraggio OT.
Per ogni sensore, seguire questa procedura:
Eseguire l'integrazione con i server SIEM/syslog partner, inclusa la configurazione delle notifiche di posta elettronica. Ad esempio:
Usare l'API Defender per IoT per creare dashboard di gestione. Per altre informazioni, vedere Le informazioni di riferimento sulle API di Defender per IoT.
Configurare un proxy o proxy concatenato all'ambiente di gestione.
Configurare il monitoraggio dell'integrità usando un server MIB SNMP o tramite l'interfaccia della riga di comando. Per altre informazioni, vedi:
Configurare l'accesso all'interfaccia di gestione del server, ad esempio tramite iDRAC o iLO.
Configurare un server di backup, incluse le configurazioni per salvare il backup in un server esterno. Per altre informazioni, vedere Eseguire il backup e il ripristino dei sensori di rete OT dalla console del sensore.
Transizione da una console di gestione locale legacy
Importante
La console di gestione locale legacy non sarà supportata o disponibile per il download dopo il 1° gennaio 2025. È consigliabile passare alla nuova architettura usando l'intero spettro di API locali e cloud prima di questa data.
Le linee guida sull'architettura correnti sono progettate per essere più efficienti, sicure e affidabili rispetto all'uso della console di gestione locale legacy. Il materiale sussidiario aggiornato include meno componenti, che semplificano la manutenzione e la risoluzione dei problemi. La tecnologia del sensore intelligente usata nella nuova architettura consente l'elaborazione locale, riducendo la necessità di risorse cloud e migliorando le prestazioni. Le linee guida aggiornate mantengono i dati all'interno della propria rete, offrendo una maggiore sicurezza rispetto al cloud computing.
Se si è un cliente esistente che usa una console di gestione locale per gestire i sensori OT, è consigliabile passare alle linee guida sull'architettura aggiornate. L'immagine seguente mostra una rappresentazione grafica dei passaggi di transizione ai nuovi consigli:
- Nella configurazione legacy tutti i sensori sono connessi alla console di gestione locale.
- Durante il periodo di transizione, i sensori rimangono connessi alla console di gestione locale mentre si connettono tutti i sensori possibili al cloud.
- Dopo la transizione completa, si rimuoverà la connessione alla console di gestione locale, mantenendo le connessioni cloud laddove possibile. Tutti i sensori che devono rimanere a portata di aria sono accessibili direttamente dall'interfaccia utente del sensore.
Per eseguire la transizione dell'architettura, seguire questa procedura:
Per ognuno dei sensori OT, identificare le integrazioni legacy in uso e le autorizzazioni attualmente configurate per i team di sicurezza locali. Ad esempio, quali sistemi di backup sono presenti? Quali gruppi di utenti accedono ai dati del sensore?
Connessione i sensori a risorse locali, Azure e altre risorse cloud, in base alle esigenze per ogni sito. Ad esempio, connettersi a un sistema SIEM, server proxy, archiviazione di backup e altri sistemi partner locali. È possibile che siano presenti più siti e adottare un approccio ibrido, in cui solo siti specifici vengono mantenuti completamente sporgenti o isolati usando diodi dati.
Per altre informazioni, vedere le informazioni collegate nella procedura di distribuzione air-gapped, nonché le risorse cloud seguenti:
Configurare le autorizzazioni e le procedure di aggiornamento per l'accesso ai sensori in modo che corrispondano alla nuova architettura di distribuzione.
Esaminare e verificare che tutti i casi d'uso e le procedure di sicurezza siano passati alla nuova architettura.
Al termine della transizione, rimuovere le autorizzazioni dalla console di gestione locale.
Sequenza temporale del ritiro
Il ritiro della console di gestione locale include i dettagli seguenti:
- Le versioni dei sensori rilasciate dopo il 1° gennaio 2025 non potranno essere gestite da una console di gestione locale.
- Le versioni software del sensore rilasciate tra il 1° gennaio 2024 e il 1° gennaio 2025 continueranno a supportare una versione della console di gestione locale.
- I sensori air-gapped che non possono connettersi al cloud possono essere gestiti direttamente tramite la console del sensore, l'interfaccia della riga di comando o l'API.
Per altre informazioni, vedere Ot monitoring software versions .For more information, see OT monitoring software versions.