حماية الملكية الفكرية على أجهزة ظاهرية Azure مع إصدار مفتاح آمن مسور بالإثبات

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

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

ملحوظة

Secure Key Release هو ميزة مستوى البيانات Azure Key Vault Premium وHSM المدار. يتحقق من صحة رمز مميز موقع من Microsoft Azure Attestation (MAA) مقابل نهج إصدار المفتاح، بغض النظر عن نوع الحساب. تعد الأجهزة الظاهرية السرية مصدرا شائعا لهذه الرموز المميزة، ولكنها غير مطلوبة - تنتج أجهزة التشغيل الظاهرية الموثوق بها رموز MAA المميزة أيضا. للحصول على متطلبات الرمز المميز، راجع Azure Key Vault نحو نهج إصدار المفتاح الآمن.

السيناريو ونموذج التهديد

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

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

اتجاه التهديد	خصم	الإمكانات	دفاع من قبل
أ — المستهلك (مالك الجهاز الظاهري/الاشتراك)	مالك الاشتراك مع التحكم في الوصول استنادا إلى الدور Azure الكامل عبر الموارد المنشورة	az vm run-command، ملحقات البرنامج النصي المخصصة، لقطة قرص نظام التشغيل والمبادلة، وحدة التحكم التسلسلية، سرقة الرمز المميز للهوية المدارة عبر IMDS - كل ذلك دون SSH	الطبقات من 1 إلى 3
ب — موفر السحابة (المضيف / برنامج مراقبة الأجهزة الافتراضية)	عامل تشغيل مع وصول على مستوى المضيف إلى ذاكرة الجهاز الظاهري	قراءة ذاكرة الضيف من خارج الجهاز الظاهري	الطبقة 4 (اختياري)

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

متى يتم إضافة الحوسبة السرية (الطبقة 4)

الحوسبة السرية ليست بديلا لهذا النمط - إنها الطبقة 4 الاختيارية التي تضيفها فوقه. يقوم النمط الأساسي (الطبقات 1-3) بالفعل ببوابات إصدار مفتاح الإثبات، ويحمي الأصل من المستهلك، ويعمل على أي من وحدات SKU لإطلاق Gen2 الموثوق به بتكلفة قياسية. لا تغير إضافة الحوسبة السرية كيفية عمل النمط: تظل SKR والصورة المتصلبة وعزل الشبكة كما هي، وتدفق الإصدار متطابق. الاختلافات الوحيدة هي أن بوابات نهج الإصدار على مطالبات الأجهزة TEE بدلا من مطالبات التمهيد المقاس vTPM، ويتم تشغيل حمل العمل على وحدة SKU VM سرية. يمكنك الحصول على الحماية من اتجاه التهديد B (المضيف/برنامج مراقبة الأجهزة الافتراضية) والتجارة SKU وGPU واتساع المنطقة بتكلفة متميزة.

يوضح الجدول التالي ما تضيفه الطبقة 4 وما تكلفه - وليس خيارا بين نمطين:

الاعتبار	النمط الأساسي (الطبقات 1-3، التشغيل الموثوق به)	مع إضافة الطبقة 4 (الحوسبة السرية)
حماية الأصول من المستهلك (التهديد أ)	‏‏نعم‬	نعم (لم يتغير)
حماية الأصل من المضيف / برنامج مراقبة الأجهزة الافتراضية (التهديد ب)	لا (مخاطر مقبولة)	نعم (تشفير الذاكرة)
إصدار مفتاح ذي بوابة التصديق	مطالبات التمهيد المقاس ل vTPM	Hardware-TEE المطالبات
توفر وحدة حفظ المخزون لوحدة معالجة الرسومات	جميع وحدات SKU Gen2	يقتصر على وحدات SKU السرية لوحدة معالجة الرسومات والحصص النسبية
اتساع المنطقة وSKU	عام	أضيق
التكلفة النسبية	تسعير الجهاز الظاهري القياسي	متميز

ابدأ بالنمط الأساسي. أضف الطبقة 4 فقط عندما يجب عدم الثقة في برنامج تشغيل الآلة الافتراضية - على سبيل المثال، حمل العمل المنظم الذي يفرض تشفير الذاكرة - قبول SKU وGPU وتوافر المنطقة الأضيق والتكلفة المتميزة.

عناصر النمط

