الشبكات حتى (إلى السحابة)— وجهة نظر مهندس معماري واحد

مقالة
07/16/2023

في هذه المقالة، يصف Ed Fisher، مهندس التوافق & الأمان في Microsoft، كيفية تحسين شبكتك للاتصال بالسحابة من خلال تجنب المخاطر الأكثر شيوعا.

نبذة عن الكاتب

لقطة شاشة لصورة Ed Fisher.

أنا حاليا متخصص تقني رئيسي في فريق البيع بالتجزئة والسلع الاستهلاكية لدينا، مع التركيز على التوافق & الأمان. لقد عملت مع العملاء الذين سينتقلون إلى Office 365 خلال السنوات العشر الماضية. لقد عملت مع متاجر أصغر مع عدد قليل من المواقع للوكالات الحكومية والمؤسسات مع الملايين من المستخدمين الموزعين في جميع أنحاء العالم، والعديد من العملاء الآخرين بينهما، مع وجود عشرات الآلاف من المستخدمين، ومواقع متعددة في أجزاء مختلفة من العالم، والحاجة إلى درجة أعلى من الأمان، والعديد من متطلبات التوافق. لقد ساعدت مئات المؤسسات والملايين من المستخدمين على الانتقال إلى السحابة بأمان وأمان.

مع خلفية على مدى السنوات ال 25 الماضية تتضمن الأمان والبنية الأساسية وهندسة الشبكات، وبعد نقل اثنين من أصحاب العمل السابقين إلى Office 365 قبل الانضمام إلى Microsoft، كنت على جانبك من الجدول الكثير من المرات، وتذكر ما يشبه ذلك. على الرغم من عدم وجود عميلين متشابهين على الإطلاق، فإن معظمهما لديه احتياجات مماثلة، وعند استهلاك خدمة موحدة مثل أي نظام أساسي SaaS أو PaaS، فإن أفضل الأساليب تميل إلى أن تكون هي نفسها.

إنها ليست الشبكة - إنها الطريقة التي تستخدمها بها (خطأ) !

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

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

المبادئ التوجيهية

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

لمجرد أنك تستطيع، لا يعني أنه يجب عليك: أو إعادة صياغة الدكتور إيان مالكولم من فيلم حديقة Jurassic "... نعم، نعم، لكن فريق الأمن الخاص بك كان منشغلا بما إذا كان بإمكانهم أم لا أن يتوقفوا عن التفكير إذا كان ينبغي عليهم ذلك".
لا يعني الأمان التعقيد: لست أكثر أمانا لمجرد إنفاق المزيد من المال أو التوجيه عبر المزيد من الأجهزة أو النقر فوق المزيد من الأزرار.
يتم الوصول إلى Office 365 عبر الإنترنت: ولكن هذا ليس نفس الشيء مثل Office 365 هو الإنترنت. إنها خدمة SaaS تديرها Microsoft وتديرها أنت. على عكس مواقع الويب التي تزورها على الإنترنت، يمكنك في الواقع الحصول على نظرة خاطفة خلف الستار، ويمكن تطبيق عناصر التحكم التي تحتاجها لتلبية سياساتك ومعايير التوافق الخاصة بك، طالما أنك تفهم أنه في حين يمكنك تحقيق أهدافك، قد تضطر فقط إلى القيام بها بطريقة مختلفة.
إن نقاط الاختناق سيئة، والفواصل المترجمة جيدة: يريد الجميع دائما إجراء نسخ احتياطي لجميع نسبة استخدام الشبكة على الإنترنت لجميع مستخدميهم إلى نقطة مركزية، عادة حتى يتمكنوا من مراقبتها وفرض النهج، ولكن في كثير من الأحيان لأنها إما أرخص من توفير الوصول إلى الإنترنت في جميع مواقعهم، أو أنها مجرد كيفية القيام بذلك. لكن نقاط الاختناق هذه هي بالضبط... نقاط حيث تخنق نسبة استخدام الشبكة. لا يوجد خطأ في منع المستخدمين من الاستعراض إلى Instagram أو بث مقاطع فيديو قطة، ولكن لا تعامل حركة مرور تطبيقات الأعمال المهمة بنفس الطريقة.
إذا لم يكن DNS سعيدا، فلا شيء سعيد: يمكن أن يكون DNS الضعيف هو أفضل شبكة مصممة، سواء كان ذلك عن طريق تكرار الطلبات إلى الخوادم في مناطق أخرى من العالم أو استخدام خوادم DNS الخاصة بم ISP أو خوادم DNS العامة الأخرى التي تخزن معلومات دقة DNS مؤقتا.
فقط لأن هذه هي الطريقة التي اعتدت على القيام بذلك، لا يعني أن هذه هي الطريقة التي يجب عليك القيام بها الآن: تتغير التكنولوجيا باستمرار Office 365 ليست استثناء. تطبيق تدابير الأمان التي تم تطويرها ونشرها للخدمات المحلية أو للتحكم في تصفح الويب لن يوفر نفس المستوى من ضمان الأمان، ويمكن أن يكون له تأثير سلبي كبير على الأداء.
تم بناء Office 365 للوصول إليها عبر الإنترنت: هذا كل شيء باختصار. بغض النظر عما تريد القيام به بين المستخدمين والحافة الخاصة بك، فإن نسبة استخدام الشبكة لا تزال تمر عبر الإنترنت بمجرد خروجها من شبكتك وقبل أن تصل إلى شبكتنا. حتى إذا كنت تستخدم Azure ExpressRoute لتوجيه بعض نسبة استخدام الشبكة الحساسة لزمن الانتقال من شبكتك مباشرة إلى شبكتنا، فإن الاتصال بالإنترنت مطلوب تماما. اقبله. لا تبالغ في ذلك.

