فهم كيفية استخدام Azure IoT Edge للشهادات

ينطبق على: IoT Edge 1.5 IoT Edge 1.4

هام

IoT Edge 1.5 LTS وIoT Edge 1.4 LTS هي إصدارات مدعومة. IoT Edge 1.4 LTS هو نهاية العمر الافتراضي في 12 نوفمبر 2024. إذا كنت تستخدم إصدارا سابقا، فشاهد تحديث IoT Edge.

يستخدم IoT Edge أنواعا مختلفة من الشهادات لأغراض مختلفة. ترشدك هذه المقالة عبر الطرق المختلفة التي يستخدم بها IoT Edge الشهادات مع سيناريوهات بوابة Azure IoT Hub وIoT Edge.

هام

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

• تمت إعادة تسمية شهادة المرجع المصدق للجهاز في الإصدار 1.1 إلى شهادة المرجع المصدق ل Edge.
• تم إيقاف شهادة CA لحمل العمل في الإصدار 1.1. في الإصدار 1.2 أو أحدث، ينشئ وقت تشغيل الوحدة النمطية IoT Edge جميع شهادات الخادم مباشرة من شهادة المرجع المصدق ل Edge، دون شهادة CA لحمل العمل الوسيط بينهما في سلسلة الشهادات.

الملخص

هذه السيناريوهات الأساسية هي المكان الذي يستخدم فيه IoT Edge الشهادات. استخدم الارتباطات لمعرفة المزيد حول كل سيناريو.

الفاعل	الغرض	شهادة
IoT Edge	يضمن أنه يتصل بمركز IoT الصحيح	شهادة خادم IoT Hub
IoT Hub	يضمن أن الطلب جاء من جهاز IoT Edge شرعي	شهادة هوية IoT Edge
جهاز IoT المتلقي للمعلومات	يضمن أنه يتصل ببوابة IoT Edge الصحيحة	شهادة خادم وحدة IoT Edge Hub edgeHub النمطية، الصادرة عن Edge CA
IoT Edge	توقيع شهادات خادم وحدة نمطية جديدة. على سبيل المثال، edgeHub	شهادة Edge CA
IoT Edge	يضمن أن الطلب جاء من جهاز انتقال البيانات من الخادم الشرعي	شهادة هوية جهاز IoT

المتطلبات الأساسية

• يجب أن يكون لديك فهم أساسي لتشفير المفتاح العام وأزواج المفاتيح وكيف يمكن للمفتاح العام والمفتاح الخاص تشفير البيانات أو فك تشفيرها. لمزيد من المعلومات حول كيفية استخدام IoT Edge لتشفير المفتاح العام، راجع فهم تشفير المفتاح العام والبنية الأساسية للمفتاح العام X.509.
• يجب أن يكون لديك فهم أساسي حول كيفية ارتباط IoT Edge ب IoT Hub. لمزيد من المعلومات، راجع فهم وقت تشغيل Azure IoT Edge وهندسته.

سيناريو جهاز واحد

للمساعدة في فهم مفاهيم شهادة IoT Edge، تخيل سيناريو حيث يتصل جهاز IoT Edge المسمى EdgeGateway بمركز Azure IoT المسمى ContosoIotHub. في هذا المثال، تتم جميع المصادقة باستخدام مصادقة شهادة X.509 بدلا من المفاتيح المتماثلة. لتأسيس الثقة في هذا السيناريو، نحتاج إلى ضمان أن يكون IoT Hub وجهاز IoT Edge أصليين: "هل هذا الجهاز أصلي وصحيح؟" و"هل هوية IoT Hub صحيحة؟". يمكن توضيح السيناريو على النحو التالي:

سنشرح إجابات كل سؤال ثم نوسع المثال في أقسام لاحقة من المقالة.

يتحقق الجهاز من هوية IoT Hub

