هل ما زلت تحتاج إلى شبكة VPN للموقع عندما يستخدم التطبيق mTLS وSSO؟
امشِ عبر القنوات التي لا يغطيها تسجيل الدخول إلى تطبيقك، ثم قرر ما إذا كان الوصول إلى الشبكة الخاصة زائدًا عن الحاجة أو ما زال السبيل الوحيد إلى المضيف.
تُسجّل الدخول عبر mTLS، وتُحمّل لوحة المعلومات، ويبدو الادعاء بأن شبكة VPN للموقع أصبحت زائدة عن الحاجة معقولًا لقرابة المدة التي تستغرقها حتى تحتاج إلى استعادة قاعدة بيانات في الثانية صباحًا. حدّ TLS الخاص بالتطبيق يصف قناة واحدة. المضيف وقاعدة البيانات وهدف النسخ الاحتياطي وحساب السحابة يحمل كل منها مسار دخول خاصًا وهوية خاصة ومعتمِدًا خاصًا، ولا يُمارَس أي منها عبر تسجيل دخول ناجح.
امشِ إلى الخارج من شاشة تسجيل الدخول
سجّل الدخول كما يفعل مستخدم عادي واكتب كل قفزة تلمسها الطلب: المتصفح، الحافة، مستمع التطبيق، مخزن الجلسات، واجهة API الخلفية. لكل قفزة مالك وقرار مصادقة. كرر الآن المشي للشخص الذي يرقّع المضيف، وللمهمة التي تكتب النسخة الاحتياطية الليلية. تفترق تلك المسارات عادةً عند القفزة الأولى.
هذا الافتراق هو السؤال الجدير بالإجابة. لا تكون شبكة VPN للموقع زائدة عن الحاجة إلا عندما تمتلك كل قناة في ذلك المسير الثاني سياسة دخول وتخويل قائمة بذاتها.
خمس قنوات لا يغطيها تسجيل دخول التطبيق أبدًا
الجدول أدناه قالب جرد، وليس قائمة تحقق للنشر. املأ العمود الثاني بما تفرضه بيئتك فعليًا اليوم.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
لا تدمج مشاركة موفّر هوية واحد هذه التخويلات. المستخدم المسموح له بتقديم طلب API لا يُسمح له بذلك باستبدال قرص جهاز ظاهري أو استعادة قاعدة بيانات ببيانات اعتماد التطبيق. يحافظ ملخص هندسة الثقة الصفرية من NIST على فصل مصادقة المورد وتخويله عن الموقع الشبكي لهذا السبب تحديدًا.
مهندس الدعم الذي يستطيع قراءة تذكرة ليس مسموحًا له بذلك بفتح وحدة تحكم على المضيف الذي يقف خلفها.
المسار حقيقي فقط إذا بقي البديل مغلقًا
تقييد إمكانية الوصول إلى مستمعات إدارية خاصة بديل مشروع عن نفق الموقع، بشرط أن يُفرض التقييد لا أن يُرسم فقط. الفشل المعتاد هو مستمع بديل لم يتذكره أحد: خدمة ما زالت مرتبطة بكل الواجهات، وقاعدة مجموعة أمنية فُتحت لمقاول، ومنفذ إدارة يمكن الوصول إليه من الإنترنت.
افحص المستمعات لا المخططات. على المضيف، اسرد ما هو مرتبط فعلًا باستخدام ss -ltnp وتأكد من أن منافذ الإدارة على عنوان خاص. في وحدة تحكم السحابة، اقرأ قواعد الوارد لشبكة حمل العمل الفرعية وابحث عن 0.0.0.0/0 على أي شيء إداري. ثم جرّب الاتصال من خارج المسار الخاص، لأن ذلك الاختبار هو الذي يجيب عن السؤال.
قاعدة واحدة مفتوحة للعالم على SSH تلغي كل حجة قدمها تصميم النفق.
اكتب الخريطة قبل أن تقارن التصاميم
لكل صف من الجرد، سجّل من يعتمد الهويات، ومن يحدّث قواعد الوصول، ومن يزيل بيانات الاعتماد عند مغادرة شخص، ومن يتولى الاستعادة عندما ينكسر المسار نفسه. أربعة أسماء لكل صف تكفي لكشف الصفوف التي تكون الإجابة فيها حسابًا مشتركًا وصفحة ويكي من ثلاث سنوات مضت.
ثم تحقق من سماح واحد ومنع واحد لكل قناة. السماح يثبت أن الهوية المقصودة تستطيع الوصول إلى المورد عبر المسار المقصود. المنع يثبت أن هوية مشابهة لا تستطيع، وهو الاختبار الذي يتخطاه الناس، ولهذا تنجو المستمعات البديلة من عمليات التدقيق. قارن التصميم المقترح بهذه النتائج، لا بإعداد TLS الخاص بالتطبيق، الذي لم يمارس أيًا منها أبدًا.
حيث ما زال نفق الموقع يستحق مكانه
النفق أو البوابة الضيقة هو الإجابة الصحيحة عندما لا يمتلك المورد مصادقة خاصة به لكل طلب: منافذ صيانة قاعدة البيانات، وأهداف النسخ الاحتياطي، ووحدات تحكم المشرف الافتراضي، والإدارة خارج النطاق. تلك المستمعات تثق بالشبكة، لذا يجب أن تكون الشبكة هي ما يصادق على المتصل.
ليست الإجابة الوحيدة. يمكن أن تكون البوابة التي تنهي التخويل لكل مورد أضيق من نفق يشمل الشبكة الفرعية بأكملها، وتترك أثر تدقيق أفضل من مضيف قفز مشترك.
ترتيب العمل: أكمل الجرد، وأغلق البدائل، وتحقق من منع واحد لكل صف، وعندها فقط أسقط النفق. إذا لم يستطع صف إنتاج منع، فأبقِ المسار الخاص حتى يستطيع.