حيث غالبا ما يتم اتخاذ خيارات سيئة

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

موارد غير كافية على الحافة

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

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

التقسيم الفرعي المترجم

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

يجب أن تتبع نسبة استخدام الشبكة لحل DNS مسار خروج الإنترنت

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

للوكيل أو عدم الوكيل، هذا هو السؤال

أحد الأشياء الأولى التي يجب مراعاتها هو ما إذا كنت تريد وكيل اتصالات المستخدمين Office 365. هذا سهل. لا وكيل. يتم الوصول إلى Office 365 عبر الإنترنت، ولكنه ليس الإنترنت. إنه امتداد لخدماتك الأساسية ويجب التعامل معه على هذا النحو. أي شيء قد ترغب في أن يفعله الوكيل، مثل DLP أو مكافحة البرامج الضارة أو فحص المحتوى، متاح بالفعل لك في الخدمة، ويمكن استخدامه على نطاق واسع ودون الحاجة إلى اختراق الاتصالات المشفرة ب TLS. ولكن إذا كنت تريد حقا وكيل نسبة استخدام الشبكة التي لا يمكنك التحكم في خلاف ذلك، انتبه إلى إرشاداتنا في https://aka.ms/pnc وفئات نسبة استخدام الشبكة في https://aka.ms/ipaddrs. لدينا ثلاث فئات من نسبة استخدام الشبكة Office 365. تحسين والسماح حقا يجب أن تذهب مباشرة وتجاوز الوكيل الخاص بك. يمكن أن يكون الافتراضي مدعوما. التفاصيل في تلك المستندات... اقرأها.

معظم العملاء الذين يصرون على استخدام وكيل، عندما ينظرون في الواقع إلى ما يفعلونه، يدركون أنه عندما يقدم العميل طلب HTTP CONNECT إلى الوكيل، يكون الوكيل الآن مجرد جهاز توجيه إضافي مكلف. البروتوكولات المستخدمة مثل MAPI وRTC ليست حتى بروتوكولات يفهمها وكلاء الويب، لذلك حتى مع تكسير TLS، فأنت لا تحصل على أي أمان إضافي. أنت* تحصل على زمن انتقال إضافي. راجع https://aka.ms/pnc لمزيد من المعلومات حول ذلك، بما في ذلك الفئات تحسين والسماح والافتراضي لنسبة استخدام الشبكة في Microsoft 365.

