كيفية التحقق من إثبات الأجهزة في Azure Confidential Computing

By Mirko Peters · 2026-10-26

تعرّف على آلية عمل إثبات الأجهزة في Azure، وقارن بين AMD SEV-SNP وIntel SGX، واكتشف كيفية دمج التحقق التشفيري في خطوط أنابيب CI/CD الخاصة بك.

Automatically translated with AI from the original post. Read the English original

إثبات الأجهزة في Azure عملية تحقق تشفيري بالغة الأهمية، تُثبت أن بيئة التنفيذ الموثوقة لديك أصلية وغير معدَّلة قبل تحميل أعباء العمل الحساسة. ومن خلال تقييم قياسات الإقلاع الآمن ومفاتيح العتاد مقارنةً بالخطوط الأساسية لكل من Microsoft والمورّدين، يسدّ الإثبات الفجوة في الثقة بين مشغّلي السحابة وخصوصية بيانات المستأجر.

النقاط الرئيسية

• يتحقق إثبات الأجهزة تشفيرياً من أن بيئة التنفيذ الموثوقة (TEE) لديك أصلية وغير مخترقة.
• تقيّم خدمة الإثبات عن بُعد قياسات المنصة مقارنةً بخطوط الأمان الأساسية قبل الإفراج عن مفاتيح فك التشفير.
• تعتمد معماريتا AMD SEV-SNP وIntel SGX على التحقق عن بُعد لضمان عدم تمكّن مسؤولي السحابة من فحص الذاكرة أثناء الاستخدام.
• إن دمج الإثبات في خطوط نشر CI/CD يُؤتمت التحقق من الثقة ويمنع بدء الحاويات التي جرى العبث بها.
• يُعدّ فهم مصافحة الإثبات أمراً أساسياً للحفاظ على نهج Zero Trust في بيئات السحابة الهجينة الحديثة.

فجوة الثقة في السحابات العامة

عند نقل أعباء العمل الحساسة إلى السحابة العامة، تحمي نماذج الأمان التقليدية بياناتك أثناء النقل باستخدام TLS، وأثناء التخزين باستخدام تشفير AES-256. غير أن ثغرة مهمة تبقى قائمة: البيانات أثناء الاستخدام. فتاريخياً، كلما نفّذ المعالج شيفرة، كان لزاماً فك تشفير تلك البيانات ووضعها بصيغة نص واضح في ذاكرة النظام. وفي بيئة سحابية متعددة المستأجرين، كان ذلك يعني الوثوق بالمشرف الافتراضي، ومزوّد البنية التحتية السحابية، وكل من لديه صلاحيات إدارية على الأجهزة المادية الأساسية.

تُغيّر Azure Confidential Computing هذا النموذج من خلال تقديم بيئات تنفيذ موثوقة (TEEs) قائمة على العتاد، وهي بيئات آمنة معزولة وأجهزة افتراضية معزولة تشفّر محتوى الذاكرة باستخدام مفاتيح عتاد مخصصة تُدار مباشرةً من شريحة المعالج. ومع ذلك، فإن امتلاك غرفة مقفلة ليس سوى نصف المعركة. فأنت بحاجة أيضاً إلى وسيلة للتحقق من أن القفل لم يُعبث به، وأن الباب مُصمَّم بشكل سليم، وأنه لا يعمل أي برنامج غير مصرّح به داخل الحدود الآمنة قبل تسليم مفاتيح التشفير الخاصة بك.

كيف يعمل الإثبات عن بُعد

الإثبات عن بُعد هو آلية التحقق التي تجيب عن سؤال جوهري: كيف تعرف أن بيئة السحابة التي تنشر إليها آمنة وغير معدَّلة فعلاً؟ من دون الإثبات، قد يتمكن مهاجم يملك صلاحيات على مستوى المشرف الافتراضي من استبدال BIOS خبيث أو تعديل محمِّل الإقلاع، فيعترض مفاتيح التشفير الخاصة بك لحظة تحميلها في الذاكرة.

