Partager via

Gérer le pare-feu hôte avec Azure IoT et OSConfig

  • Article

Important

La version 1.0.3 (publiée le 28 juin 2022) inclut des modifications cassants apportées aux noms de membres susceptibles d’avoir un impact sur les utilisateurs existants. Pour plus d’informations, consultez : Les noms de membres passent de PascalCase à camelCase dans la version 1.0.3

Public visé

Cet article est conçu pour prendre en charge les personnes qui approvisionnent ou gèrent des appareils avec Azure IoT. Si ce n’est pas le cas, envisagez de consulter la documentation Audiences pour OSConfig.

Présentation du pare-feu

Lorsque les appareils ont installé OSConfig, vous pouvez utiliser les services Azure IoT pour effectuer plusieurs tâches d’administration de pare-feu de base. Par exemple :

  • Vérifier si le pare-feu est actif
  • Vérifiez que certaines règles existent (créer s’il n’est pas présent)
  • Vérifiez que certaines règles n’existent pas (supprimer le cas échéant)
  • Comparer les règles de nombreux appareils déployés à un appareil connu
  • Définir les stratégies de trafic par défaut pour le trafic entrant et sortant

Icône de pare-feu

Conseil

Si vous êtes ici pour la référence du modèle objet, vous pouvez ignorer les exemples de cas d’utilisation aux informations de référence

Exemples de cas d’usage

Ces exemples peuvent servir de points de départ pour vous adapter à votre environnement unique.

Chaque exemple inclut des étapes et des captures d’écran pour travailler dans le Portail Azure et pour travailler dans bash avec Azure CLI.

Chaque exemple inclut également des variantes pour un appareil (par exemple, un scénario de résolution des problèmes) ou pour de nombreux appareils (par exemple, un provisionnement de configuration ou un scénario de création de rapports).

Que vous attendez -vous :

Dans les instructions de l’appareil unique, vous allez lire et écrire des propriétés signalées et souhaitées directement dans le jumeau OSConfig pour un appareil. Dans les instructions à grande échelle, vous allez utiliser IoT Hub Configurations (également appelées Gestion des appareils automatique ou ADM) pour envoyer des propriétés souhaitées à de nombreux jumeaux, et utiliser des requêtes IoT Hub (indépendamment ou attachées aux configurations en tant que métriques) pour observer les résultats provenant d’appareils.

Conditions préalables pour essayer les exemples sur les systèmes en direct

Si vous utilisez cet article pour référence, il n’existe pas de conditions préalables. Vous pouvez consulter les exemples, copier les noms de propriétés, etc.

Si vous souhaitez essayer les exemples sur les systèmes en direct (recommandé), procédez comme suit :

  1. Créer un compte Azure gratuit ou utiliser un compte existant

  2. Connectez au moins un appareil osConfig à un IoT Hub

    Conseil

    Pour créer facilement un IoT Hub avec des appareils (virtuels) attachés, consultez Créer un environnement de laboratoire OSConfig (avec Azure IoT) en 5 minutes

  3. Préparez-vous à suivre l’instruction Portail Azure ou les instructions Azure CLI dans les exemples :

Si vous préférez utiliser le Portail Azure

  1. Connectez-vous à votre Portail Azure et accédez à la page Vue d’ensemble de votre IoT Hub capture d’écran montrant IoT Hub et les appareils à partir du portail Azure

-OR- Si vous préférez utiliser Azure CLI

  1. RECOMMANDÉ : Utilisez Azure Cloud Shell comme environnement bash en vous connectant à votre portail Azure, puis lancez Azure Cloud Shell en mode bash capture d’écran ouvrant Cloud Shell à partir du portail Azure
  2. ALTERNATIVE : Si vous préférez utiliser votre propre environnement bash plutôt que Cloud Shell, installez Azure CLI et connectez-vous
  3. Vérifiez que l’extension Azure IoT est prête en cours d’exécution az extension add --name azure-iot

Exemple A. Le pare-feu hôte est-il actif ?

La state propriété sous properties.reported.Firewall fournit une indication de haut niveau indiquant si le pare-feu hôte est actif. Par exemple, il indique si le moteur de pare-feu hôte est activé et qu’au moins une règle existe dans la table FILTER . Pour plus d’informations sur l’inclusion de valeurs possibles, consultez : Informations destate référence.

  1. Dans la page du portail de votre IoT Hub, choisissez Appareils dans la navigation de gauche. Si l’appareil a IoT Edge installé en plus de OSConfig, choisissez IoT Edge au lieu des appareils.

  2. Cliquez sur un appareil où OSConfig est installé.

  3. Sous Identités de module , cliquez sur osconfig.

  4. Cliquez sur Module Identity Twin et accédez au json vers properties.reported.Firewall.state. Dans l’exemple de capture d’écran suivant, vous pouvez voir cela state: enabled.

    Capture d’écran montrant comment vérifier l’état du pare-feu pour un appareil spécifique à l’aide du portail