وأخيرا، ضع في اعتبارك التأثير العام على الوكيل واستجابته المقابلة للتعامل مع هذا التأثير. نظرا لأنه يتم إجراء المزيد والمزيد من الاتصالات من خلال الوكيل، فقد يقلل من عامل مقياس TCP بحيث لا يتعين عليه تخزين الكثير من نسبة استخدام الشبكة مؤقتا. لقد رأيت العملاء حيث كان وكلاءهم محملين بشكل زائد لدرجة أنهم كانوا يستخدمون Scale Factor من 0. نظرا لأن Scale Factor هي قيمة أسية ونرغب في استخدام 8، فإن كل انخفاض في قيمة Scale Factor هو تأثير سلبي كبير على معدل النقل.

فحص TLS يعني الأمان! ولكن ليس حقا! يرغب العديد من العملاء الذين لديهم وكلاء في استخدامها لفحص كل نسبة استخدام الشبكة، وهذا يعني أن TLS "كسر وفحص". عند القيام بذلك لموقع ويب يتم الوصول إليه عبر HTTPS (على الرغم من مخاوف الخصوصية) قد يتعين على وكيلك القيام بذلك لمدة 10 أو حتى 20 دفق متزامن لبضع مئات من المللي ثانية. إذا كان هناك تنزيل كبير أو ربما مقطع فيديو مضمن، فقد يستمر واحد أو أكثر من هذه الاتصالات لفترة أطول بكثير، ولكن بشكل عام، معظم هذه الاتصالات تنشئ وتنقل وتغلق بسرعة كبيرة. يعني إجراء الاستراحة والفحص أن الوكيل يجب أن يقوم بمضاعفة العمل. لكل اتصال من العميل إلى الوكيل، يجب على الوكيل أيضا إجراء اتصال منفصل مرة أخرى إلى نقطة النهاية. لذلك، 1 يصبح 2، 2 يصبح 4، 32 يصبح 64...انظر إلى أين أنا ذاهب؟ ربما قمت بتحديد حجم حل الوكيل الخاص بك بشكل جيد لتصفح الويب النموذجي، ولكن عندما تحاول القيام بنفس الشيء لاتصالات العميل Office 365، قد يكون عدد الاتصالات المتزامنة طويلة الأمد أوامر بحجم أكبر من حجم ما قمت بتحديد حجمه.

البث ليس مهما، إلا أنه

الخدمات الوحيدة في Office 365 التي تستخدم UDP هي Skype (سيتم إيقافها قريبا) وMicrosoft Teams. يستخدم Teams UDP لدفق نسبة استخدام الشبكة بما في ذلك مشاركة الصوت والفيديو والعرض التقديمي. تكون نسبة استخدام الشبكة المتدفقة مباشرة، مثل عندما يكون لديك اجتماع عبر الإنترنت مع الصوت والفيديو وتقديم الطوابق أو إجراء العروض التوضيحية. تستخدم هذه UDP لأنه إذا تم إسقاط الحزم، أو وصولها خارج الترتيب، فإنه من الناحية العملية غير ملحوظ من قبل المستخدم ويمكن أن يستمر الدفق فقط.

عندما لا تسمح بنسبة استخدام الشبكة UDP الصادرة من العملاء إلى الخدمة، يمكن أن تعود إلى استخدام TCP. ولكن إذا تم إسقاط حزمة TCP، يتوقف كل شيء حتى تنتهي مهلة إعادة الإرسال (RTO) ويمكن إعادة إرسال الحزمة المفقودة. إذا وصلت حزمة البيانات خارج الترتيب، يتوقف كل شيء حتى تصل الحزم الأخرى ويمكن إعادة تجميعها بالترتيب. يؤدي كلاهما إلى حدوث خلل واضح في الصوت (تذكر Max Headroom؟) والفيديو (هل نقرت فوق شيء ما... أوه، هناك هو) وتؤدي إلى الأداء الضعيف وتجربة مستخدم سيئة. وتذكر ما أطرحه أعلاه حول الوكلاء؟ عند إجبار عميل Teams على استخدام وكيل، فإنك تجبره على استخدام TCP. لذلك الآن أنت تسبب تأثيرات سلبية على الأداء مرتين.

قد يبدو تقسيم النفق مخيفا

