لماذا تضيف المضيفات الوسيطة مخاطر

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

يوجد مضيف bastion في شبكة فرعية عامة مع منفذ (عادةً 22 لـ SSH أو 3389 لـ RDP) مفتوح للإنترنت أو لنطاق عناوين IP الخاص بالشركة. يتصل المسؤولون به، ثم يصلون إلى المثيلات الخاصة. وهو بمثابة الباب المحروس الوحيد إلى البيئة، ما يجعله عنصرًا بالغ الأهمية وهدفًا رئيسيًا في الوقت نفسه.

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

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

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

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

نظرًا إلى مرور كل حركة الإدارة عبر مضيف bastion، فإنه يمثل نقطة فشل واحدة وهدفًا عالي القيمة في آنٍ واحد. فإذا توقف، فقد المسؤولون الوصول؛ وإذا اختُرق، حصل المهاجم على منصة لإطلاق الهجمات. إن تركيز المخاطر في مضيف مكشوف واحد هو نمط معماري يريد الاختبار منكم تجنبه.

يلغي Systems Manager (SSM) Session Manager من AWS الحاجة إلى مضيفات bastion بالكامل. فهو يوفر وصولًا إلى الصدفة على المثيلات من خلال خدمة SSM مع عدم وجود منافذ واردة مفتوحة، أو عناوين IP عامة، أو مفاتيح SSH. ويتحكم IAM في الوصول، ويتم تسجيل كل جلسة، مما يعالج جميع نقاط ضعف نموذج bastion دفعةً واحدة.

يعمل SSM لأن المثيل يشغّل SSM Agent الذي ينشئ اتصالًا صادرًا بخدمة SSM، من دون فتح أي اتصال وارد. ويمكن لمجموعات الأمان رفض كل حركة المرور الواردة مع استمرار عمل الإدارة. ويمثل هذا التحول، من الصادر بدلًا من الوارد، الفكرة الأساسية التي تجعل مضيفات bastion غير ضرورية.

في الاختبار، غالبًا ما يكون لأي سيناريو يصف منافذ SSH/RDP مفتوحة، أو أزواج مفاتيح موزّعة، أو صندوق قفز إجابة أفضل: استبدال مضيف bastion بـ Session Manager. فهو يقلّص سطح الهجوم، ويجعل التحكم في الوصول مركزيًا عبر IAM، وينتج سجل تدقيق كاملًا، وهو تصميم آمن بأقل صلاحيات توصي به AWS.

يكشف مضيف bastion منفذًا واردًا، ويعتمد على مفاتيح SSH الدائمة، ويفرض تدقيقًا ضعيفًا، ويتطلب تصحيحًا مستمرًا، مما يجعله هدفًا مركّزًا وجذابًا. والبديل الموصى به هو SSM Session Manager، الذي يمنح وصولًا إلى الصدفة تتحكم فيه IAM وتسجّله بالكامل، مع عدم وجود منافذ مفتوحة أو عنوان IP عام أو مفاتيح على الإطلاق.

اختبر سبب خطورة مضيفات bastion.

يفتح مضيف bastion منفذ SSH/RDP واردًا، ويعتمد على مفاتيح SSH طويلة الأجل، ويفرض تدقيقًا ضعيفًا، ويتطلب تصحيحًا مستمرًا، مما يركّز المخاطر في هدف مكشوف واحد. ويستبدله SSM Session Manager بوصول يتحكم فيه IAM ويتم تسجيله بالكامل عبر اتصال صادر من خلال الوكيل، مع الحاجة إلى عدم وجود منافذ مفتوحة أو عنوان IP عام أو مفاتيح.