إدارة جدار حماية المضيف باستخدام Azure IoT وOSConfig

مقالة
06/21/2023

هام

يتضمن الإصدار 1.0.3 (تاريخ النشر 28 يونيو 2022) التغييرات العاجلة على أسماء الأعضاء التي قد تؤثر على المستخدمين الحاليين. لمزيد من المعلومات، راجع: انتقال أسماء الأعضاء من PascalCase إلى camelCase في الإصدار 1.0.3

الجمهور

تم تصميم هذه المقالة لدعم الأشخاص الذين يقومون بتوفير الأجهزة أو إدارتها باستخدام Azure IoT. إذا لم يبدو ذلك مثلك، ففكر في إلقاء نظرة على Audiences لوثائق OSConfig.

نظرة عامة على جدار الحماية

عند تثبيت OSConfig على الأجهزة، يمكنك استخدام خدمات Azure IoT لتنفيذ العديد من مهام إدارة جدار الحماية الأساسية. على سبيل المثال:

التحقق مما إذا كان جدار الحماية نشطا
تأكد من وجود قواعد معينة (إنشاء إن لم يكن موجودا)
تأكد من عدم وجود قواعد معينة (حذف إذا تم العثور عليها)
مقارنة قواعد العديد من الأجهزة المنشورة بجهاز معروف جيدا
تعيين نهج نسبة استخدام الشبكة الافتراضية لنسبة استخدام الشبكة الواردة والصادرة

أيقونة جدار الحماية

تلميح

إذا كنت هنا لمرجع نموذج الكائن، يمكنك تخطي أمثلة استخدام الحالات إلى معلومات المرجع

أمثلة على حالات الاستخدام

يمكن أن تكون هذه الأمثلة بمثابة نقاط بداية للتكيف مع بيئتك الفريدة.

يتضمن كل مثال الخطوات والتقاطات الشاشة للعمل في مدخل Microsoft Azure، وللعمل في bash مع Azure CLI.

يتضمن كل مثال أيضا تباينات لجهاز واحد (على سبيل المثال، سيناريو استكشاف الأخطاء وإصلاحها)، أو للعديد من الأجهزة (على سبيل المثال، توفير التكوين أو سيناريو إعداد التقارير).

ما يمكن توقعه:

في إرشادات الجهاز الواحد، ستقرأ وتكتب الخصائص التي تم الإبلاغ عنها والخصائص المطلوبة مباشرة في OSConfig twin لجهاز. في الإرشادات على نطاق واسع، ستستخدم تكوينات IoT Hub (المعروفة أيضا باسم إدارة الجهاز التلقائي أو ADM) لدفع الخصائص المطلوبة إلى العديد من التوائم، واستخدام استعلامات IoT Hub (بشكل مستقل، أو المرفقة بالتكوينات كمقاييس) لمراقبة النتائج القادمة من الأجهزة.

المتطلبات الأساسية لتجربة الأمثلة على الأنظمة المباشرة

إذا كنت تستخدم هذه المقالة للرجوع إليها، فلا توجد متطلبات مسبقة. يمكنك مراجعة الأمثلة ونسخ أسماء الخصائص وما إلى ذلك.

إذا كنت تريد تجربة الأمثلة على الأنظمة المباشرة (مستحسن)، فاتبع الخطوات التالية:

إنشاء حساب Azure مجاني أو استخدام حساب موجود
توصيل جهاز واحد على الأقل ممكن بواسطة OSConfig إلى IoT Hub

تلميح

لإنشاء مركز IoT بسهولة مع الأجهزة (الظاهرية) المرفقة، راجع إنشاء بيئة مختبر OSConfig (باستخدام Azure IoT) في غضون 5 دقائق
استعد لاتباع تعليمات مدخل Azure أو إرشادات Azure CLI في الأمثلة:

إذا كنت تفضل استخدام مدخل Microsoft Azure

تسجيل الدخول إلى مدخل Microsoft Azure والوصول إلى صفحة نظرة عامة على مركز IoT

-OR- إذا كنت تفضل استخدام Azure CLI

موصى به: استخدم Azure Cloud Shell كبيئة bash الخاصة بك عن طريق تسجيل الدخول إلى مدخل Microsoft Azure، ثم تشغيل Azure Cloud Shell في وضع bash
ALTERNATIVE: إذا كنت تفضل استخدام بيئة bash الخاصة بك بدلا من Cloud Shell، فقم بتثبيت Azure CLI وتسجيل الدخول
تأكد من أن ملحق Azure IoT جاهز عن طريق تشغيل az extension add --name azure-iot

