قوة الشبكة الصالحة الدنيا

يُعد فهم الشبكات السحابية أحد أكبر التحولات التي تواجه المؤسسات عند بدء رحلتها نحو السحابة. فعند النظر إلى مخطط العنونة والمكوّنات، تبدو الشبكة وكأنها شبكة IP. ومن معظم الزوايا هي كذلك بالفعل — لكنها في جوانب أخرى كثيرة ليست كذلك. فالشبكة المعرَّفة بالبرمجيات (SDN) – مثل تلك المتاحة في السحابة – لا تخضع للقيود نفسها التي تخضع لها الشبكة المادية، وقد يكون ذلك مربكاً إلى حد بعيد في البداية.

وبدلاً من محاولة فهم أوجه اختلاف SDN عن شبكتكم المادية، فلنركّز أكثر على ما تحتاجون إلى أن تقوم به الشبكة، والأهم من ذلك، ما ينبغي عدم السماح به. ولعلكم تتذكرون مفهوماً يُسمى "الرفض الافتراضي"، ويعني أن أي اتصال يُحظر تلقائياً ما لم تسمحوا به صراحةً. ثم ظهرت الويب، ولم يعد من الممكن تقييد المنفذ 80 أو 443 لأن كل التطبيقات تقريباً تستخدم هذين المنفذين. يُضاف إلى ذلك أن "الرفض الافتراضي" لم يتجاوز فعلياً حدود المحيط، وكانت شبكاتنا الداخلية تميل إلى أن تكون مسطحة ومفتوحة، معتمدةً على منطقة DMZ لتصفية حركة المرور الضارة القادمة من العالم الخارجي. وكما أظهرت الاختراقات المتتالية، فإن فعالية هذا النموذج متوسطة فحسب.

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

ينبغي للشبكة الصالحة الدنيا أن تُحدِّد بنية التطبيق ثم تُنشئ فقط عناصر الشبكة اللازمة لدعم ذلك التطبيق، مع فرض التوجيه ومجموعات الأمان وفق مبدأ الحد الأدنى من الامتيازات، والاستفادة كذلك من مكوّنات PaaS مثل موازِنات التحميل السحابية. وهذا يحوّل فعلياً الشبكة المُبدَّلة بالحزم إلى شبكة مُبدَّلة بالدوائر، بحيث لا يمكن لمكوّنات التطبيق أن تتواصل إلا مع المكوّنات الأخرى المسموح بها، ولا يمكن لأي جهة التنصت على حركة المرور بينها (باستثناء مزوّد الخدمة السحابية في بعض الحالات). وتُسقِط الشبكة كل حركة المرور الأخرى. ويُلغي ذلك الحاجة إلى بنى مثل منطقة DMZ التقليدية أو مناطق الشبكة، لأن الشبكة بأكملها تقوم على الحد الأدنى من الامتيازات والرفض الافتراضي.

ولنجعل الأمر أكثر وضوحاً من خلال مثال. يمكنكم إنشاء حزمة تطبيقات تقليدية من ثلاث طبقات مع موازِن تحميل تطبيقات موجَّه للعامة، تدعمه خوادم ويب في شبكة فرعية خاصة لا تقبل حركة المرور إلا من موازِن التحميل. ولا يمكن لخوادم الويب الاتصال إلا بخوادم التطبيقات التي تقبل الاتصالات منها. وبالمثل، لا يمكن لخوادم التطبيقات إرسال حركة المرور إلا إلى قواعد البيانات التي تسمح بهذه الاتصالات. وكل طبقة تعمل بالرفض الافتراضي ولا تسمح إلا بالاتصالات الواردة من موازِنات التحميل والاتصالات الصادرة إلى قواعد البيانات. وفي حالات كثيرة يمكنكم تنفيذ ذلك دون أي اتصال بالإنترنت (في شبكات فرعية خاصة) باستثناء موازِنات التحميل العامة، وهي بنى PaaS عالية الأمان يتولى مزوّد الخدمة السحابية صيانتها.

فبدلاً من بناء الشبكة ثم وضع التطبيقات داخلها، تصمّمون التطبيقات ثم تكيّفون الشبكة مع احتياجات التطبيق. وهذا يقلّص بدرجة كبيرة سطح الهجوم لحزمة التطبيقات ويخفّض المخاطر لديكم تبعاً لذلك.

لقد طبّقنا هذه المبادئ عند بنائنا موقع securosis.com، كما يتضح في المخطط المعماري أدناه. وإذا نظرنا إلى هذا التصميم بعين أمن الشبكات، نجد ما يلي:

• الوصول مقيَّد عبر جدار حماية تطبيقات الويب السحابي (WAF) بحيث لا تصل إلى VPC سوى حركة المرور النظيفة.
• موازِنات تحميل التطبيقات (ALBs) هي الموارد الوحيدة في الشبكات الفرعية الموجَّهة للعامة، ولا تسمح إلا بحركة المرور عبر 80/443.
• جميع المثيلات موجودة في شبكات فرعية خاصة ولا تقبل حركة المرور إلا من موازِنات ALBs.
• يقبل مثيل "admin" عمليات تسجيل الدخول، لكن فقط من شبكة VPN مستضافة في بيئة مختلفة.
• ولا تظهر في المخطط الشبكات الفرعية الخاصة بقاعدة بيانات RDS، وهي أيضاً خاصة فقط ولا تقبل حركة المرور إلا من المثيلات. وإذا استدعت الحاجة تسجيل دخول مباشر أو وصولاً إلى نظام إدارة قواعد البيانات العلائقية لمعالجة البيانات، تُعدَّل قواعد مجموعات الأمان لمنح وصول مؤقت.
• تتم الاتصالات بـ S3 عبر نقطة نهاية خدمة، ما يلغي الحاجة إلى بوابة NAT للوصول إلى الإنترنت.
• خدمة SSH معطَّلة على المثيلات غير الإدارية. وهذه المثيلات تعمل بالتوسع التلقائي وغير قابلة للتغيير، ولا تُعدَّل إلا بتغيير الصورة الأساسية.
• لا توجد مجموعات أمان ذاتية المرجعية (مجموعات أمان تسمح بالوصول الداخلي)، وذلك لمنع الهجمات الأفقية. وتعمل مجموعات الأمان في AWS على مستوى المورد لا على مستوى الشبكة الفرعية، وهو أمر بالغ الفعالية في صد هجمات الشرق/الغرب.
• تقلّص هذه البنية سطح الهجوم الإجمالي بدرجة كبيرة. فالشبكة لا تسمح إلا بالحد الأدنى من الاتصال المطلوب، ولا تحتوي إلا على الحد الأدنى المطلوب من الشبكات الفرعية وجداول التوجيه لإتاحة الوصول. لقد كيّفنا الشبكة عملياً مع التطبيق. بل إن الشبكة لم تُصمَّم إلا بعد وضع بنية حزمة التطبيقات.
• هذا مثال بسيط جداً لموقع صغير، لكن المبادئ نفسها تنطبق على بنى أكبر بكثير تضم عدداً أكبر من الطبقات وموازِنات التحميل الداخلية وبوابات API ومكوّنات PaaS.

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