كيف يتحقق EdgeGateway من أنه يتواصل مع ContosoIotHub الأصلي؟ عندما يريد EdgeGateway التحدث إلى السحابة، فإنه يتصل بنقطة النهاية ContosoIoTHub.Azure-devices.NET. للتأكد من أن نقطة النهاية أصلية، يحتاج IoT Edge إلى ContosoIoTHub لإظهار الهوية (المعرف). يجب إصدار المعرف من قبل مرجع يثق به EdgeGateway . للتحقق من هوية IoT Hub، يستخدم IoT Edge وIoT Hub بروتوكول تأكيد اتصال TLS للتحقق من هوية خادم IoT Hub. يتم توضيح تأكيد اتصال TLS في الرسم التخطيطي التالي. لإبقاء المثال بسيطا، تم حذف بعض التفاصيل. لمعرفة المزيد حول بروتوكول تأكيد اتصال TLS، راجع تأكيد اتصال TLS على ويكيبيديا.

إشعار

في هذا المثال، يمثل ContosoIoTHub اسم مضيف IoT Hub ContosoIotHub.Azure-devices.NET.

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

في السيناريو لدينا، يعرض ContosoIotHub سلسلة الشهادات التالية:

المرجع المصدق الجذر (CA) هو شهادة Baltimore CyberTrust Root . تم توقيع شهادة الجذر هذه من قبل DigiCert، وهي موثوق بها وتخزينها على نطاق واسع في العديد من أنظمة التشغيل. على سبيل المثال، يقوم كل من Ubuntu وWindows بتضمينه في مخزن الشهادات الافتراضي.

متجر شهادات Windows:

مخزن شهادات Ubuntu:

عندما يتحقق الجهاز من شهادة Baltimore CyberTrust Root ، يتم تثبيتها مسبقا في نظام التشغيل. من منظور EdgeGateway ، نظرا لأن سلسلة الشهادات التي تقدمها ContosoIotHub موقعة من قبل مرجع مصدق جذر يثق به نظام التشغيل، تعتبر الشهادة جديرة بالثقة. تعرف الشهادة باسم شهادة خادم IoT Hub. لمعرفة المزيد حول شهادة خادم IoT Hub، راجع دعم أمان طبقة النقل (TLS) في IoT Hub.

باختصار، يمكن ل EdgeGateway التحقق من هوية ContosoIotHub والثقة بها بسبب:

• تقدم ContosoIotHub شهادة خادم IoT Hub الخاصة بها
• شهادة الخادم موثوق بها في مخزن شهادات نظام التشغيل
• يمكن فك تشفير البيانات المشفرة باستخدام المفتاح العام ل ContosoIotHub بواسطة ContosoIotHub، مما يثبت حيازتها للمفتاح الخاص

يتحقق IoT Hub من هوية جهاز IoT Edge

كيف تتحقق ContosoIotHub من اتصالها ب EdgeGateway؟ نظرا لأن IoT Hub يدعم TLS المتبادل (mTLS)، فإنه يتحقق من شهادة EdgeGateway أثناء تأكيد اتصال TLS المصادق عليه من قبل العميل. للتبسيط، سنتخطى بعض الخطوات في الرسم التخطيطي التالي.

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

تلميح

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

على سبيل المثال، يمكننا استخدام الأمر التالي للحصول على بصمة الإبهام لشهادة الهوية على EdgeGateway:

sudo openssl x509 -in /var/lib/aziot/certd/certs/deviceid-random.cer -noout -nocert -fingerprint -sha256

يقوم الأمر بإخراج بصمة إبهام الشهادة SHA256:

SHA256 Fingerprint=1E:F3:1F:88:24:74:2C:4A:C1:A7:FA:EC:5D:16:C4:11:CD:85:52:D0:88:3E:39:CB:7F:17:53:40:9C:02:95:C3

إذا عرضنا قيمة بصمة الإبهام SHA256 لجهاز EdgeGateway المسجل في IoT Hub، يمكننا أن نرى أنها تتطابق مع بصمة الإبهام على EdgeGateway:

باختصار، يمكن أن تثق ContosoIotHub في EdgeGateway لأن EdgeGateway يقدم شهادة هوية جهاز IoT Edge صالحة تتطابق بصمة إبهامها مع تلك المسجلة في IoT Hub.

لمزيد من المعلومات حول عملية إنشاء الشهادات، راجع إنشاء وتوفير جهاز IoT Edge على Linux باستخدام شهادات X.509.

إشعار

