هل ما زلت بحاجة إلى VPN إذا كنت تستخدم Identity-Aware Proxy؟

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

البوابتان تصرّحان بأشياء مختلفة

بوابة التطبيق تقرر ما إذا كان هذا الطلب، من هذه الهوية، قد يصل إلى هذا المورد المحمي. يصف نظرة عامة على Identity-Aware Proxy من Google هذا الشكل بالضبط: طبقة تصريح مركزية أمام تطبيقات HTTPS، يديرها دور IAM. الحد هو المورد، ووحدة الوصول هي الطلب. الـ VPN الموجّهة تفعل شيئًا أخشن وأوسع: فهي تسمح لعميل بنطاق شبكة محدد، وبعد ذلك يقرر التطبيق ما يمكن لهذا العميل فعله.

لا يفترض أي من النموذجين الآخر. عبور البوابة لا يقول شيئًا عن قراءة سجل معين، والتواجد على الشبكة لا يقول شيئًا عن السماح بالتصرّف.

ما لا يغطيه الوكيل ويغطيه الـ VPN

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

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

سير عمل العميل يقرر أكثر من مخطط الهندسة

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

عُدّ العملاء قبل عدّ التطبيقات. لوحة تحكم واحدة يمكن أن تخدم مئة شخص؛ ومنفذ قاعدة بيانات واحد يمكن أن يعطل فريقًا كاملًا.

وضع الجهاز ليس خاصية لأي من البوابتين

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

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

اعثر على المسارات البديلة قبل أن تتقاعد من أي شيء

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

ثم اكتب التسليم: التسجيل والتحديثات وإزالة الوصول ومسار الاستعادة لشخص أُغلق خارج النظام في الساعة 2 فجرًا. إزالة مطالبة أو تطبيق عميل تنقل المسؤولية بين الفرق؛ إنها لا تحذف المسؤولية.

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