https://virgool.ir/feed/@mansoor.aharifa2026-11-11 23:50:30https://files.virgool.ir/upload/users/4909025/avatar/avatar.pnghttps://virgool.ir/@mansoor.aharihttps://virgool.ir/@mansoor.ahari/بانکداری-بدون-هسته-واکاوی-اصطلاحی-مد-روز-rziqr5ilmabxبعد از حمله سایبری‌ای که هسته بانکی مشترک چند بانک بزرگ ایران را از کار انداخت، لینکدین فارسی پر شده از پست‌هایی که «coreless banking» را به عنوان راه‌حل معرفی می‌کنند. مشکل این‌جاست که اغلب این پست‌ها یک اصطلاح مد روز را تکرار می‌کنند بدون اینکه ابتدا به سؤال‌های ساده و اصلی جواب بدهند: این مفهوم واقعاً چیست؟ آیا واقعاً «بدون هسته» است؟ و چه چیزهایی باید کنارش رعایت شود تا کار کند؟ در این یادداشت سعی می شود تا با نگاه انتقادی و ساده به این سؤال‌ها پاسخ داده شود.۱. Coreless banking یعنی چه — و چرا اسمش کمی گمراه‌کننده است؟در بانکداری سنتی، یک سیستم بزرگ و یکپارچه همه‌کاره است این سیستم اطلاعات مشتریان و حساب‌ها، تسهیلات و تعهدات و … را نگه می‌دارد، تراکنش‌ها را پردازش می‌کند، سود را حساب می‌کند، اقساط تسهیلات را مدیریت می کند و قوانین محصولات را اجرا می‌کند یعنی همه‌چیز در یک جعبه بزرگ قرار دارد که مزیتش سادگی است و مشکلش این است که اگر آن جعبه مشکلی برایش رخ دهد یا هک شود، کل سامانه های بانک از دسترس خارج می شوند و این دقیقاً همان اتفاقی است که این روزها دیدیم.«Coreless banking» یعنی همین جعبه بزرگ را می‌شکنیم و به چند بخش مستقل تبدیل می‌کنیم: یک بخش فقط دفترداری و ثبت تراکنش‌ها را انجام می‌دهد، یک بخش قوانین و قیمت‌گذاری محصولات را مدیریت می‌کند، یک بخش اطلاعات مشتری را نگه می‌دارد، و یک بخش پرداخت‌ها را هماهنگ می‌کند و …. و این بخش‌ها با پیام و API با هم صحبت می‌کنند، نه این‌که همه در یک برنامه واحد باشند.اما نکته مهمی که در اکثر پست‌ها گفته نمی‌شود این است: بخش دفترداری (Ledger) همچنان یک هسته مرکزی است. جایی که موجودی حساب‌ها ثبت می‌شود و نمی‌تواند «تقریبی» یا با تأخیر همگام باشد، پس اسم دقیق‌تر برای این مدل، «هسته توزیع‌شده» است، نه «بدون هسته». زیرا هر خطا در این بخش یعنی پول یا گم شده یا به اشتباه اضافه شده. حالا کسی که این را نمی‌گوید، یا موضوع را کامل نفهمیده یا صرفاً یک عبارت تبلیغاتی را تکرار می‌کند.جعبه قرمز در دیاگرام (Distributed core:ledger)، بخشی است که هیچ میان‌بری در آن قابل‌قبول نیست. بقیه سیستم می‌تواند تجربه و سرعت توسعه را با معماری توزیع‌شده بهبود دهد، اما امنیت و تاب‌آوری Ledger باید با استانداردهای بسیار سخت‌گیرانه‌تر از هر بخش دیگری طراحی شود.لجر نباید مستقیماً در معرض اینترنت یا حتی در معرض همه سرویس‌های داخلی باشد. فقط چند سرویس مشخص حق فراخوانی مستقیم آن را دارند، آن هم از طریق یک لایه API داخلی با احراز هویت جداگانه و سخت‌تر از بقیه سیستم.۲. قبل از راه‌حل، باید مسئله واقعی را پیدا کردقبل از رفتن سراغ راه‌حل، باید مسئله واقعی را دقیق تشخیص داد. گزارش‌های تحلیلی درباره این حمله چند نکته جالب را نشان می‌دهند: بخش زیادی از زیرساخت بانکی کشور به حدود سه دهه قبل برمی‌گردد؛ و کارشناسان، ریشه تکرار این حملات را بیشتر «ضعف ارتباط با دنیا» و کمبود نیروی متخصص می‌دانند تا صرفاً نوع معماری.اگر مشکل اصلی، سخت‌افزار فرسوده، و کمبود متخصص امنیت باشد، آن‌وقت رفتن مستقیم سراغ بیایید معماری را عوض کنیم یک پاسخ عجولانه است، نه یک تشخیص درست. تکه‌تکه کردن سیستم به‌خودی‌خود امنیت را بالا نمی‌برد و اگر بدون طراحی امنیتی جدی انجام شود، ممکن است حتی نقاط ورود بیشتری هم برای مهاجم ایجاد کند. پس تغییر معماری باید یک تصمیم مهندسی و کسب‌وکاری باشد، نه یک وصله امنیتی سریع.۳. طراحی برای تاب‌آوری — یعنی سیستم بعد از ضربه هم سرپا بمانداگر تصمیم به این تغییر گرفته شد، چند اصل باید از همان روز اول رعایت شود:تفکیک واحدها: سیستم باید طوری طراحی شود که خرابی یک بخش، بقیه را با خودش پایین نکشد. در حادثه اخیر، چون زیرساخت مشترک بود، خرابی یک نقطه همزمان چند بانک بزرگ را از کار انداخت؛ این دقیقاً همان چیزی است که باید اصلاح شود.تخریب تدریجی به‌جای قطع کامل: به‌جای این‌که کل خدمت قطع شود، سیستم باید بتواند به یک حالت محدود اما فعال برود؛ مثلاً پرداخت کارتی با تسویه با تأخیر، به‌جای قطع کامل خدمات.مدیریت درست تراکنش‌های چندمرحله‌ای: وقتی یک تراکنش بین چند سرویس مستقل انجام می‌شود، باید مکانیزم‌هایی برای برگرداندن خودکار مراحل ناقص وجود داشته باشد تا هیچ تراکنشی نیمه‌کاره نماند.ثبت تغییرات به‌صورت غیرقابل‌تغییر: هر تغییر در حساب‌ها باید به شکلی ثبت شود که قابل حذف یا دست‌کاری نباشد؛ هم برای بازرسی بعدی مفید است، هم برای بازیابی سریع بعد از حمله.تمرین واقعی برای بحران: تاب‌آوری چیزی نیست که فقط روی کاغذ بماند؛ باید به‌طور مرتب با خاموش کردن عمدی بخش‌هایی از سیستم، آمادگی واقعی تیم‌ها تست شود.۴. مشکلات عملکردی که کمتر کسی درباره‌شان حرف می‌زندتکه‌تکه کردن سیستم مزایای زیادی دارد، اما هزینه‌های پنهانی هم دارد که باید قبل از تصمیم دید:وقتی همه‌چیز در یک برنامه واحد هست، ارتباط بین بخش‌ها سریع است. حالا اگر این بخش‌ها جدا شوند، هر ارتباط بین آن‌ها از طریق شبکه انجام می‌شود که کندتر است.ممکن است موجودی نمایش‌داده‌شده به مشتری، چند لحظه با واقعیت فاصله داشته باشد چون بخش‌های مختلف سیستم دقیقاً هم‌زمان به‌روز نمی‌شوند؛ در پرداخت‌های آنی این می‌تواند مشکل‌ساز شود.برای رفع این مشکل معمولاً مسیر خواندن اطلاعات از مسیر نوشتن جدا می‌شود و از حافظه‌های سریع‌تر استفاده می‌شود، اما این کار خودش پیچیدگی و هزینه نگه‌داری اضافه می‌کند.ردیابی و رفع اشکال هم سخت‌تر می‌شود: وقتی یک تراکنش از ده‌ها بخش مستقل عبور می‌کند، پیدا کردن این‌که کجای مسیر کند یا خراب شده، بدون ابزار مناسب رصد و ردیابی تقریباً غیرممکن است.در روزهای پرترافیک (مثل روزهای واریز حقوق یا پایان سال)، هر بخش باید جداگانه برای این حجم آماده باشد؛ اگر فقط یکی از بخش‌ها (مثلاً بخش احراز هویت) گلوگاه شود، کل زنجیره کند می‌شود حتی اگر بقیه بخش‌ها سالم باشند.۵. نحوه هماهنگی تیم‌های توسعه — بخشی که معمولاً فراموش می‌شوداین همان بخشی است که تقریباً هیچ پستی درباره‌اش حرف نمی‌زند، در حالی که رایج‌ترین دلیل شکست چنین پروژه‌هایی دقیقا همین‌جاست:تیم‌های مختلف باید قبل از نوشتن کد، روی قالب دقیق ارتباط بین سرویس‌ها توافق کنند، نه این‌که هر کدام سلیقه‌ای پیش بروند.ساختار تیم‌ها باید با ساختار سرویس‌ها هم‌راستا باشد؛ وگرنه معماری روی کاغذ زیبا است اما در عمل هماهنگی بین تیم‌ها به یک کابوس تبدیل می‌شود.قبل از هر انتشار جدید، سیستم باید کامل تست شود که تغییرات یک تیم، سرویس تیم دیگر را خراب نکند.بدون یک تیم مرکزی که استانداردهای مشترک، ابزارهای مشترک و مانیتورینگ یکپارچه را نگه دارد، هرچه تعداد تیم‌ها بیشتر شود، هماهنگی سخت‌تر و کندتر می‌شود.وقتی ده‌ها سرویس داخلی و خارجی (فین‌تک‌ها، درگاه‌های پرداخت) به سیستم متصل هستند، باید یک سیاست مشخص برای تغییر نسخه‌ها وجود داشته باشد تا یک تغییر کوچک، یک سرویس دیگر را از کار نیندازد.Coreless banking ابزار خوبی است، اما نه طلسم امنیتی است و نه جایگزین رایگان برای بلوغ سازمانی. مسیر درست این است که اول با شفافیت واقعی، علت تکرار این حملات را پیدا کنیم — که به گفته کارشناسان بخش زیادی از آن به زیرساخت فرسوده، کمبود نیروی متخصص بر‌ می‌گردد نه فقط نوع معماری — و بعد به‌صورت تدریجی و مرحله‌به‌مرحله سیستم را تجزیه کنیم، در حالی که بخش دفترداری همچنان با بالاترین سطح دقت و آزمایش طراحی می‌شود. هر پستی که این جزئیات را نادیده بگیرد، دارد یک هشتگ می‌فروشد، نه یک راه‌حل واقعی.Mansoor AhariMansoor AhariFri, 10 Jul 2026 12:27:44 +0330