لا يتناول هذا المثال خدمة توفير جهاز Azure IoT Hub (DPS)، والتي لديها دعم لمصادقة المرجع المصدق X.509 مع IoT Edge عند توفيرها مع مجموعة تسجيل. باستخدام DPS، يمكنك تحميل شهادة CA أو شهادة وسيطة، ويتم التحقق من سلسلة الشهادات، ثم يتم توفير الجهاز. لمعرفة المزيد، راجع إثبات شهادة DPS X.509.

في مدخل Microsoft Azure، يعرض DPS بصمة الإبهام SHA1 للشهادة بدلا من بصمة الإبهام SHA256.

يقوم DPS بتسجيل بصمة الإبهام SHA256 أو تحديثها إلى IoT Hub. يمكنك التحقق من بصمة الإبهام باستخدام الأمر openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256. بمجرد التسجيل، يستخدم Iot Edge مصادقة بصمة الإبهام مع IoT Hub. إذا تمت إعادة توفير الجهاز وتم إصدار شهادة جديدة، يقوم DPS بتحديث IoT Hub ببصمة الإبهام الجديدة.

لا يدعم IoT Hub حاليا مصادقة المرجع المصدق X.509 مباشرة مع IoT Edge.

استخدام الشهادة لعمليات هوية الوحدة النمطية

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

التفاعل بين الوحدات النمطية وIoT Hub آمن لأن مفتاح SAS مشتق من سر ويدير IoT Edge المفتاح دون خطر التدخل البشري.

سيناريو التسلسل الهرمي للجهاز المتداخل مع IoT Edge كبوابة

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

نضيف جهاز IoT عاديا يسمى TempSensor، والذي يتصل بجهاز IoT Edge الأصل EdgeGateway الذي يتصل ب IoT Hub ContosoIotHub. على غرار ما سبق، تتم جميع المصادقة باستخدام مصادقة شهادة X.509. يطرح السيناريو الجديد سؤالين جديدين: "هل جهاز TempSensor شرعي؟" و"هل هوية EdgeGateway صحيحة؟". يمكن توضيح السيناريو على النحو التالي:

تلميح

TempSensor هو جهاز IoT في السيناريو. مفهوم الشهادة هو نفسه إذا كان TempSensor هو جهاز IoT Edge المتلقي للمعلومات ل EdgeGateway الأصل.

يتحقق الجهاز من هوية البوابة

كيف يتحقق TempSensor من أنه يتواصل مع EdgeGateway الأصلي؟ عندما يريد TempSensor التحدث إلى EdgeGateway، يحتاج TempSensor إلى EdgeGateway لإظهار معرف. يجب إصدار المعرف من قبل سلطة يثق بها TempSensor .

التدفق هو نفسه عندما يتحدث EdgeGateway إلى ContosoIotHub. يستخدم TempSensor وEdgeGateway بروتوكول تأكيد اتصال TLS للتحقق من هوية EdgeGateway. هناك تفصيلان مهمان:

• خصوصية اسم المضيف: يجب إصدار الشهادة التي يقدمها EdgeGateway لنفس اسم المضيف (المجال أو عنوان IP) الذي يستخدمه TempSensor للاتصال ب EdgeGateway.
• خصوصية المرجع المصدق الجذر الموقع ذاتيا: من المحتمل ألا تكون سلسلة الشهادات التي يقدمها EdgeGateway في مخزن الجذر الافتراضي الموثوق به لنظام التشغيل.

لفهم التفاصيل، دعونا أولا نفحص سلسلة الشهادات التي يقدمها EdgeGateway.

خصوصية اسم المضيف

يتم سرد الاسم الشائع للشهادة CN = edgegateway.local في أعلى السلسلة. edgegateway.local هو الاسم الشائع لشهادة خادم edgeHub. edgegateway.local هو أيضا اسم المضيف ل EdgeGateway على الشبكة المحلية (LAN أو VNet) حيث يتم توصيل TempSensor و EdgeGateway . قد يكون عنوان IP خاصا مثل 192.168.1.23 أو اسم مجال مؤهل بالكامل (FQDN) مثل الرسم التخطيطي. يتم إنشاء شهادة خادم edgeHub باستخدام معلمةاسم المضيف المحددة في ملف IoT Edge config.toml. لا تخلط بين شهادة خادم edgeHub وشهادةالمرجع المصدق ل Edge. لمزيد من المعلومات حول إدارة شهادة المرجع المصدق ل Edge، راجع إدارة شهادات IoT Edge.

