مشاركة عبر

Microsoft Azure Attestation

  • مقالة

يُعد Microsoft Azure Attestation حلاً موحداً للتحقق عن بُعد من جدارة النظام الأساسي بالثقة وتكامل الثنائيات قيد التشغيل بداخله. تدعم الخدمة التصديق على الأنظمة الأساسية المدعومة بوحدات النظام الأساسي الموثوق بها (TPMs) إلى جانب القدرة على التصديق على حالة بيئات التنفيذ الموثوق بها (TEEs) مثل جيوب Intel® Software Guard Extensions (SGX) وجيوب الأمان المستندة إلى الظاهرية (VBS) ووحدات النظام الأساسي الموثوق بها (TPMs) والتشغيل الموثوق به لأجهزة Azure الظاهرية وأجهزة Azure الظاهرية السرية.

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

تمكن Azure Attestation نماذج الأمان المتطورة مثل Azure Confidential computing وIntelligent Edge protection. يطلب العملاء القدرة على التحقق من موقع الجهاز بشكل مستقل، ووضع الجهاز الظاهري (VM) على هذا الجهاز، والبيئة التي تعمل داخلها الجيوب على هذا الجهاز الظاهري. يعمل Azure Attestation على تمكين هذه الطلبات والعديد من طلبات العملاء الإضافية.

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

يدعم Azure Attestation كلا من النظام الأساسي وإثبات الضيف للأجهزة الظاهرية السرية المستندة إلى AMD SEV-SNP (CVMs). يحدث إثبات النظام الأساسي المستند إلى Azure Attestation تلقائيا أثناء مسار التمهيد الحرج ل CVMs، دون الحاجة إلى إجراء العميل. لمزيد من المعلومات حول تصديق الضيف، راجع الإعلان عن التوفر العام لمصادقة الضيف للأجهزة الظاهرية السرية.

حالات الاستخدام

توفر Azure Attestation خدمات تصديق شاملة لبيئات متعددة وحالات استخدام مميزة.

شهادة AMD SEV-SNP على الأجهزة الظاهرية السرية

يعتمد Azure Confidential VM (CVM) على معالجات AMD مع تقنية SEV-SNP. يوفر CVM خيار تشفير قرص نظام تشغيل الجهاز الظاهري باستخدام مفاتيح مدارة من قبل النظام الأساسي أو مفاتيح يديرها العميل ويربط مفاتيح تشفير القرص ب TPM الخاص بالجهاز الظاهري. عند تشغيل CVM، سيتم إرسال تقرير SNP الذي يحتوي على قياسات البرنامج الثابت للجهاز الظاهري الضيف إلى Azure Attestation. تتحقق الخدمة من صحة القياسات وتصدر رمزا مميزا للإثبات يستخدم لتحرير المفاتيح من Managed-HSM أو Azure Key Vault. يتم استخدام هذه المفاتيح لفك تشفير حالة vTPM للجهاز الظاهري الضيف، وإلغاء تأمين قرص نظام التشغيل وبدء تشغيل CVM. يتم تنفيذ عملية التصديق والإصدار الرئيسي تلقائيا على كل تمهيد CVM، وتضمن العملية تشغيل CVM فقط عند التصديق الناجح على الأجهزة.

شهادة AMD SEV-SNP على الحاويات السرية

تستند حاويات Azure السرية إلى معالجات AMD مع تقنية SEV-SNP. توفر الحاويات السرية، المستضافة على مثيلات حاوية Azure وعلى خدمة Azure Kubernetes (في المعاينة) القدرة على تشغيل مجموعات من الحاويات في بيئة تنفيذ موثوق بها محمية من SEV-SNP والتي تعزل تلك المجموعة من الحاويات عن مستوى التحكم في إدارة الحاوية والحاويات الأخرى قيد التشغيل. يتضمن التصديق في الحاويات السرية إحضار تقرير إثبات أجهزة AMD مباشرة من المعالج. يمكن تحقيق ذلك مع حاوية SKR sidecar الخاصة بنا أو تحويلها برمجيا مباشرة إلى منطق التطبيق الخاص بك. يمكن بعد ذلك تبادل تقرير الأجهزة مع Azure Attestation وHSM المدار أو Premium Azure Key Vault (AKV) لاسترداد الأسرار. يمكنك أيضا تقديم تقرير الأجهزة إلى نظام key vault الخاص بك حسب الرغبة.