مثال A. هل جدار حماية المضيف نشط؟

state تعطي الخاصية ضمن properties.reported.Firewall إشارة عالية المستوى إلى ما إذا كان جدار الحماية المضيف نشطا. على سبيل المثال، يشير إلى ما إذا كان محرك جدار الحماية المضيف ممكنا وأن قاعدة واحدة على الأقل موجودة في جدول FILTER . لمزيد من المعلومات حول state تضمين القيم المحتملة، راجع: معلومات مرجعية.

من صفحة مدخل IoT Hub، اختر الأجهزة في التنقل باليد اليسرى. إذا كان الجهاز مثبتا عليه IoT Edge بالإضافة إلى OSConfig، فاختر IoT Edge بدلا من الأجهزة.
انقر فوق جهاز حيث تم تثبيت OSConfig.
ضمن Module Identities انقر فوق osconfig.
انقر فوق Module Identity Twin واستعرض JSON إلى properties.reported.Firewall.state. في مثال التقاط الشاشة التالي، يمكنك أن ترى ذلك state: enabled.

من صفحة مدخل Azure IoT Hub، اختر إدارة الأجهزة -->الاستعلامات في التنقل باليد اليسرى.
نفذ الاستعلام التالي لفحص ما إذا كان جدار الحماية ممكنا أم لا لأسطول من الأجهزة المتصلة ب Azure IoT Hub.
```
SELECT deviceId, properties.reported.Firewall.state AS firewallState    
FROM devices.modules
WHERE moduleId='osconfig' 
```

استخدم الأمر المثال التالي الذي يحصل على الخاصية state لجهاز معين، مع <استبدال معرف> الجهاز و/أو <اسم> المركز لمطابقة بيئتك.
```
az iot hub query -q \
"SELECT properties.reported.Firewall.state AS firewallState   
FROM devices.modules
WHERE moduleId='osconfig' AND deviceId = <device-id>" \
 --hub-name <hub-name> --output table
```
في مثال التقاط الشاشة هذا، يكون جدار حماية الجهاز نشطا وممكنا.

استخدم الأمر المثال التالي الذي يحصل على الخاصية state لأسطول من الأجهزة، واستبدال <معرف> الجهاز و/أو <اسم> المركز لمطابقة بيئتك.
```
az iot hub query -q \
"SELECT deviceId, properties.reported.Firewall.state AS firewallState   
FROM devices.modules
WHERE moduleId='osconfig'" --hub-name <hub-name> --output table
```

مثال ب. إنشاء قاعدة جدار حماية

يستخدم desiredRules هذا المثال وظيفة وحدة جدار الحماية. نقوم بإنشاء قاعدة جديدة تسمح بحركة مرور منفذ tcp الصادر 443 من الجهاز إلى الشبكة الفرعية 10.9.9.0/24.

لمزيد من المعلومات حول desiredRules (بما في ذلك معالجة قواعد متعددة وإزالة القواعد) راجع مرجع Firewall desiredRules لاحقا في هذه المقالة.

باستخدام مدخل Azure، في وحدة osconfig المزدوجة للجهاز، ضمن properties.desired إضافة أو تعديل Firewall العقد و desiredRules كما يلي. وفقا لمعايير JSON، قد تحتاج إلى إضافة فاصلة في النهاية للتكامل مع الخصائص المطلوبة الأخرى إذا كانت موجودة.
```
"Firewall": {
   "desiredRules": [
      {
         "desiredState": "present",
         "action": "accept",
         "direction": "out",
         "protocol": "tcp",
         "destinationAddress": "10.9.9.0/24",
         "destinationPort": 443
      }
   ]
}
```
بعد حوالي 30 ثانية، يمكنك التحقق من إجراء التغيير بنجاح من الوحدة النمطية المزدوجة نفسها. قم بتحديث طريقة عرض الوحدة النمطية المزدوجة، ثم قم بالتمرير للعثور على properties، ثم reported، ثم FirewallconfigurationStatus، state و.desiredRules

