انتقل إلى المحتوى الرئيسي

وثائق الامتثال للتنصت ANSSI R226

هدف الوثيقة: توفر هذه الوثيقة المواصفات الفنية المطلوبة للحصول على ترخيص ANSSI R226 بموجب المواد R226-3 و R226-7 من قانون العقوبات الفرنسي لمركز خدمات الرسائل القصيرة OmniMessage (SMSc).

التصنيف: وثائق الامتثال التنظيمي

السلطة المستهدفة: الوكالة الوطنية لأمن نظم المعلومات (ANSSI)

التنظيم: R226 - حماية خصوصية المراسلات والتنصت القانوني

1. المواصفات الفنية التفصيلية​

1.1 ورقة البيانات الفنية التجارية​

اسم المنتج: OmniMessage SMSc (مركز خدمات الرسائل القصيرة) نوع المنتج: مركز رسائل الاتصالات الوظيفة الأساسية: توجيه وتخزين وتسليم رسائل SMS بروتوكولات الشبكة: REST API (HTTPS)، بروتوكولات SMS (SMPP، IMS، SS7/MAP عبر الواجهات الخارجية) نموذج النشر: تطبيق خادم محلي تكنولوجيا المكدس: Elixir/Erlang، إطار Phoenix، Mnesia، MySQL/PostgreSQL

القدرات الأساسية​

معالجة الرسائل:

  • قائمة انتظار رسائل SMS مركزية مع REST API
  • تصميم غير مرتبط بالبروتوكول يدعم واجهات SMPP وIMS وSS7/MAP
  • محرك توجيه ديناميكي مع توجيه قائم على البادئات
  • منطق إعادة المحاولة مع زيادة زمن الانتظار
  • معالجة انتهاء صلاحية الرسائل وقائمة الرسائل الميتة
  • توليد سجلات تفاصيل المكالمات (CDR) وأرشفتها
  • الأداء: ~1,750 رسالة/ثانية معدل إدراج، 150 مليون رسالة/يوم سعة

تخزين الرسائل:

  • قائمة انتظار الرسائل النشطة: قاعدة بيانات Mnesia في الذاكرة مع إمكانية الحفاظ على القرص
    • التخزين الأساسي: RAM للوصول السريع للغاية (زمن استجابة أقل من مللي ثانية)
    • النسخ الاحتياطي على القرص: وضع disc_copies يكتب إلى القرص لاستعادة النظام بعد ا��عطل
    • الاسترداد التلقائي: تبقى الرسائل بعد إعادة تشغيل النظام
    • الاحتفاظ: قابل للتكوين (الافتراضي 24 ساعة)، ثم التنظيف التلقائي
  • أرشيف CDR طويل الأجل: قاعدة بيانات MySQL/PostgreSQL (منفصلة عن قائمة انتظار الرسائل)
    • يتم كتابة CDRs عند تسليم الرسائل أو انتهاء صلاحيتها أو فشلها أو رفضها
    • قاعدة بيانات SQL تستخدم فقط لتصدير/أرشفة CDR، وليس لعمليات الرسائل النشطة
    • لا تأثير على الأداء في توجيه الرسائل (كتابة غير متزامنة)
  • فوائد بنية النظام ذات الطبقتين:
    • قائمة الانتظار النشطة: سريعة للغاية (1,750 رسالة/ثانية) بدون عنق زجاجة SQL
    • أرشيف CDR: احتفاظ طويل الأجل (شهور/سنوات) للفوترة والتنصت القانوني
    • فصل نظيف: عمليات الرسائل لا تلمس SQL أبداً
  • دعم التجمع لتوفير عالٍ (تكرار Mnesia عبر العقد)

واجهات الشبكة:

  • REST API: HTTPS (المنفذ 8443) للتواصل مع الواجهة الخارجية
  • لو��ة التحكم: HTTPS (المنفذ 8086) للإدارة عبر الويب
  • بروتوكولات الواجهة: SMPP، IMS، SS7/MAP (عبر تطبيقات البوابة الخارجية)
  • قاعدة البيانات: MySQL/PostgreSQL لتخزين CDR

التوجيه والمعالجة:

  • توجيه SMS ديناميكي مع تحديثات تكوين في وقت التشغيل
  • مطابقة قائمة على البادئات (أرقام الاتصال/المتصل)
  • تصفية SMSC المصدر والنوع
  • توازن الحمل بناءً على الأولوية والوزن
  • ترجمة الأرقام وتطبيعها
  • دعم بحث DNS ENUM (تعيين رقم E.164)
  • قدرات الرد التلقائي وإسقاط الرسائل
  • التحكم في الشحن لكل مسار (تكامل CGRates)

📖 تم توثيق البنية والميزات الكاملة في README.md

1.2 قدرات التنصت​

1.2.1 اكتساب الرسائل​

التقاط رسالة SMS:

  • يقوم OmniMessage SMSc بمعالجة جميع رسائل SMS بين المشتركين والشبكات الخارجية
  • الوصول الكامل إلى بيانات التعريف ومحتوى الرسالة بما في ذلك:
    • MSISDN المصدر (رقم الهاتف المحمول)
    • MSISDN الوجهة (رقم الهاتف المحمول)
    • IMSI المصدر (معرف المشترك الدولي المحمول)
    • IMSI الوجهة
    • نص الرسالة (محتوى النص)
    • بيانات PDU الخام (وحدة البيانات البروتوكولية)
    • معلومات TP-DCS (نظام ترميز البيانات)
    • ترميز الرسالة (GSM7، UCS-2، 8-bit، Latin-1)
    • مؤشرات الرسائل المتعددة وبيانات إعادة التجميع
    • معلومات رأس بيانات المستخدم (UDH)

اكتساب بيانات التعريف للرسالة:

  • سجلات تفاصيل المكالمات الكاملة (CDR) المخزنة في قاعدة البيانات مع:
    • معرف الرسالة (معرف فريد)
    • رقم الاتصال (MSISDN المصدر)
    • رقم المتصل (MSISDN الوجهة)
    • طابع زمني للإرسال (عندما دخلت الرسالة النظام)
    • طابع زمني للتسليم (عندما تم تسليم الرسالة)
    • طابع زمني لانتهاء الصلاحية (عندما انتهت صلاحية الرسالة إذا لم يتم تسليمها)
    • الحالة (تم التسليم، انتهت صلاحيتها، فشلت، رُفضت)
    • عدد محاولات التسليم
    • أجزاء الرسالة (لرسائل SMS المتعددة/المتسلسلة)
    • معرف SMSC المصدر
    • معرف SMSC الوجهة
    • العقدة الأصلية (اسم عقدة تجمع Erlang)
    • العقدة الوجهة (للنشر الموزع)
    • علامة الرسالة الميتة (مؤشر استنفاد إعادة المحاولة)

📖 تم توثيق مخطط CDR الكامل في CDR_SCHEMA.md

الوصول إلى قائمة انتظار الرسائل:

  • مراقبة قائمة انتظار الرسائل في الوقت الحقيقي
  • نقاط نهاية REST API لاسترجاع الرسائل
  • استعلامات قاعدة البيانات للبحث التاريخي عن الرسائل
  • قدرات التصفية بواسطة:
    • رقم الهاتف (المصدر/الوجهة)
    • بوابة SMSC
    • نطاق الوقت
    • حالة الرسالة
    • محاولات التسليم

📖 تم توثيق واجهة برمجة التطبيقات الكاملة في API_REFERENCE.md

1.2.2 قدرات معالجة البيانات​

