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

صعوبات تفاعل البنى التحتية المختلفة
يتم دعم عمليات VTB حاليًا من خلال ثلاث بنى تحتية قديمة: بنك موسكو السابق ، السابقين VTB24 و VTB نفسه. للبنية التحتية لكل منها مجموعة خاصة بها من محيط الشبكة ، توجد على حدودها معدات واقية. أحد شروط دمج البنى التحتية على مستوى الشبكة هو وجود بنية عناوين IP متسقة.
بعد الدمج مباشرة ، بدأنا في محاذاة مساحات العناوين ، والآن هو على وشك الانتهاء. لكن العملية تستغرق وقتًا طويلاً وسريعة ، وكانت المواعيد النهائية لتنظيم الوصول المتبادل بين البنى التحتية ضيقة للغاية. لذلك ، في المرحلة الأولى ، قمنا بربط البنى التحتية للبنوك المختلفة مع بعضها البعض بالشكل كما هي - من خلال وسائل الحماية من الحريق لعدد من المناطق الأمنية الرئيسية. وفقًا لهذا المخطط ، من أجل تنظيم الوصول من محيط شبكة إلى أخرى ، من الضروري توجيه حركة المرور عبر العديد من جدران الحماية وغيرها من وسائل الحماية ، والبث في عناوين الوصلات للموارد والمستخدمين الذين يستخدمون تقنيات NAT و PAT. علاوة على ذلك ، يتم حجز جميع جدران الحماية عند التقاطعات محليًا وجغرافيًا ، ويجب دائمًا أخذ ذلك في الاعتبار عند تنظيم التفاعلات وبناء سلاسل خدمة.
مثل هذا المخطط وظيفي تمامًا ، لكن بالتأكيد لا يمكنك تسميته على النحو الأمثل. هناك مشاكل فنية وتنظيمية. من الضروري تنسيق وتوثيق تفاعلات العديد من الأنظمة التي تنتشر مكوناتها عبر بنى تحتية ومناطق أمنية مختلفة. في الوقت نفسه ، في عملية تحويل البنية التحتية ، من الضروري تحديث هذه الوثائق بسرعة لكل نظام. يؤدي إجراء هذه العملية إلى تحميل مواردنا الأكثر قيمة - المتخصصين المؤهلين تأهيلا عاليا.
يتم التعبير عن المشكلات الفنية في مضاعفة عدد الزيارات على الروابط ، والحمل الكبير لأدوات الأمان ، وتعقيد تنظيم تفاعلات الشبكة ، وعدم القدرة على إنشاء بعض التفاعلات دون ترجمة العنوان.
تنشأ مشكلة تكاثر حركة المرور بشكل أساسي بسبب تفاعل العديد من مناطق الأمان مع بعضها البعض من خلال جدران الحماية على مواقع مختلفة. بغض النظر عن الموقع الجغرافي للخوادم نفسها ، إذا تجاوز عدد الزيارات محيط منطقة الأمان ، فسوف يمر عبر سلسلة من ميزات الأمان التي قد تكون موجودة في مواقع أخرى. على سبيل المثال ، لدينا خادمان في مركز بيانات واحد ، ولكن أحدهما في محيط VTB والآخر في محيط شبكة ex-VTB24. حركة المرور بينهما لا تمر مباشرة ، ولكنها تمر عبر 3-4 جدران حماية يمكن أن تكون نشطة في مراكز البيانات الأخرى ، وسيتم تسليم حركة المرور إلى جدار الحماية والعودة عدة مرات عبر شبكة الجذع.
لضمان موثوقية عالية ، نحتاج إلى كل جدار حماية من 3 إلى 4 نسخ - نسختان على موقع واحد في شكل مجموعة HA وجدار حماية أو جدارين على موقع آخر ، حيث سيتم التبديل عند مرور مجموعة جدار الحماية الرئيسية أو الموقع ككل.
نحن نلخص. هناك ثلاث شبكات مستقلة تمثل مجموعة
كاملة من المشكلات : التعقيد المفرط ، والحاجة إلى معدات إضافية باهظة الثمن ، والاختناقات ، وصعوبات التكرار ، ونتيجة لذلك ، ارتفاع تكاليف تشغيل البنية التحتية.
نهج التكامل العام
نظرًا لأننا قررنا التحول في بنية الشبكة ، سنبدأ بالأشياء الأساسية. دعنا ننتقل من الأعلى إلى الأسفل ، سنبدأ بتحليل متطلبات الأعمال والمتقدمين ومهندسي النظام وموظفي الأمن.
- بناءً على احتياجاتهم ، نقوم بتصميم الهيكل المستهدف للمناطق الأمنية ومبادئ الربط البيني بين هذه المناطق.
- نحن نفرض هيكل المناطق هذا على جغرافية المستهلكين الرئيسيين - مراكز البيانات والمكاتب الكبيرة.
- بعد ذلك ، نحن نشكل شبكة النقل MPLS.
- تحتها ، نأتي بالفعل بالشبكة الأساسية التي توفر الخدمات إلى الطبقة المادية.
- نختار مواقع لوضع وحدات الحافة ووحدات جدار الحماية.
- بعد توضيح الصورة المستهدفة ، نعمل على اعتماد منهجية الترحيل واعتمادها من البنية التحتية الحالية إلى الهدف حتى تصبح العملية شفافة في أنظمة العمل.
مفهوم الشبكة الهدفسيكون لدينا شبكة أساسية أساسية - وهي بنية تحتية لنقل الاتصالات تعتمد على خطوط الاتصالات بالألياف البصرية (FOCL) ، معدات تشكيل القنوات النشطة والفعالة. يمكن أيضًا استخدام النظام الفرعي لتكثيف القنوات الضوئية xWDM وربما شبكة SDH.
استنادًا إلى الشبكة الأساسية ، نقوم ببناء ما يسمى
الشبكة الأساسية . سيكون لديها خطة عنوان واحدة ومجموعة واحدة من بروتوكولات التوجيه. تشمل الشبكة الأساسية:
- MPLS - شبكة متعددة الخدمات ؛
- DCI - الروابط بين مراكز البيانات ؛
- وحدات EDGE - وحدات اتصال مختلفة: جدار الحماية ، والمنظمات الشريكة ، وقنوات الإنترنت ، ومراكز البيانات ، والشبكات المحلية ، والشبكات الإقليمية.
نقوم
بإنشاء شبكة متعددة الخدمات
وفقًا لمبدأ هرمي مع تخصيص نقاط العبور (P) و end (PE) . خلال تحليل أولي للمعدات المتوفرة في السوق اليوم ، أصبح من الواضح أنه سيكون من المجدي اقتصاديًا نقل مستوى العقد P إلى أجهزة منفصلة بدلاً من دمج وظيفة P / PE في جهاز واحد.
سيكون لشبكة متعددة الخدمات توفر عالي ، وتحمل للأخطاء ، والحد الأدنى من وقت التقارب ، وقابلية للتطوير ، والأداء العالي والوظائف ، ولا سيما IPv6 ودعم البث المتعدد.
أثناء إنشاء الشبكة الأساسية ، نعتزم
التخلي عن التقنيات الاحتكارية (حيثما أمكن ذلك دون المساس بالجودة) ، حيث نسعى جاهدين لجعل الحل مرنًا وغير مرتبط ببائع معين. لكن في الوقت نفسه ، لا نريد إنشاء "الخل" من معدات مختلف البائعين. يتمثل مبدأ التصميم الأساسي لدينا في توفير الحد الأقصى لعدد الخدمات عند استخدام معدات تكفي إلى الحد الأدنى لهذا العدد من البائعين. سيمكن ذلك ، من بين أشياء أخرى ، من تنظيم صيانة البنية التحتية للشبكة ، باستخدام عدد محدود من الموظفين. من المهم أيضًا أن تكون المعدات الجديدة متوافقة مع المعدات الحالية لضمان عملية انتقال سلسة.
من المخطط إعادة تصميم هيكل المناطق الأمنية لشبكات VTB و ex-VTB24 وشبكات بنك موسكو السابقة في إطار المشروع بالكامل بهدف الجمع بين الأجزاء المكررة وظيفياً. تم التخطيط لهيكل موحد لمناطق الأمان مع قواعد توجيه مشتركة ومفهوم موحد للوصول إلى العمل عبر الإنترنت. نخطط لتنفيذ جدار الحماية بين مناطق الأمان باستخدام جدران حماية منفصلة للأجهزة ، متباعدة في موقعين رئيسيين. نخطط أيضًا لتنفيذ جميع وحدات الحواف بشكل مستقل على موقعين مختلفين مع التكرار التلقائي بينهما بناءً على بروتوكولات التوجيه الديناميكية الموحدة.
نقوم بتنظيم إدارة معدات الشبكة الأساسية من خلال شبكة فعلية منفصلة (خارج النطاق). سيتم توفير الوصول الإداري إلى جميع معدات الشبكات من خلال خدمة واحدة للمصادقة والترخيص والمحاسبة (AAA).
للعثور بسرعة على المشكلات في الشبكة ، من المهم للغاية أن تكون قادرًا على نسخ حركة المرور من أي نقطة في الشبكة لتحليلها وتسليمها إلى المحلل عبر قناة اتصال مستقلة. للقيام بذلك ، سنقوم بإنشاء شبكة معزولة لحركة مرور SPAN ، والتي سنعمل على جمع وتصفية ونقل تدفقات حركة المرور إلى خوادم التحليلات.
لتوحيد الخدمات التي تقدمها الشبكة وإمكانية تخصيص التكاليف ، سنقدم كتالوجًا واحدًا يحتوي على مؤشرات SLA. ننتقل إلى نموذج الخدمة ، الذي نأخذ في الاعتبار الترابط بين البنية التحتية للشبكة والمهام المطبقة ، والربط البيني لعناصر تطبيقات التحكم ، وتأثيرها على الخدمات. ويدعم نموذج الخدمة هذا نظام مراقبة الشبكة حتى نتمكن من تخصيص تكاليف تكنولوجيا المعلومات بشكل صحيح.
من النظرية إلى الممارسة
الآن سننخفض إلى مستوى واحد ونخبرك عن الحلول الأكثر إثارة للاهتمام في البنية التحتية الجديدة لدينا والتي قد تكون مفيدة لك.
غابة الموارد: التفاصيل
لقد تعرفنا بالفعل
على سكان خابروفسك بغابة موارد VTB. حاول الآن إعطاء وصف فني أكثر تفصيلاً.

