ستاك AWS الإنتاجي في السعودية: قائمة تحقق قبل الإطلاق

في سوق الحوسبة السحابية السعودية، كثير من الفرق الهندسية تختار الـ Stack الإنتاجي على AWS بناءً على قائمة ميزاته: عدد الخدمات، سهولة النشر، وجودة القوالب الجاهزة. لكن هذه الطريقة لا تصمد أمام أول مراجعة جدية. السؤال الذي يجب أن يُطرح قبل الإطلاق ليس "ماذا يقدّم الـ Stack؟" بل "أي متطلب إنتاجي في منطقتنا يلبّيه أي مكوّن، وكيف نتحقق من ذلك قبل أن يصبح التصحيح بعد الإطلاق مكلفاً؟".

في هذا الدليل العملي، نبني قائمة تحقق (Checklist) تربط كل شرط إطلاق لمشروع AWS في السعودية بالمكوّن المسؤول عن تنفيذه. نبدأ بمنطق القياس: لماذا لا يُحكم على الـ Stack بقائمة ميزاته بل بقائمة متطلبات، ثم نحدد الشرط المسبق، وهو دورك كمشترك والتحقق من النسخة السارية من ضوابط NCA، إذ يمتد الإطار الحاكم في CCC-2:2024 ليشمل مزوّد الخدمة والمشترك معاً، ودليل المشترك هو الأقرب لمسؤولياتك. بعد ذلك نمر على المتطلبات الخمسة بالتسلسل: الشبكة داخل المنطقة والمكوّن المنفّذ لها، تقوية عناقيد EKS قبل الإطلاق، صلاحيات بأقل امتياز وحدود الأدوار، إدارة الأسرار ومنع تسريبها إلى الحالة أو المستودع، وأخيراً التسجيل والمراقبة والاحتفاظ. ونختم بجدول Checklist نهائي يضم المتطلب والمكوّن وطريقة التحقق وعلامة الرفض، لنحوّل كلمة "curated" من وصف تسويقي إلى شيء يمكنك اختباره بنفسك.

لماذا لا يُقاس الـ Stack بقائمة ميزاته بل بقائمة متطلبات

صفحة المنتج تجيب سؤالًا واحدًا: ماذا يتضمن الـ stack؟ أما الإطلاق الناجح فيُقاس بسؤال مختلف: ماذا يفرضه السياق التنظيمي والتشغيلي في السعودية على الشبكة والعنقود والصلاحيات والأسرار واللوغات؟ هذا الفرق لا تظهره قائمة الميزات، ولا يكشفه وسم verified أو curated.

وجود وحدة VPC أو IAM ليس جوابًا، بل سؤال: هل تضبط CIDR والعزل ومسارات الخروج كما يطلبها مسار المراجعة قبل الإطلاق؟ هل تربط أدوار IRSA بحدود واضحة؟ هل تجعل الاحتفاظ باللوغات معاملًا صريحًا؟ إن لم يوجد جواب مكتوب في الكود أو الوثائق، فالميزة غير مكتملة.

لذلك صُغ معيار الرفض مبكرًا: أي مكوّن يحتاج إعادة عمل بعد الإطلاق في الشبكة أو العنقود أو الصلاحيات مرفوض. والتحقق ليس تصديقًا: فحص الصياغة والتوقيع بـ cosign يثبت سلامة الملف، لا مطابقته لضوابطك. أما «منسّق» فيصف جودة الإنتاج، لا ملاءمة السياق.

النتيجة: تحويل الشراء من مقارنة قوائم إلى قائمة تحقق يملكها المشتري. هذا هو معنى ما الذي يجعل الـ Cloud Stack جاهزاً للإنتاج فعلاً؟، وكيف تُسلَّم الوحدات المنسّقة كتسليم واحد.

الشرط المسبق: دورك كمشترك والتحقق من النسخة السارية من ضوابط NCA

بعد أن حوّلنا الميزة إلى سؤال، يبقى تثبيت الإطار الذي تُقاس به الإجابات. ضوابط الأمن السيبراني للحوسبة السحابية من الهيئة الوطنية للأمن السيبراني هي الإطار الحاكم: تمتد من الضوابط الأساسية، وتضع متطلبات للحوسبة السحابية من منظوري مزوّد الخدمة والمشترك، وتنطبق على كل الخدمات السحابية، والنسخة السارية هي CCC-2:2024.

نفّذ خطوتين قبل بناء القائمة:

1. حدّد دورك: المشتري الذي ينشر على AWS في موقع المشترك (subscriber)، لذا دليل التنفيذ الموجّه للمشتركين هو مرجعك، ودليل المزوّد يخص الطرف الآخر في العلاقة.