بنية تخزين الرسائل (نظام ذو طبقتين):

يستخدم SMSc بنية تخزين متطورة ذات طبقتين تفصل بين معالجة الرسائل التشغيلية وا��أرشفة طويلة الأجل:

الطبقة 1: قائمة انتظار الرسائل النشطة (Mnesia)

  • الغرض: عمليات توجيه وتسليم الرسائل في الوقت الحقيقي
  • التكنولوجيا: قاعدة بيانات Erlang Mnesia الموزعة
  • وضع التخزين: في الذاكرة مع نسخ احتياطي disc_copies
    • التخزين الأساسي في RAM لتحقيق أقصى سرعة
    • مزامنة تلقائية للقرص لاستعادة النظام بعد العطل
    • تبقى الرسائل عبر إعادة تشغيل النظام
  • الأداء: عمليات القراءة/الكتابة أقل من مللي ثانية
  • الاحتفاظ: قصير الأجل (الافتراضي 24 ساعة)، قابل للتكوين
  • التنظيف: أرشفة تلقائية إلى قاعدة بيانات CDR، ثم الحذف من Mnesia
  • العمليات: جميع عمليات قائمة انتظار الرسائل (إدراج، تحديث، حالة التسليم، توجيه)
  • الميزة الحرجة: لا يتم استعلام قاعدة بيانات SQL أبداً أثناء توجيه/تسليم الرسائل

الطبقة 2: أرشيف CDR (MySQL/PostgreSQL)

  • الغرض: تخزين طويل الأجل للفوترة والتحليلات والتنصت القانوني
  • التكنولوجيا: قاعدة بيانات SQL التقليدية (MySQL أو PostgreSQL)
  • محفز الكتابة: يتم كتابة CDRs فقط عندما تصل الرسائل إلى الحالة النهائية:
    • تم تسليم الرسالة بنجاح
    • انتهت صلاحية الرسالة (تجاوزت فترة الصلاحية)
    • فشلت الرسالة بشكل دائم
    • تم رفض الرسالة بواسطة قواعد التوجيه
  • وضع الكتابة: كتابة دفعات غير متزامنة (لا تأثير على أداء توجيه الرسائل)
  • الاحتفاظ: طويل الأجل (شهور إلى سنوات)، قابل للتكوين وفقاً لمتطلبات التنظيم
  • العمليات: استعلامات تاريخية، تقارير، امتثال، تنصت قانوني
  • الوصول: استعلامات SQL، REST API (مستقبلية)، تصدير CSV/JSON

فوائد البنية المعمارية الرئيسية:

  1. الأداء: لا تتأثر عمليات التوجيه النشطة بـ SQL (لا عنق زجاجة قاعدة البيانات)
  2. القابلية للتوسع: تتعامل Mnesia مع 1,750+ رسالة/ثانية بدون عبء SQL
  3. الموثوقية: يضمن وضع disc_copies عدم فقدان الرسائل عند حدوث عطل
  4. الامتثال: توفر قاعدة بيانات CDR مسار تدقيق دائم
  5. فصل الاهتمامات: البيانات التشغيلية مقابل البيانات الأرشيفية مفصولة بوضوح

دورة حياة الرسالة:

1. تم تقديم الرسالة → تم تخزينها في Mnesia (RAM + نسخ احتياطي على القرص)
2. تم توجيه الرسالة → استعلام Mnesia (سريع للغاية)
3. تم تسليم الرسالة/انتهت صلاحيتها → تم كتابة CDR إلى SQL (غير متزامن)
4. بعد 24 ساعة → تم حذف الرسالة من Mnesia (عامل التنظيف)
5. تظل CDR في SQL → متاحة لاستعلامات التنصت القانوني (سنوات)

الاحتفاظ بالبيانات واسترجاعها:

  • الاحتفاظ بقابل للتكوين بمحتوى الرسالة أو الحذف من أجل الخصوصية
  • الحفاظ على البيانات الثنائية (تخزين PDU الخام في كل من Mnesia وCDR)
  • القدرة على البحث النصي الكامل (إذا تم تمكينه على قاعدة بيانات CDR)
  • حقول CDR المفهرسة لاستعلامات ال��نصت القانوني السريعة

تتبع الواجهة الأمامية:

  • تتبع في الوقت الحقيقي للواجهات الخارجية SMSC (SMPP، IMS، بوابات MAP)
  • تسجيل الواجهة الأمامية مع مراقبة نبض القلب
  • تتبع حالة الصحة (نشط/منتهي)
  • تاريخ وقت التشغيل/التوقف
  • تتبع عنوان IP واسم المضيف
  • تسجيل تكوين محدد للواجهة الأمامية

1.2.3 قدرات التحليل​

المراقبة في الوقت الحقيقي:

  • لوحة معلومات واجهة المستخدم على الويب تعرض:
    • قائمة انتظار الرسائل النشطة
    • تقديم الرسائل والتسليم
    • قرارات التوجيه واختيار البوابة
    • حالة بوابة الواجهة الأمامية
    • استخدام موارد النظام
  • تكامل مقاييس Prometheus للمراقبة التشغيلية
  • مقاييس الأداء (معدل النقل، زمن الاستجابة، معدلات النجاح)

📖 دليل المراقبة الكامل في OPERATIONS_GUIDE.md 📖 وثائق المقاييس في METRICS.md

التحليل التاريخي:

  • قاعدة بيانات CDR قابلة للاستعلام بواسطة:
    • نطاق الوقت
    • رقم الطرف المتصل/المتصل به
    • حالة الرسالة
    • بوابة SMSC
    • محاولات التسليم
    • محتوى الرسالة (بحث نصي كامل إذا تم تمكينه)
  • قدرات التحليل الإحصائي:
    • حجم الرسائل حسب الساعة/اليوم/الشهر
    • معدلات النجاح/الفشل حسب المسار
    • متوسط أوقات التسليم
    • تحليل الرسائل متعددة الأجزاء
    • أنماط التسليم الفاشلة

تتبع المشتركين:

  • تاريخ الرسائل حسب رقم الهاتف (MSISDN)
  • تتبع قائم على IMSI (عند توفره من واجهات IMS/MAP)
  • تحليل نمط المكالمات
  • ارتباط الأطراف المتواصلة
  • التحليل الزمني (تكرار الرسائل، أنماط التوقيت)

تحليلات الشبكة:

  • مقاييس أداء المسار
  • توفر وصحة البوابة
  • تصور تدفق الرسائل
  • توزيع عقد التجمع (نشر متعدد العقد)
  • تحليل محاولات التسليم
  • تحليل أنماط إعادة المحاولة

ذكاء الأرقام:

  • تطبيع رقم E.164
  • تحديد الدولة/المنطقة من بادئة الرقم
  • قواعد ترجمة وإعادة كتابة الأرقام
  • بحث DNS ENUM لذكاء التوجيه
  • قرارات التوجيه القائمة على البادئات

📖 دليل ترجمة الأرقام في number_translation_guide.md 📖 دليل التوجيه في sms_routing_guide.md

1.3 قدرات التدابير المضادة​

1.3.1 آليات حماية الخصوصية​

سرية الاتصالات:

  • HTTPS/TLS لتواصل REST API
  • مصادقة قائمة على الشهادات
  • تشفير اتصال قاعدة البيانات (دعم TLS)
  • خيار حذف محتوى الرسالة بعد التسليم

التحكم في الوصول:

  • التحكم في الوصول إلى واجهة المستخدم على الويب
  • آليات مصادقة API
  • ضوابط وصول قاعدة البيانات
  • مصادقة تسجيل الواجهة الأمامية