افترض أن لدينا اثنين من البنى التحتية للشبكة (للبساطة) للمنظمات المختلفة التي تحتاج إلى دمج. ضمن كل بنية تحتية ، كقاعدة عامة ، بين مجموعة قطاعات الشبكة الوظيفية (مناطق الأمان) ، يمكن للمرء أن يميز قطاع الشبكة الإنتاجية الرئيسي ، حيث توجد النظم الصناعية الرئيسية. نحن نربط هذه المناطق المنتجة بهيكل معين من قطاعات القفل ، والتي نسميها
"مجموعة الموارد" . تنشر مقاطع البوابة هذه الموارد المشتركة المتاحة من البنى التحتية اثنين.
يتمثل مفهوم مجموعة الموارد ، من وجهة نظر الشبكة ، في إنشاء منطقة أمان للبوابة تتكون من شبكتي VPN IP (لحالة بنكين). يتم توجيه شبكات IP VPN هذه بحرية فيما بينها وتتصل عبر جدران الحماية بشرائح منتجة. يتم تحديد عنوان IP لهذه القطاعات من مجموعة منفصلة من عناوين IP. وبالتالي ، يصبح التوجيه نحو مجموعة الموارد أمرًا ممكنًا من شبكات كلا المؤسستين.
ولكن مع التوجيه من مجموعة الموارد إلى القطاعات الصناعية ، يكون الموقف أسوأ إلى حد ما ، حيث تتداخل معالجة هذه العناصر غالبًا ومن المستحيل تكوين جدول واحد. لحل هذه المشكلة ، نحتاج فقط إلى قسمين في مجموعة الموارد. في كل جزء من أجزاء مجموعة تفرعات الموارد ، يتم كتابة مسار افتراضي نحو الشبكة الصناعية لمؤسستهم. وهذا يعني أنه يمكن للمستخدمين الوصول دون ترجمة العناوين إلى الجزء "الخاص بهم" من مجموعة تفرعات الموارد وإلى شريحة أخرى عبر PAT.
وبالتالي ، يمثل جزءان من مجموعة تفرعات الموارد منطقة أمان بوابة واحدة ، إذا قمت برسم الحدود على طول جدران الحماية. كل واحد منهم لديه التوجيه الخاص به: العبارة الافتراضية تتطلع نحو البنك "لها". إذا وضعنا موردًا في جزء من مجموعة الموارد ، فيمكن لمستخدمي البنك المقابل التفاعل معه دون NAT.
التفاعل دون NAT مهم للغاية بالنسبة للعديد من الأنظمة ، وقبل كل شيء بالنسبة لتفاعلات مجال Microsoft - بعد كل شيء ، في مجموعة الموارد ، لدينا خوادم Active Directory للمجال المشترك الجديد ، علاقات الثقة التي تم تأسيسها بواسطة كلا المؤسستين. أيضًا ، بدون تفاعل NAT ، هناك حاجة إلى أنظمة مثل Skype for Business و ABS "MBANK" والعديد من التطبيقات المختلفة الأخرى ، حيث يعود الخادم إلى عنوان العميل. وإذا كان العميل وراء PAT ، فلن يتم تأسيس الاتصال العكسي.
يتم تقسيم الخوادم التي نقوم بتثبيتها في قطاعات مجموعة الموارد إلى فئتين: البنية التحتية (على سبيل المثال ، خوادم MS AD) وتوفر الوصول إلى بعض أنظمة المعلومات. آخر نوع من الخوادم نسميه Data Marts. عادة ما تكون واجهات المتاجر خوادم ويب ، يوجد خلفها بالفعل جدار الحماية في شبكة الإنتاج الخاصة بالمؤسسة التي أنشأت واجهة المتجر هذه في مجموعة الموارد.
وكيف تتم
مصادقة المستخدمين عند الوصول إلى الموارد المنشورة؟ إذا قمنا ببساطة بتوفير الوصول إلى بعض التطبيقات لمستخدم واحد أو اثنين في مجال آخر ، فيمكننا إنشاء حسابات منفصلة للمصادقة في نطاقنا لهم. ولكن عندما نتحدث عن الاندماج الشامل للبنية التحتية - على سبيل المثال ، 50 ألف مستخدم - من غير الواقعي تمامًا البدء في حسابات مشتركة منفصلة والحفاظ عليها. من غير الممكن دائمًا إنشاء علاقات ثقة مباشرة بين غابات المؤسسات المختلفة ، سواء لأسباب أمنية أو بسبب الحاجة إلى جعل مستخدمي PAT في ظروف تقاطع مساحات العناوين. لذلك ، لحل مشكلة مصادقة المستخدم الموحدة ، يتم إنشاء مجموعة تفرعات MS AD جديدة تتكون من مجال واحد في محيط مجموعة الموارد. في هذا المجال الجديد ، يقوم المستخدمون بالمصادقة عند الوصول إلى الخدمات. لجعل هذا ممكنًا ، يتم إنشاء علاقات ثقة ثنائية المستوى بين مجموعة التفرعات الجديدة وغابات المجال لكل مؤسسة. وبالتالي ، يمكن لمستخدم أي من المنظمات المصادقة على أي مورد منشور.