لكنه ليس كذلك. جميع الاتصالات Office 365 عبر TLS. لقد تم تقديم TLS 1.2 لفترة طويلة الآن وسيتم تعطيل الإصدارات القديمة قريبا لأن العملاء القديمة لا تزال تستخدمها وهذا خطر.

لا يؤدي فرض اتصال TLS، أو 32 منها، على الانتقال عبر VPN قبل الانتقال إلى الخدمة بعد ذلك إلى إضافة الأمان. فهو يضيف زمن انتقال ويقلل من معدل النقل الإجمالي. في بعض حلول VPN، فإنه يجبر UDP على النفق من خلال TCP، والذي سيكون له مرة أخرى تأثير سلبي جدا على تدفق نسبة استخدام الشبكة. و، إلا إذا كنت تقوم بفحص TLS، ليس هناك رأسا على عقب، كل الجانب السلبي. هناك نسق شائع جدا بين العملاء، الآن بعد أن أصبحت معظم القوى العاملة لديهم بعيدة، وهو أنهم يرون نطاقا تردديا كبيرا وتأثيرات على الأداء من جعل جميع مستخدميهم يتصلون باستخدام VPN، بدلا من تكوين نفق منقسم للوصول إلى تحسين فئة Office 365 نقاط النهاية.

إنه إصلاح سهل للقيام بتقسيم النفق وهو إصلاح يجب عليك القيام به. لمزيد من الوقت، تأكد من مراجعة تحسين اتصال Office 365 للمستخدمين البعيدين باستخدام نفق تقسيم VPN.

خطايا الماضي

في كثير من الأحيان، يأتي سبب اتخاذ خيارات سيئة من مزيج من (1) عدم معرفة كيفية عمل الخدمة، (2) محاولة الالتزام بسياسات الشركة التي تمت كتابتها قبل اعتماد السحابة، و(3) فرق الأمان التي قد لا تكون مقتنعة بسهولة أن هناك أكثر من طريقة لتحقيق أهدافها. نأمل أن ما سبق، والروابط أدناه، سوف تساعد في الأول. قد تكون الرعاية التنفيذية مطلوبة لتجاوز الثانية. تساعد معالجة أهداف نهج الأمان، بدلا من أساليبها، في تحقيق الهدف الثالث. من الوصول المشروط إلى الإشراف على المحتوى، وDLP إلى حماية المعلومات، والتحقق من صحة نقطة النهاية إلى تهديدات اليوم الصفري - يمكن تحقيق أي هدف نهاية لسياسة أمان معقولة مع ما هو متاح في Office 365، ودون أي تبعية على معدات الشبكة المحلية، وأنفاق VPN المفروضة، وفواصل TLS وفحصها.

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

استثناءات القواعد

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

إذا كنت ستسمح بالأنفاق المنقسمة ولكنك تستخدم أيضا وكيلا لنسبة استخدام الشبكة العامة على الويب، فتأكد من أن ملف PAC الخاص بك يحدد ما يجب أن يكون مباشرا بالإضافة إلى كيفية تحديد نسبة استخدام الشبكة المثيرة للاهتمام لما يمر عبر نفق VPN. نحن نقدم نموذج ملفات PAC في https://aka.ms/ipaddrs ذلك يجعل هذا أسهل في الإدارة.

الختام

تستخدم عشرات الآلاف من المنظمات، بما في ذلك جميع المنظمات تقريبا Fortune 500، Office 365 كل يوم في مهامها الحرجة. إنهم يفعلون ذلك بأمان، ويفعلون ذلك عبر الإنترنت.

بغض النظر عن أهداف الأمان التي تلعبها، هناك طرق لتحقيقها لا تتطلب اتصالات VPN أو خوادم الوكيل أو فواصل TLS وفحصها أو خروج الإنترنت المركزي للحصول على نسبة استخدام الشبكة للمستخدمين خارج شبكتك وإلى شبكتنا بأسرع ما يمكن، ما يوفر أفضل أداء، سواء كانت شبكتك هي المقر الرئيسي للشركة، مكتب بعيد، أو هذا المستخدم الذي يعمل في المنزل. تستند إرشاداتنا إلى كيفية بناء خدمات Office 365 وضمان تجربة مستخدم آمنة وأداء.