تسجيل التدقيق:

  • تسجيل كامل لأحداث النظام
  • تسجيل تقديم/تسليم الرسائل
  • تتبع تغييرات التكوين
  • تسجيل الإجراءات الإدارية
  • تسجيل م��ظم مع مستويات قابلة للتكوين

1.3.2 ميزات حماية البيانات​

خصوصية الرسالة:

  • خيار حذف محتوى الرسالة بعد التسليم
  • محتوى الرسالة مستبعد من عرض واجهة المستخدم (اختياري)
  • محتوى الرسالة مستبعد من التصديرات (اختياري)
  • يمكن تعيين حقل محتوى الرسالة CDR إلى NULL من أجل الخصوصية

أمان قاعدة البيانات:

  • دعم تشفير جدول MySQL (ENCRYPTION='Y')
  • دعم تشفير البيانات الشفاف PostgreSQL
  • فصل أدوار الوصول إلى قاعدة البيانات
  • حسابات مستخدمين للقراءة فقط للتحليلات
  • وصول مقيد إلى محتوى الرسالة

تقوية النظام:

  • الحد الأدنى من المنافذ الشبكية المكشوفة
  • إدارة شهادات TLS
  • تخزين تكوين آمن
  • فصل تكوينات قائمة على البيئة
  • أمان التجمع مع بروتوكول توزيع Erlang

1.4 بنية التخزين: تصميم ذو طبقتين Mnesia + SQL​

نظرة عامة​

يستخدم OmniMessage SMSc بنية تخزين فريدة ذات طبقتين مصممة خصيصًا لفصل ��عالجة الرسائل التشغيلية عالية الأداء عن التخزين طويل الأجل للامتثال والأرشفة.

الطبقة 1: قائمة انتظار الرسائل في الذاكرة Mnesia​

ما هو Mnesia؟

  • قاعدة بيانات موزعة مدمجة في وقت تشغيل Erlang/OTP
  • تخزين هجين: التخزين الأساسي في الذاكرة مع نسخ احتياطي تلقائي على القرص
  • معاملات متوافقة مع ACID
  • تكرار التجمع عبر عدة عقد

وضع التخزين: disc_copies

  • في الذاكرة الأساسية: جميع الرسائل النشطة مخزنة في RAM
    • عمليات القراءة/الكتابة سريعة للغاية (أقل من مللي ثانية)
    • لا يوجد إدخال/إخراج للقرص أثناء عمليات توجيه الرسائل العادية
    • يمكّن من معدل نقل 1,750+ رسالة/ثانية
  • نسخ احتياطي على القرص (تلقائي): يقوم Mnesia بمزامنة RAM مع القرص
    • تحدث الكتابات بشكل غير متزامن في الخلفية
    • يتم تحديث نسخة القرص في كل عملية التزام للمعاملة
    • استعادة النظام: إعادة تشغيل النظام مع جمي�� الرسائل سليمة
    • الموقع: دليل Mnesia.*/ في بيانات التطبيق

دورة حياة الرسالة في Mnesia:

  1. تصل الرسالة عبر REST API → يتم إدراجها في RAM Mnesia + نسخ احتياطي على القرص
  2. يستعلم محرك التوجيه Mnesia → استجابة فورية (وصول إلى الذاكرة)
  3. تستعلم البوابة الخارجية عن الرسائل → استعلام Mnesia (وصول إلى الذاكرة)
  4. تقوم البوابة بتحديث حالة التسليم → تحديث Mnesia (ذاكرة + قرص)
  5. بعد التسليم/انتهاء الصلاحية → يتم وضع علامة على الرسالة للتنظيف
  6. عامل التنظيف (الافتراضي 24 ساعة) → يتم حذف الرسالة من Mnesia

الميزة الحرجة للأداء:

  • لا استعلامات قاعدة بيانات SQL أثناء توجيه/تسليم الرسائل النشطة
  • يتم تجاوز SQL تمامًا لمعالجة الرسائل التشغيلية
  • هذا يلغي عنق الزجاجة التقليدي في SMS-C (إدخال/إخراج قاعدة البيانات)

الطبقة 2: قاعدة بيانات SQL لتصدير/أرشفة CDR​

ما هو CDR (سجل تفاصيل المكالمات)؟

  • سجل تدقيق دائم لبيانات التعريف ومحتوى الرسالة
  • مكتوب إلى قاعدة بيانات MySQL أو PostgreSQL
  • يستخدم للفوترة، التحليلات، الامتثال، والتنصت القانوني

متى يتم كتابة CDRs: يتم إنشاء سجلات CDR فقط عندما تصل الرسائل إلى حالة نهائية:

  • ✅ تم تسليم الرسالة بنجاح
  • ✅ انتهت صلاحية الرسالة (تجاوزت فترة الصلاحية بدون تسليم)
  • ✅ فشلت الرسالة بشكل دائم (رقم غير صالح، خطأ في التوجيه)
  • ✅ تم رفض الرسالة (قواعد التوجيه، فشل التحقق)

كيف يتم كتابة CDRs:

  • كتابة دفعات غير متزامنة: يتم كتابة CDRs في عملية عامل خلفي
  • لا حظر: لا تنتظر عمليات توجيه الرسائل كتابة SQL
  • إدراج دفعات: يتم تجميع عدة CDRs (الافتراضي 100) وكتابتها معًا
  • فترة التفريغ: 100 مللي ثانية (قابل للتكوين)
  • معالجة الأخطاء: يتم تسجيل الكتابات الفاشلة لـ CDR، وتستمر معالجة الرسائل
# التكوين في config/runtime.exs
config :sms_c,
  batch_insert_batch_size: 100,          # حجم الدفعة لكتابات CDR
  batch_insert_flush_interval_ms: 100    # فترة التفريغ

الغرض من قاعدة بيانات SQL:

  • ❌ لا تستخدم لـ: عمليات قائمة انتظار الرسائل النشطة
  • ❌ لا تستخدم لـ: قرارات توجيه الرسائل
  • ❌ لا تستخدم لـ: تسليم الرسائل في الوقت الحقيقي
  • ✅ تستخدم فقط لـ: أرشفة CDR طويلة الأجل والاستعلامات التاريخية
  • ✅ تستخدم فقط لـ: استعلامات التنصت القانوني (شهور/سنوات من التاريخ)
  • ✅ تستخدم فقط لـ: تقارير الفوترة والتحليلات

مخطط البنية​

الأسطورة:

  • الخطوط الصلبة: عمليات متزامنة (في الوقت الحقيقي)
  • الخطوط المتقطعة: عمليات غير متزامنة (خلفية)
  • الأخضر: الطبقة عالية الأداء (في الذاكرة)
  • الأزرق: الطبقة الأرشيفية (SQL الدائم)

آثار التنصت القانوني​

الرسائل الحديثة (< 24 ساعة):

  • يمكن الوصول إليها عبر Mnesia (استعلامات REST API)
  • استرجاع سريع للغاية
  • محتوى الرسالة الكامل متاح
  • المراقبة في الوقت الحقيقي ممكنة

الرسائل التاريخية (> 24 ساعة):

  • يمكن الوصول إليها عبر قاعدة بيانات SQL (جدول CDR)
  • أداء استعلام SQL القياسي
  • بيانات التعريف الكاملة للرسالة متاحة دائمًا
  • محتوى الرسالة متاح (ما لم يتم تمكين وضع الخصوصية)

