VPN متعددة المستأجرين: بوابة مشتركة أم بوابة لكل مستأجر أم اتصال لكل مضيف
النفق ليس عزلاً للمستأجرين. قارن بين بوابة مشتركة وبوابات لكل مستأجر واتصالات لكل مضيف من حيث ربط الهويات والتوجيه والإخراج من الخدمة.
حدّد من يسمح بدخول العميل، وما يمنع ذلك العميل من الوصول إلى موارد مستأجر آخر. هذان قراران، واختيار IPsec أو WireGuard أو منتج شبكي متكامل لا يجيب عن أي منهما. النفق الذي يعمل بشكل مثالي قد يترك كل مستأجر قادراً على الوصول إلى كل مستأجر آخر، والمراجعة التي تعامل الأمرين كأنهما شيء واحد تعتمد تصميماً خاطئاً. اكتب خريطة العميل إلى الموارد أولاً: المديرون، ووصول الدعم، والخدمات المشتركة، والمسارات التي يجب أن تبقى ممنوعة.
ابدأ بالخريطة لا بالمنتج
تلك الخريطة هي الأثر الأول، وكل خيار أدناه ليس إلا قراراً حول موضع الحد الذي يفرضه. أبقِها قابلة للمراجعة: صف واحد لكل عميل، وصف واحد لكل خدمة مشتركة، والمسارات الممنوعة مكتوبة صراحة.
خريطة لا يستطيع أحد قراءتها هي خريطة لن يفرضها أحد.
نقطة دخول واحدة ومشكلة الربط الخاصة بها
كل موضع يحسمه سؤال تشغيلي واحد، والجدول هو المقارنة كاملة.
| Placement | The question it lives or dies on |
|---|---|
| One shared gateway | How does an admitted identity end up limited to its own resources and its own routing context? |
| A gateway per tenant | Who owns each gateway, its credentials, its policy, its updates and its eventual retirement? |
| A connection per hosted machine | How do enrollment, per-machine policy and replacement work at fleet scale? |
البوابة المشتركة تمركز القبول وتجمع الخطر في مكان واحد: العلاقة بين هوية المستأجر وسياسته. يجب أن تُترجم المجموعات أو عناوين الأنفاق إلى أذونات الموارد الصحيحة، والتصنيف المختلف لكل عميل لا يمنع شيئاً بحد ذاته. يمكن لسياقات التوجيه المنفصلة أن تحتفظ ببادئات متداخلة عندما تدعم المنصة ذلك ويكون التصميم مكتملاً. جدول التوجيه المشترك العادي لا يستطيع التمييز بين بادئتي وجهة متطابقتين لمجرد أن الأشخاص خلفهما لديهم حسابات مختلفة.
هذا هو الاختبار لمعظم التصاميم. مستأجران يرقّمان داخلياً بـ 10.0.0.0/8 يحتاجان إلى حالة توجيه منفصلة، لا إلى اتفاقية تسمية.
بوابة لكل مستأجر تشتري حدوداً وأنظمة
بوابة واحدة لكل عميل تجعل بعض الحدود الإدارية سهلة الشرح، لأن القبول والسياسة لذلك العميل يجتمعان معاً. لكنها أيضاً تضاعف الأنظمة التي تحتاج إلى بيانات اعتماد وتحديثات ومراقبة ومالك. وهي لا تفرض ترتيباً واحداً محدداً للعناوين العامة: مشاركة نقاط النهاية والترجمة وفصل البروتوكولات تعتمد على ما يدعمه التنفيذ فعلاً.
عُدّ الأنظمة والأشخاص قبل أن تعُدّ المكسب الأمني. تصميم فيه أربع بوابات أكثر مما يستطيع الفريق تحديثه ليس أكثر عزلاً في الواقع.
إذا كان عدد المستأجرين يتغير كل شهر، فإن ذلك النموذج يحتاج إلى قصة أتمتة لا إلى قالب.
الاتصالات لكل مضيف تنقل العمل
الاتصال على كل جهاز مستضاف لا يزيل العمل التشغيلي، بل ينقله إلى دورة حياة الجهاز. يصبح التسجيل والسياسة لكل جهاز وتدوير المفاتيح والاستبدال جزءاً من التهيئة، وتفشل داخل النافذة نفسها التي يفشل فيها الجهاز نفسه. بالنسبة لعدد قليل من المضيفين طويلي العمر على شبكات متمايزة يكون ذلك صحيحاً غالباً، وبالنسبة لأسطول فقد أصلاً تتبع أي صورة تعمل وأين نادراً ما يكون كذلك.
سمِّ دوراً لإصدار الهويات والتحديثات وإزالة الوصول والمراقبة والاستعادة تحت كل خيار. ثم اسأل عما يحدث في اليوم الذي يغادر فيه أحد العملاء.
الإخراج من الخدمة ينتمي إلى المقارنة
معظم المقارنات تتخطى الإخراج من الخدمة. إزالة مستأجر يجب أن تُبطل بيانات اعتماده، وتسقط سياسته، وتحرر عناوينه وحالة التوجيه الخاصة به، وتترك الجميع الآخرين دون مساس. إرشادات البنية الصفرية الثقة من NIST هي المرجع الصحيح هنا، لأنها تضع المصادقة والتصريح على المورد بدلاً من الثقة بموقع في الشبكة، وهذا ينطبق داخل قطاع العميل نفسه أيضاً.
زِن التدفقات المسموحة والممنوعة ومعالجة العناوين المتداخلة وإجراء الإخراج من الخدمة قبل أن تزن مقاييس البروتوكولات. ثم اختر طريقة نقل ومصادقة تناسب الحد الذي اخترته. اسم منتج أقدم، أو ادعاء بأن كل شركة يجب أن توحّد بروتوكولاً واحداً، لا يحسم أي شيء من ذلك. الخريطة التي كتبتها أولاً هي التي تحسمه.