الحصول على تكامل الشبكة
بعد أن أنشأنا تفاعل النظم من خلال البنية التحتية لغابة الموارد وبالتالي القضاء على الأعراض الحادة ، فقد حان الوقت لتناول التكامل المباشر للشبكات.
للقيام بذلك ، في المرحلة الأولى ، قمنا بتوصيل شرائح المنتجات من ثلاثة بنوك بجدار حماية واحد قوي (موحد منطقياً ، ولكن تم حجزه فعليًا عدة مرات في مواقع مختلفة). يوفر جدار الحماية تفاعلًا مباشرًا بين أنظمة البنوك المختلفة.
مع ex-VTB24 ، قبل تنظيم أي تفاعلات مباشرة بين الأنظمة ، تمكنا بالفعل من محاذاة مساحات العناوين. بعد أن شكلت جداول التوجيه على جدار الحماية وفتح الوصول المناسب ، تمكنا من ضمان التفاعل بين الأنظمة في بنيتين أساسيتين مختلفتين.
مع بنك موسكو السابق ، لم تتم محاذاة مساحات العناوين في وقت تنظيم التفاعلات التطبيقية ، وكان علينا استخدام NAT المتبادل لتنظيم تفاعل النظم. يؤدي استخدام NAT إلى إنشاء عدد من مشكلات دقة DNS التي تم حلها عن طريق صيانة مناطق DNS المكررة. بالإضافة إلى ذلك ، بسبب NAT ، كانت هناك صعوبات في تشغيل عدد من أنظمة التطبيق. لقد تخلصنا تقريبًا من تقاطعات مساحات العناوين ، لكننا نواجه حقيقة أن العديد من أنظمة VTB و ex-bank of Moscow مرتبطة ببعضها البعض بشكل وثيق للتفاعل في العناوين المترجمة. نحن الآن بحاجة إلى نقل هذه التفاعلات إلى عناوين IP حقيقية مع الحفاظ على استمرارية العمل.
إلغاء NAT
هدفنا هنا هو ضمان تشغيل الأنظمة في مساحة عنوان واحدة لزيادة تكامل كل من خدمات البنية التحتية (MS AD ، DNS) والتطبيق (Skype for Business ، MBANK). لسوء الحظ ، نظرًا لأن بعض أنظمة التطبيقات مرتبطة بالفعل مع بعضها البعض في العناوين المترجمة ، فإن العمل الفردي مع كل نظام تطبيق مطلوب للقضاء على NAT لتفاعلات محددة.
في بعض الأحيان ، يمكنك
الذهاب إلى مثل هذه الخدعة : قم بتعيين نفس الخادم في نفس الوقت تحت العنوان المترجم وتحت العنوان الحقيقي. لذلك ، يمكن لمسؤولي التطبيق اختبار العمل في عنوان حقيقي قبل الترحيل ، ومحاولة التبديل إلى التفاعل بخلاف NAT ، والتراجع إذا لزم الأمر. في الوقت نفسه ، نراقب جدار الحماية باستخدام وظيفة التقاط الحزمة لمعرفة ما إذا كان أي شخص يتصل بالخادم من خلال العنوان المترجم. بمجرد توقف هذا الاتصال ، نتوقف عن البث ، بالاتفاق مع مالك المورد: ليس لدى الخادم سوى عنوان حقيقي.
بعد تحليل NAT ، لسوء الحظ ، سيكون من الضروري لبعض الوقت الحفاظ على جدار الحماية بين القطاعات المتطابقة وظيفيًا ، لأنه لا تتوافق جميع المناطق مع نفس معايير الأمان. بعد توحيد المقاطع ، يتم استبدال جدار الحماية بين المقاطع عن طريق دمج مناطق الأمان المتطابقة وظيفياً مع بعضها البعض.
جدار الحماية
دعنا ننتقل إلى مشكلة جدار الحماية عبر الإنترنت. من حيث المبدأ ، من المهم بالنسبة لأي مؤسسة كبيرة يكون من الضروري فيها توفير التسامح مع الأعطال على الصعيدين المحلي والعالمي لمعدات الحماية.

