متطلبات سيرفر نظام إدارة الزوار On-Premise: ما الذي تجهزه تقنية المعلومات

من يحدد ماذا: المورد أم سياسة منشأتك؟

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

القاعدة التي تمنع ذلك بسيطة: البنود التقنية التي تتعلق بتشغيل البرنامج نفسه يحددها المورد في وثيقة المتطلبات، والبنود التي تتعلق بالمخاطر والسياسة تقررها المنشأة وتبلغها للمورد قبل أن يكتب الوثيقة. صفحة نظام زوار On-Premise تلخص هذا التقسيم: تتولى المنشأة البنية التحتية والنسخ الاحتياطي وسياسات الشبكة، ويتولى فريق المورد التثبيت والتحديث والدعم بالتنسيق معها.

إن لم تحسم بعد أن التشغيل الداخلي هو الخيار المناسب لمنشأتك، فابدأ بمقالة لماذا تختار بعض المنشآت تشغيل نظام الزوار على خوادمها، ثم عد إلى هذه القائمة بعد القرار.

مكونات التشغيل: ماذا سيُثبت على خوادمك؟

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

هذه المكونات مذكورة في صفحة التشغيل الداخلي، وتفاصيلها الدقيقة (عدد الخوادم، وأنظمة التشغيل، ونوع قاعدة البيانات، والمنافذ) تأتي في وثيقة المتطلبات التفصيلية التي يرسلها المورد بعد معرفة الحجم. لا تقبل أرقامًا عامة قبل أن يعرف المورد عدد مواقعك ومستخدميك وزياراتك؛ الرقم الذي يُعطى دون هذه المدخلات تقدير لا متطلب.

متطلبات سيرفر نظام الزوار: مدخلات تحديد السعة

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

كيف تقدّر تخزين المرفقات بنفسك

تقدير التخزين هو البند الوحيد الذي تستطيع حسابه بدقة معقولة قبل وثيقة المورد، وهو مفيد لفريق البنية لأنه يحدد حجم النسخ الاحتياطي أيضًا.

مثال افتراضي للتوضيح منشأة تسجل 500 زيارة يوميًا في المتوسط، يُرفع مع كل زيارة جديدة ملفان بمتوسط 400 كيلوبايت للملف، والزوار المتكررون لا يعيدون الرفع فتُحسب الزيارات الجديدة فقط بنحو 200 زيارة يوميًا. تعمل المنشأة 300 يوم في السنة، وتحتفظ بصور الهويات سنتين.

• الإضافة اليومية = 200 زيارة × 2 ملف × 400 كيلوبايت = 160 ميغابايت تقريبًا.
• الإضافة السنوية = 160 ميغابايت × 300 يوم = 48 غيغابايت تقريبًا.
• الحجم عند ثبات مدة الاحتفاظ (سنتان) = 96 غيغابايت تقريبًا، قبل النسخ الاحتياطي ونسخه المتعددة.

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

قاعدة البيانات والتخزين: قرارات تسبق التثبيت

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

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

الشبكة والمنافذ والشهادات: من يصل إلى الخادم ومن أين

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

السؤال الذي يغير التصميم: هل يصل الزائر إلى النظام من خارج الشبكة؟

التسجيل المسبق يعمل برابط يفتحه الزائر في متصفح جواله قبل وصوله. في النشر السحابي هذا بديهي. أما في التشغيل الداخلي فالقاعدة أن لا اتصال خارجي إلا بما تسمح به المنشأة، ولذلك يجب أن يُتخذ قرار صريح: هل تُتاح بوابة الزائر من الإنترنت بترتيب تصممه مع فريقك الأمني، أم يُكتفى بإكمال البيانات عند الوصول عبر الاستقبال أو جهاز الاستقبال الذاتي؟ للخيارين أثر مباشر على رحلة الزائر وعلى مستوى المخاطر، وتفاصيل التنفيذ تُحسم في التقييم الفني لا في هذه القائمة. ما يهمك الآن ألا يُكتشف السؤال بعد التثبيت.

الشهادة والنطاق الداخلي

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

الهوية والأجهزة الطرفية والإشعارات

ربط الهوية

إن كانت لديك خدمة دليل نشط أو مزود هوية، فالربط يوفر مزامنة الموظفين والإدارات، والدخول بحساب المنشأة، وربط المجموعات بالأدوار، والإيقاف الآلي عند تعطيل حساب الموظف، كما في صفحة Active Directory وSSO. جهّز حساب خدمة للمزامنة بصلاحية قراءة، وحدد المجموعات التي تقابل الأدوار. وتذكر الحراس الذين لا يملكون حسابات في الدليل: تُنشأ لهم حسابات محلية بصلاحيات محدودة، وسياسة كلمات مرورها قرار منشأتك.

