العودة إلى المقالات

بوابة موظفين وبوت خدمة عملاء: متطلبات الاستضافة والأمان

استضافة بوابة موظفين وبوت خدمة عملاء: الأمان والفصل | مرام هوست - بوابة موظفين وبوت خدمة عملاء: متطلبات الاستضافة والأمان

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

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

طبيعتان مختلفتان

المعياربوابة الموظفينبوت خدمة العملاء
من يصل إليهاموظفون معروفون فقطأي شخص
مصدر الاتصالالشركة أو VPNخوادم منصة المراسلة عبر Webhook
نمط الحملقمة في بداية الدوام ونهاية الشهرمتغيّر حسب الحملات والأوقات
أخطر ما يمكن أن يحدثتسرّب بيانات موظفينإساءة استخدام أو إغراق بالرسائل
أهم حمايةتحقق ثنائي وعدم الظهور للعمومتحقق من مصدر الرسالة وتحديد المعدّل

افصل الخدمتين على مستوى الشبكة

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

في مثال افتراضي بثلاثة أجهزة على شبكة داخلية:

bot-01     10.0.0.11   منفذ 443 للعموم، ومنفذ الـAPI الداخلي صادر فقط
portal-01  10.0.0.12   منفذ 443 من شبكة VPN فقط
db-01      10.0.0.13   منفذ 5432 من portal-01 فقط، بلا عنوان عام
مخطط فصل البوت العام عن بوابة الموظفين الخاصة وقاعدة البيانات
لاحظ أن السهم من البوت يقف عند واجهة محدودة، ولا يوجد أي مسار مباشر منه إلى قاعدة البيانات.

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

# على db-01: لا يصل إلى القاعدة إلا سيرفر البوابة
ufw default deny incoming
ufw allow from 10.0.0.12 to any port 5432 proto tcp
ufw allow from 10.0.0.0/24 to any port 22 proto tcp
ufw enable
نافذة إضافة قاعدة جدار ناري في بروكسموكس
في نافذة Add: Rule حدّد الاتجاه والإجراء والمصدر والوجهة والمنفذ. وانتبه إلى خانة Enable: فهي غير مفعّلة هنا، والقاعدة لا تعمل قبل تفعيلها.

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

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

أمان بوابة الموظفين

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

ومن حيث الموارد، البوابة خفيفة في أغلب الأوقات، لكن قمتها معروفة مسبقاً: بداية الدوام ونهاية الشهر. قِس استهلاكها في هذه الأوقات تحديداً، ولا تبنِ حساباتك على متوسط اليوم، فالمتوسط يخفي اللحظة التي يشتكي فيها الموظفون.

أمان البوت

البوت يستقبل نصاً من غرباء، فعامل كل رسالة كمدخل غير موثوق:

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

إن كان البوت يعتمد على نموذج ذكاء اصطناعي

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

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

الموارد: زمن الشبكة في العراق بين 70 و150ms، بينما يتراوح توليد الصفحة من 150ms إلى أكثر من ثانيتين حسب العتاد. المسافة تكلّف عشرات الملّي ثانية والعتاد الضعيف يكلّف آلافاً، فاسأل عن المعالج والتخزين لا عن المدينة وحدها.

لمن تناسب هذه الخدمة؟

  • شركات متوسطة تريد نقل طلبات الموظفين من الورق إلى نظام داخلي.
  • جهات خدمية تستقبل أسئلة عملاء متكررة وتريد ردوداً أولية آلية.
  • فرق برمجة تبني هذه الأنظمة لعملائها وتريد بنية جاهزة.
  • شركات بلا مدير أنظمة متفرغ، ويناسبها VPS مُدار بدل إدارة كل شيء بنفسها.

أخطاء شائعة

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

أسئلة شائعة

هل يجب وضع الخدمتين على سيرفرين منفصلين؟

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

هل يعمل الـWebhook إن كانت البوابة خلف VPN؟

البوت هو ما يحتاج عنواناً عاماً لا البوابة. لذلك يبقى البوت في الجهة العامة، والبوابة في الجهة الخاصة، وبينهما الواجهة الداخلية فقط.

ماذا لو احتاج موظف ميداني إلى البوابة؟

أضف جهازه إلى النفق بمفتاح خاص به، فتطبيق WireGuard يعمل على الهواتف. هذا أفضل من فتح البوابة للجميع من أجل حالات قليلة.

الخطوة التالية

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

Powered by WHMCompleteSolution