عندما تلتقي الهوية الوطنية بالمخاطر السيادية: قراءة معيارية في مشروع دمج البطاقة الوطنية مع بطاقة السكن

عندما تلتقي الهوية الوطنية بالمخاطر السيادية: قراءة معيارية في مشروع دمج البطاقة الوطنية مع بطاقة السكن

عندما تلتقي الهوية الوطنية بالمخاطر السيادية: قراءة معيارية في مشروع دمج البطاقة الوطنية مع بطاقة السكن

✍️ إعداد: المهندس مصطفى كامل الشريف
مستشار في أمن المعلومات والسيادة الرقمية – الدنمارك / العراق
🌐 www.ITACH.dk

أولًا: مقدمة سيادية – لماذا ملف الهوية أخطر من أي مشروع حكومي تقني؟

مشاريع الهوية الوطنية ليست “أنظمة خدمات” يمكن التعامل معها بمنطق المقاولات الاعتيادية، بل هي مفصل سيادي يحدد من هو المواطن، وكيف يُعرَّف قانونيًا، وكيف يرتبط بحقوقه وخدماته وسجلاته داخل الدولة. وعندما نتحدث عن دمج البطاقة الوطنية مع بطاقة السكن، فنحن نتحدث عن توحيد طبقات تعريف تمس: الجنسية، الاسم القانوني، السجل المدني، العنوان/السكن، والرقم التعريفي الوطني.

لهذا السبب، فإن معيار تقييم المشروع لا يبدأ من “منفذ المشروع” أو “جنسية المالك”، بل يبدأ من سؤال واحد: من يملك مفاتيح التحكم؟ ومن يملك صلاحيات الوصول والتغيير؟ وأين تقيم البيانات؟ وكيف تُدار سجلات التدقيق؟

قاعدة سيادية:
في أنظمة الهوية الوطنية، “الثقة” لا تُمنح بالتصريحات، بل تُبنى بالأدلة والضوابط: Controls + Evidence + Auditability (ضوابط + أدلة + قابلية تدقيق).

ثانيًا: السرعة المنضبطة: إنجاز دون تفريط

إن تسريع إنجاز مشاريع الحوكمة والتحول الرقمي مطلب وطني مشروع، خاصة في الملفات التي تعاني تأخيرًا تاريخيًا، غير أن مشاريع الهوية الوطنية لا يمكن التعامل معها بمنطق “الإنجاز الزمني” وحده، بل بمنطق الإنجاز السيادي المنضبط.

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

وعليه، فإن أي تنفيذ سريع يجب أن يكون تنفيذًا مرحليًا محكومًا، يبدأ بتجارب محدودة (Pilot | تجربة أولية) ثم توسعة تدريجية، مع الالتزام الصارم ببوابات إلزامية قبل الإطلاق العام، تشمل على الأقل:

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

ثالثًا: خريطة المخاطر وفق المعايير العالمية (ISO/NIST) – ما الذي يجب قياسه؟

وفق نهج إدارة المخاطر في المعايير الدولية مثل ISO/IEC 27001 (نظام إدارة أمن المعلومات) وNIST (أطر الأمن وإدارة المخاطر)، فإن مشاريع الهوية تُقاس عبر محاور “سيادية” محددة، أهمها:

  • سيادة البيانات (Data Sovereignty & Residency | سيادة البيانات وإقامتها): هل البيانات داخل العراق بالكامل؟ هل النسخ الاحتياطية داخل العراق؟ هل هناك أي إخراج مباشر/غير مباشر؟
  • سيادة المفاتيح (Key & PKI Sovereignty | سيادة المفاتيح وبنية الثقة PKI): من يملك مفاتيح التوقيع والتشفير؟ هل توجد HSM داخل العراق؟ هل هناك تحكم مزدوج (Dual Control)؟
  • إدارة الصلاحيات العالية (PAM | إدارة الوصول ذي الامتيازات): من يملك صلاحيات “مدير النظام/قاعدة البيانات/المستخدم الفائق”؟ هل الجلسات مسجلة؟
  • السجلات والتدقيق (Logging & Auditability | السجلات وقابلية التدقيق): هل السجلات غير قابلة للتلاعب (Tamper-Evident)؟ وهل تُربط بـ SIEM؟
  • مخاطر الطرف الثالث وسلسلة التوريد (Supply Chain Risk | مخاطر سلسلة التوريد): هل يوجد متعهدون فرعيون؟ هل تُدار العلاقة وفق ISO 27036 / NIST 800-161؟
