Condividi tramite

Gestire il firewall host con Azure IoT e OSConfig

  • Articolo

Importante

La versione 1.0.3 (pubblicata 28 giugno 2022) include modifiche di rilievo ai nomi dei membri che potrebbero influire sugli utenti esistenti. Per altre informazioni, vedere: I nomi dei membri passano da PascalCase a camelCase nella versione 1.0.3

Destinatari

Questo articolo è progettato per supportare le persone che effettuano il provisioning o la gestione dei dispositivi con Azure IoT. Se questo non è simile a te, prendere in considerazione Destinatari per la documentazione di OSConfig.

Panoramica del firewall

Quando i dispositivi hanno installato OSConfig, è possibile usare i servizi Azure IoT per eseguire diverse attività di amministrazione del firewall di base. Ad esempio:

  • Verificare se il firewall è attivo
  • Assicurarsi che esistano determinate regole (creare se non presente)
  • Assicurarsi che alcune regole non esistano (eliminazione se trovato)
  • Confrontare le regole di molti dispositivi distribuiti in un dispositivo noto
  • Impostare i criteri di traffico predefiniti per il traffico in ingresso e in uscita

Icona del firewall

Suggerimento

Se si è qui per il riferimento al modello a oggetti, è possibile ignorare gli esempi di casi d'uso alle informazioni di riferimento

Esempi di casi d'uso

Questi esempi possono fungere da punti di partenza per adattarsi all'ambiente univoco.

Ogni esempio include passaggi e acquisizioni dello schermo per l'uso nella portale di Azure e per l'uso in bash con l'interfaccia della riga di comando di Azure.

Ogni esempio include anche varianti per un dispositivo (ad esempio uno scenario di risoluzione dei problemi) o per molti dispositivi (ad esempio, un provisioning di configurazione o uno scenario di creazione di report).

Cosa aspettarsi:

Nelle istruzioni del singolo dispositivo leggere e scrivere le proprietà segnalate e desiderate direttamente nel gemello OSConfig per un dispositivo. Nelle istruzioni su larga scala si useranno hub IoT Configurazioni (note anche come Gestione dispositivi automatico o ADM) per eseguire il push delle proprietà desiderate in molti gemelli e usare query hub IoT (in modo indipendente o collegato a Configurazioni come metriche) per osservare i risultati provenienti dai dispositivi.

Prerequisiti per provare gli esempi nei sistemi in tempo reale

Se si usa questo articolo per informazioni di riferimento, non sono presenti prerequisiti. È possibile esaminare gli esempi, copiare i nomi delle proprietà e così via.

Per provare gli esempi nei sistemi live (consigliato), seguire questa procedura:

  1. Creare un account Azure gratuito o usare un account esistente

  2. Connettere almeno un dispositivo abilitato per OSConfig a un hub IoT

    Suggerimento

    Per creare facilmente un hub IoT con dispositivi collegati (virtuali), vedere Creare un ambiente lab OSConfig (con Azure IoT) in 5 minuti

  3. Iniziare a seguire l'istruzione portale di Azure o le istruzioni dell'interfaccia della riga di comando di Azure negli esempi:

Se si preferisce usare la portale di Azure

  1. Accedere alla pagina Panoramica del portale di Azure e accedere alla pagina Panoramica dell'hub IoT che mostra hub IoT e dispositivi dal portale di Azure

-OR- Se si preferisce usare l'interfaccia della riga di comando di Azure

  1. CONSIGLIATO: usare Azure Cloud Shell come ambiente bash accedendo al portale di Azure, quindi avviando Azure Cloud Shell in modalità bash Acquisizione schermata di apertura Cloud Shell dal portale di Azure
  2. ALTERNATIVA: se si preferisce usare un ambiente bash personalizzato anziché Cloud Shell, installare l'interfaccia della riga di comando di Azure e accedere
  3. Verificare che l'estensione Azure IoT sia pronta eseguendo az extension add --name azure-iot

Esempio A. Il firewall host è attivo?

La state proprietà in properties.reported.Firewall fornisce un'indicazione generale del fatto che il firewall host sia attivo. Ad esempio, indica se il motore del firewall host è abilitato e almeno una regola esiste nella tabella FILTER . Per altre informazioni sull'inclusione di valori possibili, vedere: Informazioni di stateriferimento.

  1. Nella pagina del portale di hub IoT scegliere Dispositivi nello spostamento a sinistra. Se il dispositivo ha IoT Edge installato oltre a OSConfig, scegliere IoT Edge anziché dispositivi.

  2. Fare clic su un dispositivo in cui è installato OSConfig.

  3. In Identità modulo fare clic su osconfig.

  4. Fare clic su Module Identity Twin (Identità modulo gemello ) e passare a JSON su properties.reported.Firewall.state. Nell'esempio di acquisizione dello schermo seguente è possibile notare che state: enabled.

    Acquisizione schermata che mostra come controllare lo stato del firewall per un dispositivo specifico usando il portale