Exemple B. Créer une règle de pare-feu

Cet exemple utilise la desiredRules fonction du module Pare-feu. Nous créons une règle autorisant le trafic tcp sortant 443 de l’appareil vers le sous-réseau 10.9.9.0/24.

Pour plus d’informations sur desiredRules (y compris la gestion de plusieurs règles et suppression de règles) consultez la référence pare-feu desiredRules plus loin dans cet article.

  1. À l’aide du portail Azure, dans le jumeau de module osconfig de l’appareil, sous properties.desired ajout ou modification d’un Firewall et desiredRules de nœuds comme suit. Par norme JSON, vous devrez peut-être ajouter une virgule à la fin pour l’intégrer à d’autres propriétés souhaitées si elles sont présentes.

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

    Capture d’écran montrant comment configurer une règle de pare-feu pour un seul appareil à l’aide du portail

  2. Après environ 30 secondes, vous pouvez vérifier que la modification est effectuée avec succès à partir du jumeau de module lui-même. Actualisez la vue de jumeau de module, puis faites défiler pour rechercherproperties, puis , puis configurationStatusFirewall , state et le desiredRulesreported.

    Capture d’écran montrant comment lire les propriétés signalées pour la configuration du pare-feu pour un seul appareil à l’aide du portail

Exemple C. Comparer l’empreinte digitale du pare-feu de nombreux appareils à un appareil connu

La fingerprint propriété permet des comparaisons rapides pour vérifier la conformité à grande échelle. Vous n’avez pas besoin de récupérer toutes les règles de tous les appareils, puis d’implémenter une stratégie de comparaison plusieurs-à-plusieurs. Vous pouvez simplement vérifier que l’empreinte digitale est la même sur les appareils qui sont censés correspondre les uns aux autres. Par exemple, vous pouvez comparer entre les appareils déployés et un appareil de référence connu.

Dans les exemples mono-appareil, nous allons simplement récupérer la valeur, ce qui implique que vous effectuez une comparaison hors bande. Dans les exemples à grande échelle, nous allons utiliser l’opérateur GROUP BY de la requête IoT Hub pour montrer la communité ou la divergence entre une flotte.

Non applicable, consultez le portail Azure à grande échelle.

Informations de référence

Description du modèle objet

Cette section décrit les propriétés de jumeau et les comportements correspondants.

Conseil

La documentation de référence OSConfig s’applique aux outils avec ou sans DTDL (Digital Twin Definition Language) avec des perspectives améliorées du modèle de données. Pour plus d’informations, consultez : À propos des vues souhaitées/signalées simples et des vues améliorées DTDL.

Propriétés signalées/en lecture seule (pour les scénarios de création de rapports et d’audit)

  • Chemin d’accès : properties.reported.Firewall (Firewall composant, propriétés en lecture seule)

  • Description : État du pare-feu hôte détecté par le module de pare-feu d’OSConfig

  • Members (Membres)

    Nom Type Notes
    configurationStatus énumération de chaînes Représente l’état d’échec/réussite de l’atteinte de la configuration souhaitée. Uniquement explicite si les propriétés de configuration souhaitées telles que desiredRules ou desiredDefaultPolicies ont été définies. La valeur possible à partir de cet écriture est success, failureet unknown.
    configurationStatusDetail string Texte retourné par les API ou outils sous-jacents tels que les iptables. Destiné à fournir le premier niveau d’insights sur les paramètres d’entrée incorrects, etc. sans recourir à la combinaison par le biais des journaux de diagnostic.
    defaultPolicies tableau d’objets (voir exemple de charge utile) Représente la main par défaut du pare-feu de paquets qui ne répondent à aucune règle spécifique. Dans le contexte des iptables, cela correspond aux stratégies de chaîne pour les chaînes d’entrée et de sortie de la table de filtre. Dans d’autres moteurs de pare-feu, cela mappe au comportement du moteur de pare-feu si nécessaire. Par exemple, certains moteurs de pare-feu n’ont pas de notion de stratégie explicite et suppriment intrinsèquement le trafic qui ne répond à aucune règle.
    Empreinte digitale string • Empreinte digitale opaque pour la liste de toutes les règles de pare-feu sur l’appareil
    • Utilisé pour comparer un grand nombre d’appareils à un appareil connu
    REMARQUE : Dans les versions de OSConfig antérieures à la version d’octobre 2022, cette propriété a été appelée « firewallFingerprint »
    state énumération de chaînes État de haut niveau du pare-feu hôte. Les valeurs possibles sont les suivantes :
    • unknown
    • enabled
    • disabled
    La logique pour enabled laquelle un moteur de pare-feu actif a été détecté et avec au moins une règle dans la table FILTER.
    REMARQUE : Dans les versions de OSConfig antérieures à la version d’octobre 2022, ces informations ont été présentées comme « firewallState » (plutôt que « state ») et les valeurs étaient des entiers (plutôt que des chaînes).

  • Exemple de charge utile (comme indiqué dans la section du properties.reported jumeau)

    "Firewall": {
    "configurationStatus": "success",
    "configurationStatusDetail": "",
    "defaultPolicies": [
       {
          "direction": "in",
          "action": "accept"
       },
       {
          "direction": "out",
          "action": "accept"
       }
    ],
    "fingerprint": "c30d8b8bf5327a8a325a686e0c4bbf73b1bd33a72779af88827e8ea256caddb2",
    "state": "enabled"
}
Pare-feu souhaitéRules