إثبات الإطلاق الموثوق به

يمكن لعملاء Azure منع التهابات bootkit و rootkit عن طريق تمكين التشغيل الموثوق به لأجهزتهم الظاهرية (VMs). عندما يكون الجهاز الظاهري هو التمهيد الآمن وتمكين vTPM مع تثبيت ملحق تصديق الضيف، يتم إرسال قياسات vTPM إلى Azure Attestation بشكل دوري لمراقبة تكامل التمهيد. يشير فشل التصديق إلى وجود برامج ضارة محتملة، والتي تظهر للعملاء عبر Microsoft Defender for Cloud، من خلال التنبيهات والتوصيات.

تصديق TPM

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

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

إثبات جيب SGX

تشير ملحقات Intel® Software Guard (SGX) إلى العزل على مستوى الأجهزة، والذي يتم دعمه على نماذج معينة من Intel CPU. تُمكن SGX التعليمات البرمجية من العمل في حجرات تم فحصها تعرف باسم جيوب SGX. ثم تتم إدارة أذونات الوصول والذاكرة بواسطة الأجهزة لضمان الحد الأدنى من الأجزاء المعرضة للهجوم مع العزل المناسب.

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

تدعم معالجات Intel® Xeon® Scalable حلول التصديق المستندة إلى ECDSA للتصديق عن بُعد على جيوب SGX. باستخدام طراز التصديق المستند إلى ECDSA، يدعم Azure Attestation التحقق من صحة معالجات Intel® Xeon® E3 والأنظمة الأساسية للخادم القائمة على المعالجات Intel® Xeon® Scalable.

إشعار

لإجراء التصديق على الأنظمة الأساسية للخوادم القائمة على المعالج Intel® Xeon® Scalable باستخدام Azure Attestation، من المتوقع أن يقوم المستخدمون بتثبيت Azure DCAP الإصدار 1.10.0 أو إصدار أحدث.

إثبات الجيب المفتوح

Open Enclave (OE) عبارة عن مجموعة من المكتبات تهدف إلى إنشاء تجريد أحادي موحد عازل يمكن للمطورين استخدامه لبناء تطبيقات قائمة على TEE. وهو يوفر طراز تطبيق آمن عالمياً يقلل من خصائص النظام الأساسي. تعتبره Microsoft بمثابة نقطة انطلاق أساسية نحو توفير تقنيات الجيب القائمة على الأجهزة مثل SGX للجميع وزيادة استيعابها على Azure.

توحد OE متطلبات محددة للتحقق من دليل الجيب. هذا يؤهل OE كمستهلك للتصديق مناسب للغاية لـ Azure Attestation.

يتم تشغيل Azure Attestation في TEE

تُعد Azure Attestation ضرورية لسيناريوهات الحوسبة السرية، حيث تقوم بتنفيذ الإجراءات التالية:

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

للحفاظ على Microsoft من الناحية التشغيلية خارج قاعدة الحوسبة الموثوق بها (TCB)، يتم نقل العمليات الهامة ل Azure Attestation مثل التحقق من صحة الاقتباس وإنشاء الرمز المميز وتقييم النهج وتوقيع الرمز المميز إلى جيب SGX.

لماذا تستخدم Azure Attestation

Azure Attestation هو الخيار المفضل لتصديق TEEs حيث يقدم الفوائد التالية:

  • إطار عمل موحد لإثبات بيئات متعددة مثل TPMs وجيوب SGX وجيوب VBS.
  • يسمح بإنشاء موفري تصديق مخصصين وتكوين النهج لتقييد إنشاء الرمز المميز.
  • يحمي بياناته أثناء الاستخدام مع التنفيذ في جيب SGX أو الجهاز الظاهري السري استنادا إلى AMD SEV-SNP.
  • خدمة عالية الإتاحة

