دليل الترحيل السحابي للمؤسسات السعودية: ضوابط NCA ECC وإقامة البيانات
دليل عملي لترحيل المؤسسات السعودية إلى الحوسبة السحابية بما يتوافق مع ضوابط NCA ECC ومتطلبات إقامة البيانات وإطار CCRF، مع خارطة طريق وجدول تكاليف تفصيلي.

دليل الترحيل السحابي للمؤسسات السعودية: ضوابط NCA ECC وإقامة البيانات
معظم مشاريع الترحيل السحابي (Cloud Migration) في المملكة العربية السعودية لا تتعثر بسبب سعة الشبكة أو نضج بيئة الحاويات، بل تتعثر بسبب إقامة البيانات (Data Residency). يوقّع المسؤول عن المشروع عقدًا مع مزود خدمة سحابية عالمي قبل أن يحدد فريق حوكمة البيانات أي مجموعات البيانات تُصنَّف كـ"بيانات حكومية سعودية" بموجب الإطار التنظيمي للحوسبة السحابية (Cloud Computing Regulatory Framework - CCRF)، وأيها يجوز أن يغادر حدود المملكة قانونًا. وبحلول الوقت الذي يُجرى فيه تمرين التصنيف، تكون منطقة الهبوط (Landing Zone) قد بُنيت بالفعل في الإقليم الخطأ، وتكون مفاتيح التشفير تُدار من مستوى تحكم خارج المملكة، ويتحول تقييم الفجوات مقابل الضوابط الأساسية للأمن السيبراني (NCA Essential Cybersecurity Controls - NCA ECC) من مراجعة إلى إعادة بناء كاملة.
كلفة عكس هذا التسلسل ليست نظرية. إعادة بناء منطقة الهبوط بعد الإطلاق التشغيلي تعني إعادة تهيئة الهويات، وإعادة إصدار المفاتيح، وإعادة تشغيل التقييم الذاتي لضوابط NCA ECC، وإعادة التفاوض على شروط معالجة البيانات مع مزود الخدمة — وهو عمل أنجزه فريقك مرة واحدة بالفعل، ويُعاد إنجازه الآن تحت اتفاقية مستوى خدمة (SLA) لبيئة إنتاجية حية. وبالنسبة لجهة خاضعة لجهة تنظيمية قطاعية إضافية (مثل مؤسسة النقد العربي السعودي "ساما" للمؤسسات المالية — انظر مقالنا حول متطلبات ساما وNESA للامتثال)، فإن ملاحظة تتعلق بإقامة البيانات تُكتشف أثناء التفتيش يمكن أن توقف أي ترحيل إضافي للبيانات حتى يتم التحقق من المعالجة، مما يجمّد بقية البرنامج بغض النظر عن جودة البناء التقني في بقية الأجزاء.
هذا الدليل يعرض التسلسل الذي يعتمده فريق الهندسة والأمن السيبراني في D-Elite Solutions عند تخطيط عمليات الترحيل السحابي للمؤسسات السعودية: ماذا تطلب NCA ECC فعليًا من حِمل عمل سحابي (Workload)، وماذا يقول CCRF عن الأماكن المسموح فيها للبيانات — والمفاتيح التي تحميها — بالإقامة، وكيف تُبنى منطقة هبوط تصمد أمام تدقيق الهيئة الوطنية للأمن السيبراني (National Cybersecurity Authority - NCA)، ومتى يكون القرار الصحيح هو عدم الترحيل بعد.
أبرز النقاط
- نسخة ECC-2:2024 من ضوابط NCA دمجت متطلبات الطرف الثالث والحوسبة السحابية ضمن المجالات الرئيسية بدلًا من إبقائها مجالًا خامسًا منفصلًا — لذا يجب أن تُطابق مصفوفة المسؤولية المشتركة مع مزود الخدمة ضوابط فرعية محددة، لا أن تكتفي بعبارة "المزود حاصل على شهادة ISO 27001".
- بموجب نموذج التصنيف الذي أرساه CCRF، فإن البيانات الحكومية السعودية (المقسّمة إلى أربع فئات: سري للغاية، سري، سري مقيّد، وعام) لا يجوز عمومًا أن تغادر المملكة، مؤقتًا أو دائمًا، إلا بتصريح صريح من نظام أو لائحة؛ أما تصنيف البيانات غير الحكومية فهو قرار يتخذه المشترك نفسه بناءً على مستويات الأمان التي يعلنها مزود الخدمة.
- الهيئة التي كانت تُعرف باسم CITC أصبحت الآن هيئة الاتصالات والفضاء والتقنية (Communications, Space & Technology Commission - CST). تأكد من أن أي وثيقة مشتقة من CCRF تعتمدها تشير إلى الاسم الحالي للجهة التنظيمية ولائحة تقديم خدمات الحوسبة السحابية الصادرة عام 2023، لا إلى نص CCRF الإصدار الثالث الملغى.
- وجود إقليم سحابي (Region) داخل حدود المملكة شرط ضروري لكنه غير كافٍ لاعتبار البيانات "محلية". إذا كان مفتاح إدارة المفاتيح الجذري (KMS)، أو أدوات الدعم الفني، أو مسار نسخ النسخ الاحتياطي يمر عبر مستوى تحكم خارج المملكة، فإن ادعاء إقامة البيانات لديك أضعف مما توحي به مخطط البنية التحتية.
- مفاتيح التشفير المُدارة من العميل (Customer-Managed Keys - CMK) المحفوظة في مخزن مفاتيح داخل المملكة، مع الفصل بين دور أمين المفتاح ودور أمين البيانات، لا تقل أهمية عن مكان إقامة البيانات المشفَّرة نفسها.
- ليست كل أحمال العمل جاهزة للترحيل الآن. بعض فئات البيانات وبعض بيئات أنظمة التحكم الصناعي (ICS/OT) من الصواب إبقاؤها محليًا داخل المملكة أو في نموذج هجين إلى حين نضج الإقليم السحابي ومستوى امتثال مؤسستك لضوابط NCA ECC.
ضوابط NCA ECC والحوسبة السحابية: المجالات التي تحكم كل قرار ترحيل
تُصدر الهيئة الوطنية للأمن السيبراني (NCA) الضوابط الأساسية للأمن السيبراني (ECC)، وهي خط الأساس المتوقع من كل جهة سعودية مشمولة بنطاق التطبيق. تصف ملخصات استشارية عامة صادرة عن جهات متخصصة في الامتثال (مثل Qualys وSecurityWall) نسخة ECC-2:2024 بأنها أعادت هيكلة الإطار إلى أربعة مجالات رئيسية — حوكمة الأمن السيبراني، والدفاع السيبراني، والمرونة السيبرانية، ومتطلبات أمن الطرف الثالث والحوسبة السحابية المدمجة ضمن هذه المجالات — تمتد عبر نحو 28 مجالًا فرعيًا و108 ضوابط رئيسية، بانخفاض من 114 ضابطًا في النسخة السابقة ECC-1:2018، مع اعتماد نموذج امتثال متدرج (أساسي، متقدم، أدنى) بحسب حساسية دور مؤسستك. تعامل مع هذا العدد كمؤشر استرشادي لا كنص نهائي؛ اسحب وثيقة NCA الرسمية والمحدّثة لنسخة ECC-2:2024 قبل تحديد نطاق أي تقييم رسمي، لأن الملخصات الثانوية قد تتأخر عن تحديثات الهيئة نفسها.
المهم لعملية الترحيل ليس حفظ عدد الضوابط، بل معرفة أين تنتهي مسؤولية NCA تجاهك وأين تبدأ مسؤولية مزود الخدمة السحابية.
توزيع المسؤولية المشتركة مع مزود الخدمة
| مجال الضبط | الجهة المسؤولة | الدليل المطلوب من المزود |
|---|---|---|
| الأمن المادي والبيئي للإقليم السحابي | مزود الخدمة | إقرار الأمن المادي لمركز البيانات |
| تحديث برمجيات المحاكاة الافتراضية (Hypervisor) | مزود الخدمة | تقرير دورية التحديثات وإدارة الثغرات |
| إدارة الهويات والوصول ضمن حسابك | العميل (أنت) | لا ينطبق — هذا بناؤك الخاص |
| توليد وحفظ مفاتيح التشفير (عند استخدام CMK) | العميل، عند اعتماد المفاتيح المُدارة ذاتيًا | تأكيد ربط KMS بالإقليم السعودي |
| تجزئة الشبكة داخل حسابك | العميل | مخطط شبكة منطقة الهبوط |
| تسجيل أحداث مستوى التحكم (Control Plane) | مشتركة — المزود يسجل أحداث البنية التحتية، والعميل يهيئ سجلات التدقيق على مستوى الحساب | إعداد تصدير سجلات التدقيق |
| كشف الحوادث والاستجابة لها | العميل لطبقة حِمل العمل، والمزود لطبقة البنية التحتية | خطة الاستجابة للحوادث ونموذج تغطية مركز العمليات الأمنية |
الإطار التنظيمي للحوسبة السحابية: ما يجوز أن يغادر المملكة وما لا يجوز
تُنظّم هيئة الاتصالات والفضاء والتقنية (CST) قطاع الحوسبة السحابية في المملكة، وهي الجهة ذاتها التي كانت تُعرف سابقًا بهيئة الاتصالات وتقنية المعلومات (CITC)، قبل أن يُعاد تسميتها في ديسمبر 2022. النسخة الثالثة من الإطار التنظيمي للحوسبة السحابية (CCRF v3) أرست نموذج تصنيف ثنائي المستوى لبيانات المشتركين: البيانات الحكومية السعودية، المقسّمة إلى أربع فئات (سري للغاية، سري، سري مقيّد، عام)، والبيانات غير الحكومية. وبموجب CCRF v3، لا يجوز نقل البيانات الحكومية السعودية خارج المملكة لأي غرض، مؤقتًا كان أم دائمًا، إلا بتصريح صريح من نظام أو لائحة. أما تصنيف البيانات غير الحكومية فيُترك للمشترك نفسه، مقابل مستويات الأمان التي يعلنها مزود الخدمة.
في 10 أكتوبر 2023، أصدرت CST لائحة محدَّثة لتقديم خدمات الحوسبة السحابية حلّت محل CCRF v3. لم نتمكن من التحقق بشكل مستقل من المصادر الأولية لدى CST مما إذا كانت اللائحة الجديدة لعام 2023 قد أبقت على نص إقامة البيانات الحكومية كما هو، أو عدّلته. لذا، تعامل مع مبدأ "البيانات الحكومية السعودية تبقى داخل المملكة" كخط أساس آمن للتخطيط، لكن اطلب من المستشار القانوني سحب النص الحالي المنشور من CST قبل إقرار أي مخطط تدفق بيانات يفترض تخفيفًا لهذا المبدأ.
بشكل منفصل، إذا كانت مؤسستك تتعامل مع بيانات لجهات حكومية أو بالتعاون معها، فإن مكتب إدارة البيانات الوطنية (National Data Management Office - NDMO)، التابع للهيئة السعودية للبيانات والذكاء الاصطناعي (SDAIA)، يحتفظ بمعاييره الخاصة لحوكمة البيانات وتصنيفها على المستوى الوطني. لم نتمكن من التحقق المستقل من الأسماء الدقيقة الحالية لفئات تصنيف NDMO لغرض هذا المقال — تعامل مع NDMO كعدسة تصنيف ثانية قد تُطبَّق فوق تصنيف CCRF، واسحب وثائق NDMO الحالية مباشرة بدلًا من الاعتماد على ملخصات ثانوية.
الأثر العملي: التصنيف قرار يتخذه مالكو البيانات لديك قبل اختيار الإقليم أو مزود الخدمة، وليس تمرينًا يُضاف لاحقًا بعد توقيع العقد.
الأقاليم السحابية داخل المملكة: ماذا تعني "المحلية" فعليًا في عقدك
| المزود | الحضور داخل المملكة (المعلن علنًا) | ملاحظة |
|---|---|---|
| Oracle Cloud Infrastructure | إقليمان فعّالان — جدة (منذ 2020) والرياض (منذ أكتوبر 2024)، وفق وثائق Oracle الرسمية للأقاليم | أوسع حضور متعدد الأقاليم داخل المملكة بين مزودي الحوسبة الفائقة |
| Google Cloud | إقليم السعودية في منطقة الدمام، أُطلق عام 2023 | تحقق من عدد مناطق التوافر الحالي مباشرة من المزود |
| Microsoft Azure | مراكز بيانات في المنطقة الشرقية اكتملت وفق إعلانات Microsoft، مع استهداف تشغيل كامل لمناطق التوافر بحلول 2026 | الجداول الزمنية المعلنة تغيّرت — تحقق من حالة التوافر العام الحالية قبل التعاقد |
| AWS | إقليم AWS الشرق الأوسط (السعودية) أُعلن في فبراير 2024 بالتزام استثماري بمليارات الدولارات | تحقق من حالة الإطلاق والتوافر العام مباشرة من AWS قبل التعاقد |
نظرًا لأن الجداول الزمنية لبناء الأقاليم قابلة للتغيّر، تعامل مع هذا الجدول كنقطة انطلاق لأعمال العناية الواجبة لا كبديل عنها. تحقق من حالة التوافر العام الحالية، وعدد مناطق التوافر، وحالة تسجيل CST للخدمة المحددة مباشرة من المزود قبل الالتزام بأي ادعاء إقامة بيانات في عقد مع عميلك.
"المحلية" بند تعاقدي، لا نقطة على خريطة
وجود إقليم فعليًا داخل حدود المملكة يجيب فقط عن أول أسئلة عدة يجب إغلاقها:
- وصول الدعم الفني. هل يمكن لموظفي الدعم لدى مزود الخدمة الوصول إلى بيانات الإنتاج من خارج المملكة لأغراض استكشاف الأخطاء، وبأي تفويض؟
- وجهة النسخ الاحتياطي والتعافي من الكوارث. هل تُكرّر إعدادات التعافي من الكوارث لديك افتراضيًا إلى إقليم خارج المملكة؟
- القياس عن بُعد والتسجيل. هل تمر بيانات القياس التشغيلي الخاصة بحسابك عبر لوحة تحكم عالمية خارج المملكة؟
- شبكة توصيل المحتوى والتخزين المؤقت الطرفي (CDN). هل تُخزَّن البيانات المنظَّمة مؤقتًا في نقاط طرفية خارج المملكة؟
- الترخيص. هل الكيان القانوني المحدد الذي يشغّل الإقليم داخل المملكة مسجَّل فعليًا لدى CST لتقديم فئة الخدمة السحابية تلك محليًا؟ هذا سؤال منفصل عن الموقع الفعلي لمركز البيانات.
هندسة منطقة الهبوط لأحمال العمل المنظَّمة في السعودية
منطقة الهبوط (Landing Zone) هي البنية المحكومة متعددة الحسابات (أو الاشتراكات) التي تهبط فيها أحمال العمل — تُبنى مرة واحدة قبل ترحيل أي حِمل عمل منظَّم. البنية أدناه محايدة تجاه المزود؛ استبدل العناصر بما يناسب AWS Organizations/Control Tower، أو Azure Management Groups، أو GCP Resource Manager.
Organization: KSA-Production
├── ou-security
│ ├── acct-log-archive # سجلات ثابتة غير قابلة للتعديل، داخل إقليم المملكة فقط
│ └── acct-security-tooling # أدوات تجميع السجلات، إدارة المفاتيح، كشف التهديدات
├── ou-workloads-regulated
│ ├── acct-prod-restricted # بيانات تتطلب إقامة داخل المملكة (فئات البيانات الحكومية)
│ └── acct-prod-confidential # بيانات غير حكومية مصنَّفة "سري مقيّد"
├── ou-workloads-general
│ └── acct-prod-general # أحمال عمل بلا قيود إقامة
└── ou-sandbox
└── acct-dev-test
الضوابط الحاكمة (رفض افتراضي):
- رفض إنشاء حاويات تخزين خارج قائمة الأقاليم السعودية المعتمدة
- رفض إنشاء مفاتيح KMS خارج الإقليم السعودي المعتمد
- رفض توسيع قوائم التحكم بالشبكة العامة على الوحدات التنظيمية المنظَّمة
- إلزام وسم كل موارد التخزين بوسم "data-classification"
طبّق هذه الضوابط كسياسات مبرمَجة (Policy as Code) — عبر سياسات التحكم بالخدمة، أو Azure Policy، أو OPA/Gatekeeper لبيئات Kubernetes — لا كقائمة مراجعة يدوية يتذكرها أحد الموظفين قبل كل عملية نشر. أي ضابط يعتمد على تذكّر إنسان له ليس ضابطًا يمكن أن يعتمد عليه ملف أدلة NCA ECC.
الهوية والتشفير وإدارة المفاتيح: لماذا إقامة المفتاح لا تقل أهمية عن إقامة البيانات
مفاتيح التشفير المُدارة من العميل (CMK) — التي تُناقش أحيانًا إلى جانب نماذج "أحضر مفتاحك الخاص" (Bring Your Own Key - BYOK) و"احتفظ بمفتاحك الخاص" (Hold Your Own Key - HYOK) — تمنحك التحكم بدورة حياة مفتاح التشفير الذي يحمي بياناتك، بمعزل عن المفتاح الافتراضي الذي يديره مزود الخدمة. هذا مهم لأن دورة حياة المفتاح الافتراضي يتحكم بها خادم إدارة المفاتيح (Key Management Service - KMS) العالمي لدى المزود، والذي قد تتضمن عملياته على مستوى التحكم لمسات لبنية تحتية خارج المملكة بحسب الخدمة، حتى عندما تكون البيانات المشفَّرة نفسها مقيمة في الإقليم السعودي.
المفتاح المُدار من العميل والمثبَّت في نسخة KMS داخل المملكة، مع إسناد دور أمين المفتاح إلى شخص غير مسؤول البنية التحتية أو مسؤول البيانات لديك (الفصل بين المهام — وهو موضوع في مجال الدفاع ضمن NCA ECC)، يمنحك ثلاثة أمور لا يمنحها المفتاح الافتراضي:
- دليل على من يستطيع فك التشفير — سلسلة حفظ موثَّقة وقابلة للتدقيق لجذر الثقة التشفيري.
- رافعة إلغاء مستقلة — يمكنك قطع صلاحية فك التشفير دون الاعتماد على إجراء الطوارئ الخاص بالمزود.
- موقف أقوى أمام التفتيش — يمكنك إثبات أن جذر الثقة التشفيري لم يغادر أبدًا حفظ المملكة، حتى عندما يكون مستوى التحكم العالمي لدى المزود في مكان آخر.
قائمة تحقق عملية للبناء:
- استخدم CMK حيثما تدعمه الخدمة لأحمال العمل المصنَّفة "سري مقيّد" أو أعلى.
- بدّل المفاتيح وفق جدول محدد وسجّل كل حدث استخدام للمفتاح في مركز العمليات الأمنية (SOC).
- وثّق دور أمين المفتاح بشكل منفصل في مصفوفة المسؤوليات (RACI) — ويجب ألا يكون هو نفسه من يدير حِمل العمل.
- بالنسبة لأي خدمة لا تدعم بعد CMK داخل الإقليم، تعامل مع ذلك كمعيار قبول أو رفض لاستضافة بيانات مصنَّفة على تلك الخدمة تحديدًا — لا كملاحظة هامشية تُعالج لاحقًا.
التسجيل والمراقبة وتكامل مركز العمليات الأمنية
تسجيل الأحداث والمراقبة موزَّع عبر مجالي الدفاع والمرونة ضمن NCA ECC — وهذا ليس إضافة اختيارية لعملية الترحيل السحابي، بل شرط أساسي لمنطقة الهبوط. وجّه سجلات مستوى التحكم ومستوى البيانات على مستوى حسابك إلى أرشيف سجلات مركزي غير قابل للتعديل داخل المملكة، وربطه بنظام إدارة معلومات وأحداث الأمن (SIEM) لدى مركز العمليات الأمنية — سواء كان داخليًا أو عبر مزود خدمات أمنية مُدارة (MSSP) — مع تغطية محددة لكل مصدر سجل.
| مصدر السجل | مكان الحفظ | إجراء مركز العمليات الأمنية |
|---|---|---|
| سجلات دخول موفر الهوية | حساب أرشيف السجلات، داخل المملكة | تنبيه عند "السفر المستحيل" أو تصعيد الصلاحيات |
| أحداث استخدام مفاتيح KMS | حساب أرشيف السجلات | تنبيه عند فك تشفير خارج أوقات العمل أو من جهة غير مخوّلة |
| سجلات تدفق الشبكة | حساب أرشيف السجلات | إرساء خط أساس للحركة المرورية ورصد الانحرافات |
| مسار تدقيق مستوى التحكم لدى المزود | حساب أرشيف السجلات | تنبيه عند تغيّر سياسات الإقليم أو الضوابط الحاكمة |
| سجلات التطبيقات | طبقة التطبيق، موجَّهة إلى SIEM | مراقبة قياسية من مركز العمليات الأمنية |
اضبط مدة الاحتفاظ بالسجلات وفق نص ضابط NCA ECC الحالي وأي طبقة تنظيمية قطاعية إضافية (مثل إطار ساما للأمن السيبراني للمؤسسات المالية)، لا وفق قيمة افتراضية عامة من الصناعة. مدة الاحتفاظ من أكثر القيم عرضة للتغيّر بين نسخ ECC، لذا اسحب الحد الأدنى الإلزامي الحالي من نص الجهة التنظيمية وقت التقييم، لا من مشروع سابق.
تسلسل الترحيل من سبع خطوات
- اكتشاف البيانات وتصنيفها. صنّف كل مجموعة بيانات وفق نموذج CCRF (حكومي/غير حكومي) — وبالنسبة للأطراف المقابلة الحكومية، وفق عدسة تصنيف NDMO — قبل اتخاذ أي قرار بشأن الإقليم أو المزود.
- تقييم الفجوات مقابل NCA ECC. قيّم الوضع الحالي مقابل مجالات ECC-2:2024، محدودًا بأحمال العمل التي تنوي ترحيلها. النتيجة هي قائمة أعمال المعالجة، لا بوابة نجاح أو رسوب.
- اختيار مزود الخدمة والإقليم مع التحقق من تسجيل CST. اقتصر على مزودي خدمة مسجَّلين لدى CST لفئات الخدمة التي تحتاجها، في أقاليم بحالة تشغيل مؤكدة.
- بناء منطقة الهبوط. بنية الحسابات، والضوابط الحاكمة، وإدارة المفاتيح، وأرشيف السجلات — قبل هبوط أي حِمل عمل، لا بالتوازي مع أول عملية ترحيل.
- ترحيل تجريبي لحِمل عمل غير منظَّم. تحقق من منطقة الهبوط والضوابط والمراقبة من طرف إلى طرف على بيانات غير مصنَّفة أولًا.
- ترحيل أحمال العمل المنظَّمة مع مراجعة موثَّقة لأثر حماية البيانات. رحّل أحمال العمل المصنَّفة "مقيّد" أو "سري مقيّد" فقط بعد أن يثبت الترحيل التجريبي صلابة الضوابط، وبموافقة مالك البيانات وفريق الأمن.
- التحول النهائي وإيقاف التشغيل والمراقبة المستمرة للامتثال. أوقف تشغيل البيئة المصدر وفق جدول محدد، وأدمج حِمل العمل ضمن دورة التقييم الذاتي المستمرة لـNCA ECC وتغطية مركز العمليات الأمنية — الإطلاق التشغيلي ليس خط النهاية.
العناية الواجبة تجاه مزود الخدمة السحابية: مسار الاعتماد
- مزود الخدمة مسجَّل لدى CST لفئة الخدمة السحابية المعنية
- يوفّر مزود الخدمة ملحقًا لمعالجة البيانات يحدد مواقع الجهات الفرعية المعالِجة
- يفصح مزود الخدمة عمّا إذا كان وصول الدعم الفني إلى بيانات الإنتاج يمكن أن يصدر من خارج الإقليم
- يدعم مزود الخدمة مفاتيح CMK داخل الإقليم للخدمات التي تخطط لاستخدامها
- اتفاقية مستوى خدمة الإخطار بالحوادث موثَّقة كتابيًا وتفي بالجدول الزمني الداخلي للتصعيد لديك
- يوفّر مزود الخدمة خطة خروج/قابلية نقل — صيغة تصدير البيانات، الجدول الزمني، وأي سقف لتكلفة إخراج البيانات
- الشهادات المستقلة (ISO 27001 أو SOC 2 أو ما يعادلهما) سارية ومحدودة النطاق للإقليم الذي تستخدمه، لا لكيان المزود العالمي فقط
- سلسلة الاعتماد الداخلية — موافقة مالك البيانات، مراجعة هندسة الأمن، مراجعة قانونية لاتفاقية معالجة البيانات، واعتماد نهائي من الرئيس التنفيذي لأمن المعلومات أو ما يعادله — موثَّقة لأغراض التدقيق
خارطة الطريق المرحلية
| المرحلة | المدة (تقدير مبني على المنطق الهندسي) | المخرجات الرئيسية | الجهة المسؤولة |
|---|---|---|---|
| المرحلة صفر — التصنيف وخط الأساس لـNCA ECC | ٢–٤ أسابيع | سجل تصنيف البيانات، تقييم فجوات ECC | فريق الأمن ومالكو البيانات |
| المرحلة الأولى — تصميم وبناء منطقة الهبوط | ٤–٨ أسابيع | بنية الحسابات، الضوابط الحاكمة، إدارة المفاتيح، أرشيف السجلات | هندسة الحوسبة السحابية |
| المرحلة الثانية — الترحيل التجريبي | ٢–٤ أسابيع | حِمل عمل غير منظَّم يعمل فعليًا، مراقبة مُتحقق منها | هندسة الحوسبة السحابية ومركز العمليات الأمنية |
| المرحلة الثالثة — ترحيل أحمال العمل المنظَّمة | ٦–١٢ أسبوعًا، تتوسع مع عدد أحمال العمل | أحمال عمل مصنَّفة مُرحَّلة، مراجعة أثر حماية بيانات موقَّعة لكل حِمل عمل | الهندسة والأمن والقانونية |
| المرحلة الرابعة — التحول النهائي وإيقاف التشغيل | ٢–٤ أسابيع | إيقاف تشغيل البيئة المصدر، اختبار التعافي من الكوارث | البنية التحتية |
| المرحلة الخامسة — الامتثال المستمر | مستمرة | تحديث ربع سنوي للتقييم الذاتي لـECC، مراجعة تغطية مركز العمليات الأمنية | فريق الأمن |
المدد الزمنية تقدير مبني على المنطق الهندسي يتوسع مع عدد أحمال العمل ونضج امتثال مؤسستك الحالي لـNCA ECC — وليست عرض سعر ثابت لأي مشروع محدد.
واقعية التكلفة والجدول الزمني: مثال محسوب
خذ مجموعة أحمال عمل منظَّمة متوسطة الحجم كمثال تخطيطي: نحو 40 خادمًا افتراضيًا موازيًا من حيث القدرة الحاسوبية، و15 تيرابايت من البيانات المصنَّفة، مع بناء منطقة هبوط من الصفر. هذا تقدير مبني على المنطق الهندسي لأغراض التخطيط فقط، وليس عرض سعر — أرقامك الفعلية تعتمد على المزود والإقليم والتسعير الحالي:
- بناء منطقة الهبوط (الضوابط الحاكمة، إدارة المفاتيح، أرشيف السجلات، إدارة الهويات): نحو ٣–٥ أسابيع هندسية بجهد مركّب من مهندس سحابي أول ومعماري أمني.
- إغلاق قائمة معالجة تقييم فجوات ECC: يتوسع مع نضج ضوابطك الحالية — فريق ينطلق من خط أساس جزئي لـECC-1:2018 يحمل عادة معالجات أقل بكثير من فريق ينطلق من الصفر.
- ترحيل البيانات نفسه (15 تيرابايت عبر رابط خاص أو مخصص): مقيَّد بعرض النطاق الترددي لا بالقدرة الحاسوبية — احسب نافذة النقل وفق سرعة رابطك الفعلية، لا بافتراض معدل نقل الإنترنت العام.
- تكامل CMK وKMS: نحو ١–٢ أسبوعين هندسيين، غالبيتها تعديلات في كود التطبيق لاستدعاء KMS المثبَّت في الإقليم.
- الترحيل التجريبي والتحول النهائي المنظَّم: أضف احتياطيًا زمنيًا بنسبة ٢٠–٣٠٪ تحديدًا لمرحلة أحمال العمل المنظَّمة — دورات موافقة مراجعة أثر حماية البيانات والمراجعة القانونية عادة هي الجزء الأكثر تقلبًا في الجدول الزمني، لا العمل الهندسي.
مشروع ترحيل منظَّم متوسط الحجم يستغرق عادة من أربعة إلى سبعة أشهر من البداية إلى النهاية عندما يُنجز التصنيف وخط أساس ECC بشكل صحيح مسبقًا — مقارنة بمدة أطول بكثير عندما يتوجب إعادة بناء منطقة الهبوط بعد ظهور ملاحظة إقامة بيانات في منتصف المشروع.
متى لا تُرحِّل بعد: حالة النموذج الهجين والبقاء داخل المملكة
- إذا وضع تمرين التصنيف لديك حصة معتبرة من أحمال عملك ضمن فئتي "سري للغاية" أو "سري" للبيانات الحكومية السعودية — أو طبّق الطرف الحكومي المقابل فئة NDMO معادلة — ولم يتأكد وجود خيار مزود خدمة مسجَّل لدى CST يفي بمتطلب إقامة البيانات هذا للخدمة المحددة التي تحتاجها، فإن القرار الصحيح هو البقاء محليًا داخل المملكة أو اعتماد سحابة حكومية معتمدة مسبقًا، لا الترحيل إلى مزود حوسبة فائقة على جدول زمني متفائل.
- إذا لم تُغلق مؤسستك بعد تقييم فجوات NCA ECC للوضع الحالي، فإن الترحيل أولًا ومعالجة الضوابط لاحقًا يعكس التسلسل الصحيح. أنت ترث بيئة إنتاج حية تحمل فجوة ضبط غير معالَجة — وهو موقف تدقيقي أسوأ بكثير من الفجوة نفسها في منطقة هبوط لم تدخل الإنتاج بعد.
- بيئات أنظمة التحكم الصناعي والتشغيلية (ICS/OT) ذات حلقات التحكم الفورية الصارمة وبلا مسار تعافي مُتحقق منه متصل بالسحابة هي حالة هجينة افتراضيًا: أبقِ حلقة التحكم محليًا داخل المملكة، وفكّر في السحابة فقط لطبقات السجل التاريخي والتحليلات والتقارير التي لا تقع ضمن المسار الفوري.
- إذا كان إقليم المزود المستهدف داخل المملكة لا يدعم بعد مفاتيح CMK للخدمة التي تحتاجها، أو رفض المزود تأكيد حدود وصول الدعم الفني كتابيًا، أجّل ترحيل حِمل العمل المصنَّف تحديدًا — ويمكنك مع ذلك ترحيل الجزء غير المنظَّم من بيئتك وفق الجدول الزمني الحالي.
- التكلفة سبب مشروع لتقسيم المشروع على مراحل لا لإيقافه. إذا لم يتجاوز التقدير المحسوب أعلاه عتبة العائد على الاستثمار لدى مؤسستك بالنسبة لحِمل عمل معين، فإن نهجًا هجينًا — ترحيل ما له فائدة واضحة من حيث القدرة الحاسوبية أو التوسع، مع إبقاء البيانات المصنَّفة محليًا داخل المملكة — استراتيجية دفاعية معقولة، لا فشلًا في التحديث.
الأخطاء الشائعة وأنماط الفشل المتكررة
- توقيع عقد مزود الخدمة قبل إنجاز تمرين تصنيف البيانات.
- اعتبار "المزود لديه إقليم في السعودية" مكافئًا لـ"التزامنا بإقامة البيانات محقَّق"، دون التحقق من إقامة المفتاح، وحدود وصول الدعم الفني، وتسجيل CST للخدمة المحددة.
- استخدام مفاتيح التشفير الافتراضية المُدارة من المزود لأحمال العمل المصنَّفة لأن مفاتيح CMK تضيف سبرنتًا إضافيًا للجدول الزمني.
- تشغيل تقييم فجوات NCA ECC مقابل بيئتك المحلية الحالية فقط، ثم افتراض أن النتيجة تبقى صالحة بعد انتقال أحمال العمل إلى نموذج مسؤولية مشتركة مختلف جذريًا.
- تخطي الترحيل التجريبي ونقل حِمل عمل منظَّم مباشرة إلى الإنتاج في منطقة الهبوط الجديدة.
- التعامل مع الاحتفاظ بالسجلات وتكامل مركز العمليات الأمنية كمهمة لما بعد الإطلاق التشغيلي بدلًا من كونها شرطًا أساسيًا لمنطقة الهبوط.
- افتراض أن نص إقامة البيانات في CCRF v3 لا يزال ساريًا حرفيًا بعد صدور لائحة تقديم خدمات الحوسبة السحابية لعام 2023، دون التحقق من النص المنشور حاليًا لدى CST.
الأسئلة الشائعة
هل يجوز قانونًا استخدام AWS أو Azure في السعودية للبيانات المنظَّمة؟ نعم، بشروط: يجب أن يكون الكيان المحدد لمزود الخدمة مسجَّلًا لدى CST لفئة الخدمة المعنية، ويجب مطابقة تصنيف البيانات وفق نموذج CCRF مع إقليم وشروط تعاقدية تفي بمتطلبات إقامة البيانات، وبالنسبة للبيانات الحكومية السعودية تحديدًا، لا يجوز عمومًا أن تغادر المملكة دون استثناء قانوني صريح.
ما الفرق بين ضوابط NCA ECC وإطار ساما للأمن السيبراني؟ ضوابط NCA ECC هي خط الأساس الوطني الذي يجب أن تلتزم به كل جهة سعودية مشمولة بنطاق التطبيق. أما إطار ساما للأمن السيبراني فهو طبقة تنظيمية قطاعية إضافية للبنوك وشركات التأمين والمؤسسات المالية الخاضعة لإشراف مؤسسة النقد العربي السعودي، وعادة ما يضيف متطلبات فوق NCA ECC لا بدلًا منها.
هل يجوز تخزين البيانات الحكومية السعودية خارج المملكة؟ بموجب نموذج التصنيف الذي أرساه CCRF، لا يجوز عمومًا نقل البيانات الحكومية السعودية — المقسّمة إلى فئات سري للغاية وسري وسري مقيّد وعام — خارج المملكة، مؤقتًا أو دائمًا، إلا بتصريح صريح من نظام أو لائحة. تحقق من النص الحالي مع CST والمستشار القانوني قبل الاعتماد على أي استثناء.
هل ما زالت CITC موجودة، أم أصبحت CST؟ أُعيدت تسمية CITC إلى هيئة الاتصالات والفضاء والتقنية (CST) في ديسمبر 2022، مع توسيع نطاق مهامها ليشمل الإشراف على قطاع الفضاء. أي وثيقة حالية متعلقة بترخيص الحوسبة السحابية أو CCRF يجب أن تشير إلى CST بوصفها الجهة التنظيمية.
ما هو المفتاح المُدار من العميل، وهل أحتاجه في السعودية؟ المفتاح المُدار من العميل (CMK) هو مفتاح تشفير تتحكم أنت بدورة حياته بدلًا من الاعتماد على المفتاح الافتراضي الذي يديره مزود الخدمة. بالنسبة للبيانات المصنَّفة أو المقيَّدة في السعودية، فإن مفتاح CMK داخل المملكة — مع فصل دور أمين المفتاح عن مسؤول البنية التحتية لديك — يقوّي موقف إقامة البيانات والتدقيق بشكل ملموس.
كم يستغرق الترحيل السحابي لمؤسسة سعودية بموجب NCA ECC؟ بالنسبة لمجموعة أحمال عمل منظَّمة متوسطة الحجم، خطط لمدة تتراوح بين أربعة وسبعة أشهر من البداية إلى النهاية عندما يُنجز تصنيف البيانات وتقييم فجوات NCA ECC قبل بدء بناء منطقة الهبوط. تخطي هذا التسلسل هو السبب الأكثر شيوعًا لتأخر الجدول الزمني بأشهر عدة.
قراءات ذات صلة
- متطلبات ساما وNESA للامتثال السيبراني في قطاع التقنية المالية الخليجي — الطبقة التنظيمية القطاعية التي تحتاجها المؤسسات المالية في المملكة والخليج الأوسع فوق NCA ECC.
- خارطة طريق الامتثال لـ DevSecOps للشركات — كيفية دمج فحوصات الامتثال ضمن خط الأنابيب الذي يُطلق تغييرات منطقة الهبوط لديك.
- خارطة طريق الامتثال لحماية البيانات KVKK — نقطة مقارنة مفيدة إذا كان ترحيلك السعودي يتقاطع أيضًا مع بيانات تُعالج في تركيا.
- دليل الترحيل من البنية الأحادية إلى الخدمات المصغَّرة — أعمال إعادة تفكيك البنية التي غالبًا ما تسير بالتوازي مع الترحيل السحابي المنظَّم.
تواصل مع D-Elite Solutions
يصمم فريق الهندسة والأمن السيبراني في D-Elite Solutions مناطق الهبوط ويدقّقها مقابل متطلبات NCA ECC وCCRF للمؤسسات العاملة داخل المملكة، عبر قطاعات منظَّمة تشمل الخدمات المالية والرعاية الصحية. احجز جلسة على https://www.d-elite.solutions/ar/free-consultation وسنراجع تصنيف بياناتك الحالي وقائمة مزودي الخدمة المرشَّحين مقابل NCA ECC وحالة تسجيل CST، ونحدد مخاطر إقامة البيانات التي يستحق إصلاحها قبل التوقيع — دون أي التزام.
هل تحتاج إلى استشارات معمارية وتدقيق هندسي لشركتك؟
يساعد فريق مهندسينا المعماريين المؤسسات في تحديث الأنظمة، وتدقيق الأمن السيبراني، والتوسع دون ديون تقنية.
