تتطلب المحاكاة الافتراضية الآمنة KMS وHSM

من قبل: إيغور جارديم

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

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

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

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

لماذا يتم إهمال أمن البيانات؟

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

اليوم، مع سهولة إنشاء خوادم افتراضية، أصبحت هذه مهمة غير عملية تقريبًا، مما يؤدي في النهاية إلى دفع مسؤولي النظام إلى اختيار عدم تشفير القرص عن طريق الخطأ.

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

حل للأمن

إذا فكرت: ولكن ماذا عن هبرفيسرألا يحل هذا الأمر؟ الإجابة المختصرة هي: لست وحدي.

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

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

استخدام KMS لتخزين المفاتيح التشفيرية

Kryptus kNET HSM يعمل كـ KMS.

لحل هذه المشكلة والحفاظ على المفاتيح آمنة، الحل هو استخدام KMS (خدمة إدارة المفاتيح). أنظمة إدارة المفاتيح (KMS) هي نوع من الأنظمة القادرة على إدارة دورة حياة المفاتيح التشفيرية بشكل آمن في شكل خدمة. في هذه الخدمة، يمكنك ربط العديد من الأنظمة الأخرى التي تدعم تشفير البيانات، مثل Hypervisor وقاعدة البيانات وحتى SIEMs.

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

إذا كنت تبحث عن حل لهذه المشكلة، فلدينا خبرين جيدين!

الأول هو أنه مع إصدار vSphere 6.5، قدمت VMware إمكانية تشفير الجهاز الظاهري (VM) نفسه بشكل شفاف، بغض النظر عن نظام التشغيل الذي يعمل عليه، مما يحل مشاكل الأمان التي ذكرناها بالفعل، بالإضافة إلى المساعدة في لوائح حماية البيانات مثل اللائحة العامة لحماية البيانات! بالنسبة لهذه الوظيفة، يستخدم vSphere نظام KMS لحماية مفاتيح التشفير الخاصة بك!

والخبر الثاني هو أن وحدة أمن الأجهزة kNET يعمل كـ KMS ومتوافق تمامًا مع Vmware vSphere.

التواصل بين vSphere وkNET

يوضح الشكل أدناه، بشكل عام، كيفية إجراء الاتصال بين vSphere الخاص بـ VMware وkNET الخاص بـ Kryptus:

1- أولاً، يجب أن تكون هناك علاقة ثقة بين kNET (KMS) و vCenter؛

2- يطلب vCenter مفتاحًا من KMS؛

3- يرسل KMS مفتاح تشفير رئيسي (KEK) إلى vCenter؛

4- يقوم vCenter بتخزين معرف المفتاح فقط ويرسل مجموعة KEK+ID إلى ESXi (Hypervisor)؛

5- يستقبل ESXi ويخزن KEK حصريًا في الذاكرة؛

6- مع استلام KEK، يقوم ESXi بإنشاء مفتاح تشفير البيانات (DEK) لتشفير ملفات VM؛

7- يقوم ESXi الآن بتشفير محركات الأقراص الثابتة VM باستخدام DEK ثم يقوم بتشفير DEK باستخدام KEK؛

ملاحظة: عند إعادة تشغيل ESXi، يطالب vCenter KMS بالمفتاح مرة أخرى وتتكرر العملية بأكملها.

علاقة الثقة بين VMware vCenter وKryptus kNET يتم ذلك بطريقة سهلة وعملية: باستخدام بروتوكول معالجة المفاتيح KMIP. للقيام بذلك، أضف مجموعة KMS التي سيتم استخدامها إلى vCenter، مع إعلام عنوان IP الخاص بـ kNET والمنفذ والمستخدم وكلمة المرور. يتم بعد ذلك إنشاء طلب توقيع شهادة (CSR)، والذي يجب توقيعه بواسطة KMS وإعادته إلى vCenter، والذي يقوم من تلك النقطة بإنشاء علاقة ثقة مع KMS.

فوائد تكامل VMware وkNET

مع التكامل، تحتوي مجموعة الخوادم على طبقتين من الحماية! يرجع ذلك إلى أن كل جهاز افتراضي مشفر بمفتاح DEK فريد، وكل مفتاح DEK، بدوره، مشفر بمفتاح KEK فريد. لذلك، حتى لو اكتشف المهاجم مفتاح DEK، فإنه بدون مفتاح KEK - والذي يتم تخزينه بشكل آمن داخل kNET HSM - لن يكون لديه حق الوصول إلى الملفات.

قبل استخدام نظام إدارة المفاتيح المدمج مع VMware لإدارة وتخزين المفاتيح، كان علينا إدخال كلمات المرور يدويًا على كل خادم. أما الآن، فقد أصبحت هذه العملية أكثر عملية، بالإضافة إلى تحسين أمان البيئة ككل بشكل ملحوظ، كما يقول إيغور، مدير تكنولوجيا المعلومات في Kryptus.

يقدم إيغور أيضًا نصيحة مفادها أنه يجب على المرء أن يفكر في تكوين أكثر من kNET واحد، وإنشاء مجموعة KMS، من أجل زيادة توفر النظام، نظرًا لأن ESXi، عند إعادة تشغيله، و/أو إنشاء مثيل لـ VM جديد، يطلب مفاتيح يجب توفيرها تحت خطر عدم التوفر.