Attention

Comme pour toute administration de pare-feu, prenez soin de bloquer le trafic. Vous avez la possibilité de bloquer l’appareil de continuer sa connexion avec IoT Hub ou d’autres canaux d’administration. Dans ce cas, l’accès local à l’appareil peut être nécessaire pour récupérer.

  • Chemin d’accès : properties.desired.Firewall.desiredRules (Firewall composant, desiredRules propriété accessible en écriture)

  • Description : Liste ordonnée des descripteurs de règle. Chaque descripteur de règle dans la liste peut avoir les membres suivants.

  • Membres de chaque descripteur de règle

    Nom Type Notes
    desiredState énumération de chaînes Toujours obligatoire. Les valeurs possibles sont present (signifie qu’une telle règle doit être créée si une règle correspondante n’existe pas déjà), ou absent (signifie que toute règle existante sur l’appareil correspondant à ce descripteur doit être supprimée si elle est trouvée. Pour les descripteurs de règle où desiredState: "present" et où aucune règle correspondante n’existe déjà sur l’appareil, la nouvelle règle est ajoutée en haut de la liste des règles sur l’appareil. Pour le contexte, vous pouvez penser qu’il s’agit d’être analogue à iptables -I celui de iptables -A. Si plusieurs desiredState: "present" descripteurs de règle sont présents, desiredRulesils sont ajoutés de sorte que l’ordre soit conservé. En d’autres termes, la règle supérieure est desiredRules en haut de la liste des règles sur l’appareil, la règle suivante suit desiredRules que dans la liste des règles sur l’appareil, et ainsi de suite.
    action énumération de chaînes Toujours obligatoire. Les valeurs possibles sont accept, drop ou reject.
    direction énumération de chaînes Toujours obligatoire. Les valeurs possibles sont in ou out.
    protocol énumération de chaînes Toujours obligatoire. Les valeurs possibles sont any, udp, tcp ou icmp. Notez que cela any signifie tout trafic (par opposition à la signification « tcp et udp, mais pas d’autres protocoles IP). En conséquence, les règles où protocol: "any" ne doivent pas inclure sourcePort ou destinationPort.
    sourceAddress string Adresse IP ou plage CIDR. Si elle n’est pas spécifiée, la règle résultante correspond à n’importe quelle adresse
    sourcePort entier Pertinent pour les règles où protocol: tcp ou protocol:udp. Ne doit pas être inclus dans d’autres règles. Spécifie le numéro de port lorsqu’il est inclus dans une règle appropriée. Lorsqu’elle n’est pas incluse, indique une règle qui doit correspondre à n’importe quel numéro de port.
    destinationAddress string Adresse IP ou plage CIDR. Si elle n’est pas spécifiée, la règle résultante correspond à n’importe quelle adresse
    destinationPort entier Pertinent pour les règles où protocol: tcp ou protocol:udp. Ne doit pas être inclus dans d’autres règles. Spécifie le numéro de port lorsqu’il est inclus dans une règle appropriée. Lorsqu’elle n’est pas incluse, indique une règle qui doit correspondre à n’importe quel numéro de port.

Exemple de charge utile (comme illustré dans la section du properties.desired jumeau)

Les règles suivantes représentent les intentions d’administrateur suivantes :

  1. « Mon sous-réseau administrateur local est 10.9.9.0/24, donc je souhaite que les appareils autorisent le port entrant 22 (SSH) à partir de là »

  2. « Mon ancien sous-réseau d’administration était 10.24.24.0/24. Par conséquent, si un appareil a toujours une règle autorisant le port 22 (SSH) à partir de là, je souhaite qu’une telle règle soit supprimée »

  3. REMARQUE : L’administrateur peut vouloir ici qu’une troisième règle bloque SSH partout (à l’exception ci-dessus), mais dans cet exemple, nous allons utiliser une stratégie de suppression par défaut, ce qui rend une telle règle redondante. Consultez l’exemple desiredDefaultPolicies plus loin dans ce document.

    "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
      }
   ]
}