الخطر الحقيقي ليس وجود شركة خارجية بحد ذاته،
الخطر هو “نقطة القدرة” التي قد تُمنح للطرف الثالث: وصول بيانات، تشغيل إنتاج، مفاتيح، دعم عن بُعد، أو صلاحيات عالية.

رابعًا: مخاطر الطرف الثالث وسلسلة التوريد – عندما تصبح “الشراكة” منفذًا سياديًا

في مشاريع الهوية، وجود طرف ثالث (شركة منفذة/شريك محلي/مورد) يمكن أن يكون طبيعيًا من حيث التوريد والتكامل، لكن يصبح مخاطرة سيادية عندما تتحول “الشراكة” إلى:

  • قدرة تشغيلية داخل بيئة الإنتاج (Production Environment | بيئة الإنتاج).
  • قدرة وصول إلى البيانات أو النسخ الاحتياطية أو واجهات التكامل (APIs | واجهات برمجة التطبيقات).
  • قدرة احتجاز تقني (Vendor Lock-in | احتجاز تقني) تمنع الدولة من الاستقلال لاحقًا.
  • توسع صامت في الصلاحيات عبر الدعم والصيانة والتحديثات.

لذلك، تُشدد أفضل الممارسات المعيارية على: تعريف نطاق الدور، وتقييد الصلاحيات، والتدقيق المستقل، ومنع التعاقد من الباطن دون موافقات سيادية.

مبدأ معياري واضح:
العلاقة مع المورد يجب أن تُدار وفق ISO/IEC 27036 (علاقات الموردين) وNIST SP 800-161 (إدارة مخاطر سلسلة التوريد)، لا وفق الانطباعات أو الضمانات العامة.

خامسًا: مخاطر الاختصاص القضائي والفرع الخارجي – لماذا “دبي” ليست تفصيلاً؟

وجود فرع خارجي لأي شركة مشاركة في مشروع هوية وطنية (مثل فرع في دبي) لا يعني تلقائيًا “تسريبًا” أو “اختراقًا”، لكنه يُدخل عاملًا حساسًا يُسمى: Jurisdictional Risk (مخاطر الاختصاص القضائي).

هذا النوع من المخاطر يظهر عندما تصبح الشركة – بحكم وجودها القانوني في دولة أخرى – عرضة لالتزامات تنظيمية أو طلبات قانونية أو ترتيبات تعاون قد تؤثر على:

  • الدعم الفني عن بُعد (Remote Support | دعم عن بُعد) ومسارات الوصول المحتملة.
  • إدارة الحوادث (Incident Response | الاستجابة للحوادث) وما قد تتطلبه من “تبادل أدلة/سجلات”.
  • تدفقات العمل بين الفروع وما إذا كانت تتضمن نقل بيانات أو مشتقات بيانات.
ملاحظة سيادية:
في أنظمة الهوية، حتى “الاحتمال القانوني” لفرض التزام خارجي على شركة مشاركة يُعد عامل مخاطرة حتى تُثبت الضوابط العكس.

سادسًا: مخاطر “السياق الحساس” وضرورة التدقيق الأمني (Vetting) بلا تشهير