تعمل عملية الإثبات كمصافحة تشفيرية دقيقة متعددة الخطوات:

الخطوة 1: الإقلاع الآمن وقياس المنصة

عندما تُقلع آلة افتراضية سرية من Azure أو مثيل حاوية، تسجّل الأجهزة والبرامج الثابتة قياسات تشفيرية لكل مكوّن يشارك في عملية الإقلاع. ويشمل ذلك محمّل الإقلاع وصور النواة وأي أقراص ذاكرة عشوائية أولية (initial ramdisks). تُخزَّن هذه القياسات بأمان في سجلات أجهزة داخل وحدة المعالجة المركزية، ولا يمكن لنظام التشغيل المضيف أو المشرف الافتراضي (hypervisor) تعديلها.

الخطوة 2: إنشاء التقرير التشفيري

بعد تهيئة عبء العمل داخل بيئة التنفيذ الموثوقة (TEE)، يطلب من وحدة المعالجة المركزية تقريرًا موقّعًا بالأجهزة. تُوقّع المعالجة هذا التقرير القياسي باستخدام مفتاح خاص ثابت لا يمكن تغييره، مدمج في السيليكون أثناء التصنيع. يعمل هذا التقرير كجواز سفر رقمي لا يمكن تزويره، يمثل الحالة الدقيقة لمكدس البرمجيات العامل داخل البيئة المعزولة.

الخطوة 3: التقييم من خدمة Azure Attestation

يُرسل التقرير الموقّع بالأجهزة إلى خدمة Microsoft Azure Attestation (MAA) أو إلى أداة تحقق متوافقة من طرف ثالث. تقارن خدمة التصديق القياسات الواردة مع خط أساس معروف وموثوق، يحدده المستأجر في نهج محدد. فإذا تطابق الكود العامل داخل البيئة المعزولة مع النهج المصرّح به، تُنشئ الخدمة رمز تصديق (attestation token).

الخطوة 4: إطلاق الأسرار

بعد الحصول على رمز تصديق صالح، يمكن لتطبيقك أن يطلب بأمان بيانات اعتماد قواعد البيانات، أو شهادات TLS، أو مفاتيح تشفير البيانات من Key Vault Managed HSM. يتحقق Key Vault من الرمز ولا يُفرج عن الأسرار إلا لبيئة TEE الموثوقة، بما يضمن ألا تتمكن أي بيئة غير مصرّح بها من الوصول إلى بياناتك غير المشفّرة أبدًا.

الاختلافات المعمارية: AMD SEV-SNP مقابل Intel SGX

يتطلب تطبيق التصديق فهمًا للبنية المادية الكامنة وراء عُقد Azure Confidential Computing لديكم. تدعم Microsoft Azure تقنيتين رئيسيتين للأجهزة، تتعاملان مع العزل والتصديق بشكل مختلف قليلًا.

تركّز Intel Software Guard Extensions (SGX) على العزل على مستوى العملية. فبدلًا من حماية الآلة الافتراضية بالكامل، تتيح SGX للمطوّرين عزل شيفرات محددة وبنى بيانات دقيقة داخل بيئات معزولة (enclaves) مخصصة. ويعتمد التصديق في SGX بشكل كبير على enclaves الاقتباس (quoting enclaves) التي تغلّف حالة الأجهزة في اقتباس قابل للتحقق، ثم يُتحقق منه مقابل بنية Intel's Enhanced Privacy ID (EPID) أو البنية الأحدث Data Center Attestation Primitives (DCAP).

من ناحية أخرى، تحمي AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) الأجهزة الافتراضية بالكامل. تؤمّن SEV-SNP سلامة الذاكرة من خلال تشفير الذاكرة المدعوم بالأجهزة، وتمنع المشرفات الافتراضية الخبيثة من إعادة ربط عناوين الذاكرة الفعلية للضيف. ويتضمن تقرير التصديق الذي تُنشئه آلة افتراضية AMD SEV-SNP إعدادات نهج الضيف وقياسات الإطلاق، مما يسهّل عملية نقل التطبيقات الحاوية الحالية كما هي (lift-and-shift) دون إعادة كتابة الشيفرة لاستخدام واجهات برمجية خاصة بالـ enclaves.

