چرا سامانهٔ بیمهٔ تکمیلی نباید داخل CMS اصلی زندگی کند
وسوسهانگیز است که «یک ماژول دیگر» به هر پلتفرمی که سایت عمومی رویش اجرا میشود اضافه کنی — یک فرم اینجا، یک جدول آنجا، تمام. برای دادههای بیمهٔ کارکنان، این راحتی هزینهای دارد که هیچکس متوجهش نمیشود تا وقتی یک ممیزی یا یک حادثه سؤال بدیهی را میپرسد: چه کس دیگری به این دیتابیس دسترسی دارد؟ فنکاور بهعنوان سرویسی کاملاً ایزوله اجرا میشود — MongoDB اختصاصی، مسیریابی nginx فقط داخلی — دقیقاً برای اینکه جواب کوتاه بماند.
ایزولهسازی دقیقاً چه چیزی میخرد
- نفوذ به CMS عمومی به سوابق بیمه نمیرسد. دیتابیس جدا، اعتبار جدا، شعاع انفجار جدا — یک صفحه بازاریابی که هک شده نمیتواند به جزئیات پوشش بیمهای یک کارمند پرش کند.
- مسیریابی فقط داخلی. سرویس مستقیماً از اینترنت مثل یک صفحه showcase عمومی در دسترس نیست؛ nginx فقط همان چیزی را که فرآیند لاگین لازم دارد آشکار میکند.
- ممیزیها یکجمله جواب میگیرند. «چه چیزی به داده سلامت کارمند دسترسی دارد» یک لیست کوتاه است، نه یک فهرست از هر ماژولی که سالها روی یک CMS مشترک چسبانده شده.
لاگین از طریق هویتی که لازم نبود خودت بسازی
ورود از طریق سامانهٔ احراز هویت ملی «دولتمن» انجام میشود، نه یک نامکاربری/رمز عبور اختصاصی فنکاور. برای داده حساس منابع انسانی، این یک ویژگی راحتی نیست — یعنی دسترسی به یک هویت ملی تأییدشده با ردپای ممیزی خودش گره خورده، و رمز عبور جداگانهای وجود ندارد که کسی فیشینگ کند، دوباره استفاده کند، یا در یک اکسل جا بگذارد.
این الگو فراتر از بیمه تعمیم پیدا میکند
افراد تحت تکفل، تاریخچه پوشش، وضعیت خسارت — هیچکدام لازم نیست در همان مرز اعتماد سیستم مدیریت محتوای سایت عمومی بنشینند. پیشفرض درست برای هر سیستم رو-به-کارمند که دادهای را مدیریت میکند که یک سازمان ترجیح میدهد در یک اطلاعیه نفوذ توضیحش ندهد، سرویس خودش، دیتابیس خودش، و لاگین از طریق هویتی است که سازمان از قبل بهش اعتماد دارد — نه یک ماژول جدید در هر چیزی که از قبل در حال اجراست.