من صفحة مدخل Azure IoT Hub، اختر إدارة الأجهزة -->التكوينات -->إضافة تكوين الوحدة النمطية.
حدد اسما لملف تعريف التكوين، ثم قم بتعيين إعدادات التوأم بالتكوين المطلوب: قم بتعيين خاصية الوحدة النمطية المزدوجة إلى properties.desired.Firewall وضبط محتوى خاصية الوحدة النمطية المزدوجة على ما يلي:
```
"desiredRules": [
   {
      "desiredState": "present",
      "action": "accept",
      "direction": "out",
      "protocol": "tcp",
      "destinationAddress": "10.9.9.0/24",
      "destinationPort": 443
   }
]
```
بالنسبة إلى الوحدات النمطية الهدف، حدد المعايير الخاصة بالأجهزة الموجودة في النطاق. في هذا المثال، سنستهدف جميع الأجهزة الممكنة ل OSConfig، عن طريق تحديد شرط الهدف ل FROM devices.modules where moduleId='osconfig'
قم بإنشاء مقياس مخصص تم تكوين الاسم بنجاحومعايير القياس كما هو موضح أدناه. سيحدد استعلام القياس هذا جميع الأجهزة التي نجحت في تحديث التكوين.
```
SELECT deviceId FROM devices.modules 
WHERE properties.reported.Firewall.desiredRules.ac = 200
AND properties.reported.Firewall.configurationStatus = 'success'
```
بمجرد تطبيق التكوين على الأجهزة، يمكنك التحقق من توائم الأجهزة التي تم تحديثها بمحتوى الخاصية المزدوجة المطلوبة (جانب السحابة)، عن طريق التحقق من المقياس المطبق (المعروف أيضا باسم appliedCount). لمعرفة الأجهزة التي قامت بتحديث التكوين بنجاح، راجع المقياس المخصص الذي تم تكوينه بنجاح والذي تم إنشاؤه أعلاه.

استخدم الأمر التالي لإنشاء القاعدة، واستبدال <معرف> الجهاز و/أو <اسم> المركز لمطابقة بيئتك.

az iot hub module-twin update -m osconfig --desired \
'{
   "Firewall": {
      "desiredRules": [
         {
            "desiredState": "present",
            "action": "accept",
            "direction": "out",
            "protocol": "tcp",
            "destinationAddress": "10.9.9.0/24",
            "destinationPort": 443
         }
      ]
   }
}' -d <device id> --hub-name <hub name>

لمعرفة اكتمال التكوين بنجاح، انتظر 30 ثانية على الأقل، ثم اقرأ الوحدة النمطية المزدوجة كما يلي:

az iot hub query -q \
"SELECT deviceId, properties.reported.Firewall.desiredRules.ac,properties.reported.Firewall.configurationStatus
FROM devices.modules
WHERE moduleId='osconfig'
AND deviceId='<device id>'" --hub-name <hub name> --output table

لقطة شاشة توضح كيفية التحقق بعد إنشاء قاعدة جدار حماية لجهاز واحد باستخدام bash

استخدم الأمر المثال التالي لإنشاء تكوين مركز IoT. يتضمن هذا التكوين معايير الاستهداف والتكوين المطلوب. تأكد من استبدال اسم المركز باسم IoT Hub الخاص بك. لاحظ أنه يمكن القيام بما يلي في أمر واحد ودون استخدام الملفات المؤقتة، ولكن لتجنب أمر متجانس معقد مع هروب حرف متداخل، نختار استخدام تسلسل من الأوامر وملفين مؤقتين. يجب أن يكون هذا التنسيق أسهل في التعديل والتكيف مع بيئتك.

printf '
{
 "moduleContent": 
    {"properties.desired.Firewall":
       {"desiredRules": [
          {
             "desiredState": "present",
             "action": "accept",
             "direction": "out",
             "protocol": "tcp",
             "destinationAddress": "10.9.9.0/24",
             "destinationPort": 443
          }
       ]
    }
  }
 }' > temp_myconfig_modulecontent.json

 printf $' 
 { 
   "metrics": { 
      "queries": { 
         "successfullyconfigured": "SELECT deviceId FROM devices.modules WHERE moduleId=\'osconfig\' AND properties.reported.Firewall.desiredRules.ac=200 AND properties.reported.Firewall.  configurationStatus=\'success\'"
      }
   }
 }' > temp_myconfig_metrics.json  

 az iot hub configuration create -c "setfirewall_config" --content temp_myconfig_modulecontent.json \
 --target-condition "from devices.modules where moduleId='osconfig'" --priority 10 \
 --metrics temp_myconfig_metrics.json --hub-name <hub-name>