فوائد الامتثال:

  1. لا فقدان للبيانات: يضمن وضع disc_copies بقاء الرسائل سليمة عند حدوث عطل
  2. مسار تدقيق دائم: يتم الاحتفاظ بـ CDRs لسنوات في قاعدة بيانات SQL
  3. الأداء: لا تؤثر استعلامات التنصت القانوني على توجيه الرسائل
  4. المرونة: الرسائل الحديثة (Mnesia) + الرسائل التاريخية (SQL) كلاهما متاح

1.5 بنية تكامل الواجهة متعددة البروتوكولات​

يستخدم OmniMessage SMSc تصميمًا أساسيًا غير مرتبط بالبروتوكول يتفاعل مع بوابات خارجية محددة بالبروتوكول عبر REST API موحد. تسمح هذه البنية للتنصت القانوني بالتقاط الرسائل بغض النظر عن البروتوكول الذي تم استخدامه لإرسالها أو استلامها.

نظرة عامة على البنية​

تفاصيل تكامل بروتوكول الواجهة​

1. تكامل الواجهة IMS/SIP

تستخدم شبكات IMS بروتوكول SIP لتبادل الرسائل عبر IP. تقوم بوابة IMS بترجمة بين SIP وREST API لـ SMSc.

بيانات التنصت المحددة IMS:

  • IMSI المصدر/الوجهة (من تسجيل IMS)
  • رؤوس SIP P-Asserted-Identity
  • SIP Call-ID للربط
  • موقع شبكة IMS (P-Access-Network-Info)
  • ملفات تعريف المشتركين من HSS IMS

2. تكامل الواجهة SMPP

SMPP هو البروتوكول القياسي للصناعة لمجمعي SMS ومقدمي الخدمة. تقوم بوابة SMPP بترجمة رسائل SMPP المعتمدة على PDU إلى مكالمات REST API.

بيانات التنصت المحددة SMPP:

  • PDU SMPP الكامل (يتم الحفاظ على التنسيق الثنائي)
  • تفاصيل نظام ترميز البيانات (DCS)
  • رأس بيانات المستخدم (UDH) للرسائل المتعددة
  • معرف النظام ESME (تحديد العميل)
  • معلومات خطة ترقيم TON/NPI
  • علامات التسليم المسجلة

3. تكامل الواجهة SS7/MAP

تستخدم الشبكات القديمة المتبدلة بروتوكول SS7 MAP للرسائل القصيرة. تقوم بوابة MAP بترجمة بين الإشارات SS7 وREST API.

بيانات التنصت المحددة SS7/MAP:

  • IMSI من رسائل MAP
  • عناوين Global Title (GT)
  • عنوان MSC/VLR (تحديد عنصر الشبكة)
  • عناوين الأطراف المتصلة SCCP
  • رموز العمليات MAP
  • تنسيق TP-User-Data الثنائي

التنصت الموحد عبر جميع البروتوكولات​

الفائدة الرئيسية للتنصت القانوني: بغض النظ�� عن البروتوكول المستخدم (IMS/SIP، SMPP، أو SS7/MAP)، تتقارب جميع الرسائل في جوهر SMSc مع هيكل بيانات موحد، مما يمكّن من:

  1. المراقبة غير المرتبطة بالبروتوكول: نقطة تنصت واحدة تلتقط جميع أنواع الرسائل
  2. تنسيق CDR الموحد: تكتب جميع البروتوكولات إلى نفس مخطط CDR
  3. الربط عبر البروتوكولات: تتبع الرسائل عبر حدود البروتوكول
  4. الحفاظ على البيانات الوصفية الكاملة: يتم الحفاظ على الحقول المحددة بالبروتوكول في CDR

ملخص تدفق البيانات:

تحديد البروتوكول في CDR:

  • يشير حقل source_smsc إلى بروتوكول الواجهة (مثل "ims.gateway-01"، "smpp.customer123"، "map.msc-01")
  • يمكّن من التصفية والتحليل حسب نوع البروتوكول
  • يمكن لاستعلامات التنصت القانوني استهداف بروتوكولات محددة أو جميع البروتوكولات

1.6 البنية التقنية للتنصت القانوني​

نقاط تكامل التنصت القانوني​

توفر بنية التخزين ذات الطبقتين نقاط وصول متعددة للتنصت القانوني، محسّنة لكل من المراقبة في الوقت الحقيقي (Mnesia) والتحليل التاريخي (SQL).

1. الوصول عبر REST API للرسائل الحديثة (Mnesia):

الوصول إلى الرسائل النشطة في قائمة انتظار Mnesia (عادةً آخر 24 ساعة):

نقاط نهاية API للتنصت في الوقت الحقيقي:

  • GET /api/messages - قائمة الرسائل النشطة مع التصفية
  • GET /api/messages/{id} - الحصول على تفاصيل رسالة معينة (من Mnesia)
  • GET /api/messages/get_by_smsc?smsc=X - الحصول على الرسائل حسب البوابة
  • جميع الاستعلامات تضرب Mnesia (في الذاكرة) للاستجابة الفورية

ملاحظة: تستعلم هذه النقاط النهاية قائمة انتظار الرسائل النشطة في Mnesia، مما يوفر الوصول إلى الرسائل التي تتم معالجتها حاليًا أو تم تسليمها مؤخرًا (ضمن فترة الاحتفاظ).

معلمات الاستعلام:

  • تصفية بواسطة MSISDN المصدر/الوجهة
  • تصفية بواسطة نطاق الوقت
  • تصفية بواسطة بوابة SMSC
  • تصفية بواسطة حالة الرسالة
  • دعم الفرز والتقسيم

2. الوصول المباشر إلى قاعدة بيانات CDR للرسائل التاريخية (SQL):

الوصول إلى الرسائل ا��مؤرشفة في قاعدة بيانات SQL (جميع الرسائل التي تم تسليمها/انتهت صلاحيتها/فشلت):

الوصول المباشر إلى SQL:

  • بيانات اعتماد قاعدة بيانات للقراءة فقط للأنظمة المصرح بها
  • الوصول إلى استعلام SQL إلى جدول cdrs (مسار تدقيق دائم)
  • طريقة الوصول: عميل SQL قياسي (mysql، psql، DBeaver، إلخ)
  • مصدر البيانات: فقط الرسائل المؤرشفة (ليس قائمة الانتظار النشطة)
  • حقول مفهرسة للبحث الفعال:
    • calling_number (مفهرس) - رقم الهاتف المصدر
    • called_number (مفهرس) - رقم الهاتف الوجهة
    • message_id (مفهرس) - معرف الرسالة الفريد
    • submission_time (مفهرس) - عندما دخلت الرسالة النظام
    • status (مفهرس) - الحالة النهائية للتسليم
    • dest_smsc (مفهرس) - البوابة المستخدمة للتسليم

ملاحظة: تحتوي قاعدة بيانات CDR على سجلات دائمة لجميع الرسائل المعالجة. هذا هو المصدر الرئيسي لاستعلامات التنصت القانوني التاريخية (شهور/سنوات من البيانات).

3. تغذية الرسائل في الوقت الحقيقي (PubSub):

  • تكامل Phoenix PubSub للأحداث في الوقت الحقيقي
  • إشعارات تقديم الرسائل
  • إشعارات تسليم الرسائل
  • أحداث تغيير حالة الرسالة
  • تصفية الأحداث القابلة للتكوين حسب المعايير
  • دعم WebSocket للمراقبة المباشرة

4. واجهة تصدير الدفعات:

  • تصدير CSV لسجلات CDR
  • تصدير JSON للوصول البرمجي
  • حقول تصدير قابلة للتكوين
  • تصديرات قائمة على نطاق الوقت
  • تصديرات واعية للخصوصية (استبعاد محتوى الرسالة الاختياري)

