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

اكتب الخدمة قبل أن تكتب القاعدة

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

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

ثلاثة نماذج للمصدر، ثلاث قواعد مختلفة

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

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

اقرأ الاتحاد عبر كل مجموعة مرتبطة

افتح النسخة، واعثر على واجهة الشبكة الخاصة بها، واسرد كل مجموعة أمان مرتبطة بها. ولكل مجموعة، افحص كل قاعدة تغطي بروتوكولك ومنفذك، بما في ذلك نطاقات المنافذ الواسعة وكلا عائلتي العناوين. قاعدة IPv4 من 0.0.0.0/0 لا تعفيك من فحص ::/0، والقاعدة التي تسمح بكل حركة المرور تخفي مسألة المنفذ تماما. وبعد هذا الجرد فقط يمكنك أن تقول ما هي الصلاحية الفعلية للخدمة.

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

قوائم التحكم في الوصول إلى الشبكة (NACL) سياسة منفصلة بلا حالة، ذات إدخالات سماح ومنع مرتبة، وهي تُقيَّم على الشبكة الفرعية لا على النسخة.

لا تجب بجدار من المنع

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

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

اختبر بجلسة جديدة واحتفظ بطريق للدخول

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

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

مقالات ذات صلة