الأجهزة عند البوابات

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

الإشعارات دون اتصال خارجي

الإشعارات داخل النظام والبريد الداخلي تعمل داخل الشبكة. أما SMS وWhatsApp فتحتاج بوابة إرسال تسمح بها المنشأة، وحساب مزود رسائل باسم مرسل معتمد، أو حساب أعمال وقوالب موافقًا عليها، والمنشأة تتحمل رسوم الرسائل. إن كانت سياستك تمنع أي اتصال خارجي فخطط لدعوات الزوار عبر بريدك المؤسسي، واقبل أن الزائر قد لا يقرأ البريد قبل وصوله. تفاصيل التشغيل الكامل داخل الشبكة في مقالة تشغيل نظام الزوار داخل شبكة المنشأة دون اتصال بالإنترنت.

النسخ الاحتياطي والاستعادة والمراقبة

في التشغيل الداخلي، النسخ الاحتياطي مسؤولية فريق المنشأة. النظام يدعم النسخ الدوري مع اختبار الاستعادة، لكن الجدولة والوسائط ومكان حفظ النسخ قرارات تُتخذ وفق سياسة منشأتك. وإن كانت جهتك ضمن نطاق الضوابط الأساسية للأمن السيبراني ECC-2:2024 الصادرة من الهيئة الوطنية للأمن السيبراني، فسيطبق فريقك الأمني متطلباتها على هذا الخادم كما يطبقها على غيره؛ دور المورد أن يقدم المعلومات الفنية التي يحتاجها هذا التقييم، وتقييم الامتثال يبقى مسؤولية المنشأة.

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

في مراقبة التكاملات تحديدًا، اطلب من المورد أن يوضح أين تظهر الأخطاء. إن كانت أنظمتك تستقبل أحداثًا من النظام، فصفحة REST API وWebhooks تذكر إعادة إرسال الأحداث عند فشل الاستلام مع سجل بمحاولات الإرسال؛ اربط هذا السجل بأدوات المراقبة لديك بدل أن تكتشف الفشل من شكوى موظف.

التحديثات ووصول فريق الدعم

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

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

قائمة التجهيز قبل يوم التثبيت

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

لاحظ أن «دليل الجاهزية» في كل بند فعل يمكن مشاهدته لا عبارة «تم». هذه القائمة تكمّل متطلبات الأمن التي يطرحها فريقك على المورد؛ أسئلة ذلك التقييم مفصلة في مقالة تقييم أمن مورد نظام الزوار.

سيناريو: مجموعة طبية بمستشفيين وشبكة واحدة

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

بدأ مدير تقنية المعلومات بطلب «خادمين» من المورد، ثم أعاد ترتيب الطلب بالقائمة السابقة، فظهرت أربعة قرارات لم يكن أحد قد اتخذها:

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

النتيجة أن وثيقة المتطلبات التي وصلت من المورد طابقت قرارات المجموعة بدل أن تفرض افتراضاته، وأن يوم التثبيت لم يتوقف عند منفذ مغلق. ولمنشآت بهذه الطبيعة، صفحة نظام زوار المستشفيات تجمع ما يخص أوقات الزيارة والأقسام المقيدة والمرافقين.

أخطاء تؤخر التثبيت الداخلي

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

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

الأسئلة الشائعة

الخلاصة: جهّز القرارات قبل الخوادم

الخوادم أسهل ما في التشغيل الداخلي؛ ما يؤخره هو القرارات التي لم تُتخذ: من يصل إلى النظام من خارج الشبكة، وكم تحتفظ بصور الهويات، ومن ينسخ ومن يستعيد، وكيف يدخل فريق الدعم. احسم هذه القرارات مع الأمن السيبراني والإدارة، واجمع مدخلات الحجم، ثم اطلب وثيقة المتطلبات واطابقها بقائمة الجاهزية أعلاه.

إن كانت منشأتك جهة حكومية، فمقالة نظام زوار On-Premise للجهات الحكومية تضيف ما يخص البنية والتشغيل في هذا السياق. وإن أردت أن ترى كيف يعمل نظام إدارة زوار المنشآت على خوادمك، أرسل حجم مواقعك وبواباتك ومستخدميك من صفحة طلب عرض السعر لتصلك وثيقة متطلبات تفصيلية مبنية عليها.