لقطة شاشة توضح كيفية إنشاء تكوين جدار حماية باستخدام bash لأسطول من الأجهزة

لمراقبة توائم الأجهزة التي تم تحديثها بمحتوى الخاصية المزدوجة المطلوبة، راجع المقياس المطبق (المعروف أيضا باسم appliedCount). لاحظ أن Applied يعكس النشاط السحابي فقط لإعداد الخصائص المطلوبة في التوائم. لمراقبة الأجهزة الموجودة في العالم التي قامت بتحديث تكوينها بنجاح، راجع المقياس المخصص الذي تم تكوينه بنجاح والذي تم إنشاؤه أعلاه.

استخدم الأوامر التالية للتحقق من هذين القياسين.

az iot hub configuration show-metric --metric-id appliedCount \
-c "setfirewall_config" --metric-type system \
-n <hub name>

az iot hub configuration show-metric --metric-id successfullyconfigured \
-c "setfirewall_config" --metric-type user \
-n <hub name>

مثال C. مقارنة بصمة حالة جدار الحماية للعديد من الأجهزة بجهاز معروف جيد

fingerprint تتيح الخاصية مقارنات سريعة للتحقق من التوافق على نطاق واسع. لا تحتاج إلى استرداد جميع القواعد من جميع الأجهزة ثم تنفيذ استراتيجية مقارنة متعدد إلى متعدد. يمكنك ببساطة التحقق من أن بصمة الإصبع هي نفسها عبر الأجهزة التي من المتوقع أن تتطابق مع بعضها البعض. على سبيل المثال، يمكنك المقارنة بين الأجهزة المنشورة وجهاز مرجعي معروف جيد.

في أمثلة الجهاز الواحد، سنقوم ببساطة باسترداد القيمة، مما يعني أنك تقوم بإجراء مقارنة خارج النطاق. في الأمثلة على نطاق واسع، سنستخدم عامل تشغيل GROUP BY لاستعلام IoT Hub لإظهار القواسم المشتركة أو التباعد عبر الأسطول.

غير قابل للتطبيق، راجع مدخل Microsoft Azure، على نطاق واسع.

من صفحة مدخل Azure IoT Hub، اختر إدارة الأجهزة -->الاستعلامات في التنقل باليد اليسرى.

تنفيذ الاستعلام التالي:

SELECT properties.reported.Firewall.fingerprint AS firewallFingerprint,
COUNT() AS numberOfDevices
FROM devices.modules
GROUP BY properties.reported.Firewall.fingerprint

لقطة شاشة توضح كيفية مقارنة بصمة جدار الحماية لأسطول من الأجهزة باستخدام bash

استخدم الأمر المثال التالي الذي يقارن الخاصية fingerprint لأسطول من الأجهزة، مع <استبدال معرف> الجهاز و/أو <اسم> المركز لمطابقة بيئتك.

az iot hub query -q \
"SELECT properties.reported.Firewall.fingerprint AS firewallFingerprint,
COUNT() AS numberOfDevices
FROM devices.modules
GROUP BY properties.reported.Firewall.fingerprint" \
--hub-name <hub-name> --output table

لقطة شاشة توضح كيفية مقارنة بصمة جدار الحماية لأسطول من الأجهزة باستخدام bash

معلومات مرجعية

وصف نموذج الكائن

يصف هذا القسم الخصائص المزدوجة والسلوكيات المقابلة.

تلميح

تنطبق الوثائق المرجعية ل OSConfig على الأدوات ذات وجهات نظر محسنة لنموذج البيانات بلغة تعريف التوأم الرقمي (DTDL) أو بدونها. لمزيد من المعلومات، راجع: حول طرق العرض المطلوبة/المبلغ عنها العادية وطرق العرض المحسنة ل DTDL.

خصائص جدار الحماية المبلغ عنها/للقراءة فقط (لسيناريوهات إعداد التقارير والتدقيق)

المسار: properties.reported.Firewall (Firewall مكون، خصائص للقراءة فقط)
الوصف: حالة جدار الحماية المضيف كما تم اكتشافه بواسطة وحدة جدار الحماية في OSConfig