دعونا نحاول صياغة مشكلة حجز جدار الحماية بشكل عام. لدينا موقعان: الموقع 1 والموقع 2. وهناك عدة (على سبيل المثال ، ثلاثة) شبكات VPN MPLS IP التي تتواصل مع بعضها البعض من خلال جدار حماية فعال. يجب أن يكون جدار الحماية هذا محجوزًا محليًا وجغرافيًا.
لن نأخذ في الاعتبار مشكلة النسخ الاحتياطي المحلي لجدران الحماية ؛ حيث توفر أي جهة تصنيع تقريبًا القدرة على تجميع جدران الحماية في مجموعة HA محلية. أما بالنسبة للحجز الجغرافي لجدران الحماية ، فليس هناك مورد تقريبًا لديه هذه المهمة.
بالطبع ، يمكنك "تمديد" مجموعة جدار الحماية عبر عدة مواقع على طول L2 ، ولكن بعد ذلك سوف تمثل هذه المجموعة نقطة فشل واحدة ولن تكون موثوقية حلنا عالية جدًا. لأن التجمعات تتجمد في بعض الأحيان تمامًا بسبب أخطاء البرنامج ، أو تنقسم إلى حالة انقسام الدماغ بسبب انقطاع رابط L2 بين المواقع. لهذا السبب ، رفضنا على الفور تمديد مجموعات جدار الحماية على L2.
لقد احتجنا إلى الخروج بمخطط ، إذا فشلت وحدة جدار الحماية في أحد المواقع ، فسيحدث انتقال تلقائي إلى موقع آخر. إليك كيف فعلنا ذلك.
تقرر الالتزام بنموذج الحجز الجغرافي النشط / الاستعداد عندما تكون المجموعة النشطة في نفس الموقع. خلاف ذلك ، نواجه على الفور مشاكل في التوجيه غير المتناظر ، والتي يصعب حلها مع عدد كبير من شبكات L3 VPN.
يجب أن تشير كتلة جدار الحماية النشط بطريقة ما إلى العملية الصحيحة. كطريقة للإشارة ، اخترنا إعلان OSPF من جدار الحماية إلى شبكة مسار (علامة) الاختبار باستخدام القناع / 32. يراقب جهاز الشبكة الموجود في الموقع 1 وجود هذا المسار من جدار الحماية ، وإذا كان ذلك متاحًا ، فإنه ينشط التوجيه الثابت (على سبيل المثال ، 0.0.0.0 / 0) ، نحو نظام جدار الحماية المحدد. ثم يتم وضع هذا المسار الافتراضي الثابت (من خلال إعادة التوزيع) في جدول بروتوكول BGP MP ويتم توزيعه عبر الشبكة الأساسية. , OSPF , , IP VPN.
, , , .
1 - , , 1 , 2 — . , , VPN' . , , , .
, active/standby. active-. , . , (, IP- ). . . .
L3 , . .
. , , — , , . L3-, .
, IP-. MPLS VPN. MPLS VPN «IN» VPN «OUT». VPN HUB-and-spoke VPN. Spoke HUB' VPN, .
«IN»
- Spoke VPN' VPN. «OUT»
Spoke VPN' .
MPLS VPN «IN». VPN . VPN HUB-VPN «IN» . . , Policy Based Routing. VPN «OUT», VPN «OUT» Spoke-VPN.

VPN, . MPLS import / export HUB VPN.
VPN , — , VLAN, ..
الخاتمة
, , . , , , . .