- أمن أنظمة إدارة العيادات لا يُقيَّم بسؤال «هل النظام آمن؟»، بل بعشرين ضابطًا محددًا تطلب لكل منها دليلًا: وثيقة، أو تنفيذًا أمامك في بيئة التجربة، أو تقريرًا يثبت أن الضابط يعمل باستمرار.
- وزّع الضوابط على خمس مجموعات: الهوية والدخول، والصلاحيات، والبيانات، والتشغيل، والاستمرارية. كل مجموعة تلتقط ما تفلت منه المجموعة التي قبلها.
- اجعل سبعة ضوابط بوابات لا تعوضها الدرجة الكلية: الحساب الفردي، وMFA، والصلاحيات حسب الدور، والتشفير أثناء التخزين، وسجل تدقيق يسجل الاطلاع، واختبار الاستعادة، وتصدير بياناتك عند الخروج.
- ما يثبت في التقييم يُكتب في ملحق العقد: أهداف الاستعادة، ومهلة إبلاغك بالحوادث، ومن يصل إلى بياناتك، وكيف تسترجعها كاملة.
هذه المقالة موجهة لمدير تقنية المعلومات أو مسؤول أمن المعلومات الذي طُلب منه أن يوافق على نظام عيادات قبل التعاقد. تعطيك قائمة الضوابط العشرين، والدليل الذي تطلبه لكل ضابط، وسؤال التحقق أو الاختبار الذي يكشف الإجابة الشكلية، وطريقة تحويل النتائج إلى قرار وبنود تعاقدية.
لماذا لا تكفي «نعم» في استبيان الأمن؟
كثير من الموردين يجيبون عن استبيانات الأمن بكلمة «نعم» في كل سطر. المشكلة أن «نعم» قد تعني أن الميزة موجودة لكنها معطلة افتراضيًا، أو أنها تغطي الواجهة ولا تغطي التكاملات، أو أنها مكتوبة في سياسة لم تُطبق. لذلك قيّم كل ضابط بقوة دليله، لا بوجوده:
| درجة الدليل | ما تحصل عليه | ما يثبته فعلًا |
|---|---|---|
| 0: قول | إجابة «نعم» أو جملة في عرض تقديمي | لا شيء قابل للتحقق |
| 1: وثيقة | سياسة، أو وصف فني، أو مصفوفة صلاحيات مكتوبة | أن المورد صمم الضابط وفكّر فيه |
| 2: تنفيذ أمامك | تجربة الضابط بنفسك في بيئة التجربة | أن الضابط موجود ويعمل كما وُصف |
| 3: سجل مستمر | تقرير آخر اختبار استعادة، أو نتائج فحص ثغرات مع معالجتها، أو سجل تدقيق فعلي | أن الضابط يعمل باستمرار، لا يوم العرض فقط |
بعض الضوابط لا يمكن تجربتها في جلسة، مثل النسخ الاحتياطي والتعافي من الكوارث؛ دليلها الأقوى تقرير موثق بتاريخ. وبعضها لا يثبت إلا بالتجربة، مثل نطاق الصلاحيات؛ فالوثيقة وحدها لا تكفي. الجداول التالية تحدد لكل ضابط الدليل الأقوى المعقول وسؤال التحقق.
- 1. الهوية والدخول (الضوابط 1–4)من يدخل النظام؟ حساب فردي، وتحقق ثنائي، وسياسة كلمات مرور، وجلسات مضبوطة.
- 2. الصلاحيات (الضوابط 5–8)إن دخل، ماذا يرى ويفعل؟ أدوار، ونطاق بيانات، ووصول طارئ مسجل، ومراجعة دورية للحسابات.
- 3. البيانات (الضوابط 9–12)إن تجاوز أحد الصلاحيات أو سُرقت نسخة، هل تُقرأ البيانات؟ تشفير، ومفاتيح، وموقع، وضبط للتصدير.
- 4. التشغيل (الضوابط 13–16)هل نعرف ما حدث ونكتشفه مبكرًا؟ سجل تدقيق، ومراقبة، وإدارة ثغرات، وفصل بيئات.
- 5. الاستمرارية (الضوابط 17–20)إن وقع الضرر، كم نخسر ومتى نعود؟ نسخ، واستعادة مختبرة، وأهداف في العقد، واستجابة للحوادث.
المجموعة الأولى: ضوابط الهوية والدخول
كثير من حوادث الأنظمة الطبية يبدأ من هنا: حساب مشترك في الاستقبال، أو كلمة مرور مكتوبة على ورقة، أو جهاز بقي مفتوحًا على ملف مريض. هذه الضوابط الأربعة تجيب عن سؤال واحد: هل نعرف يقينًا من يعمل على النظام في هذه اللحظة؟
| الضابط | ما تطلبه بالضبط | الدليل الأقوى | سؤال التحقق أو الاختبار |
|---|---|---|---|
| 1. حساب فردي لكل مستخدم | لا حسابات مشتركة، بما فيها حسابات فريق الدعم لدى المورد وحسابات التكامل | تنفيذ أمامك + قائمة الحسابات الفنية | «أرونا قائمة كل الحسابات في بيئتنا، ومنها حسابات فريقكم. هل يوجد حساب لا يرتبط بشخص أو نظام محدد؟» |
| 2. التحقق الثنائي MFA | قابل للإلزام لكل المستخدمين أو لأدوار محددة، وإلزامي لحسابات الإدارة والدخول من خارج الشبكة | تنفيذ أمامك | فعّل الإلزام لدور «مدير النظام» ثم ادخل به. هل يمكن تجاوز الخطوة الثانية من أي مسار آخر، مثل تطبيق الجوال أو API؟ |
| 3. سياسة كلمات المرور وقفل الحساب | طول وتعقيد، ومنع إعادة الاستخدام، وقفل بعد محاولات فاشلة، وإعادة تعيين آمنة | وثيقة الإعدادات + تنفيذ | أدخل كلمة مرور خاطئة عدة مرات. هل قُفل الحساب؟ ومن يفتحه؟ وهل ظهرت المحاولات في السجل؟ |
| 4. إدارة الجلسات وتقييد الدخول | إنهاء الجلسة بعد خمول تحدده المنشأة، وحد للجلسات المتزامنة، وإنهاء عن بُعد، وتقييد بالشبكة أو أوقات الدوام عند الحاجة | تنفيذ أمامك | افتح الحساب نفسه من جهازين. ماذا يحدث؟ وهل يستطيع المسؤول إنهاء جلسة موظف غادر وجهازه ما زال مفتوحًا؟ |
انتبه لسؤال الأجهزة المشتركة في الاستقبال وغرف الكشف: التحقق الثنائي عند كل دخول قد يعطل الطبيب بين مريضين، والحل في سياسة تميّز بين الدخول من شبكة المنشأة ومن خارجها، وبين الأدوار. تفصّل مقالة التحقق الثنائي وسياسات الدخول دون تعطيل الطبيب هذه الموازنة.
المجموعة الثانية: ضوابط الصلاحيات ونطاق البيانات
الدخول الصحيح لا يعني الاطلاع الصحيح. موظف الاستقبال يدخل بحسابه وبالتحقق الثنائي، ثم يفتح التشخيص لأن النظام لا يمنعه. هنا يقاس نضج النظام بدقة الصلاحية: على مستوى الإجراء، وعلى مستوى البيانات.
| الضابط | ما تطلبه بالضبط | الدليل الأقوى | سؤال التحقق أو الاختبار |
|---|---|---|---|
| 5. صلاحيات حسب الدور RBAC على مستوى الإجراء | فصل العرض عن التعديل والاعتماد والطباعة والتصدير في كل شاشة، لا «مدير أو مستخدم» | مصفوفة الأدوار الافتراضية + تنفيذ | أنشئ دورًا يرى الفواتير ويطبعها ولا يعدلها ولا يصدّرها، ثم جرّبه. |
| 6. نطاق البيانات وإخفاء الحقول | تقييد حسب الفرع والقسم والمريض، وإخفاء حقول حساسة مثل الملاحظات النفسية عن أدوار بعينها | تنفيذ أمامك | ادخل بحساب طبيب في الفرع الأول وابحث عن مريض يُعالج في الفرع الثاني فقط. ماذا يظهر؟ |
| 7. الوصول الطارئ المسجل | فتح ملف خارج النطاق عند الضرورة بسبب مكتوب، مع تنبيه للمسؤول وتسجيل خاص | تنفيذ + مثال على التنبيه | نفّذ وصولًا طارئًا. من وصله التنبيه؟ وأين يظهر السبب في السجل؟ |
| 8. دورة حياة الحساب ومراجعته | صلاحية مؤقتة تنتهي تلقائيًا، وإيقاف فوري عند ترك العمل مع بقاء السجل، وتقرير دوري بمن يملك أي صلاحية وآخر دخول له | تقرير المراجعة الدوري + تنفيذ | اطلب تقرير «الحسابات التي لم تدخل منذ 60 يومًا». هل يخرج من النظام مباشرة أم يُطلب من الدعم؟ |
الضابط الثامن هو الأكثر إهمالًا: الصلاحيات تُضبط جيدًا يوم الإطلاق، ثم تتراكم مع التنقلات والتكليفات المؤقتة حتى يملك نصف الموظفين صلاحيات لا يحتاجونها. تصميم الأدوار من الصفر موضوع مقالة مصفوفة الأدوار والصلاحيات في المركز الطبي، وترى في صفحة المستخدمين والصلاحيات كيف يعمل نطاق البيانات في المنصة.
المجموعة الثالثة: ضوابط حماية البيانات نفسها
هذه الضوابط تفترض أن الطبقتين السابقتين قد تفشلان: نسخة احتياطية خرجت، أو قرص سُرق، أو اتصال اعتُرض. السؤال هنا: هل تبقى البيانات غير مقروءة، وهل تعرف أين هي ومن يصل إليها؟
| الضابط | ما تطلبه بالضبط | الدليل الأقوى | سؤال التحقق أو الاختبار |
|---|---|---|---|
| 9. التشفير أثناء النقل | TLS لكل اتصال: بين المستخدم والنظام، وبين النظام والأنظمة المتكاملة، وتطبيق الجوال وبوابة المريض | وثيقة البنية + فحص الشهادة بنفسك | «هل تمر أي تكاملات، مثل أجهزة المختبر أو الربط المحاسبي، باتصال غير مشفر داخل الشبكة؟ وكيف تُحمى؟» |
| 10. التشفير أثناء التخزين وإدارة المفاتيح | تشفير قاعدة البيانات والملفات المرفقة والنسخ الاحتياطية، ومفاتيح تُدار بمعزل عن البيانات | وثيقة فنية تذكر النطاق وطريقة إدارة المفاتيح | «هل النسخ الاحتياطية والمرفقات مشمولة بالتشفير؟ ومن يستطيع الوصول إلى المفاتيح؟» |
| 11. موقع البيانات ووصول المورد إليها | تحديد مكان الاستضافة ومزودها، ووصول فريق الدعم إلى بياناتك بإذن المنشأة ومسجل في السجل | تفاصيل الاستضافة مكتوبة + سطر من السجل لوصول دعم فعلي | «أين تُخزن البيانات والنسخ؟ ومن في فريقكم يستطيع رؤية بيانات المرضى، وبأي إجراء؟» |
| 12. ضبط التصدير وحق استرجاع البيانات | تقييد التصدير والطباعة بالصلاحية وتسجيلهما، وتصدير كامل لبيانات المنشأة بصيغ مقروءة عند طلبها أو عند انتهاء العقد | نموذج ملف تصدير + بند في العقد | «اعرضوا تصديرًا كاملًا لبيانات مريض تجريبي. وما الصيغة والمدة عند إنهاء العقد؟» |
البيانات الصحية من البيانات الحساسة في نظام حماية البيانات الشخصية كما تنشره الهيئة السعودية للبيانات والذكاء الاصطناعي (سدايا). والنظام يُلزم جهة التحكم، وهي منشأتك هنا، باختيار معالج يوفر الضمانات اللازمة لتنفيذ أحكامه، دون أن يعفيها ذلك من مسؤوليتها تجاه أصحاب البيانات. أي أن طلب الدليل من المورد جزء من واجب المنشأة، لا تشددًا منها. لذلك الضابط الحادي عشر ليس تفصيلًا فنيًا، بل جزء من قدرتك على الإجابة عن سؤال «من اطلع على بيانات مرضانا؟». ما يتحمله المركز بموجب النظام تشرحه مقالة حماية البيانات الصحية في المنشأة، ومسألة الاستضافة داخل المملكة تتناولها مقالة استضافة الأنظمة الطبية داخل السعودية.
المجموعة الرابعة: ضوابط التشغيل والرقابة
النظام الآمن اليوم قد لا يبقى آمنًا بعد ستة أشهر من التحديثات والتكاملات والموظفين الجدد. ضوابط التشغيل تقيس هل يعرف المورد والمنشأة ما يحدث في النظام، وهل تُعالج الثغرات قبل أن تُستغل.
| الضابط | ما تطلبه بالضبط | الدليل الأقوى | سؤال التحقق أو الاختبار |
|---|---|---|---|
| 13. سجل تدقيق يسجل الاطلاع لا التعديل فقط | كل دخول واطلاع وتعديل وإلغاء وتصدير، بالقيم قبل وبعد، في سجل لا يعدله أحد حتى مدير النظام | تنفيذ أمامك | افتح ملف مريض دون تعديل، ثم ابحث في السجل باسمه. هل ظهر الاطلاع؟ ثم اطلب من مدير النظام حذف السطر. |
| 14. المراقبة والتنبيه | تنبيهات لمحاولات الدخول الفاشلة، والدخول خارج الدوام، والاطلاع غير المعتاد، والتصدير الكبير، وإمكانية إرسال السجلات إلى نظام SIEM | تنفيذ + قائمة قواعد التنبيه | «ما القواعد المفعلة افتراضيًا؟ ومن يستلم التنبيه: فريقكم أم فريقنا؟» |
| 15. إدارة الثغرات والتحديثات | فحص دوري للثغرات، واختبار اختراق، وجدول لمعالجة النتائج حسب خطورتها، وتحديثات أمنية منتظمة | ملخص آخر اختبار اختراق ومعالجة نتائجه | «متى كان آخر اختبار اختراق؟ ومن نفذه؟ وكم استغرق إغلاق الثغرات عالية الخطورة؟» |
| 16. فصل البيئات وإدارة التغيير | بيئة إنتاج منفصلة عن الاختبار، وعدم استخدام بيانات مرضى حقيقية في الاختبار، وتحديثات تُجرّب قبل نقلها | وثيقة مسار التحديث + بيئة الاختبار الخاصة بكم | «كيف تصلنا التحديثات؟ وهل نستطيع تجربتها في بيئة الاختبار قبل الإنتاج؟» |
في الضابط الثالث عشر يكمن أكثر الاختبارات كشفًا في التقييم كله: بعض الأنظمة يسجل التعديل ولا يسجل الاطلاع، فلا تستطيع المنشأة الإجابة عن شكوى مريض بأن أحدًا اطلع على ملفه. راجع عناصر كل سطر في سجل التدقيق لترى ما يُفترض أن يحفظه السجل، ومقالة التحقيق في اطلاع غير مبرر على ملف مريض لترى كيف يُستخدم.
المجموعة الخامسة: ضوابط الاستمرارية والاستجابة للحوادث
المركز الطبي لا يستطيع إيقاف الاستقبال حتى يعود النظام. هذه الضوابط تحدد كم بيانات قد تفقد، وكم ساعة قد تعمل دون النظام، ومن يخبرك حين يقع حادث.
| الضابط | ما تطلبه بالضبط | الدليل الأقوى | سؤال التحقق أو الاختبار |
|---|---|---|---|
| 17. النسخ الاحتياطي | نسخ تلقائية مجدولة ومشفرة، ونسخة في موقع منفصل، ومدة احتفاظ تحددها المنشأة | سياسة النسخ مكتوبة بالتكرار والموقع والمدة | «كم مرة يُنسخ النظام يوميًا؟ وأين النسخة المنفصلة؟ وهل تتأثر بما يصيب البيئة الأساسية؟» |
| 18. اختبار الاستعادة الموثق | استعادة فعلية دورية بتاريخ ومدة ونتيجة، لا مجرد وجود نسخة | تقرير آخر اختبار استعادة | «متى استعدتم آخر مرة نسخة كاملة؟ كم استغرقت؟ وما الذي لم يعمل؟» |
| 19. أهداف RPO وRTO وخطة التعافي | نقطة الاستعادة (أقصى فقد مقبول للبيانات) وزمن الاستعادة (أقصى مدة توقف) مكتوبة، وبيئة احتياطية أو إجراء بديل | خطة التعافي من الكوارث + الأهداف في العقد | «ما RPO وRTO لخيار النشر الذي نناقشه؟ وهل هما في العقد أم في العرض فقط؟» |
| 20. الاستجابة للحوادث وإبلاغ المنشأة | إجراء مكتوب لاكتشاف الحادث واحتوائه، ومهلة محددة بالساعات لإبلاغ المنشأة، وتقرير بعد الحادث | إجراء الاستجابة + بند المهلة في العقد | «لو اكتشفتم وصولًا غير مصرح به إلى بياناتنا، متى نعلم؟ وماذا يحتوي أول بلاغ؟» |
مهلة إبلاغك في الضابط العشرين ليست تفصيلًا تعاقديًا. تنص اللائحة التنفيذية لنظام حماية البيانات الشخصية على إبلاغ الجهة المختصة بحادثة تسرب البيانات خلال مدة لا تتجاوز 72 ساعة من العلم بها، إذا كان من شأنها الإضرار بالبيانات أو بأصحابها، ويتم ذلك عبر خدمة الإبلاغ عن تسرب البيانات في منصة حوكمة البيانات الوطنية. إن كان المورد يحتاج أيامًا ليبلغك، فلن تستطيع منشأتك الوفاء بالتزامها. تحديد RPO وRTO حسب أهمية كل عمل واختبار الاستعادة يشرحهما بالتفصيل مقال النسخ الاحتياطي والتعافي من الكوارث للأنظمة الطبية.
من ينفذ الضابط: المورد أم منشأتك؟
الضابط نفسه قد يكون مسؤولية المورد في خيار نشر، ومسؤوليتك في خيار آخر. على خوادم المنشأة (On-Premise) يصبح النسخ الاحتياطي وأمن الخوادم والشبكة غالبًا مسؤولية فريقك، ولو كان النظام يدعمهما. وفي السحابة المُدارة يتولاهما المورد، لكن إدارة المستخدمين والصلاحيات ومراجعتها تبقى عليك في كل الخيارات. لذلك اسأل عن كل ضابط: من ينفذه، ومن يراقبه، ومن يقدم الدليل؟
| الضوابط | سحابي مُدار | على خوادم المنشأة | ما يبقى على المنشأة دائمًا |
|---|---|---|---|
| 1–4 الهوية والدخول | المورد يوفر الإمكانية | المورد يوفر الإمكانية | تفعيل السياسة وإلزام MFA وضبط مدد الجلسات |
| 5–8 الصلاحيات | المورد يوفر الأدوات | المورد يوفر الأدوات | تصميم الأدوار، وإيقاف حسابات المغادرين، والمراجعة الدورية |
| 9–12 البيانات | المورد غالبًا | مشترك: التطبيق من المورد والخوادم والتخزين منك | قرار موقع البيانات، وتحديد من يصدّر |
| 13–16 التشغيل | المورد للبنية والتحديثات | مشترك | قراءة التنبيهات والتصرف فيها |
| 17–20 الاستمرارية | المورد | منشأتك غالبًا بإرشاد المورد | خطة العمل اليدوي المؤقت، وإبلاغ الجهة المختصة ومرضاك |
تفصيل هذا التوزيع لكل خيار في جدول المسؤوليات في صفحة خيارات النشر. الخطأ الشائع أن تقبل المنشأة خيار الخوادم الداخلية لأسباب سياسية، ثم تكتشف أن ضوابط الاستمرارية أصبحت عليها وليس لديها من ينفذها.
كيف تحوّل الأدلة إلى قرار: البوابات أولًا ثم الدرجة
امنح كل ضابط درجة دليله من 0 إلى 3 كما في الجدول الأول، فيصبح الحد الأعلى 60 درجة. لكن لا تجعل المجموع يقرر وحده؛ فبعض الضوابط يجعل غيابها بقية الضوابط بلا معنى. اعتبر هذه الضوابط السبعة بوابات يجب أن تحصل كل منها على 2 على الأقل: الحساب الفردي (1)، وMFA (2)، والصلاحيات حسب الدور (5)، والتشفير أثناء التخزين (10)، وتصدير بياناتك (12)، وسجل التدقيق للاطلاع (13)، واختبار الاستعادة (18).
مثال توضيحي بموردين افتراضيين| المجموعة (الحد الأعلى 12) | المورد (أ) | المورد (ب) |
|---|---|---|
| الهوية والدخول | 10 | 11 |
| الصلاحيات | 9 | 11 |
| البيانات | 9 | 10 |
| التشغيل | 10 | 8 |
| الاستمرارية | 9 | 11 |
| المجموع من 60 | 47 | 51 |
| البوابات السبع | كلها 2 أو أكثر | الضابط 13 = 0 |
| النتيجة | يستمر إلى التفاوض | يُستبعد أو يُطلب إصلاح مكتوب قبل التعاقد |
بعد البوابات، استخدم المجموع للمقارنة، وانظر إلى المجموعة الأضعف لكل مورد: هي أول ما تضعه في ملحق العقد بتاريخ إصلاح محدد.
أين تقع الضوابط العشرون من الأطر الوطنية؟
هذه القائمة أداة شراء عملية، لا بديل عن الأطر الرسمية. أصدرت الهيئة الوطنية للأمن السيبراني الضوابط الأساسية للأمن السيبراني (ECC-2:2024)، وهي ملزمة للجهات الحكومية والجهات التابعة لها وجهات القطاع الخاص التي تملك بنى تحتية وطنية حساسة أو تشغلها أو تستضيفها، وللهيئة كذلك ضوابط خاصة بالحوسبة السحابية. إن كانت منشأتك ضمن هذا النطاق، فاطلب من المورد مطابقة ضوابطه مع متطلبات الإطار الذي يلزمك، وأشرك فريق الامتثال في التقييم.
وإن لم تكن ضمن النطاق، كمعظم العيادات والمجمعات الخاصة، فالأطر نفسها مرجع جيد لما يُعد ممارسة معقولة، وتبقى التزاماتك بموجب نظام حماية البيانات الشخصية قائمة. في الحالتين لا تقبل عبارة «النظام متوافق» دون أن تعرف: متوافق مع أي بند، وبأي دليل.
تنبيه: وجود الضابط في النظام لا يعني امتثال منشأتك. MFA غير المفعّل، والأدوار غير المراجعة، والتنبيهات التي لا يقرؤها أحد، كلها ضوابط موجودة ولا تحمي شيئًا. الامتثال مسؤولية المنشأة، والنظام يوفر لها الأدوات والسجل الذي تثبت به.
ما الذي تطلبه عيادة صغيرة مقارنة بمجموعة طبية؟
الضوابط العشرون مهمة للجميع، لكن عمق الدليل المطلوب يختلف. عيادة بطبيبين دون فريق تقنية لن تراجع تقرير اختبار اختراق بنفسها، ولن تربط السجلات بنظام SIEM. تقييم عادل للمورد يراعي حجمك:
- عيادة صغيرة دون فريق تقنية: اختبر بنفسك الضوابط 1 و2 و5 و13 في بيئة التجربة، واطلب كتابيًا سياسة النسخ وتقرير آخر استعادة، ومهلة الإبلاغ، وطريقة تصدير بياناتك. غالبًا يكون السحابي المُدار أنسب لك لأن ضوابط التشغيل والاستمرارية تنتقل إلى المورد.
- مجمع أو مستوصف بمدير تقنية: الضوابط العشرون كاملة، مع جلسة فنية حول التشفير وإدارة المفاتيح وموقع البيانات، ومراجعة تقرير المراجعة الدورية للحسابات.
- مجموعة متعددة الفروع أو جهة ضمن نطاق الأطر الوطنية: أضف مطابقة الضوابط مع إطارك، وإرسال السجلات إلى SIEM، وربط الدخول بنظام الهوية لديك، واختبار اختراق مستقل على بيئتك، ونظر في السحابة الخاصة أو البيئة المخصصة.
أخطاء تجعل تقييم الأمن شكليًا
الاختبار بحساب مدير النظام فقط: حساب المدير يرى كل شيء، فلا يكشف أي خلل في الصلاحيات. اختبر بحسابات الاستقبال والمحاسب والطبيب.
قبول شهادة عامة إجابةً عن كل الأسئلة: الشهادة قد تغطي مركز البيانات أو جزءًا من عمليات المورد ولا تغطي التطبيق الذي ستستخدمه. اسأل عن نطاقها، واستمر في طلب الدليل لكل ضابط.
سؤال «هل البيانات مشفرة؟» دون تحديد: الإجابة «نعم» قد تعني التشفير أثناء النقل فقط. اسأل عن قاعدة البيانات والمرفقات والنسخ الاحتياطية والمفاتيح كلًا على حدة.
وجود نسخ احتياطية دون تقرير استعادة: النسخة التي لم تُستعد قط قد لا تُستعاد يوم الحاجة. التقرير المؤرخ هو الدليل.
ترك ما ثبت في التقييم خارج العقد: العرض يتغير، والعقد يبقى. كل ما تعتمد عليه من أهداف ومهل وحقوق يجب أن يُكتب.
ما تكتبه في العقد وكيف تبدأ التقييم
حوّل نتائج التقييم إلى ملحق أمني قصير في العقد، يتضمن على الأقل:
- خيار النشر وموقع البيانات والنسخ ومزود الاستضافة
- أهداف RPO وRTO، وتكرار اختبار الاستعادة وحق المنشأة في الاطلاع على نتيجته
- مهلة إبلاغ المنشأة بالحوادث بالساعات، ومحتوى البلاغ الأول والتقرير اللاحق
- إجراء وصول فريق الدعم إلى البيانات وتسجيله
- تكرار فحص الثغرات واختبار الاختراق، ومدد معالجة النتائج حسب الخطورة
- تصدير البيانات كاملة بصيغة مقروءة عند الطلب وعند انتهاء العقد، ومدة ذلك
- توزيع المسؤوليات لكل ضابط بحسب خيار النشر
- أي ضابط لم يجتز التقييم، بتاريخ إصلاح محدد
ما تقدمه المنصة لهذا التقييم: نجيب عن استبيان الأمن الخاص بمنشأتك، ونزود فريقك بوثيقة البنية التقنية ومصفوفة الأدوار الافتراضية وتفاصيل الاستضافة وخطة التعافي، ونوفر بيئة تجربة يختبر فيها فريقك الضوابط بنفسه، كما تعرض صفحة الأمن والخصوصية. ونناقش معك خيار النشر الذي يوزع المسؤوليات بما يناسب فريقك. اطلب جلسة فنية لمراجعة الضوابط العشرين وخيار الاستضافة المناسب لمنشأتك.
أسئلة شائعة
كم يستغرق تقييم أمن نظام عيادات قبل التعاقد؟
لمجمع لديه مدير تقنية، أسبوعان إلى ثلاثة أسابيع عادة: أسبوع لإرسال الاستبيان واستلام الوثائق، وجلسة فنية، وأيام لتجربة الضوابط في بيئة التجربة. العيادة الصغيرة تستطيع اختبار الضوابط الأساسية في جلسة واحدة إذا أرسلت قائمة الأسئلة مسبقًا.
هل يحق لي طلب تقرير اختبار الاختراق كاملًا من المورد؟
كثير من الموردين لا يشاركون التقرير الكامل لأنه يصف ثغرات قد تفيد المهاجم. الطلب المعقول ملخص يذكر تاريخ الاختبار ومنفذه ونطاقه وعدد النتائج حسب الخطورة وحالة معالجتها. وإن كانت سياستك تتطلب أكثر، فاتفق على اختبار مستقل على بيئتك.
هل يجب أن أطلب ربط النظام بنظام الهوية لدى المنشأة (SSO)؟
يفيد عندما يكون لدى المنشأة نظام هوية مركزي تدير به حسابات الموظفين، لأنه يجعل إيقاف حساب المغادر في مكان واحد. أما في عيادة صغيرة بلا نظام هوية مركزي فحسابات النظام الفردية مع MFA كافية، ويُدرس الربط عند التوسع ضمن نطاق التكامل.
ماذا أفعل إذا فشل المورد المفضل لدينا في ضابط بوابة؟
اطلب منه خطة إصلاح مكتوبة بتاريخ، وأعد اختبار الضابط قبل التوقيع أو اجعله شرطًا لبدء التشغيل الفعلي. لا تقبل وعدًا بإصلاح «في الإصدار القادم» دون تاريخ وحق في إنهاء العقد إن لم يتحقق.
هل أحتاج إعادة التقييم بعد التعاقد؟
نعم، بصيغة أخف. راجع سنويًا تقرير آخر اختبار استعادة وملخص فحص الثغرات، وراجع كل ربع سنة تقرير الحسابات والصلاحيات. وأعد تقييم الضوابط كاملة عند تغيير خيار النشر أو إضافة تكامل كبير.