واجهات التنصت القانوني وفقًا لمعايير ETSI​

يوفر OmniMessage SMSc الأساس لتنفيذ واجهات التنصت القانوني المتوافقة مع ETSI. بينما لا يقوم جوهر SMSc بتنفيذ واجهات X1/X2/X3 بشكل أصلي، فإنه يوفر جميع نقاط الوصول اللازمة التي يمكن دمجها مع أنظمة وظائف الوساطة للتنصت القانوني (LIMF) الخارجية.

واجهات LI القياسية ETSI:

وصف الواجهات:

واجهة X1 - وظيفة الإدارة:

  • الغرض: تتبع أوامر التنصت وتوفير الأهداف من قبل تنفيذ القانون إلى نظام التنصت
  • الاتجاه: LEMF → LIMF (ثنائي الاتجاه)
  • الوظائف:
    • تفعيل/إلغاء تفعيل التنصت لأهداف محددة (MSISDNs، IMSIs)
    • تعيين مدة التنصت وفترة الصلاحية
    • تكوين معايير التصفية (أرقام الهواتف، نوافذ زمنية)
    • استرجاع حالة التنصت
  • التكامل مع SMSc:
    • يحتفظ LIMF بقائمة الأهداف (قاعدة بيانات الأوامر)
    • يستعلم LIMF من SMSc CDR/API للرسائل المطابقة
    • يقوم LIMF بالتصفية بناءً على المعايير المقدمة من X1

واجهة X2 - تسليم IRI (معلومات متعلقة بالتنصت):

  • الغرض: تسليم بيانات التعريف الخاصة بالرسالة إلى تنفيذ القانون
  • الاتجاه: LIMF → LEMF (اتجاه واحد)
  • تنسيق البيانات: متوافق مع ETSI TS 102 232-x XML/ASN.1
  • المحتوى من SMSc CDR:
    • معرف الرسالة
    • رقم الاتصال (MSISDN المصدر)
    • رقم المتصل (MSISDN الوجهة)
    • IMSI (المصدر والو��هة، إذا كان متاحًا)
    • طابع زمني للإرسال
    • طابع زمني للتسليم
    • حالة الرسالة (تم التسليم/فشل/انتهت صلاحيتها)
    • محاولات التسليم
    • معلومات بوابة SMSC (المصدر/الوجهة)
    • موقع الشبكة (إذا كان متاحًا)
  • التكامل مع SMSc:
    • يستعلم LIMF من قاعدة بيانات CDR لأرقام الهواتف المستهدفة
    • يقوم LIMF بتحويل سجلات CDR إلى تنسيق IRI المتوافق مع ETSI
    • يقوم LIMF بتسليم IRI إلى LEMF عبر X2

واجهة X3 - تسليم CC (محتوى الاتصال):

  • الغرض: تسليم محتوى الرسالة الفعلي إلى تنفيذ القانون
  • الاتجاه: LIMF → LEMF (اتجاه واحد)
  • تنسيق البيانات: متوافق مع ETSI TS 102 232-x
  • المحتوى من SMSc:
    • محتوى الرسالة (محتوى النص)
    • PDU الخام (بيانات SMS الثنائية)
    • معلومات الترميز
    • أجزاء الرسالة المتعددة
    • معلومات TP-DCS
  • التكامل مع SMSc:
    • يسترجع LIMF محتوى الرسالة من حقل message_body في CDR
    • يسترجع LIMF بيانات PDU الخام إذا كانت متاحة
    • يقوم LIMF بتعبئة المحتوى في تنسيق CC المتوافق مع ETSI
    • يقوم LIMF بتسليم CC إلى LEMF عبر X3

معمارية التنفيذ:

تعيين بيانات SMSc إلى واجهات LI:

حقل بيانات SMScX2 (IRI)X3 (CC)عمود جدول CDR
معرف الرسالة✅ معرف الربط✅ مرجعmessage_id
رقم الاتصال✅ الطرف A-calling_number
رقم المتصل✅ الطرف B-called_number
طابع زمني للإرسال✅ طابع زمني-submission_time
طابع زمني للتسليم✅ الاكتمال-delivery_time
الحالة✅ النتيجة-status
محتوى الرسالة-✅ المحتوىmessage_body
PDU الخام-✅ ثنائي(Mnesia/CDR)
SMSC المصدر✅ عنصر الشبكة-source_smsc
SMSC الوجهة✅ عنصر الشبكة-dest_smsc
IMSI✅ معرف المشترك-(عبر الواجهات)

خيارات تكامل LIMF:

الخيار 1: بنية الاستعلام

  • يستعلم LIMF دوريًا من قاعدة بيانات CDR (كل 1-60 ثانية)
  • اس��علام SQL يتصفّح الأرقام المستهدفة من قائمة الأوامر X1
  • تعقيد منخفض، سهل التنفيذ
  • تأخير طفيف بين تسليم الرسالة وتسليم LI

الخيار 2: بنية التغذية في الوقت الحقيقي

  • تنشر SMSc أحداث الرسائل
  • يشترك LIMF في تدفق الرسائل في الوقت الحقيقي
  • يقوم LIMF بالتصفية بناءً على قائمة الأهداف
  • زمن تأخير قريب من الصفر للتنصت القانوني
  • يتطلب تطوير تكامل مخصص

الخيار 3: بنية هجينة

  • الرسائل الحديثة: تدفق تغذية في الوقت الحقيقي (< 24 ساعة)
  • الرسائل التاريخية: استعلام قاعدة بيانات CDR
  • توازن مثالي بين زمن التأخير والموثوقية

آليات تحفيز التنصت​

التنصت القائم على الهدف:

  • مطابقة رقم الهاتف (MSISDN)
  • استهداف قائم على IMSI (عند توفره)
  • قوائم مراقبة قابلة للتكوين
  • وجهات نظر قاعدة البيانات لعزل الأهداف
  • تصفية API بواسطة معرفات ا��أهداف

التنصت القائم على الحدث:

  • جميع الرسائل إلى/from أرقام محددة
  • الرسائل عبر بوابات SMSC محددة
  • الرسائل ذات الخصائص المحددة (متعددة الأجزاء، فشل التسليم، إلخ.)
  • التوجيه الجغرافي (عبر ENUM أو مطابقة البادئات)

التنصت القائم على الوقت:

  • تصفية نطاق التاريخ/الوقت في استعلامات CDR
  • فرض فترة الاحتفاظ
  • أرشفة تلقائية للرسائل القديمة
  • سياسات احتفاظ البيانات القابلة للتكوين

أمثلة استعلام SQL للتنصت القانوني:

-- الحصول على جميع الرسائل للرقم المستهدف
SELECT * FROM cdrs
WHERE calling_number = '+33612345678'
   OR called_number = '+33612345678'
ORDER BY submission_time DESC;

-- الحصول على الرسائل في نافذة زمنية محددة
SELECT * FROM cdrs
WHERE (calling_number = '+33612345678' OR called_number = '+33687654321')
  AND submission_time BETWEEN '2025-11-01 00:00:00' AND '2025-11-30 23:59:59'
ORDER BY submission_time;

-- الحصول على المحادثة بين طرفين
SELECT * FROM cdrs
WHERE (calling_number = '+33612345678' AND called_number = '+33687654321')
   OR (calling_number = '+33687654321' AND called_number = '+33612345678')
ORDER BY submission_time;