Notez que lorsqu’un flux de travail administratif définit properties.desired.Firewall.desiredRules (composant, desiredRules propriété accessible en écriture du point de vue DTDL), l’appareil accuse réception du même résultat en ajoutant une desiredRules propriété à properties.reported.FirewallFirewall . La valeur de cette propriété inclut une copie de la charge utile d’origine desiredRules , ainsi qu’un numéro de version et un code d’état. IoT Hub flux de travail administratifs basés sur cette option pour déterminer si l’état souhaité a encore atteint l’appareil. Il s’agit uniquement d’un accusé de réception. Pour déterminer si l’appareil a réussi à atteindre l’état souhaité, consultez configurationStatus également et configurationStatusDetail.

Firewall desiredDefaultPolicies

Attention

Comme pour toute administration de pare-feu, prenez soin de bloquer le trafic. Vous avez la possibilité de bloquer la connexion de l’appareil avec IoT Hub ou d’autres canaux administratifs. Dans ce cas, l’accès local à l’appareil peut être nécessaire pour récupérer.

Les stratégies par défaut nécessitent une application particulièrement minutieuse. Sur les systèmes iptables, par exemple, les stratégies s’appliquent à chaque paquet individuellement sans tenir compte des connexions existantes. En d’autres termes, une stratégie par défaut entrante de will (en plus du drop blocage de nouvelles connexions entrantes) bloque les réponses des systèmes distants. Cela peut rendre impossible la communication sortante de l’appareil à l’aide de protocoles (tels que TCP) qui nécessitent un flux de paquet bidirectionnel. Ne définissez pas action la valeur drop sur les stratégies ou out sur les in stratégies sans d’abord s’assurer que des règles spécifiques existent pour activer tous les paquets requis dans les deux sens.

  • Chemin d’accès : properties.desired.Firewall.desiredDefaultPolicies (Firewall composant, desiredDefaultPolicies propriété accessible en écriture)

  • Description : Tableau avec deux éléments, décrivant le comportement par défaut souhaité (accepter ou supprimer) pour le trafic entrant et pour le trafic sortant.

  • Membres de chaque élément

    Nom Type Notes
    direction énumération de chaînes Les valeurs possibles sont in ou out
    action énumération de chaînes Toujours obligatoire. Les valeurs possibles sont accept ou drop.

Exemple de charge utile (comme illustré dans la section du properties.desired jumeau)

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

Notez que lorsqu’un flux de travail administratif définit properties.desired.Firewall.desiredDefaultPolicies (composant, desiredDefaultPolicies propriété accessible en écriture du point de vue DTDL), l’appareil accuse réception du même résultat en ajoutant une desiredDefaultPolicies propriété à properties.reported.FirewallFirewall . La valeur de cette propriété inclut une copie de la charge utile d’origine, ainsi qu’un numéro de version et un code d’état. IoT Hub flux de travail administratifs basés sur cette option peut l’utiliser pour déterminer si l’état souhaité a encore atteint l’appareil. Il s’agit uniquement d’un accusé de réception et d’un traitement. Pour plus d’informations sur la réussite ou l’échec de l’atteinte de l’état souhaité, consultez configurationStatus et configurationStatusDetail.

Informations supplémentaires et FAQ

Qu’en est-il d’un cas d’usage « remplacer tout » ?

Dans certains cas, les administrateurs peuvent imposer un contrôle absolu sur la liste nette des règles de pare-feu de l’appareil. Imaginez une intention telle que « Seules les règles X, Y et Z doivent exister ; Toutes les autres règles (préexistantes sur l’appareil ou créées au fil du temps par d’autres processus) doivent être supprimées régulièrement. » À ce stade, le module de pare-feu OSConfig ne fournit pas directement ce cas d’usage. La suppression de règles spécifiques peut être effectuée desiredRules et "desiredState": "absent", mais il n’existe aucune fonctionnalité de remplacement explicite. Si vous souhaitez ajouter une telle fonctionnalité, consultez la documentation sur l’extensibilité à l’adresse https://github.com/Azure/azure-osconfig.

Étapes suivantes

Pour obtenir une vue d’ensemble des scénarios et fonctionnalités OSConfig, consultez :

Pour obtenir des exemples pratiques spécifiques, consultez :