Esempio B. Creare una regola del firewall

In questo esempio viene usata la desiredRules funzione del modulo Firewall. Viene creata una nuova regola che consente il traffico tcp in uscita 443 dal dispositivo alla subnet 10.9.9.0/24.

Per altre informazioni (inclusa la gestione di più regole e rimozione delle regole) vedere Informazioni di riferimento sul desiredRulesfirewall desiderateRules più avanti in questo articolo.

  1. Usando il portale di Azure, nel modulo osconfig gemello del dispositivo, in properties.desired aggiungere o modificare un Firewall nodo e desiredRules come indicato di seguito. Per standard JSON, potrebbe essere necessario aggiungere una virgola alla fine per integrare con altre proprietà desiderate se presenti.

    "Firewall": {
   "desiredRules": [
      {
         "desiredState": "present",
         "action": "accept",
         "direction": "out",
         "protocol": "tcp",
         "destinationAddress": "10.9.9.0/24",
         "destinationPort": 443
      }
   ]
}

    Acquisizione schermata che illustra come configurare una regola del firewall per un singolo dispositivo usando il portale

  2. Dopo circa 30 secondi, è possibile verificare che la modifica venga apportata correttamente dal modulo gemello stesso. Aggiornare la visualizzazione del modulo gemello, quindi scorrere per trovare properties, quindi reported, quindi stateFirewallconfigurationStatus, e .desiredRules

    Acquisizione schermata che mostra come leggere le proprietà segnalate per la configurazione del firewall per un singolo dispositivo usando il portale

Esempio C. Confrontare l'impronta digitale dello stato del firewall di molti dispositivi con un dispositivo valido noto

La fingerprint proprietà consente confronti rapidi per verificare la conformità su larga scala. Non è necessario recuperare tutte le regole da tutti i dispositivi e quindi implementare una strategia di confronto molti-a-molti. Puoi semplicemente verificare che l'impronta digitale sia la stessa tra i dispositivi che dovrebbero corrispondere l'uno all'altro. Ad esempio, è possibile confrontare tra i dispositivi distribuiti e un dispositivo di riferimento valido noto.

Negli esempi a dispositivo singolo si recupererà semplicemente il valore, implicando che si sta eseguendo un confronto fuori banda. Negli esempi su larga scala si userà hub IoT operatore GROUP BY di Query per mostrare la commonalità o la divergenza tra una flotta.

Non applicabile, vedere Portale di Azure su larga scala.

Informazioni di riferimento

Descrizione del modello a oggetti

In questa sezione vengono descritte le proprietà dei dispositivi gemelli e i comportamenti corrispondenti.

Suggerimento

La documentazione di riferimento di OSConfig si applica agli strumenti con o senza prospettive avanzate DTDL (Digital Twin Definition Language) del modello di dati. Per altre informazioni, vedere Informazioni sulle visualizzazioni desiderate/segnalate normale e sulle viste avanzate DTDL.

Proprietà segnalate/di sola lettura del firewall (per scenari di creazione di report e controllo)

  • Path: properties.reported.Firewall (Firewall component, proprietà di sola lettura)

  • Descrizione: stato del firewall host rilevato dal modulo Firewall di OSConfig

  • Members

    Nome Type Note
    configurationStatus enumerazione di stringhe Rappresenta lo stato di errore/esito positivo del raggiungimento della configurazione desiderata. Significativo solo se sono state impostate proprietà di configurazione desiderate, desiredRules ad esempio o desiredDefaultPolicies . Il valore possibile a partire da questo documento è success, failuree unknown.
    configurationStatusDetail string Testo restituito da API o strumenti sottostanti, ad esempio iptables. Progettato per fornire il primo livello di informazioni dettagliate su parametri di input non corretti e così via, senza ricorrere a combing attraverso i log di diagnostica.
    defaultPolicies matrice di oggetti (vedere payload di esempio) Rappresenta la distribuzione predefinita del firewall di pacchetti che non soddisfano alcuna regola specifica. Nel contesto delle tabelle iptable viene eseguito il mapping ai criteri della catena per le catene di input e output della tabella di filtro. In altri motori del firewall viene eseguito il mapping al comportamento del motore del firewall in base alle esigenze. Ad esempio, alcuni motori firewall non hanno un concetto esplicito di criteri e scendono intrinsecamente il traffico che non soddisfa alcuna regola.
    Impronte digitali string • Impronta digitale opaca per l'elenco di tutte le regole del firewall nel dispositivo
    • Usato per confrontare un numero elevato di dispositivi con un dispositivo valido noto
    NOTA: nelle versioni di OSConfig precedenti alla versione di ottobre 2022, questa proprietà era nota come "firewallFingerprint"
    state enumerazione di stringhe Stato generale del firewall host. I valori possibili sono:
    • unknown
    • enabled
    • disabled
    La logica per enabled è che è stato rilevato un motore firewall attivo e con almeno una regola nella tabella FILTER.
    NOTA: nelle versioni di OSConfig precedenti alla versione di ottobre 2022 queste informazioni sono state presentate come "firewallState" (anziché "state") e i valori erano numeri interi (anziché stringhe).

  • Payload di esempio (come illustrato nella sezione del properties.reported gemello)

    "Firewall": {
    "configurationStatus": "success",
    "configurationStatusDetail": "",
    "defaultPolicies": [
       {
          "direction": "in",
          "action": "accept"
       },
       {
          "direction": "out",
          "action": "accept"
       }
    ],
    "fingerprint": "c30d8b8bf5327a8a325a686e0c4bbf73b1bd33a72779af88827e8ea256caddb2",
    "state": "enabled"
}
Firewall desiredRules