2. قدرات التشفير والتحليل​

2.1 نظرة عامة على القدرات التشفيرية​

يطبق OmniMessage SMSc آليات تشفير لتأمين الاتصالات وحماية البيانات الحساسة. توثق هذه القسم جميع القدرات التشفيرية وفقًا لمتطلبات ANSSI.

2.2 تشفير طبقة النقل​

2.2.1 تنفيذ TLS/SSL​

البروتوكولات المدعومة:

  • TLS 1.2 (RFC 5246)
  • TLS 1.3 (RFC 8446) - موصى به
  • SSL 2.0/3.0: غير مدعوم (ثغرات معروفة)
  • TLS 1.0/1.1: مُهمل (غير موصى به)

التنفيذ:

  • مكتبة SSL/TLS Erlang/OTP (تم التحقق منها تشفيرياً)
  • خادم ويب Cowboy مع دعم TLS
  • نقاط نهاية HTTPS لإطار Phoenix

مجموعات الشفرات:

يستخدم النظام اختيار مجموعة الشفرات الآمنة الافتراضية لـ Erlang/OTP، والتي تشمل:

المفضل - TLS 1.3:

  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_GCM_SHA256
  • TLS_CHACHA20_POLY1305_SHA256

المدعوم - TLS 1.2:

  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES256-GCM-SHA384
  • DHE-RSA-AES128-GCM-SHA256

ميزات الأمان:

  • السرية المثالية للأمام (PFS) عبر تبادل المفاتيح ECDHE/DHE
  • مجموعات Diffie-Hellman قوية (2048 بت كحد أدنى)
  • دعم تشفير المنحنيات البيانية
  • دعم إشارة اسم الخادم (SNI)

إدارة الشهادات:

  • دعم الشهادات X.509
  • أحجام مفاتيح RSA: 2048 بت كحد أدنى، 4096 بت موصى بها
  • دعم ECDSA
  • التحقق من سلسلة الشهادات
  • الشهادات الموقعة ذاتيًا (للتطوير فقط)
  • تكامل CA الخارجي

موقع تكوين TLS:

# config/runtime.exs
config :api_ex,
  api: %{
    enable_tls: true,
    tls_cert_path: "priv/cert/omnitouch.crt",
    tls_key_path: "priv/cert/omnitouch.pem"
  }

📖 مرجع التكوين الكامل في CONFIGURATION.md

التطبيقات:

  • HTTPS لـ REST API (المنفذ 8443)
  • HTTPS للوحة التحكم على الويب (المنفذ 8086)
  • اتصالات قاعدة البيانات (MySQL/PostgreSQL عبر TLS)

2.3 تشفير البيانات في حالة السكون​

2.3.1 تشفير قاعدة البيانات​

تشفي�� MySQL/MariaDB:

  • دعم تشفير على مستوى الجدول
  • خوارزمية تشفير AES-256
  • تشفير البيانات الشفاف (TDE)
-- تمكين التشفير لجدول CDR
ALTER TABLE cdrs ENCRYPTION='Y';

تشفير PostgreSQL:

  • دعم تشفير البيانات الشفاف
  • تشفير على مستوى نظام الملفات
  • تشفير على مستوى العمود (امتداد pgcrypto)

2.3.2 تخزين القرص Mnesia​

قاعدة بيانات Mnesia:

  • تخزين نسخ القرص لاستمرارية الرسائل
  • يوصى بتشفير مستوى نظام الملفات (LUKS، dm-crypt)
  • حماية الذاكرة عبر عزل VM Erlang

2.3.3 تشفير نظام الملفات​

تخزين البيانات الحساسة:

  • ملفات التكوين: يوصى بتشفير نظام الملفات
  • المفاتيح الخاصة: أذونات الملفات (0600) + تشفير نظام الملفات
  • ملفات السجل: تشفير قابل للتكوين لسجلات الأرشفة
  • تصديرات CDR: تخزين مشفر للتصديرات الحساسة

تخزين المفاتيح:

  • يتم تخزين شهادات TLS والمفاتيح في priv/cert/
  • مخازن المفاتيح المستندة إلى الملفات مع أذونات مقيدة
  • إجراءات دوران المفاتيح الآمنة

2.4 المصادقة والتحكم في الوصول​

2.4.1 مصادقة API​

أمان REST API:

  • تشفير نقل HTTPS/TLS إلزامي
  • مصادقة قائمة على الرؤوس (رأس SMSc لتحديد الواجهة الأمامية)
  • التحكم في الوصول القائم على IP (على مستوى جدار الحماية)
  • مصادقة عميل قائمة على الشهادات (اختياري)

تسجيل الواجهة الأمامية:

  • تحديد فريد للواجهة الأمامية (الاسم، النوع، IP، اسم المضيف)
  • مصادقة قائمة على نبض القلب
  • إدارة الجلسات بناءً على انتهاء الصلاحية (مهلة 90 ثانية)
  • تتبع ومراقبة الواجهة الأمامية

2.4.2 مصادقة قاعدة البيانات​

التحكم في الوصول إلى قاعدة البيانات:

  • مصادقة اسم المستخدم/كلمة المرور
  • دعم اتصال TLS/SSL
  • قيود الاتصال القائمة على IP
  • التحكم في الوصول القائم على الدور (RBAC)

التكوين:

# config/runtime.exs
config :sms_c, SmsC.Repo,
  username: "omnitouch",
  password: "omnitouch2024",  # يجب استخدام كلمات مرور قوية في الإنتاج
  hostname: "localhost",
  ssl: true  # تمكين TLS لاتصالات قاعدة البيانات

توصيات التحكم في الوصول:

-- إنشاء مستخدم للقراءة فقط للوصول إلى تنفيذ القانون
CREATE USER 'li_readonly'@'%' IDENTIFIED BY 'secure_password';
GRANT SELECT ON sms_c.cdrs TO 'li_readonly'@'%';

-- إنشاء مستخدم محدود بدون الوصول إلى محتوى الرسالة
CREATE USER 'analytics'@'%' IDENTIFIED BY 'secure_password';
GRANT SELECT (id, message_id, calling_number, called_number,
              source_smsc, dest_smsc, submission_time, delivery_time,
              status, delivery_attempts)
ON sms_c.cdrs TO 'analytics'@'%';

2.5 تفاصيل الخوارزميات التشفيرية​

2.5.1 خوارزميات التجزئة​

المتاحة في Erlang/OTP:

  • SHA-256، SHA-384، SHA-512 (موصى بها)
  • SHA-1 (مُهمل، فقط للتوافق مع الأنظمة القديمة)
  • MD5 (مُهمل، لا يُستخدم للأمان)
  • BLAKE2 (متاح في إصدارات OTP الحديثة)

الاستخدام:

  • بصمات الرسائل (كشف التكرار)
  • التحقق من سلامة البيانات
  • سلامة سجل التدقيق

2.5.2 التشفير المتماثل​

الخوارزميات المتاحة:

  • AES (معيار التشفير المتقدم)
    • AES-128-GCM
    • AES-256-GCM
    • AES-128-CBC
    • AES-256-CBC
  • ChaCha20-Poly1305

أحجام المفاتيح:

  • 128 بت (الحد الأدنى)
  • 256 بت (موصى بها)

الاستخدام:

  • تشفير جلسة TLS
  • تشفير قاعدة البيانات في حالة السكون
  • تشفير محتوى الرسالة الاختياري

2.5.3 التشفير غير المتماثل​