تطبيق التصديق في خطوط CI/CD

بالنسبة لمهندسي السحابة ومهندسي DevOps، لا يُعد التحقق اليدوي من تقارير التصديق قابلًا للتوسع ولا عمليًا. ولبناء بنية تحتية سحابية متينة، يجب دمج التصديق بعمق في خطوط النشر الآلية.

يمكن لعمليات نشر الحاويات الحديثة التي تعمل على Azure Kubernetes Service (AKS) مع عُقد سرية أن تستخدم حاويات مساندة (sidecar) أو مكونات إضافية للأجهزة (device plugins) لإدارة مصافحة التصديق تلقائيًا. عند بدء تشغيل Pod سرّي، يجلب عميل التصديق تقرير الأجهزة، ويرسله إلى خدمة Azure Attestation، ويخزّن الرمز الناتج مؤقتًا. ولا تُركّب حاوية التطبيق وحداتها السرية وتبدأ معالجة الطلبات إلا بعد التحقق من الرمز.

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

الخاتمة: تأمين البيانات أثناء الاستخدام اليوم

توفر Azure Confidential Computing الأساس التقني اللازم لحماية أحمال العمل الحساسة في السحابة من تهديدات البنية التحتية الحديثة، غير أن عزل الأجهزة وحده لا يكفي دون تحقق دقيق. فمن خلال إتقان التصديق عن بُعد (Remote Attestation)، يستطيع مهندسو السحابة إقامة ثقة قابلة للتحقق بين شيفرة المستأجر والأجهزة المادية، بما يضمن بقاء البيانات قيد الاستخدام آمنة بالقدر نفسه الذي تكون عليه البيانات المخزّنة والبيانات المنقولة. للاستماع إلى شرح شامل لمفاهيم أمان السحابة هذه، واستكشاف المشهد الأوسع لـ Microsoft 365 وAzure، استمع إلى الحلقة كاملة من بودكاست M365 FM.

الأسئلة المتداولة

ما الغرض الأساسي من Azure Attestation؟

Azure Attestation خدمة سحابية موحّدة تتحقق تشفيريًا من موثوقية بيئة التنفيذ الموثوقة (Trusted Execution Environment)، وتتأكد من سلامة البرمجيات العاملة داخلها قبل الإفراج عن الأسرار أو مفاتيح التشفير.

هل يستطيع مسؤول السحابة تجاوز التصديق على مستوى الأجهزة؟

لا. يعتمد التصديق على مستوى الأجهزة على مفاتيح تشفيرية مدمجة مباشرةً في شريحة المعالج من قِبل الشركة المصنّعة للأجهزة. ولأن هذه المفاتيح غير متاحة لمشرفي الأجهزة الافتراضية (Hypervisors) ولمشغّلي السحابة، فلا يستطيع المسؤولون تزوير تقرير تصديق صالح لبيئة مخترَقة.

ما الفرق بين التصديق على مستوى الجهاز الافتراضي والتصديق على مستوى العملية؟

يقيس التصديق على مستوى الجهاز الافتراضي (مثل AMD SEV-SNP) نظام التشغيل الكامل للجهاز الافتراضي وأحمال عمله ويتحقق منها. أما التصديق على مستوى العملية (مثل Intel SGX) فيعزل إجراءات برمجية أو بيئات معزولة (Enclaves) محددة داخل بيئة نظام تشغيل قياسية ويصادق عليها.

كيف تتكامل رموز التصديق مع Azure Key Vault؟

بعد أن ينجز حمل العمل السري عملية المصافحة الخاصة بالتصديق بنجاح، يحصل على رمز موقّع. ويمكن تقديم هذا الرمز إلى Azure Key Vault Managed HSM لإثبات سلامة البيئة، ما يُفعّل الإفراج الآلي عن مفاتيح التشفير وبيانات اعتماد قواعد البيانات.