كثيرًا ما تتحول مشاريع الهوية إلى ساحة جدل بسبب “سياق” الشركات أو ملاكها أو علاقاتهم أو ارتباطاتهم العابرة للحدود. مهنيًا، لا تُدار هذه النقطة بالشائعات ولا بالتشهير، بل بآلية معيارية اسمها: Vetting & Due Diligence (التدقيق الأمني والعناية الواجبة).

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

  • إيضاح رسمي حول نطاق الدور والصلاحيات والحدود التقنية.
  • إثباتات موثقة لعدم وجود وصول لبيانات الهوية أو مفاتيحها.
  • تدقيق مستقل، واختبارات أمنية، وحوكمة صارمة للصلاحيات.
الخلاصة هنا:
حين تكون المنظومة High-Trust System (منظومة عالية الثقة)، فإن معيار الحماية هو High-Verification (تحقق عالي المستوى)، وليس النقاش الشخصي أو الإعلامي.

سابعًا: أسئلة رسمية مطلوبة من وزارة الداخلية – من يفعل ماذا؟ ومن يصل إلى ماذا؟

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

1) ما هي معمارية النظام؟ (Architecture | المعمارية)

  • أين تقع قواعد البيانات؟ وأين تقع بيئة الإنتاج (Production Environment | بيئة الإنتاج)؟
  • هل توجد بيئات مساندة/اختبار؟ (Staging/Test | اختبار/تهيئة) وكيف تُعزل عن الإنتاج؟

2) ما هو دور كل طرف؟ (Vendor Roles | أدوار المزوّدين)

  • هل دور الشركة الألمانية/الشركة العراقية: تصميم؟ توريد؟ تكامل؟ تشغيل؟ دعم؟ صيانة؟
  • هل يوجد تعاقد من الباطن (Subcontracting | تعاقد فرعي)؟ ومن هم المتعهدون؟

3) من يصل إلى ماذا؟ (Access Scope | نطاق الوصول)

  • هل لأي طرف ثالث وصول إلى البيانات الديموغرافية/البيومترية/بيانات السكن؟
  • هل لأي طرف ثالث وصول إلى النسخ الاحتياطية (Backups | النسخ الاحتياطية)؟
  • هل لأي طرف ثالث وصول إلى مفاتيح التوقيع أو التشفير؟ (PKI/HSM | بنية الثقة/وحدة أمن عتادية)

4) هل يوجد دعم عن بُعد؟ (Remote Support | دعم عن بُعد)

  • هل توجد قنوات VPN (شبكة افتراضية خاصة) أو إدارة عن بُعد (Remote Admin | إدارة عن بُعد)؟
  • إذا وُجدت: هل الجلسات مسجلة؟ وهل الوصول زمني؟ وهل هناك موافقة داخل الموقع؟
الهدف من هذه الأسئلة:
تحويل “الجدل” إلى “تحقق” عبر أدلة: مخططات، مصفوفات صلاحيات، سياسات مفاتيح، وتقارير تدقيق.

ثامنًا: سؤال الدولة العميق – هل من المنطقي الاعتماد الخارجي مع هذا الحجم من الكفاءات؟

إذا كانت وزارة الداخلية تمتلك موارد بشرية ضخمة وكفاءات هندسية واسعة، فإن السؤال السيادي المنطقي ليس “لماذا شركة؟” بل: لماذا يُبنى اعتماد طويل الأمد على طرف ثالث في ملف هوية؟ وهل تم تصميم مسار Capacity Building (بناء القدرات) وKnowledge Transfer (نقل المعرفة) بحيث تصبح الدولة هي المشغّل الكامل وصاحبة السيطرة التشغيلية والفنية؟

جوهر السيادة الرقمية هو أن تبقى “القدرة” داخل الدولة: لا أن تبقى الدولة بحاجة دائمة لمقاول كي “يستمر النظام”. وعند غياب مسار بناء قدرات واضح، تتكون مخاطر: Vendor Dependency (اعتماد على المزوّد) وOperational Lock-in (احتجاز تشغيلي).