2. تحقق من النسخة: CCC-1 صدرت في 2020 وCCC-2 في 2024 مع ملحق يوضح التغييرات، والنسخة 2024 سارية وإصدار 1442 (هـ) سابق.

لا تكتفِ بالتحقق مرة واحدة: الهيئة تراجع الضوابط وتحدّثها دوريًا وتعلن وجوب تطبيق النسخة المعدلة، فقد تكون قائمة أُعدّت عند بداية المشروع قديمة عند الإطلاق.

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

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

بعد تثبيت النسخة السارية وتحديد دورك كمشترك، يبدأ أول بند قابل للقياس: الشبكة. السؤال الذي يجب أن يجيب عنه الـ stack كتابةً هو: هل ينشئ الشبكة داخل منطقة AWS المختارة في السعودية، أم يفتح اتصالات عابرة للمناطق في مسارات غير ضرورية؟

المكوّن المسؤول عن ذلك هو وحدة الشبكة (VPC وsubnets وتوجيهها)، ووحدات الربط (transit/VPC peering)، وقواعد الخروج (egress)، ووحدات النقاط الطرفية الخاصة بخدمات AWS. أي stack لا يفصل هذه المسؤوليات في وحدات مستقلة يجعل المراجعة لاحقًا تخمينًا.

كيف تتحقق قبل الإدماج

1. تتبّع مخرجات terraform plan وحدّد كل مورد ينشأ داخل المنطقة المطلوبة وكل مورد ينشأ خارجها.

2. راجع مسارات خروج العُقد إلى الإنترنت ومسارات الوصول إلى واجهات AWS؛ كل مسار يخرج من المنطقة يحتاج مبررًا مكتوبًا.

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

علامات الرفض: شبكة مثبتة افتراضيًا على منطقة واحدة دون معامل واضح، عزل غير مكتمل بين طبقتي الحوسبة والبيانات، أو نقاط دخول عامة غير مبرَّرة في مسار الإنتاج.

عمليًا، يمكن فحص وحدة شبكة جاهزة من السوق بدءًا من 29 دولارًا للوحدة دون اشتراك، لكن الفحص لا قيمة له إن لم يُجب عن الأسئلة أعلاه قبل الإدماج.

المتطلب الثاني: تقوية عناقيد EKS قبل الإطلاق

بعد ضبط الشبكة، ينتقل الاختبار إلى ما يعمل فوقها: العنقود نفسه. المكوّن المسؤول هنا هو وحدة العنقود ووحدات مجموعات العُقد ووحدة المكوّنات الإضافية ووحدة سياسات الشبكة داخل العنقود. راجع الكود مقابل منصة حاويات AWS (EKS) للتأكد من أن كل إعداد مطلوب ممثل في المورِدات لا في الوثائق فقط.

اسأل أولًا: من ينشئ نقطة النهاية العامة لواجهة Kubernetes؟ ومن يملك الوصول إليها؟ وهل مجموعة عُقد الإنتاج على شبكات خاصة فعلًا، أم تحتفظ بمسار عام افتراضي؟ ثم تحقق من سياسات الشبكة: هل تفرض وحدة NetworkPolicy فصلًا بين الأعباء، أم أن الإعداد الافتراضي يسمح لكل حاوية برؤية كل حاوية؟ وأخيرًا، وثّق قناة تحديث العنقود وإصدار Kubernetes والمكوّنات الإضافية. القناة المقبولة قابلة للتكرار ومختبَرة، لا خطوات يدوية تُنسى عند أول ضغط زمني.

ارفض أي تصريف في صلاحيات الحاويات الافتراضية، أو غياب requests‏/limits، أو آلية تحديث لا يمكن تشغيلها على بيئة مطابقة قبل الإطلاق. اجعل كل إعداد عنقود يمر على بيئة إنتاج مطابقة أو قريبة منها، لأن إصلاحه بعد الإطلاق يمس توفر الخدمة مباشرة.

المتطلب الثالث: صلاحيات بأقل امتياز وحدود الأدوار

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

معيار التحقق الأول: هل دور نشر البنية التحتية، ودور تشغيل التطبيق، ودور خط النشر (pipeline) مفصولة فعليًا، أم يشترك اثنان منها في سياسة واحدة واسعة؟

المعيار الثاني: اقرأ كل سياسة كمورِدات وشروط محددة، وأحصِ كل استخدام لـ wildcard في الأفعال أو الموارد، واطلب مبررًا مكتوبًا لكل واحد قبل الإطلاق. وإن استُخدم IRSA، فتحقق من ربط كل ServiceAccount بدور محدد لا بدور مشترك.

