فرض الشبكة الظاهرية مع قواعد مسؤول الأمان في Azure Virtual Network Manager

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

هام

يتوفر Azure Virtual Network Manager بشكل عام لتكوينات اتصال النظام المحوري وتكوينات الأمان مع قواعد مسؤول الأمان. تظل تكوينات اتصال الشبكة قيد المعاينة.

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

فرض الشبكة الظاهرية

مع مجموعات أمان الشبكة (NSGs) وحدها، يمكن أن يكون الإنفاذ على نطاق واسع على الشبكات الظاهرية عبر العديد من التطبيقات أو الفرق أو حتى المؤسسات بأكملها أمرا صعبا. غالبا ما يكون هناك عمل موازنة بين محاولات الإنفاذ المركزي عبر المؤسسة وتسليم التحكم الدقيق والمرن للفرق.

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

نماذج الإنفاذ

لنلق نظرة على بعض النماذج الشائعة لإدارة الأمان دون قواعد مسؤول الأمان، و إيجابياتها وسلبياتها:

النموذج 1 - إدارة فريق الحوكمة المركزية مع مجموعات أمان الشبكة

في هذا النموذج، يدير فريق الحوكمة المركزية داخل المؤسسة جميع مجموعات أمان الشبكة.

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

النموذج 2 - إدارة الفريق الفردية باستخدام مجموعات أمان الشبكة

في هذا النموذج، تدير الفرق الفردية داخل المؤسسة دون فريق حوكمة مركزي مجموعات أمان الشبكة الخاصة بها.

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

قد يقوم الفريق الفردي أيضا بتكوين أو نسيان إرفاق مجموعات أمان الشبكة، مما يؤدي إلى التعرض للثغرات الأمنية.

النموذج 3 - يتم إنشاء مجموعات أمان الشبكة من خلال نهج Azure وتديرها فرق فردية.

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

المزايا العيوب
يتمتع الفريق الفردي بتحكم مرن في تصميم قواعد الأمان.

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

كما سيكون من غير الممكن إدارة الإعلامات.

فرض نسبة استخدام الشبكة والاستثناءات مع قواعد مسؤول الأمان

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

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

يوضح الرسم التخطيطي كيف يمكن للمسؤول تحقيق الأهداف التالية:

  • فرض قواعد مسؤول الأمان عبر المؤسسة.
  • السماح بالاستثناءات لفريق التطبيق للتعامل مع حركة مرور SSH.

رسم تخطيطي لفرض قواعد مسؤول الأمان مع مجموعات أمان الشبكة.

الخطوة 1: إنشاء مثيل مدير شبكة

يمكن لمسؤول الشركة إنشاء مدير شبكة مع مجموعة إدارة الجذر للشركة كنطاق مثيل مدير الشبكة هذا.

الخطوة 2: إنشاء مجموعات شبكة للشبكات الظاهرية

ينشئ المسؤول مجموعتي شبكة - مجموعة جميع الشبكات التي تتكون من جميع الشبكات الظاهرية في المؤسسة، ومجموعة شبكة التطبيق التي تتكون من شبكات ظاهرية للتطبيق الذي يحتاج إلى استثناء. تتكون مجموعة جميع الشبكة في الرسم التخطيطي أعلاه من VNet 1 إلى VNet 5، وتحتوي مجموعة شبكة التطبيقات على VNet 4 وVNet 5. يمكن للمستخدمين بسهولة تحديد مجموعتي الشبكة باستخدام العضوية الديناميكية.

الخطوة 3: إنشاء تكوين مسؤول أمان

في هذه الخطوة، يتم تعريف قاعدتين لمسؤول الأمان بتكوين مسؤول الأمان التالي:

  • قاعدة مسؤول أمان لحظر حركة مرور SSH الواردة لمجموعة جميع الشبكات ذات الأولوية الأقل من 100.
  • قاعدة مسؤول أمان للسماح بنسبة استخدام الشبكة SSH الواردة لمجموعة شبكة التطبيق ذات الأولوية الأعلى 10.

الخطوة 4: نشر تكوين مسؤول الأمان

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

الخطوات التالية