النمط هو مكدس دفاعي متعمق. تدافع كل طبقة عن اتجاه تهديد محدد: تدافع الطبقات من 1 إلى 3 ضد المستهلك (اتجاه التهديد A)، وتدافع الطبقة 4 الاختيارية ضد المضيف (اتجاه التهديد B). الأصول المحمية تقع في الذاكرة الأساسية، ويمكن الوصول إليها فقط من خلال كل طبقة مرفقة.

الأصول المحمية تقع في جوهرها. تقوم أربع طبقات متحدة المركز بإحاطته، من أقصى الحدود إلى أقصى الحدود: الطبقة 1، إصدار مفتاح آمن ذي بوابة التصديق، حيث يقوم vTPM بقياس تمهيد المطالبات بإصدار مفتاح البوابة؛ الطبقة 2، صورة متصلبة مع dm-verity، جذر للقراءة فقط، وليس SSH أو عامل؛ الطبقة 3، وعزل الشبكة مع نقاط النهاية الخاصة، وعدم الخروج العام، ورفض التعيينات؛ والطبقة 4 (اختيارية، تظهر بحد متقطع)، والحوسبة السرية التي توفر تشفير ذاكرة المضيف. تدافع الطبقات من 1 إلى 3 ضد اتجاه التهديد A والمستهلك أو الجهاز الظاهري ومالك الاشتراك باستخدام أمر التشغيل ولقطة القرص والمبادلة ووحدة التحكم التسلسلية وسرقة الهوية المدارة. تدافع الطبقة 4 ضد اتجاه التهديد B، المضيف أو برنامج مراقبة الأجهزة الافتراضية الذي يقرأ ذاكرة الضيف.

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

يحتوي مستأجر المستهلك (عامل التشغيل غير الموثوق به) على الجهاز الظاهري للتشغيل الموثوق به، والذي يحتوي على التمهيد الآمن، vTPM، وصورة متصلبة. يحتوي مستأجر الناشر (الذي يحتوي على نقاط ارتساء الثقة) على Microsoft Azure Attestation وHSM Key Vault Premium أو Managed الذي يحتوي على المفتاح القابل للتصدير ونهج الإصدار. يحتوي التدفق على أربع خطوات: (1) يرسل الجهاز الظاهري طلب تصديق مع دليل vTPM إلى Microsoft Azure Attestation؛ (1) يرسل الجهاز الظاهري طلب إثبات مع دليل vTPM إلى Microsoft Azure Attestation؛ (1) إرسال طلب إثبات مع دليل vTPM إلى Microsoft Azure Attestation؛ (1) إرسال طلب إثبات مع دليل vTPM إلى Microsoft Azure Attestation؛ (1) إرسال طلب إثبات مع دليل (2) يقوم Microsoft Azure Attestation بإرجاع رمز MAA مميز موقع يحتوي على مطالبات secureboot وP PCR إلى الجهاز الظاهري؛ (3) يرسل الجهاز الظاهري "POST /keys/{key}/release" مع رمز MAA المميز إلى Key Vault؛ (4) Key Vault بإرجاع المفتاح الملتف إلى المفتاح المؤقت vTPM، أو "AccessDenied" إذا لم يتم استيفاء النهج.

الطبقة 1: إصدار مفتاح آمن ببوابات التصديق (بوابة التشفير)

هذه الطبقة هي الأساس. يتم تشغيل جهاز ظاهري موثوق به مع التمهيد الآمن وTPM ظاهري (vTPM). يقيس vTPM سلسلة التمهيد في سجلات تكوين النظام الأساسي (PCRs)، ما يؤدي إلى إنشاء بصمة تشفير لما تم تمهيده بالضبط. يطلب الضيف رمز MAA المميز الذي يتضمن هذه القياسات، مثل المطالبة secureboot ومن x-ms-azurevm-attested-pcr-values.pcr0 خلال pcr7. ثم يستدعي نقطة نهاية Key Vault /release ويعرض الرمز المميز. يتحقق Key Vault من صحة توقيع الرمز المميز ويقيمه مقابل نهج إصدار المفتاح. إذا تطابقت مطالبات النهج، Key Vault بإصدار المفتاح، مغلفا بالمفتاح المؤقت ل vTPM بحيث يمكن للجهاز الظاهري المصدق فقط فكه. إذا لم تتطابق، يقوم الإصدار بإرجاع AccessDenied.

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