النقطة التنظيمية: ترتبط ضوابط الهويات بوثيقتين مرافقتين، سياسة إدارة هويات الدخول والصلاحيات وسياسة الأمن السيبراني للجهات الخارجية، ويُستحسن الرجوع إليهما عند تصميم الوصول والأطراف الثالثة، مع التحقق من النسخة السارية من ضوابط الأمن السيبراني للحوسبة السحابية.

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

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

المتطلب الرابع: إدارة الأسرار وعدم تسريبها إلى الحالة أو المستودع

بعد فصل الأدوار، ينتقل الخطر إلى مكان تخزين القيم الحساسة نفسها. المكوّن المسؤول هنا هو وحدة إدارة الأسرار، ووحدة التشفير KMS، ووحدة إدارة الحالة state backend، وسياسة الوصول إلى ملف الحالة. راجع إدارة الأسرار والمفاتيح كمرجع تصميمي، ثم اختبر:

• أين تُخزَّن الأسرار فعليًا؟ ومن يقرأها؟ وهل تُمرَّر إلى الأعباء وقت التشغيل أم تُكتب في متغيرات أو في ملف الحالة؟

• من يملك فك تشفير مفاتيح KMS المخصصة؟ وهل هناك فصل واجبات بين الناشر وقارئ الأسرار، أم دور واحد يجمع الاثنين؟

• ماذا يحدث عند الدوران؟ إذا تطلب إعادة تطبيق كاملة أو تدخلًا يدويًا، فالتصميم هش أمام أول تسريب أو انتهاء صلاحية.

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

المتطلب الخامس: التسجيل والمراقبة والاحتفاظ

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

تحقق أولًا من نطاق التفعيل: هل التسجيل مفعّل على مستوى الحساب والمنطقة والعنقود معًا، أم مقتصر على طبقة واحدة تاركًا فراغًا في مسار التحقيق؟ ثم اسأل أين تُخزَّن اللوغات ومن يستطيع تعديلها أو حذفها، فحماية سجل التدقيق من التعديل شرط عملي لصلاحيته عند المراجعة، وليست تحسينًا لاحقًا.

أما مدة الاحتفاظ فيجب أن تكون معاملًا صريحًا في الوحدة، لا قيمة افتراضية لا يعرف أحد من قررها ولا متى يعيد تقييمها.

علامات الرفض: تنبيهات غير موجّهة إلى أي قناة، غياب أثر لعمليات تغيير الصلاحيات والشبكة، أو لوغات قصيرة الأمد تختفي قبل أي مراجعة دورية.

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

جدول الـ Checklist النهائي: المتطلب، المكوّن، طريقة التحقق، وعلامة الرفض

بعد أن يثبت مسار التحقيق في القسم السابق، اجمع المتطلبات الخمسة في جدول حكم واحد، واشترط لكل صف جوابًا مكتوبًا في الكود أو الوثائق قبل أي إطلاق:

طبّق الجدول على أي stack تدرسه، بما في ذلك الحزم الجاهزة للإنتاج على AWS وEKS. إن غاب جواب مكتوب لكل صف في الكود أو الوثائق، فأصلح ذلك قبل قياس أداء أي ميزة أخرى. ولاختيار الوحدة المناسبة مسبقًا، راجع المستويات الأربعة وما يكلّفه كل منها.

الخلاصة: ما الذي يحوّل كلمة curated إلى شيء قابل للتحقق

بعد أن اكتمل الجدول بخمسة صفوف، تبقى خطوات تضمن أن الحكم على أي Stack مبني على دليل لا على وصف.

1. افتح ملف ضوابط الحوسبة السحابية ودليل المشترك من NCA، وثبّت النسخة السارية (2024) وأدرج تاريخها في مستند مراجعة ما قبل الإطلاق. أعد التحقق قبل كل مراجعة لأن الضوابط تُحدَّث دوريًا.

2. حوّل المتطلبات الخمسة إلى جدول بأربعة أعمدة: المتطلب، المكوّن، طريقة التحقق، علامة الرفض. لا تدمج في الفرع الرئيسي قبل وجود جواب مكتوب لكل صف.

3. ارفض أي مكوّن يحتاج إعادة عمل بعد الإطلاق. فضّل وحدات Terraform أو OpenTofu أو Ansible المُتحقَّق منها والمفحوصة أمنيًا والموقّعة بـ cosign، والمتاحة للتنزيل منفردة بدءًا من 29 دولارًا بلا اشتراك، لأنها تُنتِج إعدادًا متكررًا وقابلًا للاختبار.

4. طبّق الـ checklist على أي حزمة جاهزة للإنتاج، ومع مُنسّق مثل Vizier، لكن اجعل الحكم لاختبارك لا لوسم المنتج.

الخلاصة: curated صفة تُثبت بالكود والوثائق. تحويلها من كلمة تسويقية إلى واقع هو ما يجعل الـ checklist بيدك أداة حكم.