مطلب سيادي عملي:
أي عقد/شراكة في ملف الهوية يجب أن يتضمن خطة تسليم وتشغيل وامتلاك كامل، وخطة خروج وتسليم (Exit & Handover Plan | خطة خروج وتسليم).

تاسعًا: توصيات سيادية قابلة للتنفيذ

  1. إعلان “شفافية المعمارية والصلاحيات” رسميًا: نشر توصيف مبسّط لمعمارية النظام (Architecture | المعمارية) ونطاق أدوار الشركات، ومن يصل إلى ماذا، دون كشف أسرار تشغيلية حساسة.
  2. سيادة البيانات (Data Residency | إقامة البيانات): تأكيد مكتوب وملزم بأن البيانات والنسخ الاحتياطية داخل العراق بالكامل، مع ضوابط منع الإخراج (DLP | منع تسرب البيانات).
  3. سيادة المفاتيح (Key & PKI Sovereignty | سيادة المفاتيح وبنية الثقة): مفاتيح التوقيع والتشفير داخل HSM (وحدة أمن عتادية) داخل العراق، مع تحكم مزدوج (Dual Control) ومنع النسخ.
  4. إدارة الصلاحيات العالية (PAM | إدارة الوصول ذي الامتيازات): جلسات مسجلة، فصل واجبات (SoD | فصل الواجبات)، وموافقات مزدوجة على أي تعديل يخص السجل أو الربط أو المفاتيح.
  5. سجلات غير قابلة للتلاعب (Tamper-Evident Logs | سجلات كاشفة للعبث): ربط السجلات بمنصة SIEM (إدارة معلومات وأحداث الأمن) مع تنبيهات فورية.
  6. تدقيق مستقل دوري (Independent Audit | تدقيق مستقل): تدقيق أمني وقانوني ومراجعة سلسلة توريد وفق ISO 27036 / NIST 800-161.
  7. خطة خروج وتسليم (Exit & Handover Plan | خطة خروج وتسليم): لضمان عدم نشوء احتجاز تقني (Vendor Lock-in | احتجاز تقني) ولتمكين التشغيل الوطني الكامل.

عاشرًا: الخاتمة – نقل النقاش من “منفّذ المشروع” إلى “كيف يُدار المشروع”

هذا المقال لا يُدين أحدًا ولا يبرّئ أحدًا، بل يضع معيار الدولة أمام الدولة: هل نُدير هويتنا الوطنية بمنطق السيادة أم بمنطق المشروع؟ لأن الفرق بينهما هو الفرق بين “منظومة دولة” و“نظام يمكن اختراقه/الالتفاف عليه” إذا غابت الضوابط.

خاتمة سيادية:
الجدل لا يُحسم بالأسماء ولا بالجنسيات.
السيادة الرقمية تُقاس بالتحكم الفعلي: من يملك المفاتيح؟ من يملك البيانات؟ من يملك صلاحية التغيير؟
وما فعلناه سابقًا في ملف Starlink، هو نفس ما يجب فعله هنا: نقل النقاش من “منفّذ المشروع” إلى “كيف يُدار المشروع”.

الملحق الرقابي (رقم 1)

إطار تدقيق سيادي وأمني لمشروع دمج البطاقة الوطنية مع بطاقة السكن

(Annex – Sovereign Cybersecurity & Information Assurance Review) | (ملحق – مراجعة سيادية للأمن السيبراني وضمان أمن المعلومات)


أولًا: الغاية من هذا الملحق

