تقدم هذه المقالة إجابات لبعض الأسئلة الأكثر شيوعًا حول Azure Attestation.
إذا لم يتم تناول مشكلة Azure في هذه المقالة، فيمكنك أيضا إرسال طلب دعم Azure على صفحة دعم Azure.
ما هي إدارة هوية الأجهزة الموثوق بها (THIM) ودورها في إثبات الجيب؟
تجلب إدارة هوية الأجهزة الموثوق بها (THIM) أساس أمان Azure لعقد الحوسبة السرية Azure (ACC) من Intel وتخزن البيانات مؤقتا. يستخدم Azure Attestation أيضا المعلومات المخزنة مؤقتا في التحقق من صحة بيئات التنفيذ الموثوق بها (TEEs).
يوصى باستخدام THIM للأسباب التالية:
- يوفر قابلية وصول عالية
- يقلل من التبعيات على الخدمات المستضافة خارجيا والاتصال بالإنترنت.
- يجلب بشكل دوري الإصدارات الأحدث من شهادات Intel وقوائم CRLs ومعلومات قاعدة الحوسبة الموثوق بها (TCB) وهوية Quoting Enclave لعقد ACC من Intel. تؤكد الخدمة أن أساس أمان Azure ستتم الإشارة إليه بواسطة Azure Attestation أثناء التحقق من صحة TEEs، ما يقلل إلى حد كبير من حالات فشل التصديق بسبب إبطال شهادات Intel أو إبطالها.
هل شهادة ملحقات Software Guard (SGX) مدعومة من Azure Attestation في بيئات غير Azure؟
لا. يعتمد Azure Attestation على أساس الأمان الذي حددته إدارة هوية الأجهزة الموثوق بها (THIM) للتحقق من صحة TEEs. تم تصميم THIM حاليا لدعم عقد الحوسبة السرية Azure فقط.
ما هي عمليات التحقق من الصحة التي يقوم بها Azure Attestation للمصادقة على جيوب SGX؟
أثناء عملية تصديق SGX، يقوم Azure Attestation بإجراء عمليات التحقق التالية:
- التحقق مما إذا كان الجذر الموثوق به لاقتباس الجيب الموقع ينتمي إلى Intel
- التحقق من صحة ما إذا كان عرض أسعار TEE يلبي أساس أمان Azure كما هو محدد بواسطة إدارة هوية الأجهزة الموثوق بها (THIM)
- إذا قام العميل بإنشاء موفر تصديق وتكوين نهج مخصص، بالإضافة إلى عمليات التحقق من الصحة أعلاه، فإن Azure Attestation يقيم عرض أسعار TEE مقابل نهج التصديق. يمكن للعملاء استخدام نهج التصديق لتحديد قواعد التخويل ل TEE وأيضا إملاء قواعد الإصدار لإنشاء رمز التصديق المميز.
كيف يمكن لمدقق الحصول على الضمانات الخاصة بمصادقة SGX المدعومة من Azure Attestation؟
بشكل عام، بالنسبة لنماذج التصديق مع Intel كجذر للثقة، يتحدث عميل التصديق إلى واجهات برمجة تطبيقات الجيب لجلب أدلة الجيب. تستدعي واجهات برمجة تطبيقات الجيب داخليا خدمة التخزين المؤقت Intel PCK لإحضار شهادات Intel للعقدة ليتم التصديق عليها. وتستخدم الشهادات لتوقيع دليل الجيب مما يؤدي إلى الحصول على ضمانات يمكن التصديق عليها عن بعد.
يمكن تنفيذ نفس العملية ل Azure Attestation. ومع ذلك لجني الفوائد التي تقدمها إدارة هوية الأجهزة الموثوق بها (THIM)، بعد تثبيت الجهاز الظاهري ACC، يوصى بتثبيت مكتبة Azure DCAP. استنادا إلى الاتفاقية مع Intel، عند تثبيت مكتبة Azure DCAP، تتم إعادة توجيه طلبات إنشاء أدلة الجيب من خدمة التخزين المؤقت Intel PCK إلى THIM. مكتبة Azure DCAP مدعومة في البيئات المستندة إلى Windows وLinux.
كيف يمكنني الانتقال إلى Azure Attestation من نماذج تصديق SGX الأخرى؟
- بعد تثبيت الجهاز الظاهري للحوسبة السرية من Azure، قم بتثبيت مكتبة Azure DCAP (Windows/ Linux) لجني الفوائد التي تقدمها إدارة هوية الأجهزة الموثوق بها (THIM).
- يجب تأليف عميل التصديق عن بعد الذي يمكنه استرداد دليل الجيب وإرسال الطلبات إلى Azure Attestation. راجع نماذج التعليمات البرمجية للرجوع إليها.
- يمكن إرسال طلبات التصديق إلى نقطة نهاية REST API للموفرين الافتراضيين أو موفري التصديق المخصصين.
- في إصدار واجهة برمجة التطبيقات 2018-09-01-preview ، يحتاج العميل إلى إرسال الرمز المميز للوصول إلى Microsoft Entra جنبا إلى جنب مع الأدلة إلى نقطة نهاية SGX attest API. الرمز المميز للوصول إلى Microsoft Entra ليس معلمة مطلوبة لإجراء شهادة SGX في إصدار واجهة برمجة التطبيقات 2020-10-01 .
كيف يمكن لجهة الاعتماد التحقق من سلامة الرمز المميز للإثبات والتأكد من أن Azure Attestation يعمل داخل جيب؟
يتم توقيع رمز التصديق الذي تم إنشاؤه بواسطة Azure Attestation باستخدام شهادة موقعة ذاتيا. يتم عرض شهادات التوقيع عبر نقطة نهاية بيانات تعريف OpenID. يمكن لجهة الاعتماد استرداد شهادات التوقيع من نقطة النهاية هذه وإجراء التحقق من التوقيع للرمز المميز للإثبات. تتضمن شهادة التوقيع أيضا اقتباس SGX من TEE الذي يتم تشغيل Azure Attestation داخله. إذا كان جهة الاعتماد تفضل أيضا التحقق مما إذا كان Azure Attestation يعمل داخل جيب SGX صالح، يمكن استرداد اقتباس SGX من شهادة التوقيع والتحقق من صحته محليا. لمزيد من المعلومات، راجع نماذج التعليمات البرمجية.
ما المدة التي يكون فيها الرمز المميز للإثبات صالحا؟
وقت صلاحية الرمز المميز للإثبات هو 8 ساعات. لا يوجد حاليا أي توفير لتخصيص القيمة.
كيفية تحديد الشهادة التي سيتم استخدامها للتحقق من التوقيع من نقطة نهاية بيانات تعريف OpenID
تتوافق الشهادات المتعددة المكشوفة في نقطة نهاية بيانات تعريف OpenID مع حالات استخدام مختلفة (على سبيل المثال، شهادة SGX) التي يدعمها Azure Attestation. وفقا للمعايير المحددة بواسطة RFC 7515، سيتم استخدام الشهادة ذات المعرف الرئيسي (الطفل) التي تطابق معلمة الطفل في رأس رمز التصديق للتحقق من التوقيع. إذا لم يتم العثور على طفل مطابق، فمن المتوقع تجربة جميع الشهادات التي تعرضها نقطة نهاية بيانات تعريف OpenID.
هل من الممكن لجهة الاعتماد مشاركة البيانات السرية مع بيئات التنفيذ الموثوق بها (TEEs) التي تم التحقق من صحتها؟
في وقت إنشاء أدلة TEE، يمكن أن تتضمن التعليمات البرمجية التي تعمل داخل TEE معلومات تعسفية في الأدلة. على سبيل المثال، يمكن ل TEE إنشاء زوج مفاتيح غير متماثل واحد أو أكثر، وتسلسل مكونات المفتاح العام لأزواج المفاتيح هذه كسلسلة JWKS JSON وتضمين سلسلة JWKS JSON في دليل TEE ك RunTimeData { quote، وسلسلة JWKS JSON }. يتحقق Azure Attestation مما إذا كانت تجزئة SHA256 من RuntimeData تطابق أقل 32 بايت من سمة "بيانات التقرير" الخاصة بالاقتباس. بعد تقييم دليل TEE، ينشئ Azure Attestation JWT مع JWKS المتوفرة كمطالبة تسمى "keys" ضمن المطالبة "x-ms-runtime". يمكن استخدام RunTimeData بشكل أكبر من قبل جهة الاعتماد لإنشاء قناة آمنة ونقل البيانات بأمان إلى TEE.
أين يخزن Azure Attestation بيانات العملاء؟
يخزن Azure Attestation بيانات العملاء الثابتة، أثناء المعالجة والنسخ المتماثل لأغراض BCDR داخل المنطقة الجغرافية التي ينشر العميل مثيل الخدمة فيها.