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