يأتي هذا الملحق كمرفق رقابي–تحليلي مكمل للمقال الرئيس، ويهدف إلى:

  1. نقل النقاش من مستوى الجدل الإعلامي إلى مستوى التحقق المهني وفق معايير أمن المعلومات والسيادة الرقمية.
  2. تحديد الأسئلة الصحيحة التي يجب أن تُطرح على أي مشروع يمس هوية المواطن العراقية، بغض النظر عن أسماء الشركات أو جنسيات المالكين.
  3. توفير إطار عملي يمكن للخبراء، واللجان البرلمانية، وهيئات الرقابة، والجهات السيادية الاعتماد عليه لطلب الأدلة الفنية بدل الاكتفاء بالتصريحات.
  4. حماية الدولة والمؤسسات المنفذة من الشبهات عبر ترسيخ مبدأ “الثقة المبنية على الضوابط لا على النوايا”.

هذا الملحق لا يوجه اتهامًا لأي جهة، ولا ينفي البيانات الرسمية، بل يعمل ضمن منطق: High Trust Systems Require High Verification (الأنظمة عالية الثقة تتطلب تحققًا عالي المستوى).


ثانيًا: توصيف الأصل السيادي محل النقاش (Asset Classification | تصنيف الأصل المعلوماتي)

وفق المعايير الدولية (ISO 27001 / NIST):

  • مشروع دمج البطاقة الوطنية مع بطاقة السكن يُصنَّف كـ:
    • Critical National Information Asset — (أصل معلوماتي وطني حرج)
    • High-Value Target (HVT) — (هدف عالي القيمة سيبرانيًا — HVT)
    • Core Digital Identity Infrastructure — (البنية التحتية الجوهرية للهوية الرقمية الوطنية)

لأنه:

  • يدمج الهوية القانونية مع الهوية المكانية/السكنية.
  • يعتمد على رقم تعريفي موحد يُستخدم عبر منظومات الدولة.
  • أي خلل فيه لا يسبب ضررًا فرديًا بل ضررًا وطنيًا واسع النطاق.

ثالثًا: نطاق التدقيق الرقابي المقترح

1️⃣ الحوكمة والسيادة الرقمية (Digital Sovereignty Governance | حوكمة السيادة الرقمية)

التحقق المطلوب:

  • من هي الجهة المالكة للقرار النهائي في:
    • تشغيل النظام
    • تعديل السجلات
    • إيقاف أو استعادة الخدمة
  • هل توجد أي صلاحيات تشغيلية أو تقنية لطرف غير عراقي داخل بيئة الإنتاج (Production Environment | بيئة الإنتاج الفعلية)؟

المعيار المرجعي:

  • ISO/IEC 27001 – Clause 5 (Leadership & Governance | القيادة والحوكمة)
  • NIST SP 800-53 – (PL, IA, AC) (التخطيط/الهوية والمصادقة/التحكم بالوصول)

2️⃣ سيادة البيانات (Data Sovereignty & Residency | سيادة البيانات وإقامتها التخزينية)

التحقق المطلوب:

  • أين تُخزن:
    • البيانات الديموغرافية؟
    • البيانات البيومترية؟
    • بيانات السكن والربط؟
  • أين تُخزن النسخ الاحتياطية؟
  • هل توجد أي قنوات:
    • نسخ خارجية
    • مزامنة
    • دعم فني يتطلب نقل بيانات؟
خط أحمر سيادي (غير قابل للتأويل):
1) لا خروج لأي بيانات هوية أو مشتقاتها خارج الحدود العراقية، لا مباشر ولا غير مباشر.
2) كأصلٍ عام، لا وصول عن بُعد إلى بيئة الإنتاج أو قواعد بيانات الهوية من خارج العراق لأي طرف، بما في ذلك الدعم الفني والصيانة.
3) وإذا فُرض استثناء لسببٍ تقني قاهر، فيجب أن يكون عبر بوابة وطنية داخل العراق (Sovereign Bastion Gateway | بوابة وصول سيادية)، وبموافقة حضورية، وتقييد زمني، وتسجيل كامل للجلسات، و (No Copy/No Export | منع النسخ/التصدير).

