الشبكات الخاصة وحماية التطبيقات
7 دقيقة قراءة
أهداف الدرس
- يحلل الشبكات الخاصة وحماية التطبيقات ويبرر القرار وحدوده.
المهارة
في مهمة SAA-C03 1.2 لا يكفي أن تقول «ضع قاعدة البيانات في شبكة خاصة». يرسم مهندس الحلول مسار كل طلب: من أين يصل العميل، أين تنتهي TLS، أي طبقة تستقبل الطلب، ما المنافذ بين الطبقات، وكيف تصل الطبقة الخاصة إلى خدمات AWS دون فتح مخرج عام غير لازم. النتيجة المطلوبة مخطط تدفق وحجج لكل منفذ ومسار، لا قائمة أسماء خدمات. المثال يفترض تطبيق ويب بثلاث طبقات؛ يختلف الحكم لتطبيق لا يملك اتصالًا عامًا أو يستخدم خدمة بلا خوادم.
اقرأ حدود الشبكة أولًا
الشبكة الفرعية «العامة» هي التي تملك جدول توجيه إلى بوابة إنترنت، وليس مجرد شبكة حصل فيها خادم على عنوان عام. الشبكة الخاصة لا تملك مسارًا مباشرًا إلى بوابة الإنترنت. هذا لا يعني أن كل مورد فيها معزول تمامًا: يمكنه استقبال طلب من موازن حمل داخلي أو من مجموعة أمنية مصرح بها، ويمكنه الوصول إلى خدمة عبر نقطة نهاية VPC أو إلى الإنترنت عبر NAT إذا صُمم ذلك. حدد المسارات بدل الوثوق باسم الشبكة.
مجموعات الأمان تتحكم بحركة مواردها وهي ذات حالة؛ الاستجابة لحركة مسموح بها لا تتطلب قاعدة عكسية مستقلة. قوائم التحكم بالشبكة NACL تعمل على مستوى الشبكة الفرعية ولا تحفظ الحالة، ولذلك يحتاج مسارها إلى قواعد للطلب والاستجابة. قاعدة NACL واسعة لا تعوض مجموعة أمان دقيقة، كما أن مجموعة أمان صحيحة لا تصلح جدول توجيه مفقودًا. عند تشخيص انقطاع اتصال، افحص DNS ثم التوجيه ثم مجموعة الأمان ثم NACL ثم خدمة الهدف؛ ترتيب الأدلة يمنع توسيع كل الحدود دفعة واحدة.
لا تضع بيانات اعتماد قاعدة البيانات في متغيرات ظاهرة أو داخل صورة الحاوية. استخدم إدارة أسرار مع صلاحية قراءة محددة لهوية التشغيل، وتحقق من طريقة تدوير السر وموعد تحديث تجمع الاتصالات. اختيار Secrets Manager لا يمنح صلاحية التطبيق تلقائيًا؛ تحتاج الهوية إلى إذن جلب السر وقد تحتاج الوصول إلى المفتاح إذا شُفر بمفتاح يديره العميل. افصل هوية التشغيل عن هوية النشر. عند عرض API علني، تقيّم قواعد AWS WAF على المورد المدعوم مثل ALB أو CloudFront وفق نمط الهجوم؛ WAF طبقة لحركة HTTP ولا يغني عن مصادقة التطبيق أو تقليل منافذ الشبكة. لا تفترض أن Shield أو WAF يزيلان كل هجوم أو خطأ منطقي في التطبيق.
حالة محلولة: بوابة حجوزات
الخطوة الأولى هي تحديد حدود الثقة: عميل الإنترنت إلى ALB على 443، ALB إلى خدمة الحاويات على منفذ التطبيق المحدد، خدمة الحاويات إلى قاعدة البيانات على منفذ المحرك، وخدمة الحاويات إلى S3 وسجل الصور عبر مخارج AWS المناسبة. انقل الحاويات وقاعدة البيانات إلى شبكات خاصة موزعة على منطقتي توافر. تبقى شبكات ALB عامة لأنه يستقبل العملاء، لكن قاعدة بيانات لا تحتاج بوابة إنترنت ولا عنوانًا عامًا. تضبط مجموعة ALB الوارد على 443 من العملاء؛ تضبط مجموعة الحاويات الوارد من مجموعة ALB فقط على منفذ التطبيق؛ تضبط مجموعة قاعدة البيانات الوارد من مجموعة الحاويات فقط على منفذ قاعدة البيانات. لا تفتح قاعدة البيانات للعالم ولا لجميع موارد VPC.
الخطوة الثانية هي مسار الخروج. لقراءة S3 من الحاويات الخاصة، صل جدول توجيه الشبكات الخاصة بنقطة نهاية gateway لـS3 في المنطقة المناسبة، ثم راجع سياسة النقطة وسياسة الحاوية مع IAM؛ وجود المسار لا يمنح إذن الكائن. نقاط gateway لـS3 أو DynamoDB لا تحتاج NAT أو بوابة إنترنت لهذا المرور، لكن لا تستخدمها تلقائيًا لكل خدمة. لسجل الصور أو Secrets Manager تحقق من نقاط interface المدعومة ومتطلبات DNS ومنافذها، أو صمم NAT للمخارج التي تتطلبه، مع حساب التكلفة والتوافر في درس لاحق. لا تخلط نقطة gateway لـS3 مع نقطة interface: الأخيرة تستخدم عناوين خاصة ولها خصائص ومسار تكلفة مختلفان. ولا تفترض أن نقطة النهاية في منطقة واحدة تخدم حركة منطقة أخرى.
الخطوة الثالثة هي اختبار الفشل المقصود. من عميل خارجي يجب أن تنجح `GET /health` عبر ALB، وأن يفشل اتصال مباشر بمنفذ قاعدة البيانات. من حاوية في الشبكة الخاصة يجب أن ينجح الوصول إلى الكائن المصرح به عبر S3 بعد تحقق IAM وسياسات النقطة، وأن يفشل كائن غير مصرح به. سجّل المسار الذي استُخدم فعليًا في جدول التوجيه، ولا تعد نجاح DNS دليلًا على نجاح السياسة. إذا فشلت قراءة الصورة الخاصة، فتّش عن متطلبات ECR ومسار S3 المرتبط بها قبل فتح مخرج إنترنت شامل. قرار التصميم هو إبقاء واجهة واحدة عامة وتقليل المسارات الداخلية والخارجية إلى الحاجة المثبتة. حدّه أن ALB العام يظل معرضًا لطلبات الويب، لذا تحتاج طبقات مصادقة ومراقبة وتدابير حماية تطبيقية بحسب المخاطر.
رسم الشبكة لا يكتمل بوضع كلمة خاص على صندوق قاعدة البيانات. اسأل من يبدأ الاتصال، وما البروتوكول والمنفذ، وما جدول التوجيه الذي يحمل الحزمة، وما المجموعة التي تقبلها عند الهدف. طلب العميل إلى ALB يختلف عن طلب ALB إلى التطبيق، ويختلف الاثنان عن اتصال التطبيق بقاعدة البيانات. إذا احتاج التطبيق S3 من شبكة خاصة، فمدخل gateway endpoint يغيّر مسار ذلك التدفق في جدول التوجيه، لكنه لا يمنح هوية التطبيق صلاحية S3 وحده؛ تظل سياسة الدور والدلو والمدخل جزءًا من القرار. اختبر أيضًا رجوع الاستجابة واتصال خدمة تحديث أو مراقبة أخرى قبل حذف NAT. في تحليل هجوم HTTP، ضع WAF عند طبقة HTTP المناسبة، ثم أبق تحقق المدخلات والتصريح داخل التطبيق. توسيع NACL أو مجموعة أمان قاعدة البيانات لا يعالج حقنًا في الطلب، ولو جعل الاختبار الشبكي أخضر.
تمرين ذو ناتج
| المسار | النتيجة من المدخلات | الإجراء والتحقق |
|---|---|---|
| العميل→ALB:443 | يصل | اختبر HTTPS والمسار العلني؛ لا تفتح منفذ قاعدة البيانات |
| ALB→حاوية:8080 | يصل | اختبر هدف ALB الصحي ورد التطبيق |
| حاوية→قاعدة:5432 | يصل لكن قاعدة المصدر واسعة | اربط الوارد بـSG الحاويات واختبر منع مورد غير مرتبط |
| حاوية الشبكة الأولى→S3 | مسار endpoint موجود؛ الإذن يحتاج تحققًا | اختبر IAM وسياسة النقطة وكائنًا مسموحًا |
| حاوية الشبكة الثانية→S3 | لا مسار endpoint ولا NAT | اربط جدولها بالنقطة، ثم اختبر الوصول والرفض |
تمييز مهني
في اختيار جواب امتحاني، افصل «خاص» بوصفه توجيهًا، و«مسموح» بوصفه قرار سياسة، و«آمن» بوصفه مجموعة ضوابط. نقطة النهاية توفر مسارًا؛ IAM وسياسات المورد تحدد الوصول. مجموعة الأمان تحدد حركة الشبكة؛ صلاحية التطبيق والبيانات تحدد ما يحدث بعد الاتصال. الإجابة القوية تعالج موضع الانكشاف أو الفشل الأول دون إدخال اعتماد ثابت أو شبكة خروج عامة غير ضرورية.
خلاصة الدرس
الجدول يبين نجاح 443 و8080، وضيق 5432، ونجاح S3 من كل شبكة بعد الربط. إذا كانت الوجهة غير S3 فلا يكفي gateway endpoint ويعود قرار interface endpoint أو NAT.