الأعضاء

الاسم	النوع	ملاحظات
حالة التكوين	تعداد السلاسل	يمثل حالة الفشل/النجاح للوصول إلى التكوين المطلوب. ذات معنى فقط إذا تم تعيين خصائص التكوين المطلوبة مثل `desiredRules` أو `desiredDefaultPolicies` تم تعيينها. القيمة المحتملة اعتبارا من هذه الكتابة هي `success`و `failure`و.`unknown`
configurationStatusDetail	سلسلة	النص الذي يتم إرجاعه بواسطة واجهات برمجة التطبيقات الأساسية أو الأدوات مثل iptables. تهدف إلى توفير المستوى الأول من الرؤى في معلمات الإدخال السيئة، وما إلى ذلك دون اللجوء إلى التمشيط من خلال سجلات التشخيص.
نهج افتراضية	صفيف من الكائنات (راجع مثال الحمولة)	يمثل التسليم الافتراضي لجدار الحماية للحزم التي لا تفي بأي قاعدة محددة. في سياق iptables، يتم تعيين هذا إلى نهج السلسلة لسلاسل الإدخال والإخراج لجدول التصفية. في محركات جدار الحماية الأخرى، سيؤدي ذلك إلى تعيين سلوك محرك جدار الحماية حسب الحاجة. على سبيل المثال، لا تحتوي بعض محركات جدار الحماية على فكرة سياسة صريحة، وتسقط حركة المرور بطبيعتها والتي لا تفي بأي قاعدة.
بصمات الاصابع	سلسلة	• بصمة مبهمة لقائمة جميع قواعد جدار الحماية على الجهاز • يستخدم لمقارنة أعداد كبيرة من الأجهزة بجهاز معروف ملاحظة: في إصدارات OSConfig قبل إصدار أكتوبر 2022، كانت هذه الخاصية تعرف باسم "firewallFingerprint"
الولاية	تعداد السلاسل	حالة عالية المستوى لجدار حماية المضيف. القيم المحتملة هي: • `unknown` • `enabled` • `disabled` المنطق هو `enabled` أنه تم الكشف عن محرك جدار حماية نشط وبقاعدة واحدة على الأقل في جدول FILTER. ملاحظة: في إصدارات OSConfig قبل إصدار أكتوبر 2022، تم تقديم هذه المعلومات على أنها "firewallState" (بدلا من "state") وكانت القيم عبارة عن أعداد صحيحة (بدلا من سلاسل).

مثال على الحمولة (كما هو ملاحظ في قسم التوأم properties.reported )

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

قواعد جدار الحماية المطلوبة

تنبيه

كما هو الحال مع أي إدارة جدار حماية، انتبه كثيرا عند حظر حركة المرور. لديك القدرة على منع الجهاز من متابعة اتصاله ب IoT Hub أو قنوات إدارية أخرى. في مثل هذه الحالات قد تكون هناك حاجة إلى الوصول المحلي إلى الجهاز للاسترداد.

المسار: properties.desired.Firewall.desiredRules (Firewall مكون، desiredRules خاصية قابلة للكتابة)
الوصف: قائمة مرتبة من واصفات القواعد. يمكن أن يكون لكل واصف قاعدة في القائمة الأعضاء التالين.

أعضاء كل واصف قاعدة