المعيار المرجعي:

  • ISO/IEC 27001 Annex A (Information Classification & Handling | تصنيف المعلومات وتداولها)
  • GDPR Art. 44–49 (International Data Transfers | نقل البيانات عبر الحدود – مثال معياري دولي)

3️⃣ سيادة مفاتيح التشفير والتوقيع (Key & PKI Sovereignty | سيادة المفاتيح وبنية الثقة PKI)

التحقق المطلوب:

  • من يملك ويدير:
    • مفاتيح توقيع الهوية؟
    • مفاتيح تخصيص البطاقات؟
  • هل المفاتيح:
    • مخزنة داخل HSM (Hardware Security Module | وحدة أمن عتادية لحفظ المفاتيح) داخل العراق؟
    • خاضعة لآلية Dual Control / M-of-N (تحكم مزدوج / قاعدة عدد من عدد)؟
  • هل يملك أي طرف خارجي:
    • نسخة مفاتيح؟
    • قدرة إعادة توليد؟
    • وصول إداري إلى HSM؟
تنبيه:
هذه النقطة تمثل أخطر محور سيادي في المشروع.

المعيار المرجعي:

  • ETSI EN 319 401 / 411 (Trust Services | خدمات الثقة)
  • NIST SP 800-57 / 800-53 (Key Management/Identity | إدارة المفاتيح/الهوية)

4️⃣ إدارة الصلاحيات العالية (Privileged Access Management | إدارة الوصول ذي الامتيازات)

التحقق المطلوب:

  • قائمة كاملة بالحسابات التي تملك:
    • DBA Access (صلاحيات مدير قاعدة البيانات)
    • System Admin (صلاحيات مدير النظام)
    • Application Superuser (صلاحيات المستخدم الفائق للتطبيق)
  • هل توجد:
    • جلسات مسجلة (Session Recording | تسجيل الجلسات)؟
    • فصل واجبات (SoD | Segregation of Duties | فصل الواجبات)؟
    • موافقات مزدوجة على العمليات الحساسة (Dual Approval | موافقة مزدوجة)؟

سيناريو الخطر:

  • موظف أو متعاقد بصلاحية مشروعة يستطيع:
    • تعديل سجل
    • دمج غير صحيح
    • حذف أثر دون اكتشاف فوري

المعيار المرجعي:

  • ISO/IEC 27002 – Privileged Access (الوصول ذو الامتيازات)
  • NIST SP 800-53 – (AC, AU, IA) (الوصول/التدقيق/الهوية)

5️⃣ سلسلة التوريد والشركات الشريكة (Supply Chain Risk | مخاطر سلسلة التوريد)

التحقق المطلوب:

  • هل توجد شركات من الباطن (Subcontractors | متعهدون فرعيون) في:
    • دعم فني
    • تطوير
    • صيانة
    • استضافة
  • هل تم:
    • الإفصاح عنها (Disclosure | إفصاح)؟
    • تدقيقها أمنيًا (Security Due Diligence | عناية واجبة أمنية)؟
  • هل العقود تمنع التعاقد من الباطن دون موافقة سيادية؟

المعيار المرجعي:

  • ISO/IEC 27036 (Supplier Relationships | علاقات الموردين)
  • NIST SP 800-161 (Supply Chain Cybersecurity | أمن سلسلة التوريد السيبرانية)

6️⃣ الإدارة عن بُعد والدعم الفني (Remote Access | الوصول عن بُعد)

التحقق المطلوب:

  • هل توجد أي:
    • VPN (شبكة افتراضية خاصة)
    • Remote Admin (إدارة عن بُعد)
    • Bastion Access (بوابة وصول وسيطة / حصن وصول)
  • إن وُجد:
    • هل هو مقيّد بزمن (Time-bound Access | وصول زمني)؟
    • هل الجلسات مسجلة (Session Recording | تسجيل جلسات)؟
    • هل بموافقة مسؤول عراقي داخل الموقع (On-site Approval | موافقة داخل الموقع)؟