كيفية تأسيس الثقة مع Azure Attestation

  1. تحقق مما إذا تم إنشاء رمز التصديق المميز بواسطة Azure Attestation - تم توقيع رمز التصديق الذي تم إنشاؤه بواسطة Azure Attestation باستخدام شهادة موقعة ذاتيا. يتم عرض عنوان URL لشهادات التوقيع عبر نقطة نهاية بيانات تعريف OpenID. يمكن لجهة الاعتماد استرداد شهادة التوقيع وإجراء التحقق من التوقيع للرمز المميز للإثبات. راجع نماذج التعليمات البرمجية لمزيد من المعلومات
  2. تحقق مما إذا كان Azure Attestation يعمل داخل جيب SGX - تتضمن شهادات توقيع الرمز المميز اقتباس SGX من TEE الذي يتم تشغيل Azure Attestation داخله. إذا كان الطرف المعتمد يفضل التحقق مما إذا كان Azure Attestation يعمل داخل جيب SGX صالح، يمكن استرداد اقتباس SGX من شهادة التوقيع والتحقق من صحته محليا. راجع نماذج التعليمات البرمجية لمزيد من المعلومات
  3. التحقق من ربط اقتباس Azure Attestation SGX بالمفتاح الذي وقع رمز التصديق المميز - يمكن لجهة الاعتماد التحقق مما إذا كانت تجزئة المفتاح العام الذي وقع رمز التصديق تطابق حقل بيانات التقرير لاقتباس Azure Attestation SGX. راجع نماذج التعليمات البرمجية لمزيد من المعلومات
  4. تحقق مما إذا كانت قياسات التعليمات البرمجية ل Azure Attestation تطابق القيم المنشورة في Azure - يتضمن اقتباس SGX المضمن في شهادات توقيع رمز التصديق قياسات التعليمات البرمجية ل Azure Attestation، مثل MRSIGNER. إذا كان الطرف المعتمد مهتما بالتحقق مما إذا كان اقتباس SGX ينتمي إلى Azure Attestation الذي يعمل داخل Azure، يمكن استرداد قيمة MRSIGNER من عرض أسعار SGX في شهادة توقيع رمز التصديق ومقارنتها بالقيمة التي يوفرها فريق Azure Attestation. إذا كنت مهتما بإجراء هذا التحقق من الصحة، أرسل طلبا على صفحة دعم Azure. سيتواصل معك فريق Azure Attestation عندما نخطط لتدوير MRSIGNER.

من المتوقع أن تتغير Mrsigner من Azure Attestation عند تدوير شهادات توقيع التعليمات البرمجية. يتبع فريق Azure Attestation جدول الإطلاق أدناه لكل دوران mrsigner:

1. يقوم فريق Azure Attestation بإعلام قيمة MRSIGNER القادمة بفترة سماح لمدة شهرين لإجراء تغييرات التعليمات البرمجية ذات الصلة

‫2. بعد فترة السماح لمدة شهرين، يبدأ Azure Attestation باستخدام قيمة MRSIGNER الجديدة

3. تاريخ الإعلام بعد ثلاثة أشهر، يتوقف Azure Attestation عن استخدام قيمة MRSIGNER القديمة

دعم استمرارية الأعمال والتعافي من الكوارث (BCDR)

تمكنك استمرارية الأعمال والتعافي من الكوارث (BCDR) ل Azure Attestation من التخفيف من اضطرابات الخدمة الناتجة عن مشكلات التوفر الكبيرة أو أحداث الكوارث في منطقة ما.

تعمل المجموعات الموزعة في منطقتين بشكل مستقل في ظل الظروف العادية. في حالة حدوث خطأ أو انقطاع في منطقة إقليمية واحدة، يحدث ما يلي:

  • يوفر Azure Attestation BCDR تجاوز فشل سلس لا يحتاج فيه العملاء إلى اتخاذ أي خطوة إضافية للاسترداد.
  • سيكتشف Azure Traffic Manager للمنطقة أن التحقيق الصحي متدهور ويحول نقطة النهاية إلى منطقة مقترنة.
  • لن تعمل الاتصالات الموجودة وستتلقى أخطاء الخادم الداخلية أو مشكلات المهلة.
  • سيتم حظر جميع عمليات وحدة التحكم. لن يتمكن العملاء من إنشاء موفري التصديق في المنطقة الأساسية.
  • سيتم تقديم جميع عمليات مستوى البيانات، بما في ذلك استدعاءات التصديق وتكوين النهج، من خلال المنطقة الثانوية. يمكن للعملاء الاستمرار في العمل على عمليات مستوى البيانات باستخدام URI الأصلي المقابل للمنطقة الأساسية.

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