عندما يتصل TempSensor ب EdgeGateway، يستخدم TempSensor اسم المضيف edgegateway.local للاتصال ب EdgeGateway. يتحقق TempSensor من الشهادة المقدمة من EdgeGateway ويتحقق من أن الاسم الشائع للشهادة هو edgegateway.local. إذا كان الاسم الشائع للشهادة مختلفا، يرفض TempSensor الاتصال.

إشعار

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

لماذا يحتاج EdgeGateway إلى إعلامه باسم المضيف الخاص به؟

لا يملك EdgeGateway طريقة موثوقة لمعرفة كيفية اتصال العملاء الآخرين على الشبكة به. على سبيل المثال، على شبكة خاصة، قد تكون هناك خوادم DHCP أو خدمات mDNS التي تسرد EdgeGateway ك 10.0.0.2 أو example-mdns-hostname.local. ولكن، قد تحتوي بعض الشبكات على خوادم DNS يتم تعيينها edgegateway.local إلى عنوان 10.0.0.2IP الخاص ب EdgeGateway.

لحل المشكلة، يستخدم IoT Edge قيمة اسم المضيف المكونة في config.toml وينشئ شهادة خادم لها. عندما يتعلق الطلب بوحدة edgeHub النمطية، فإنه يقدم الشهادة بالاسم الشائع الصحيح للشهادة (CN).

لماذا ينشئ IoT Edge شهادات؟

في المثال، لاحظ أن هناك iotedged workload ca edgegateway في سلسلة الشهادات. إنها المرجع المصدق (CA) الموجود على جهاز IoT Edge المعروف باسم Edge CA (المعروف سابقا باسم المرجع المصدق للجهاز في الإصدار 1.1). مثل المرجع المصدق الجذري ل Baltimore CyberTrust في المثال السابق، يمكن ل Edge CA إصدار شهادات أخرى. الأهم من ذلك، وأيضا في هذا المثال، فإنه يصدر شهادة الخادم إلى وحدة edgeHub . ولكن، يمكن أيضا إصدار شهادات للوحدات النمطية الأخرى التي تعمل على جهاز IoT Edge.

هام

بشكل افتراضي بدون تكوين، يتم إنشاء Edge CA تلقائيا بواسطة وقت تشغيل الوحدة النمطية IoT Edge عند بدء تشغيله لأول مرة، والمعروف باسم quickstart Edge CA، ثم يصدر شهادة إلى وحدة edgeHub . تعمل هذه العملية على تسريع اتصال جهاز انتقال البيانات من الخادم عن طريق السماح ل edgeHub بتقديم شهادة صالحة موقعة. بدون هذه الميزة، سيتعين عليك الحصول على المرجع المصدق لإصدار شهادة لوحدة edgeHub النمطية. استخدام مرجع مصدق ل Edge للتشغيل السريع الذي تم إنشاؤه تلقائيا غير مدعوم للاستخدام في الإنتاج. لمزيد من المعلومات حول التشغيل السريع ل Edge CA، راجع Quickstart Edge CA.

أليس من الخطر أن يكون لديك شهادة مصدر على الجهاز؟

تم تصميم المرجع المصدق Edge لتمكين الحلول ذات الاتصال المحدود أو غير الموثوق به أو المكلف أو الغائب ولكن في نفس الوقت لديها لوائح أو سياسات صارمة بشأن تجديد الشهادات. بدون Edge CA، لا يمكن ل IoT Edge - وبشكل خاص edgeHub - العمل.

لتأمين المرجع المصدق ل Edge في الإنتاج:

• ضع مفتاح EdgeCA الخاص في وحدة نمطية للنظام الأساسي الموثوق به (TPM)، ويفضل أن يكون بطريقة يتم فيها إنشاء المفتاح الخاص بشكل سريع ولا يترك TPM أبدا.
• استخدم البنية الأساسية للمفتاح العام (PKI) التي يظهر بها Edge CA. يوفر هذا القدرة على تعطيل أو رفض تجديد الشهادات المخترقة. يمكن إدارة PKI بواسطة تكنولوجيا المعلومات للعميل إذا كان لديه معرفة كيفية (تكلفة أقل) أو من خلال موفر PKI تجاري.