المعيار المرجعي:

  • ISO/IEC 27002 – Remote Access (الوصول عن بُعد)
  • NIST Zero Trust Architecture (هندسة انعدام الثقة)

7️⃣ السجلات والتدقيق (Logging & Auditability | السجلات وقابلية التدقيق)

التحقق المطلوب:

  • هل السجلات:
    • غير قابلة للتلاعب (Tamper-Evident | كاشفة للعبث)؟
    • محفوظة مركزياً (Centralized Logging | سجلات مركزية)؟
  • هل يتم ربطها بـ:
    • SIEM (Security Information and Event Management | إدارة معلومات وأحداث الأمن)
    • تنبيهات فورية عند:
      • تصعيد صلاحيات
      • تصدير بيانات
      • تعديل سجلات حرجة

المعيار المرجعي:

  • ISO/IEC 27001 – Logging & Monitoring (السجلات والمراقبة)
  • NIST SP 800-92 (Log Management | إدارة السجلات)

رابعًا: طلبات أدلة رقابية مشروعة (RFI | طلبات معلومات رقابية)

يمكن لأي جهة رقابية أو برلمانية أو مختصة أن تطلب رسميًا:

  1. Data Flow Diagram (مخطط تدفق البيانات) معتمد
  2. Privileged Access Matrix (مصفوفة الصلاحيات العالية)
  3. Key Management Policy (سياسة إدارة المفاتيح)
  4. Third-Party Security Assessment (تقييم أمني للطرف الثالث)
  5. Penetration Test Summary (خلاصة اختبار اختراق)
  6. Supplier & Sub-contractor Register (سجل الموردين والمتعهدين الفرعيين)
  7. Exit & Handover Plan (خطة الخروج والتسليم)

هذه الطلبات ليست تشكيكًا بل ممارسة معيارية عالمية في مشاريع الهوية الوطنية.


خامسًا: الخلاصة المهنية للملحق

  • الجدل لا يُحسم بالأسماء ولا بالجنسيات.
  • السيادة الرقمية تُقاس بالتحكم الفعلي:
    • من يملك المفاتيح؟
    • من يملك البيانات؟
    • من يملك صلاحية التغيير؟
  • أي مشروع هوية لا يُخضع لهذه الأسئلة سيبقى محل شك مهما كانت نوايا القائمين عليه.
خاتمة الملحق:
ما فعلناه سابقًا في ملف Starlink، هو نفس ما يجب فعله هنا: نقل النقاش من “منفّذ المشروع” إلى “كيف يُدار المشروع”.

✍️ إعداد: المهندس مصطفى كامل الشريف
مستشار في أمن المعلومات والسيادة الرقمية – الدنمارك / العراق

المصادر والمراجع

  • Tech4Peace (T4P) – توضيح حول خبر إحالة مشروع الدمج:
    https://t4p.co/story/2025-12-16-truth-about-referral-project-merge-national-id-card-with-housing-card-syrian-company
  • المعايير المرجعية (بالاسم):
    • ISO/IEC 27001 — (نظام إدارة أمن المعلومات)
    • ISO/IEC 27002 — (ممارسات وضوابط أمن المعلومات)
    • ISO/IEC 27036 — (أمن علاقات الموردين وسلسلة التوريد)
    • NIST SP 800-53 — (ضوابط أمنية للأنظمة)
    • NIST SP 800-161 — (إدارة مخاطر سلسلة التوريد السيبرانية)
    • NIST SP 800-92 — (إدارة السجلات)
    • NIST SP 800-57 — (إدارة مفاتيح التشفير)
    • ETSI EN 319 401 / 411 — (معايير خدمات الثقة والتوقيع)

يمنع إعادة النشر بدون ذكر اسم الكاتب

لمن يرغب بمشاركة هذا المقال السيادي – مع أطيب تحياتي – م. مصطفى كامل الشريف

Facebook X (Twitter) WhatsApp Telegram