نهج إصدار تمثيلي لجهاز ظاهري لإطلاق موثوق به:

{
  "version": "1.0.0",
  "anyOf": [
    {
      "authority": "https://<MAA_PROVIDER>.<region>.attest.azure.net",
      "allOf": [
        { "claim": "secureboot", "equals": true },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr4", "equals": "<BASE64_PCR4>" },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr7", "equals": "<BASE64_PCR7>" }
      ]
    }
  ]
}

الطبقة 2: صورة محصنة (حماية الأصل الذي تم فك تشفيره)

تتحكم الطبقة 1 في ما إذا كان يتم تحرير المفتاح؛ لا يحمي الأصل بمجرد فك تشفيره في الضيف قيد التشغيل. تقوية الصورة لتقليص سطح الهجوم داخل الضيف ووحدة التحكم: تكامل نظام الملفات (على سبيل المثال، dm-verity)، ونظام ملفات جذر للقراءة فقط، ولا يوجد برنامج SSH خفي، ولا تسجيل دخول تفاعلي، ولا عامل داخل الضيف يمكنه تنفيذ الأوامر التي يوفرها المشغل.

ما يمنعه (التهديد أ): استغلال الضيف لجهاز ظاهري قيد التشغيل، مصدق عليه - العمليات المارقة، تصعيد الامتيازات، استخراج الأصل الذي تم فك تشفيره من ذاكرة العملية من خلال ثغرة أمنية على مستوى نظام التشغيل.

الطبقة 3: عزل الشبكة (تقليص السطح)

تقييد كيفية تحدث الجهاز الظاهري إلى نقاط ارتساء الثقة والبيانات. استخدم نقاط النهاية الخاصة Key Vault والتخزين وأي سجل؛ مسار خاص لموفر التصديق؛ DNS خاص؛ ولا خروج عام غير ضروري. حيث تدعم آلية التسليم ذلك - على سبيل المثال، تطبيق مدار - يمكن أن تجرد التعيينات أيضا التحكم في الوصول استنادا إلى الدور للمستهلك عبر موارد الحساب، وحظر هجمات وحدة التحكم (run-command، وعمليات القرص، ووحدة التحكم التسلسلية، وسرقة الهوية) مباشرة. ضمن تسليم قالب الحل يحتفظ المستهلك بالتحكم في الوصول استنادا إلى الدور عبر الموارد المنشورة، لذلك لا يتوفر تصلب مستوى التحكم؛ هناك، تحمل الطبقتين 1 و2 الدفاع ضد التهديد أ - لقطة أو فشل إثبات القرص المبدل (الطبقة 1)، وتمنع الصورة المتصلبة (الطبقة 2) استخراج الأصول المفككة في الضيف.

ما يمنعه (التهديد أ): يقلل من السطح المكشوف لكل من هجمات وحدة التحكم و مستوى البيانات ويمنع مسارات النقل غير المصرح بها من الضيف المصدق.

الطبقة 4 (اختياري): الحوسبة السرية (تدافع عن اتجاه التهديد ب)

كل شيء أعلاه يثق بالمضيف. إذا لم تتمكن من الوثوق في برنامج hypervisor، فقم بتشغيل حمل العمل على جهاز ظاهري سري (AMD SEV-SNP أو Intel TDX). يمنع تشفير الذاكرة المضيف من قراءة ذاكرة الضيف، وترقيات SKR من مطالبات التمهيد المقاس vTPM إلى مطالبات الأجهزة TEE في نهج الإصدار. هذه الطبقة هي الطبقة الوحيدة التي تدافع عن اتجاه التهديد B. يتم إيقاف تشغيله بشكل افتراضي لأنه يضيق نطاق توفر SKU وGPU والمنطقة ويضيف التكلفة.

الهوية عبر المستأجرين

يمتلك الناشر نقاط ارتساء الثقة - Key Vault (أو HSM المدار) وموفر التصديق - في مستأجر الناشر، خارج RBAC الخاص بالمستهلك. يعمل الجهاز الظاهري المصدق عليه في مستأجر المستهلك و يجب عليه استدعاء Key Vault عبر هذا الحد. هناك قيدان على النظام الأساسي يستبعدان النهج الواضحة:

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

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

يضع النمط الذي يعمل هوية الجسر - تطبيق متعدد المستأجرين - على جانب المستهلك:

1. يسجل المستهلك تطبيقا متعدد المستأجرين في المستأجر الخاص به وتكوين نفس المستأجر FIC عليه يثق في الهوية المدارة للجهاز الظاهري. يسمح ب FIC الذي يثق في هوية في نفس المستأجر.
2. يدمج الناشر هذا التطبيق في المستأجر الخاص به عن طريق توفير كيان خدمة له ومنح هذا المدير دور مستخدم إصدار خدمة التشفير Key Vault على المفتاح. هذه الخطوة المدروسة لكل مستهلك هي المكان الذي يمنح فيه الناشر ممثلا خارجيا حق الوصول إلى المستأجر الخاص به.
3. في وقت التشغيل، تحصل الهوية المدارة للجهاز الظاهري على رمز مميز من IMDS، وتتبادله من خلال FIC للمصادقة كتطبيق متعدد المستأجرين، وتستدعي نقطة نهاية Key Vault /release مع رمز MAA المميز في نص الطلب.

Important

تبادل الهوية ليس حد الأمان. نظرا لأن المستهلك يمتلك تسجيل التطبيق متعدد المستأجرين، يمكن للمسؤول من جانب المستهلك إضافة بيانات اعتماد أخرى (مثل سر العميل) إليه ودفع هذا التدفق يدويا - لذلك لا تمنح طبقة الهوية الناشر أي ضمان ضد مستهلك متطفل. الحد الحقيقي هو SKR + التصديق (الطبقة 1): حتى مع رمز مميز صالح لمستأجر الناشر، يرفض Key Vault إصدار المفتاح ما لم يستوفي رمز MAA صالح نهج الإصدار، ويمكن فقط للصورة الأصلية والمصدقة للناشر إنتاج واحدة. توجه طبقة الهوية الطلب إلى المخزن الصحيح فقط.

Walkthrough

1. توفير نقاط ارتساء الثقة (مستأجر الناشر). إنشاء Key Vault Premium أو Managed HSM. إنشاء مفتاح RSA-HSM قابل للتصدير . إرفاق نهج إصدار يربط سلطة MAA ومطالبات التشغيل الموثوق به (securebootالمحددة x-ms-azurevm-attested-pcr-values.pcrN).
2. تحديد قيم PCR المتوقعة. قم بالمصادقة على مثيل جيد معروف لصورتك مرة واحدة واقرأ x-ms-azurevm-attested-pcr-values من رمز MAA المميز الذي تم إرجاعه. قم بتثبيت PCRs مقاييس سلسلة التمهيد الخاصة بك - عادة pcr4 (محمل التمهيد / النواة) و pcr7 (حالة التمهيد الآمن).
3. توزيع حمل العمل (مستأجر المستهلك). انشر جهازا ظاهريا للتشغيل الموثوق به (Gen2) يقوم بتشغيل الصورة المتصلبة. امنحها هوية مدارة وقم بوحد تلك الهوية مع التطبيق متعدد المستأجرين المملوك للمستهلك الموضح في الهوية عبر المستأجرين، الذي منحه الناشر كيان الخدمة Key Vault مستخدم إصدار خدمة التشفير على المفتاح.
4. التصديق والإصدار في وقت التشغيل. يحصل الضيف على رمز MAA مميز، ثم يستدعي POST /keys/{key-name}/release. يقوم Key Vault بالتحقق من صحة المفتاح الملتف وإرجاعه؛ يقوم الضيف بفكه داخل الجهاز الظاهري.
5. تحقق من الحالة السلبية. قم بتغيير PCR المثبت في نهج الإصدار إلى قيمة غير متطابقة (أو تمهيد صورة معدلة) وتأكد من إرجاع AccessDeniedالإصدار .

للحصول على التعليمات البرمجية القابلة للتشغيل، راجع العينات في المحتوى ذي الصلة.

المحتوى ذو الصلة

• النحو النحوي لنهج إصدار المفتاح الآمن في Azure Key Vault
• تأمين إصدار المفتاح باستخدام Azure Key Vault والحوسبة السرية Azure
• أمثلة على نهج إصدار المفتاح الآمن
• نظرة عامة على Microsoft Azure Attestation
• الإطلاق الموثوق لأجهزة Azure الافتراضية
• اتحاد هويات عبء العمل
• عينة: cvm-securekey-release-app في Azure/confidential-computing-cvm-guest-attestation
• نموذج: أمثلة SKR في Azure-Samples/confidential-computing