وصول الشريك إلى HSM عبر VPN: تعريف عمليات المفاتيح

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

أبقِ الحالة الملموسة في الاعتبار: يقدّم الشريك مستندًا معتمدًا للتوقيع بمفتاح واحد محدد، ولا شيء غير ذلك. كل ما يلي ينبع من تلك الجملة الواحدة.

إمكانية الوصول والهوية وسياسة المفاتيح ثلاث بوابات

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

اربط كل بوابة بمالك قبل كتابة المتطلبات. وعندما لا يملك أحد البوابة الثانية، فالنتيجة المعتادة أن تُمنح هوية مسؤول HSM واسعة لأنها بيان الاعتماد الوحيد الذي يعمل.

البوابة الأولى: مسار الشبكة الممنوح للشريك

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

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

البوابة الثانية: ما الذي يصادق فعليًا أمام HSM

هوية VPN وهوية HSM كائنان منفصلان ما لم يدمجهما تكامل مدعوم عمدًا. ومع عميل PKCS#11 ينفذ التطبيق تسجيل دخول إلى فتحة ببيان اعتماد مخزّن في مكان ما على مضيف الشريك، وذلك التسجيل هو ما يقيّمه HSM.

يُعد AWS CloudHSM مرجعًا مفيدًا لأن توثيقه يفصل بين الاثنين: مستخدمو HSM مختلفون عن مستخدمي IAM، ونوع المستخدم يحكم ما يجوز للحساب فعله. يدير ضابط التشفير المستخدمين والمفاتيح لكنه ليس الهوية التي تنفذ العمليات التشفيرية، بينما يمكن لمستخدم التشفير استخدام المفاتيح دون القدرة على إدارتها. ذلك الفصل هو الشكل الذي تريده حتى على جهاز مورّد آخر، حيث ستختلف أسماء الأدوار.

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

البوابة الثالثة: أي مفتاح، وأي عملية

التوقيع وفك التشفير وتوليد المفاتيح وتغليف المفاتيح وإدارة المستخدمين أذونات منفصلة ويجب سردها منفصلة. بمصطلحات PKCS#11، تصف سمات مثل CKA_SENSITIVE و CKA_EXTRACTABLE ما إذا كانت مادة المفتاح يمكن أن تغادر الوحدة بصيغة صالحة للاستخدام، وهي تُضبط لكل مفتاح لا لكل جهاز. اقرأ السياسة الفعلية على المفتاح بدلًا من استنتاج عدم قابلية التصدير من كلمة عتاد أو من وجود نفق.

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

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

الرفض جزء من اختبار القبول

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

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

المصافحة المكتملة عبر VPN تنتمي إلى ذلك السجل. ولا يمكن أن تحل محل نتيجة واحدة خاصة بـ HSM.