SMPP نفسه غير مشفَّر — يعبر system_id وpassword الخاصان بالـ bind على السلك بشكل صريح فوق TCP العادي. وفي الإنتاج تؤمّنه بتشغيل SMPP عبر TLS (بتغليف جلسة TCP)، وبالمصادقة ببيانات الاعتماد مع قوائم IP المسموحة، وبفرض TLS 1.2 فما فوق، وبتدوير بيانات الاعتماد من مدير أسرار بدل ترميزها صراحةً.
bind_transceiverفتح الجلسة والمصادقة عليهاbind_transceiver_respتم قبول الجلسةsubmit_smإرسال رسالةsubmit_sm_respتم القبول، وإعادة معرف الرسالةdeliver_smإيصال استلام أو رسالة واردةdeliver_sm_respتم التأكيدenquire_linkإشارة Keepalive أثناء الخمول
لماذا يمثّل SMPP الصريح خطرًا
لا تحدّد مواصفة SMPP أي أمان للنقل. فعلى ربط TCP صريح (منفذ 2775)، يعبر system_id وpassword في bind_transmitter/receiver/transceiver، وكل جسم رسالة، دون تشفير. وعلى أي مسار غير موثوق يعرّض ذلك بيانات الاعتماد للاعتراض والحركة للتنصّت. لذا يُضاف الأمان عند طبقة النقل، لا بواسطة البروتوكول.
SMPP عبر TLS
الضابط المعياري هو تشغيل جلسة SMPP داخل نفق TLS: يُكمِل اتصال TCP مصافحة TLS قبل إرسال وحدة bind، فتُشفَّر بيانات الاعتماد والحمولات من الطرف إلى الطرف. ولا يوجد منفذ TLS واحد لدى IANA لـ SMPP، لذا يوفّر المزوّدون منفذًا مخصّصًا مفعّلًا بـ TLS. افرض TLS 1.2 فما فوق، وتحقّق من سلسلة شهادة الخادم، وارفض الشهادات المنتهية أو الموقّعة ذاتيًا، ولا تعطّل التحقق أبدًا لجعلها تعمل.
| الجانب | SMPP بسيط | SMPP over TLS |
|---|---|---|
| النقل | TCP (المنفذ الافتراضي 2775) | TCP + TLS (منفذ يهيّئه المزوّد) |
| بيانات الاعتماد على السلك | نص مجرد | مشفر |
| نصوص الرسائل | نص مجرد | مشفر |
| هوية الخادم | غير موثق | تم التحقق من الشهادة |
المصادقة وقوائم IP المسموحة
يصادِق SMPP بزوج system_id/password في الـ bind. وهذا ضعيف وحده، لذا يضيف المشغّلون قوائم IP المسموحة فوقه: تُسمَح فقط لعناوين IP المصدر المسجَّلة مسبقًا بفتح ربط، على الطرفين. وقوائم السماح ضابط تشغيلي معياري وطريقة سريعة لاحتواء بيانات اعتماد مسرَّبة — فكلمة مرور مسروقة عديمة الجدوى من IP غير مدرَج. اجمعها مع TLS لا كبديل عنه.
نظافة بيانات الاعتماد
عامِل بيانات اعتماد SMPP كأي سرّ آخر. خزّنها في مدير أسرار، لا في الكود المصدري أو إعداد مُودَع في مستودع. ودوّرها بجدول زمني وفورًا عند أي اشتباه بتسريب. استخدم بيانات اعتماد متمايزة لكل بيئة ولكل تكامل كي يكون لأي تسريب نطاق أثر محدود، وراقِب عمليات الربط من عناوين IP غير متوقعة أو في أوقات غير متوقعة.
الأسئلة المتكررة
هل SMPP مشفَّر افتراضيًا؟
لا. لا يملك SMPP تشفيرًا مدمجًا — فوق TCP الصريح تُرسَل بيانات الاعتماد وأجسام الرسائل بشكل صريح. ويُضاف التشفير بتشغيل جلسة SMPP عبر TLS، وهو ما لا يحدّده البروتوكول لكن يدعمه كل مزوّد جادّ.
ما منفذ SMPP عبر TLS؟
لا يوجد منفذ TLS معياري واحد. يستخدم SMPP الصريح منفذ IANA رقم 2775؛ ولـ TLS يوفّر المزوّدون منفذًا منفصلًا مزوَّدًا (يُستخدم 3550 أحيانًا). استخدم أي منفذ TLS يسنده إليك مزوّدك.
هل تكفي قوائم IP المسموحة وحدها؟
لا. تحدّ قوائم IP المسموحة من يمكنه الاتصال وتحتوي بيانات الاعتماد المسرَّبة، لكنها لا تشفّر الحركة. اجمع قوائم السماح مع SMPP عبر TLS كي يُحمى أصل الاتصال وسرية البيانات معًا.
كيف ينبغي أن أخزّن بيانات اعتماد SMPP؟
في مدير أسرار، لا في الكود أو إعداد مُودَع. استخدم بيانات اعتماد منفصلة لكل بيئة وتكامل، ودوّرها بجدول زمني وعند أي اشتباه بتسريب، وراقِب عمليات الربط من عناوين IP غير متوقعة.
مواصفات المصدر
تستند هذه الصفحة إلى المعايير المنشورة. يفتح في علامة تبويب جديدة.