خصوصية المرجع المصدق الجذر الموقع ذاتيا

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

إشعار

لا يستخدم بعض العملاء وSDKs مخزن الجذر الموثوق به لنظام التشغيل وتحتاج إلى تمرير ملف المرجع المصدق الجذر مباشرة.

بتطبيق كل هذه المفاهيم، يمكن ل TempSensor التحقق من أنه يتواصل مع EdgeGateway الأصلي لأنه قدم شهادة تطابق العنوان وتم توقيع الشهادة من قبل جذر موثوق به.

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

openssl s_client -connect edgegateway.local:8883 --CAfile my_private_root_CA.pem

depth=3 CN = my_private_root_CA
verify return:1
depth=2 CN = my_optional_intermediate_CA
verify return:1
depth=1 CN = iotedged workload ca edgegateway
verify return:1
depth=0 CN = edgegateway.local
verify return: 1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=edgegateway.local
  i:/CN=iotedged workload ca edgegateway
1 s:/CN=iotedged workload ca edgegateway
  i:/CN=my_optional_intermediate_CA
2 s:/CN=my_optional_intermediate_CA
  i:/CN=my_private_root_CA

لمعرفة المزيد حول openssl الأمر، راجع وثائق OpenSSL.

يمكنك أيضا فحص الشهادات حيث يتم تخزينها بشكل افتراضي في /var/lib/aziot/certd/certs. يمكنك العثور على شهادات المرجع المصدق ل Edge وشهادات هوية الجهاز وشهادات الوحدة النمطية في الدليل. يمكنك استخدام openssl x509 الأوامر لفحص الشهادات. على سبيل المثال:

sudo ls -l /var/lib/aziot/certd/certs

total 24
-rw-r--r-- 1 aziotcs aziotcs 1090 Jul 27 21:27 aziotedgedca-86f154be7ff14480027f0d00c59c223db6d9e4ab0b559fc523cca36a7c973d6d.cer
-rw-r--r-- 1 aziotcs aziotcs 2589 Jun 22 18:25 aziotedgedmoduleIoTEdgeAPIProxy637913460334654299server-c7066944a8d35ca97f1e7380ab2afea5068f39a8112476ffc89ea2c46ca81d10.cer
-rw-r--r-- 1 aziotcs aziotcs 2576 Jun 22 18:25 aziotedgedmoduleedgeHub637911101449272999server-a0407493b6b50ee07b3fedbbb9d181e7bb5f6f52c1d071114c361aca628daa92.cer
-rw-r--r-- 1 aziotcs aziotcs 1450 Jul 27 21:27 deviceid-bd732105ef89cf8edd2606a5309c8a26b7b5599a4e124a0fe6199b6b2f60e655.cer

باختصار، يمكن أن يثق TempSensor في EdgeGateway بسبب:

• أظهرت الوحدة النمطية edgeHub شهادة خادم وحدة IoT Edge صالحة ل edgegateway.local
• يتم إصدار الشهادة من قبل المرجع المصدق Edge الذي يتم إصداره من قبل my_private_root_CA
• يتم تخزين المرجع المصدق الجذر الخاص هذا أيضا في TempSensor كمرجع مصدق جذري موثوق به سابقا
• تتحقق خوارزميات التشفير من أن سلسلة الملكية والإصدار يمكن الوثوق بها

شهادات للوحدات النمطية الأخرى

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

تتحقق البوابة من هوية الجهاز

كيف يتحقق EdgeGateway من اتصاله ب TempSensor؟ يستخدم EdgeGateway مصادقة عميل TLS لمصادقة TempSensor.

التسلسل مشابه ل ContosoIotHub للتحقق من جهاز. ومع ذلك، في سيناريو البوابة، يعتمد EdgeGateway على ContosoIotHub كمصدر للحقيقة لسجل الشهادات. يحتفظ EdgeGateway أيضا بنسخة غير متصلة أو ذاكرة تخزين مؤقت في حالة عدم وجود اتصال بالسحابة.