الاسم	النوع	ملاحظات
desiredState	تعداد السلاسل	مطلوب دائما. القيم المحتملة هي `present` (تعني أنه يجب إنشاء مثل هذه القاعدة إذا لم تكن هناك قاعدة مطابقة موجودة بالفعل)، أو `absent` (تعني أنه يجب حذف أي قاعدة موجودة على الجهاز الذي يطابق هذا الواصف إذا تم العثور عليها. بالنسبة لواصفات القواعد حيث `desiredState: "present"` وحيث لا توجد قاعدة مطابقة بالفعل على الجهاز، تتم إضافة القاعدة الجديدة في أعلى قائمة القواعد على الجهاز. بالنسبة للسياق، يمكنك التفكير في هذا على أنه مماثل ل `iptables -I` بدلا من `iptables -A`. إذا كانت واصفات قواعد متعددة `desiredState: "present"` موجودة في `desiredRules`، تتم إضافتها بحيث يتم الاحتفاظ بالترتيب. بمعنى آخر، ستكون القاعدة العليا في `desiredRules` أعلى قائمة القواعد على الجهاز، وستتبع القاعدة `desiredRules` التالية في ذلك في قائمة القواعد على الجهاز، وهكذا.
إجراء	تعداد السلاسل	مطلوب دائما. القيم المُحتملة هي `accept` و`drop` أو `reject`.
direction	تعداد السلاسل	مطلوب دائما. القيم المُحتملة هي `in` أو `out`.
البروتوكول	تعداد السلاسل	مطلوب دائما. القيم المُحتملة هي `any` و`udp` و`tcp` و`icmp`. لاحظ أن يعني `any` أي حركة مرور (على عكس معنى "كل من tcp وudp، ولكن ليس بروتوكولات IP الأخرى). وفقا لذلك، يجب ألا تتضمن `sourcePort` القواعد أو .`destinationPortprotocol: "any"`
عنوان المصدر	سلسلة	عنوان IP أو نطاق CIDR. إذا لم يتم تحديدها، فستتطابق القاعدة الناتجة مع أي عنوان
منفذ المصدر	عدد صحيح	ذات صلة بالقواعد حيث `protocol: tcp` أو `protocol:udp`. يجب عدم تضمينها في قواعد أخرى. تحديد رقم المنفذ عند تضمينه في قاعدة ذات صلة. عند عدم تضمينها، يشير إلى قاعدة يجب أن تتطابق مع أي رقم منفذ.
عنوان الوجهة	سلسلة	عنوان IP أو نطاق CIDR. إذا لم يتم تحديدها، فستتطابق القاعدة الناتجة مع أي عنوان
منفذ الوجهة	عدد صحيح	ذات صلة بالقواعد حيث `protocol: tcp` أو `protocol:udp`. يجب عدم تضمينها في قواعد أخرى. تحديد رقم المنفذ عند تضمينه في قاعدة ذات صلة. عند عدم تضمينها، يشير إلى قاعدة يجب أن تتطابق مع أي رقم منفذ.

مثال على الحمولة (كما هو ملاحظ في قسم التوأم properties.desired )

تمثل القواعد التالية نوايا المسؤول التالية:

"الشبكة الفرعية للمسؤول المحلية هي 10.9.9.0/24، لذلك أريد أن تسمح الأجهزة للمنفذ الوارد 22 (SSH) من هناك"
"كانت الشبكة الفرعية للمسؤول القديم 10.24.24.0/24، لذلك إذا كان أي جهاز لا يزال لديه قاعدة تسمح بالمنفذ 22 (SSH) من هناك، أريد إزالة مثل هذه القاعدة"

ملاحظة: قد يرغب المسؤول في قاعدة ثالثة هنا لحظر SSH من كل مكان (مع الاستثناء أعلاه)، ولكن في هذا المثال سنستخدم نهج إسقاط افتراضي، مما يجعل مثل هذه القاعدة زائدة عن الحاجة. desiredDefaultPolicies راجع المثال لاحقا في هذا المستند.

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

لاحظ أنه عندما يقوم سير عمل إداري بتعيين properties.desired.Firewall.desiredRules ( مكون، desiredRules خاصية قابلة للكتابة من منظور DTDL)، يقر الجهاز بإيصال نفس الشيء عن طريق إضافة خاصية desiredRules إلى properties.reported.FirewallFirewall . تتضمن قيمة هذه الخاصية نسخة من الحمولة الأصلية desiredRules ، إلى جانب رقم الإصدار ورمز الحالة. يمكن أن تستخدم مهام سير العمل الإدارية المستندة إلى IoT Hub هذا لتحديد ما إذا كانت الحالة المطلوبة قد وصلت إلى الجهاز بعد. هذا فقط اعتراف. لتحديد ما إذا كان الجهاز قد نجح في الوصول إلى الحالة المطلوبة، راجع configurationStatus أيضا و configurationStatusDetail.

نهج جدار الحماية المرغوبة

تنبيه

تتطلب النهج الافتراضية تطبيقا دقيقا بشكل خاص. على الأنظمة المستندة إلى iptables، على سبيل المثال، تنطبق النهج على كل حزمة على حدة دون النظر في الاتصالات الموجودة. وبعبارة أخرى، فإن نهج الإرادة drop الافتراضي الوارد (بالإضافة إلى حظر الاتصالات الواردة الجديدة) يمنع الاستجابات من الأنظمة البعيدة. يمكن أن يجعل هذا من المستحيل على الجهاز الاتصال الصادر باستخدام بروتوكولات (مثل TCP) التي تتطلب تدفق حزمة ثنائية الاتجاه. لا تقم بتعيين action إلى drop على in النهج أو out دون التأكد أولا من وجود قواعد محددة لتمكين جميع الحزم المطلوبة في كلا الاتجاهين.

المسار: properties.desired.Firewall.desiredDefaultPolicies (Firewall مكون، desiredDefaultPolicies خاصية قابلة للكتابة)
الوصف: صفيف ذو عنصرين، يصف السلوك الافتراضي المطلوب (قبول أو إسقاط) لنسبة استخدام الشبكة الواردة وحركة المرور الصادرة.

أعضاء كل عنصر

الاسم	النوع	ملاحظات
direction	تعداد السلاسل	القيم المحتملة هي `in` أو `out`
إجراء	تعداد السلاسل	مطلوب دائما. القيم المُحتملة هي `accept` أو `drop`.

مثال على الحمولة (كما هو ملاحظ في قسم التوأم properties.desired )

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

لاحظ أنه عندما تقوم مهام سير عمل إدارية بتعيين properties.desired.Firewall.desiredDefaultPolicies ( مكون، desiredDefaultPolicies خاصية قابلة للكتابة من منظور DTDL)، يقر الجهاز بإيصال نفس الشيء عن طريق إضافة خاصية desiredDefaultPolicies إلى properties.reported.FirewallFirewall . تتضمن قيمة هذه الخاصية نسخة من الحمولة الأصلية، إلى جانب رقم الإصدار ورمز الحالة. يمكن أن تستخدم مهام سير العمل الإدارية المستندة إلى IoT Hub هذا لتحديد ما إذا كانت الحالة المطلوبة قد وصلت إلى الجهاز بعد. هذا مجرد إقرار بالإيصال والمعالجة. لمزيد من المعلومات حول نجاح أو فشل الوصول إلى الحالة المطلوبة، راجع configurationStatus و configurationStatusDetail.

معلومات إضافية وأسئلة المتداولة

ماذا عن حالة استخدام "استبدال كل شيء"؟

في بعض الحالات، قد يرغب المسؤولون في فرض التحكم المطلق في القائمة الصافية لقواعد جدار الحماية الخاصة بالجهاز. تخيل نية مثل، "يجب أن توجد القواعد X وY وZ فقط؛ يجب إزالة أي قواعد أخرى (موجودة مسبقا على الجهاز أو تم إنشاؤها بمرور الوقت بواسطة عمليات أخرى) بشكل دوري." في هذا الوقت، لا توفر الوحدة النمطية OSConfig Firewall حالة الاستخدام هذه مباشرة. يمكن إنجاز إزالة قواعد محددة من خلال desiredRules و "desiredState": "absent"، ولكن لا توجد وظائف استبدال الكل صريحة. إذا كنت ترغب في إضافة مثل هذه الميزة، فشاهد وثائق القابلية للتوسعة في https://github.com/Azure/azure-osconfig.

الخطوات التالية

للحصول على نظرة عامة على سيناريوهات وقدرات OSConfig، راجع:

ما هو OSconfig ل IoT

للحصول على أمثلة عملية محددة، راجع:

مشاركة عبر

إدارة جدار حماية المضيف باستخدام Azure IoT وOSConfig

الجمهور

نظرة عامة على جدار الحماية

أمثلة على حالات الاستخدام

المتطلبات الأساسية لتجربة الأمثلة على الأنظمة المباشرة

مثال A. هل جدار حماية المضيف نشط؟

مثال ب. إنشاء قاعدة جدار حماية

مثال C. مقارنة بصمة حالة جدار الحماية للعديد من الأجهزة بجهاز معروف جيد

معلومات مرجعية

وصف نموذج الكائن

خصائص جدار الحماية المبلغ عنها/للقراءة فقط (لسيناريوهات إعداد التقارير والتدقيق)

قواعد جدار الحماية المطلوبة

نهج جدار الحماية المرغوبة

معلومات إضافية وأسئلة المتداولة

ماذا عن حالة استخدام "استبدال كل شيء"؟

الخطوات التالية

الموارد الإضافية