الخوارزميات المدعومة:

  • RSA (2048 بت كحد أدنى، 4096 بت موصى بها)
  • ECDSA (خوارزمية التوقيع الرقمي المنحني)
    • P-256، P-384، P-521
  • Ed25519 (EdDSA)

الاستخدام:

  • مصادقة شهادة TLS
  • التوقيعات الرقمية
  • تبادل المفاتيح

2.6 أمان بروتوكول SMS​

2.6.1 ترميز رسالة SMS​

دعم ترميز الأحرف:

  • GSM 7-bit (ترميز SMS القياسي)
  • UCS-2 (يونكود، 16 بت)
  • بيانات ثنائية 8 بت
  • Latin-1

TP-DCS (نظام ترميز البيانات):

  • إشارة فئة الرسالة
  • علامات الضغط
  • مواصفات مجموعة الترميز
  • تحديد مجموعة الأحرف

لا تشفير SMS أصلي:

  • لا يوفر بروتوكول SMS تشفيرًا من النهاية إلى النهاية
  • محتوى الرسالة متاح على مستوى SMSc
  • يمكّن من التنصت القانوني كما هو مطلوب

2.6.2 اعتبارات أمان البروتوكول​

بروتوكول SMPP (واجهة خارجية):

  • مصادقة اسم المستخدم/كلمة المرور على مستوى SMPP
  • دعم TLS متاح (SMPP عبر TLS)
  • مصادقة الربط

بروتوكول IMS (واجهة خارجية):

  • رسائل قائمة على SIP
  • آليات مصادقة SIP
  • التكامل مع أمان الشبكة الأساسية IMS

بروتوكول SS7/MAP (واجهة خارجية):

  • أمان شبكة SS7
  • مصادقة بروتوكول MAP
  • أمان طبقة SCCP/TCAP

ملاحظة: يتم تنفيذ أمان البروتوكول المحدد في بوابات الواجهة الخارجية، وليس في جوهر SMSc.

2.7 قدرات التحليل والتشفير​

2.7.1 أدوات تحليل البروتوكول​

قدرات تصحيح الأخطاء المدمجة:

  • نظام تسجيل شامل
  • تتبع تدفق الرسائل
  • تسجيل طلبات/استجابات API
  • تسجيل استعلامات قاعدة البيانات
  • تتبع الأخطاء والاستثناءات

التكامل الخارجي:

  • إخراج تسجيل قياسي (stdout/ملفات)
  • دعم التقاط PCAP لتحليل الشبكة
  • تسجيل استعلامات قاعدة البيانات للطب الشرعي
  • تصدير مقاييس Prometheus

2.7.2 اعتبارات تقييم الثغرات​

القيود المعروفة:

  • بروتوكول SMS غير مشفر بطبيعته (بشكل متعمد، يمكّن التنصت القانوني)
  • بيانات اعتماد قاعدة البيانات في ملفات التكوين (يجب استخدام إدارة الأسرار)
  • دعم الشهادات الموقعة ذاتيًا (للتطوير/الاختبار فقط)

توصيات تعزيز الأمان:

  • استخدام مجموعات الشفرات TLS القوية
  • تنفيذ تشفير اتصال قاعدة البيانات
  • استخدام إدارة الأسرار الخارجية (Vault، AWS Secrets Manager)
  • تحديثات أمان منتظمة لـ Erlang/OTP والاعتماديات
  • قيود جدار الحماية على منافذ API
  • تصفية IP للوصول إلى الواجهة الأمامية

اختبار الأمان:

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

2.8 بنية إدارة المفاتيح​

2.8.1 توليد المفاتيح​

توليد شهادة TLS:

# توليد مفتاح خاص (RSA 4096 بت)
openssl genrsa -out omnitouch.pem 4096

# توليد طلب توقيع الشهادة
openssl req -new -key omnitouch.pem -out omnitouch.csr

# شهادة موقعة ذاتيًا (للتطوير)
openssl x509 -req -days 365 -in omnitouch.csr -signkey omnitouch.pem -out omnitouch.crt

# الإنتاج: احصل على الشهادة من CA موثوق

توليد الأرقام العشوائية:

  • CSPRNG (مولد الأرقام العشوائية الآمنة تشفيرياً) في Erlang/OTP
  • مجموعة انتباه النظام (/dev/urandom)
  • عشوائية قوية لمفاتيح الجلسة، المعرفات، الرموز

2.8.2 تخزين المفاتيح وحمايتها​

تخزين المفاتيح الخاصة:

  • نظام الملفات مع أذونات مقيدة (0600)
  • مخزنة في دليل priv/cert/
  • تنسيق PEM (يمكن تشفيره اختياريًا)
  • إجراءات النسخ الاحتياطي الآمنة

دوران المفاتيح:

  • إجراءات تجديد شهادة TLS (موصى بها سنويًا)
  • دوران بيانات اعتماد قاعدة البيانات
  • دوران رموز API (إذا تم تنفيذها)

2.8.3 توزيع المفاتيح​