تلميح

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

باختصار، يمكن أن يثق EdgeGateway في TempSensor بسبب:

• قدم TempSensor شهادة هوية جهاز IoT صالحة لاسمه
• تطابق بصمة إبهام شهادة الهوية تلك التي تم تحميلها إلى ContosoIotHub
• تتحقق خوارزميات التشفير من أن سلسلة الملكية والإصدار يمكن الوثوق بها

مكان الحصول على الشهادات والإدارة

في معظم الحالات، يمكنك توفير الشهادات الخاصة بك أو الاستخدام على الشهادات التي تم إنشاؤها تلقائيا. على سبيل المثال، يتم إنشاء المرجع المصدقEdge وشهادة edgeHub تلقائيا.

ومع ذلك، فإن أفضل الممارسات هي تكوين أجهزتك لاستخدام خادم التسجيل عبر النقل الآمن (EST) لإدارة شهادات x509. يؤدي استخدام خادم EST إلى تحريرك من معالجة الشهادات يدويا وتثبيتها على الأجهزة. لمزيد من المعلومات حول استخدام خادم EST، راجع تكوين التسجيل عبر خادم النقل الآمن ل Azure IoT Edge.

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

إذا لم تتمكن من استخدام خادم EST، فيجب عليك طلب شهادات من موفر PKI الخاص بك. يمكنك إدارة ملفات الشهادات يدويا في IoT Hub وأجهزة IoT Edge. لمزيد من المعلومات، قم بإدارة الشهادات على جهاز IoT Edge.

لإثبات تطوير المفهوم، يمكنك إنشاء شهادات اختبار. لمزيد من المعلومات، راجع إنشاء شهادات تجريبية لاختبار ميزات جهاز IoT Edge.

الشهادات في IoT

هيئة الشهادات

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

الشهادة الخاصة بالمرجع المصدق الجذر

الشهادة لخاصة بالمرجع المصدق الجذر هو جذر الثقة في العملية بأكملها. في سيناريوهات الإنتاج، يتم شراء شهادة المرجع المصدق هذه من مرجع مصدق تجاري موثوق به مثل Baltimore أو Verisign أو DigiCert. إذا كان لديك عنصر تحكم كامل في الأجهزة المتصلة بأجهزةIoT Edge، فمن الممكن استخدام مرجع شهادة على مستوى الشركة. في كلتا الحالتين، تستخدم سلسلة الشهادات بأكملها من IoT Edge إلى IoT Hub. يجب أن تثق أجهزة IoT المتلقية للمعلومات في شهادة الجذر. يمكنك تخزين الشهادة الخاصة بالمرجع المصدق الجذر إما في مخزن المرجع المصدق الجذر الموثوق به أو توفير تفاصيل الشهادة في التعليمات البرمجية للتطبيق الخاص بك.

الشهادات المتوسطة

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

• تسلسل هرمي للأقسام داخل الشركة المصنعة
• شركات متعددة تشارك بشكل تسلسلي في إنتاج جهاز
• عميل يشتري مرجعا مصدقا جذريا ويستمد شهادة توقيع للشركة المصنعة لتوقيع الأجهزة التي يقوم بها نيابة عن هذا العميل

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

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

• لمزيد من المعلومات حول كيفية تثبيت الشهادات على جهاز IoT Edge والإشارة إليها من ملف التكوين، راجع إدارة الشهادة على جهاز IoT Edge.
• فهم وحدات Azure IoT Edge النمطية
• تكوين جهاز IoT Edge ليكون بمثابة بوابة شفافة
• تتناول هذه المقالة الشهادات المستخدمة لتأمين الاتصالات بين المكونات المختلفة على جهاز IoT Edge أو بين جهاز IoT Edge وأي أجهزة انتقال البيانات من الخادم. يمكنك أيضا استخدام الشهادات لمصادقة جهاز مزود بـ IoT Edge إلى مركز IoT. تختلف شهادات المصادقة هذه، ولا تتم مناقشتها في هذه المقالة. لمزيد من المعلومات حول مصادقة جهازك باستخدام الشهادات، راجع إنشاء جهاز IoT Edge وتوفيره باستخدام شهادات X.509.