نقل تطبيق ويب لشركة إلى ما خلف الشبكة الخاصة الافتراضية: دليل تنفيذ الانتقال
تابع التغيير من إشارة المستخدم المرجعية إلى المستمع العام القديم. أبقِ HTTPS وحسابات التطبيق وكل متصل من خارج الموظفين داخل الخطة.
تخيّل التغيير من جهة المستخدم. ينقر أحدهم على إشارة مرجعية، ويتوقع صفحة الدخول المألوفة، فيحصل بدلًا من ذلك على خطأ في الاتصال لأن اسم المضيف لم يعد يستجيب إلا داخل النفق. تلك اللحظة الواحدة تحتوي على كل ما يجب أن تنجح فيه خطة الترحيل: الاسم والمسار والشهادة والحساب والعملية التي تقف خلفها. اتبع الخطوات أدناه بهذا الترتيب، وسيتوقف الانتقال عن كونه قفزة.
الخطوة 1: اكتب ما يفعله المستخدمون اليوم
ابدأ باسم المضيف في شريط العنوان، والمنفذ، والعمليات التي ينفذها الناس، والحسابات التي يستخدمونها. إن لم تستطع تسمية أهم ثلاث عمليات، فأنت لست جاهزًا لإغلاق المدخل العام، لأنك لن تتعرف على عملية معطلة أثناء القبول.
ثم قرّر من هم الجمهور الخاص. الموظفون على شبكة الشركة الخاصة الافتراضية بداية وليست إجابة. قد يحتاج المتعاقدون وفريق الدعم والفريق المالي جميعًا إلى التطبيق، وقد لا يجلسون جميعًا خلف البوابة نفسها.
الخطوة 2: افصل النفق عن تسجيل الدخول
عندما يصل المستخدم إلى التطبيق عبر الشبكة الخاصة الافتراضية، لا يزال المتصفح يفتح اتصال TLS بنقطة نهاية التطبيق نفسه. يجب أن تطابق الشهادة ذلك الاسم، ولا يزال التطبيق يوثّق الحساب. لا شيء في النفق يحل محل أي منهما.
هنا تنزلق عمليات الترحيل بهدوء. يقرر أحدهم أن العنوان الخاص لم يعد بحاجة إلى شهادة صالحة، فيتعلم المستخدمون النقر عبر تحذير، وتكون المؤسسة قد استبدلت تعرضًا عامًا ببرنامج تدريبي على تجاهل تنبيهات الأمان. إذا كان التطبيق يحتاج فعلًا إلى شهادة داخلية، فأصدر واحدة من السلطة الداخلية ووزّع الثقة بشكل صحيح. ذلك تغيير مضبوط؛ أما صفحة التحذير فليست كذلك.
أبقِ التفويض حيث يقيم أصلًا. إن ملخص هندسة انعدام الثقة من NIST يوضح النقطة مباشرة: الموقع على الشبكة ليس سببًا لمنح عملية حساسة. الوجود داخل النفق لا ينبغي أن يحوّل حساب قراءة فقط إلى مسؤول.
الخطوة 3: اعثر على المتصلين الذين ليسوا موظفين
افتح إعدادات التطبيق وأدرج كل ما يتحدث إليه: عنوان رد اتصال مزوّد الهوية، وويب هوك مزوّد الدفع، واستيراد مجدول، ومجس مراقبة، وعميل API لشريك. كل واحد منها تبعية لها مالك، وكل واحد منها سينكسر في لحظة مختلفة.
حدد مسارًا مدعومًا لكل واحد يجب أن يبقى. لا يستطيع مزوّد ويب هوك الانضمام إلى شبكة الموظفين الخاصة الافتراضية، لذا إما أن تكشف نقطة نهاية تكامل ضيقة النطاق لها توثيقها الخاص، أو تغيّر نموذج التكامل. إبقاء التطبيق كله عامًا لأن هناك رد اتصال واحد هو خيار، وهو عادةً الخيار الخاطئ.
اكتب كل استثناء مع الوجهة والعملية المسموح بها والتوثيق والمالك. حساب شبكة خاصة افتراضية عام يُمنح لتكامل هو الطريقة التي يصبح بها الاستثناء دائمًا. راجع القائمة في مراجعة الوصول التالية، لأن التكاملات تعيش أطول من المشاريع التي أضافتها. الاستثناء الذي لا تاريخ انتهاء له هو قرار تصميم دائم لم يتخذه أحد.
الخطوة 4: اسحب المسار العام، لا سجل DNS فقط
امشِ عبر سلسلة النشر: DNS، ومستمعو موازن التحميل، وقواعد الوسيط العكسي، وجدار حماية المضيف، وأي اسم بديل لا يزال يشير إلى العنوان القديم. افحص عائلتي العناوين. تغيير سجل A الرئيسي لا يثبت شيئًا تقريبًا إذا ظل CNAME أقدم أو مستمع IPv6 يخدم التطبيق.
وبالتوازي، تأكد من أن الاسم الخاص يُحل داخل النفق وأن الشهادة تغطي الاسم الذي سيكتبه المستخدمون. المستخدم الذي يضطر إلى لصق عنوان رقمي وجد عرَضًا، لا حلًا بديلًا.
احصر جمهور الشبكة الخاصة الافتراضية في مسار التطبيق. الوصول الواسع إلى شبكة المكتب يقايض قرار تعرض بقرار أكبر، وواجهات الإدارة تحتاج مصادرها المسموح بها بدلًا من أن ترث قاعدة المستخدمين.
الخطوة 5: نفّذ القبول بنفسك
اتصل كمستخدم معتمد، وافتح الإشارة المرجعية، وافحص الشهادة، وسجّل الدخول، ونفّذ عملية حقيقية واحدة. ثم جرّب حسابًا لا ينبغي أن يملك تلك العملية وتأكد من رفضه. ثم جرّب من جهاز خارج الشبكة الخاصة الافتراضية وتأكد من تعذر الوصول إلى التطبيق.
كرّر ذلك لكل تكامل محتفظ به، واقرأ سجل التسليم لدى المزوّد بدلًا من افتراض أن رمز 200 من أداة اختبارك يعني الشيء نفسه. تسجيل دخول ناجح إلى الشبكة الخاصة الافتراضية ليس دليلًا على أي من هذه النتائج.
الخطوة 6: تدرّب على اليوم السيئ
قرّر ما يحدث أثناء انقطاع النفق: تتوقف الأعمال، أو تتولى طريقة وصول معتمدة أخرى. أيًا كان اختيارك، اكتبه واختبره مرة واحدة، لأن إعادة الفتح العام في حالات الطوارئ كآلية تعافٍ غير موثقة سينفذها في النهاية شخص تحت ضغط.
احتفظ بوصول التعافي للمسؤولين الذين يصونون البوابة والتطبيق، مع مالك وتاريخ إزالة. سجّل التغيير وشروط عكسه في المكان نفسه، حتى لا يمنع ترحيل فاشل الأشخاص الذين سيصلحونه.
بعد الانتقال، يبقى الترقيع ودورة حياة الحسابات وتفويض التطبيق والتدقيق مسؤوليتك. لقد ضيّق النفق المدخل؛ لكنه لم يتولَّ أيًا من تلك المهام.