توزيع الشهادات:

  • التثبيت اليدوي في priv/cert/
  • مراجع ملفات التكوين
  • دعم بروتوكول ACME ممكن (Let's Encrypt)

توزيع المفاتيح المتماثلة:

  • تبادل المفاتيح خارج النطاق لبيانات اعتماد قاعدة البيانات
  • اتفاقية مفتاح Diffie-Hellman في TLS
  • لا نقل مفتاح نصي واضح

2.9 الامتثال والمعايير​

امتثال المعايير التشفيرية:

  • NIST SP 800-52: إرشادات TLS
  • NIST SP 800-131A: انتقالات خوارزمية التشفير
  • RFC 7525: توصيات TLS
  • ETSI TS 133 310: أمان الشبكة (لتكامل IMS)

التشريعات الفرنسية المتعلقة بالتشفير:

  • لا تشفير مقيد للتصدير (جميع الخوارزميات القياسية)
  • إعلان وسائل التشفير (إذا كان ذلك مناسبًا)
  • شهادة منتج التشفير ANSSI (إذا لزم الأمر)

2.10 مقاومة التحليل​

2.10.1 مبادئ التصميم​

الدفاع ضد التحليل:

  • لا خوارزميات تشفير مخصصة/ملكية
  • خوارزميات قياسية من الصناعة، تمت مراجعتها من قبل الأقران فقط
  • تحديثات أمان منتظمة لمكتبات التشفير
  • إهمال الخوارزميات الضعيفة
  • استخدام التشفير المعتمد (GCM، Poly1305)

2.10.2 الأمان التشغيلي​

دوران المفاتيح:

  • إجراءات تجديد شهادة TLS
  • دوران مفتاح الجلسة (لكل جلسة لـ TLS)
  • سياسات دوران بيانات اعتماد قاعدة البيانات

المراقبة والكشف:

  • تسجيل محاولات المصادقة الفاشلة
  • مراقبة انتهاء صلاحية الشهادات
  • تسجيل فشل المصافحة TLS
  • الكشف عن الشذوذ في حالات الفشل في التشفير
  • تنبيه الأحداث الأمنية

3. التحكم في التنصت والتفويض​

3.1 التحكم في الوصول للتنصت القانوني​

تفويض إداري:

  • يتطلب الوصول إلى مسؤول النظام للتكوين
  • ضوابط وصول على مستوى قاعدة البيانات لاستعلامات CDR
  • الوصول إلى API مقيد بواسطة IP/المصادقة
  • تسجيل تدقيق لجميع الوصول

تكامل الإطار القانوني:

  • تتبع أوامر التنصت (تكامل النظام الخارجي)
  • قوائم تفويض معرفات الأهداف (وجهات نظر قاعدة البيانات)
  • استعلامات محدودة زمنياً (عبارات WHERE SQL)
  • فرض تلقائي عبر سياسات الوصول

3.2 الاحتفاظ بالبيانات والخصوصية​

سياسات الاحتفاظ:

  • الاحتفاظ بالرسائل النشطة: قابل للتكوين (الافتراضي 24 ساعة في Mnesia)
  • احتفاظ CDR: قابل للتكوين (عادةً 6 أشهر إلى 2 سنوات)
  • أرشفة تلقائية من Mnesia إلى SQL
  • تطهير تلقائي لـ CDRs القديمة (استنادًا إلى cron)

حمايات الخصوصية:

  • خيار حذف محتوى الرسالة بعد التسليم
  • استبعاد محتوى الرسالة من واجهة المستخدم/التصديرات
  • تشفير قاعدة البيانات في حالة السكون
  • تسجيل المراقبة والوصول
  • مبدأ الحد الأدنى من جمع البيانات

التكوين:

# config/runtime.exs
config :sms_c,
  # الاحتفاظ برسالة Mnesia قبل الأرشفة
  message_retention_hours: 24,

  # حذف محتوى الرسالة بعد التسليم من أجل الخصوصية
  delete_message_body_after_delivery: false,  # تعيين true لوضع الخصوصية

  # التحكم في كتابة CDR
  cdr_enabled: true,

  # إعدادات الأرشفة الدفعة
  batch_insert_batch_size: 100,
  batch_insert_flush_interval_ms: 100

📖 انظر CONFIGURATION.md لجميع إعدادات الاحتفاظ

3.3 واجهات التسليم لجهات تنفيذ القانون​

الواجهات القياسية:

1. الوصول عبر REST API:

  • نقاط نهاية HTTPS لاسترجاع الرسائل
  • تبادل البيانات بتنسيق JSON
  • المصادقة والتفويض
  • تصفية الاستعلامات حسب معايير الهدف

2. الوصول المباشر إلى قاعدة البيانات:

  • بيانات اعتماد SQL للقراءة فقط
  • استعلامات SQL قياسية
  • وصول إلى جدول CDR
  • قدرات البحث المفهرسة

3. تصدير الدفعات:

  • تنسيق تصدير CSV
  • تنسيق تصدير JSON
  • تصديرات قائمة على نطاق الوقت
  • اختيار الحقول القابلة للتكوين

تنسيقات التسليم:

IRI (معلومات متعلقة بالتنصت):

  • حقول بيانات CDR:
    • معرف الرسالة
    • أرقام الاتصال/المتصل
    • الطوابع الزمنية (الإرسال، التسليم، انتهاء الصلاحية)
    • الحالة
    • محاولات التسليم
    • معلومات توجيه SMSC
    • معلومات العقدة (تتبع التجمع)

CC (محتوى الاتصال):

  • محتوى الرسالة (محتوى النص)
  • بيانات PDU الخام
  • معلومات الترميز
  • تجميع الرسائل متعددة الأجزاء

مثال تصدير:

# تصدير CSV لتنفيذ القانون
mysql -u li_readonly -p -D sms_c -e "
SELECT
  message_id,
  calling_number,
  called_number,
  message_body,
  submission_time,
  delivery_time,
  status
FROM cdrs
WHERE (calling_number = '+33612345678' OR called_number = '+33612345678')
  AND submission_time BETWEEN '2025-11-01' AND '2025-11-30'
ORDER BY submission_time
" --batch --silent | sed 's/\t/,/g' > interception_report.csv

4. أمان النظام وسلامته​

4.1 أمان التطبيق​

أمان Elixir/Erlang:

  • عزل VM Erlang وتطبيقه
  • عزل العمليات والإشراف
  • استعادة الأعطال والموثوقية
  • عدم وجود ثغرات تجاوز المخزن المؤقت (وقت تشغيل مُدار)

إدارة الاعتماديات:

  • قفل إصدار الاعتماديات (mix.lock)
  • مسح ثغرات الأمان
  • تحديثات الاعتماديات بانتظام
  • الحد الأدنى من بصمة الاعتماديات

4.2 أمان الشبكة​

تعرض الشبكة:

  • الحد الأدنى من المنافذ المكشوفة:
    • 8443 (HTTPS REST API)
    • 8086 (لوحة التحكم HTTPS)
    • 3306/5432 (قاعدة البيانات - يجب أن تكون محمية بجدار ناري)
  • يوصى بتكوين جدار ناري
  • تصفية IP للوصول إلى الواجهة الأمامية
  • نشر DMZ للخدمات المتاحة على الإنترنت

تقسيم الشبكة:

  • شبكة إدارة منفصلة
  • شبكة قاعدة بيانات معزولة
  • فصل شبكة بوابة الواجهة الأمامية
  • شبكة اتصال التجمع (توزيع Erlang)

4.3 المراقبة وكشف التسلل​

قدرات التسجيل:

  • تسجيل تطبيق منظم
  • مستويات تسجيل قابلة للتكوين
  • تدوير السجلات والأرشفة
  • دعم تكامل Syslog
  • تسجيل مركزي (متوافق مع ELK stack)

مراقبة أحداث الأمان:

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

المقاييس والتنبيه:

  • تصدير مقاييس Prometheus
  • مراقبة معدل نقل الرسائل
  • تتبع معدلات الأخطاء
  • استخدام موارد النظام
  • قواعد تنبيه مخصصة

📖 وثائق المراقبة الكاملة في OPERATIONS_GUIDE.md و METRICS.md

4.4 التوافر العالي واستعادة الكوارث​

دعم التجمع:

  • قدرة التجمع الموزع Erlang
  • تكرار Mnesia عبر العقد
  • الفشل التلقائي
  • اكتشاف العقد والانضمام

ازدواجية البيانات:

  • نسخ Mnesia على جميع عقد التجمع
  • تكرار قاعدة بيانات SQL (MySQL/PostgreSQL الأصلية)
  • إجراءات النسخ الاحتياطي لـ CDR
  • النسخ الاحتياطي للتكوين

إجراءات الاستعادة:

  • النسخ الاحتياطي واستعادة قاعدة البيانات
  • استعادة جدول Mnesia
  • استعادة التكوين
  • إجراءات استبدال العقد

5. مراجع الوثائق​

5.1 الأدلة الفنية​

التوثيق المتاح في مستودع المشروع:

5.2 الشهادات الأمنية​

  • تقارير اختبار الاختراق: [سيتم توفيرها عند الطلب]
  • تقارير تدقيق الأمان: [سيتم توفيرها عند الطلب]
  • تقييمات الثغرات: [سيتم توفيرها عند الطلب]
  • التحقق من تشفير Erlang/OTP: مكتبة تشفير قياسية في الصناعة

5.3 وثائق الامتثال​

  • طلب ترخيص ANSSI R226: هذه الوثيقة
  • امتثال التنصت القانوني: كما هو مطلوب بموجب تنظيمات الاتصالات الفرنسية
  • امتثال حماية البيانات: اعتبارات GDPR لبيانات الرسائل

6. معلومات الاتصال​

معلومات البائع/المشغل:

  • اسم الشركة: Omnitouch Network Services Pty Ltd
  • العنوان: PO BOX 296, QUINNS ROCKS WA 6030, AUSTRALIA
  • الشخص المسؤول: فريق الامتثال
  • البريد الإلكتروني: compliance@omnitouch.com.au

جهة الاتصال الفنية للأمان:

جهة الاتصال القانونية/الامتثال:

الملاحق​