Attenzione

Come per qualsiasi amministrazione del firewall, prestare molta attenzione quando si blocca il traffico. È possibile impedire al dispositivo di continuare la connessione con hub IoT o altri canali amministrativi. In questi casi potrebbe essere necessario l'accesso locale al dispositivo per il ripristino.

  • Path: properties.desired.Firewall.desiredRules (Firewall componente, desiredRules proprietà scrivibile)

  • Descrizione: elenco ordinato di descrittori di regole. Ogni descrittore di regola nell'elenco può avere i membri seguenti.

  • Membri di ogni descrittore di regola

    Nome Type Note
    desiredState enumerazione di stringhe Sempre obbligatoria. I valori possibili sono present (significa che tale regola deve essere creata se non esiste già una regola corrispondente) o absent (significa che qualsiasi regola esistente nel dispositivo corrispondente a questo descrittore deve essere eliminata se presente. Per i descrittori di regole in cui desiredState: "present" e dove non esiste già alcuna regola di corrispondenza nel dispositivo, la nuova regola viene aggiunta all'inizio dell'elenco di regole nel dispositivo. Per il contesto, è possibile considerare questo comportamento come analogo a iptables -I invece di iptables -A. Se in sono presenti desiredRulespiù desiredState: "present" descrittori di regole, vengono aggiunti in modo che l'ordine venga mantenuto. In altre parole, la regola principale in desiredRules sarà all'inizio dell'elenco delle regole nel dispositivo, la regola successiva in desiredRules seguirà tale regola nell'elenco di regole nel dispositivo e così via.
    azione enumerazione di stringhe Sempre obbligatoria. I valori possibili sono accept, drop o reject.
    direction enumerazione di stringhe Sempre obbligatoria. I possibili valori sono in o out.
    protocol enumerazione di stringhe Sempre obbligatoria. I possibili valori sono any, udp, tcp o icmp. Si noti che any significa qualsiasi traffico (anziché "tcp e udp, ma non altri protocolli IP). Di conseguenza, le regole in cui protocol: "any" non devono includere sourcePort o destinationPort.
    sourceAddress string Indirizzo IP o intervallo CIDR. Se non specificato, la regola risultante corrisponde a qualsiasi indirizzo
    sourcePort numero intero Pertinente per le regole in cui protocol: tcp o protocol:udp. Non deve essere incluso in altre regole. Specifica il numero di porta quando incluso in una regola pertinente. Se non incluso, indica una regola che deve corrispondere a qualsiasi numero di porta.
    destinationAddress string Indirizzo IP o intervallo CIDR. Se non specificato, la regola risultante corrisponde a qualsiasi indirizzo
    destinationPort numero intero Pertinente per le regole in cui protocol: tcp o protocol:udp. Non deve essere incluso in altre regole. Specifica il numero di porta quando incluso in una regola pertinente. Se non incluso, indica una regola che deve corrispondere a qualsiasi numero di porta.

Payload di esempio (come illustrato nella sezione del properties.desired gemello)

Le regole seguenti rappresentano le intenzioni di amministratore seguenti:

  1. "La subnet di amministrazione locale è 10.9.9.0/24, quindi voglio che i dispositivi consentano la porta in ingresso 22 (SSH) da lì"

  2. "La subnet di amministrazione precedente era 10.24.24.0/24, quindi se qualsiasi dispositivo ha ancora una regola che consente la porta 22 (SSH) da lì, voglio che tale regola venga rimossa"

  3. NOTA: l'amministratore potrebbe volere una terza regola qui per bloccare SSH da ovunque (con l'eccezione precedente), ma in questo esempio verrà usato un criterio di eliminazione predefinito, rendendo tale regola ridondante. Vedere l'esempio desiredDefaultPolicies più avanti in questo documento.

    "Firewall": {
   "desiredRules": [
      {
         "desiredState": "present",
         "action": "accept",
         "direction": "in",
         "protocol": "tcp",
         "sourceAddress": "10.9.9.0/24",
         "destinationPort": 22
      },
      {
         "desiredState": "absent",
         "action": "accept",
         "direction": "in",
         "protocol": "tcp",
         "sourceAddress": "10.24.24.0/24",
         "destinationPort": 22
      }
   ]
}

Si noti che quando un flusso di lavoro amministrativo imposta properties.desired.Firewall.desiredRules ( componente, desiredRules proprietà scrivibile dal punto di vista DTDL), il dispositivo riconosce la ricezione dello stesso aggiungendo una desiredRules proprietà a properties.reported.FirewallFirewall . Il valore di tale proprietà include una copia del payload originale desiredRules , insieme a un numero di versione e al codice di stato. hub IoT flussi di lavoro amministrativi basati su possono usare questo per determinare se lo stato desiderato ha ancora raggiunto il dispositivo. Questo è solo un riconoscimento. Per determinare se il dispositivo ha avuto esito positivo nel raggiungere lo stato desiderato, vedere configurationStatus anche e configurationStatusDetail.

Firewall desiredDefaultPolicies

Attenzione

Come per qualsiasi amministrazione del firewall, prestare molta attenzione quando si blocca il traffico. È possibile impedire al dispositivo di continuare la connessione con hub IoT o altri canali amministrativi. In questi casi l'accesso locale al dispositivo potrebbe essere necessario per il ripristino.

I criteri predefiniti richiedono un'applicazione particolarmente attenta. Nei sistemi basati su iptable, ad esempio, i criteri si applicano a ogni pacchetto singolarmente senza considerare le connessioni esistenti. In altre parole, un criterio predefinito in ingresso ( drop oltre a bloccare le nuove connessioni in ingresso) blocca le risposte dai sistemi remoti. Ciò può rendere impossibile per il dispositivo comunicare in uscita usando protocolli (ad esempio TCP) che richiedono il flusso di pacchetti bidirezionali. Non impostare action su drop su o inout criteri senza prima assicurarsi che esistano regole specifiche per abilitare tutti i pacchetti necessari in entrambe le direzioni.

  • Percorso: properties.desired.Firewall.desiredDefaultPolicies (Firewall componente, desiredDefaultPolicies proprietà scrivibile)

  • Descrizione: matrice con due elementi, che descrive il comportamento predefinito desiderato (accettare o eliminare) per il traffico in ingresso e per il traffico in uscita.

  • Membri di ogni elemento

    Nome Type Note
    direction enumerazione delle stringhe I valori possibili sono in o out
    azione enumerazione delle stringhe Sempre obbligatoria. I possibili valori sono accept o drop.

Payload di esempio (come illustrato nella sezione del properties.desired gemello)

"Firewall": {
   "desiredDefaultPolicies": [
      {"direction": "in", "action": "drop"},
      {"direction": "out", "action": "accept"}
   ]
}

Si noti che quando un flusso di lavoro amministrativo imposta properties.desired.Firewall.desiredDefaultPolicies ( componente, desiredDefaultPolicies proprietà scrivibile dal punto di vista DTDL), il dispositivo riconosce la ricezione della stessa aggiungendo una desiredDefaultPolicies proprietà a properties.reported.FirewallFirewall . Il valore di tale proprietà include una copia del payload originale, insieme a un numero di versione e al codice di stato. hub IoT flussi di lavoro amministrativi basati su possono usare questo per determinare se lo stato desiderato ha ancora raggiunto il dispositivo. Si tratta solo di un riconoscimento della ricezione e dell'elaborazione. Per altre informazioni sull'esito positivo o negativo del raggiungimento dello stato desiderato, vedere configurationStatus e configurationStatusDetail.

Informazioni aggiuntive e domande frequenti

Che cos'è un caso d'uso "sostituisci tutto" ?

In alcuni casi gli amministratori potrebbero voler imporre il controllo assoluto sull'elenco netto di regole del firewall del dispositivo. Immaginare un'intenzione, ad esempio, "Esistono solo regole X, Y e Z; Tutte le altre regole (preesistenti nel dispositivo o create nel tempo da altri processi) devono essere rimosse periodicamente." A questo punto il modulo OSConfig Firewall non fornisce direttamente per questo caso d'uso. La rimozione di regole specifiche può essere eseguita tramite desiredRules e , "desiredState": "absent"ma non esiste alcuna funzionalità di sostituzione esplicita. Se si vuole aggiungere tale funzionalità, vedere la documentazione di estendibilità in https://github.com/Azure/azure-osconfig.

Passaggi successivi

Per una panoramica degli scenari e delle funzionalità osConfig, vedere:

Per esempi pratici specifici, vedere: