حمله به هسته مشترک؛ اختلال چهار بانک ایران چه چیزی را آشکار کرد؟
اختلال بانکی ایران فقط یک حمله یا قطعی ساده نبود؛ نشانهای بود از بحران در لایه میانی بانکداری الکترونیکی، جایی میان هسته خدمات مشترک، تصمیمهای اضطراری برای ایزولهسازی، بازیابی نامتقارن سرویسها و نبود شفافیت فنی.
اختلال در چهار بانک بزرگ ایران که از اواخر خردادماه آغاز شد و سپس به شش بانک گسترش یافت، در نگاه اول شبیه یک اختلال معمول در خدمات بانکی در برابر حملات سایبری به نظر میرسید؛ کارتخوانها خطا میدادند، همراهبانکها بالا نمیآمدند، انتقال وجه با محدودیت روبهرو بود و برخی مشتریان حتی در مراجعه به شعب هم پاسخ روشنی نمیگرفتند. اما روایت رسمی بعدی، تصویر پیچیدهتری ساخت: حمله سایبری به یک هسته خدماتی مشترک، قطع موقت برخی خدمات برای جلوگیری از دسترسی غیرمجاز و بازیابی تدریجی سامانههایی که بازگشت آنها روزها طول کشید. در آخرین خبرها، بانک مرکزی اعلام کردهاست هماکنون خدمات همه بانکها غیر از ملی و صادرات و تجارت به وضع عادی بازگشته و این سه بانک نیز تا پایان روز ۲ تیر ۱۴۰۵، مشکلشان حل خواهد شد.
در چنین رخدادی، آنچه کاربر میبیند لزوما خود حمله نیست؛ ممکن است بخشی از آن نتیجه تصمیمهای دفاعی، ایزولهسازی، آزمون پایداری و بازیابی مرحلهای باشد.
رخداد بانکی اخیر در خلأ اتفاق نیفتاد. در روزهای پیش از آن، چند رخداد نظامی، سایبری و تبلیغاتی، زیرساختهای حیاتی را به مرکز جنگ روایتها تبدیل کرده بود. نخست، روایتهایی درباره درگیری با هلیکوپتر آپاچی و ورود پهپاد سپاه به کابین آن منتشر شد. سپس، سنتکام در پاسخ، یک آنتن یا ایستگاه هدایت پهپاد در منطقه سیریک را هدف قرار داد؛ نقطهای که در مجاورت مخازن آب قرار داشت. پس از حمله، رسانههای جمهوری اسلامی کمپینی درباره تخریب مخازن و قطع آب در منطقه سیریک و کوهستک را آغاز کردند و یک روز بعد، گروه حنظله مدعی نفوذ به زیرساخت آب کالیفرنیا شده و بخشی از اطلاعات مشترکان آب این ایالات در آمریکا را منتشر کرد.
مقالههای بیشتر
چند روز بعد، همزمان با اختلال گسترده در بانکهای ایران، گروه TRoLL Team مسئولیت حمله به بانک ملی را بر عهده گرفت و آن را بهعنوان عملیات اختلالی علیه زیرساخت مالی جمهوری اسلامی در برابر آن حمله معرفی کرد.
این رخدادها لزوما یک زنجیره عملیاتی واحد و اثباتشده را تشکیل نمیدهند، اما کنار هم نشان میدهند که در فضای تشدید تنش، زیرساختهای حیاتی، از آب و هدایت پهپاد تا بانکداری الکترونیکی، به میدان فشار عملیاتی، جنگ روانی و نمایش توان سایبری تبدیل شدهاند. بنابراین حمله بانکی را باید نه فقط در سطح یک اختلال خدماتی، بلکه در بستر گستردهتر رقابت بر سر اعتماد عمومی و تابآوری زیرساختهای حیاتی خواند.
آنچه میدانیم و آنچه هنوز نمیدانیم
پرونده اختلال بانکی اخیر پر از روایتهای ناقص، ادعاهای رسمی و ادعاهای هکتیویستی است. برای فهم دقیقتر رخداد، ابتدا باید مرز میان دانستهها و نادانستهها روشن شود.
آنچه میدانیم:
- چهار بانک اصلی در مرکز اختلال قرار داشتند: بانک ملی، بانک صادرات، بانک تجارت و بانک توسعه صادرات. در روزهای بعد، برخی گزارشها از درگیر شدن یا اثرپذیری چند بانک دیگر نیز خبر دادند و دامنه اختلال در برخی روایتها به شش بانک رسید.
- روایت رسمی نیز در طول بحران تغییر کرد. آنچه ابتدا بهعنوان «اختلال فنی» یا مشکل در زیرساخت شرکت خدمات انفورماتیک مطرح شد، بعدتر در اطلاعیهها و اظهارنظرهای رسمی به «حمله سایبری» تغییر یافت.
- مقامها در توضیح دامنه رخداد، از «زیرساخت مشترک» یا «هسته خدماتی مشترک» میان بانکهای درگیر سخن گفتهاند. همین تعبیر نشان میدهد که مسئله احتمالا فقط در سطح اپلیکیشنهای بانکی یا یک بانک منفرد نبوده، بلکه به لایهای مشترک در معماری بانکداری الکترونیکی مربوط میشده است.
- بخشی از خدمات کارتی و انتقال وجه بهصورت مرحلهای برگشت، اما بازگشت خدمات یکدست نبود. برخی سرویسها، از جمله ساتنا، پایا، چک، خدمات شعب و خدمات غیرحضوری، دیرتر پایدار شدند یا با محدودیت ادامه یافتند.
- شرکت خدمات انفورماتیک نیز در اطلاعیه خود از قطع موقت برخی خدمات برای جلوگیری از دسترسی غیرمجاز سخن گفت. این نکته مهم است، چون نشان میدهد بخشی از اختلالی که کاربران دیدند ممکن است فقط اثر مستقیم حمله نبوده باشد، بلکه نتیجه تصمیمهای دفاعی، ایزولهسازی و بازیابی مرحلهای بوده است.
- در خبرهای روز ۲۳ ژوئن، از موج تازه یا تداوم اختلال در برخی بانکها و سرویسها سخن گفته شد. در همان روز، بانک مرکزی اعلام کرد خدمات همه بانکها، جز بانک ملی، بانک صادرات و بانک تجارت، به وضعیت عادی بازگشته و مشکل این سه بانک نیز تا پایان روز دوم تیر ۱۴۰۵ برطرف خواهد شد.
آنچه هنوز نمیدانیم
- هنوز بردار حمله روشن نیست. معلوم نیست مهاجمان از چه مسیر یا ضعفی استفاده کردهاند: فشار ترافیکی، اختلال در مسیرهای ارتباطی، سوءاستفاده از دسترسی، آسیبپذیری نرمافزاری، حمله به سرویس مشترک یا ترکیبی از چند عامل.
- هنوز مشخص نیست حمله فقط از جنس DDoS بوده یا نفوذ عمیقتری نیز رخ داده است. از کار افتادن سرویسها میتواند نتیجه حمله به دسترسپذیری باشد، اما بهتنهایی ثابت نمیکند مهاجم وارد شبکه داخلی، سامانههای اصلی یا پایگاههای داده شده است.
- هنوز نمیدانیم آیا مهاجم به شبکه داخلی یا سامانههای حساس دسترسی داشته یا نه. مقامها از جلوگیری از دسترسی غیرمجاز و حفاظت از دادهها سخن گفتهاند، اما گزارشی فنی منتشر نشده که سطح واقعی تهدید را روشن کند.
- هنوز شواهد عمومی قابل اتکا از استخراج یا نشت داده مشتریان منتشر نشده است. با این حال، نبود شواهد عمومی از نشت، به معنی اثبات نبود دسترسی غیرمجاز نیست.
- هنوز روشن نیست چرا سازوکارهای پشتیبان، بازیابی اضطراری، DR و failover نتوانستهاند بازگشت سریعتر و یکدستتری ایجاد کنند. طولانی شدن اختلال و بازگشت نامتقارن خدمات، پرسشهایی جدی درباره کیفیت تابآوری این زیرساخت ایجاد میکند.
- نقش واقعی گروه TRoLL Team نیز همچنان نامشخص است. این گروه مسئولیت حمله به بانک ملی را بر عهده گرفته و از حملات DDoS لایه ۴ و ۷ سخن گفته، اما تاکنون شواهد فنی کافی، مانند لاگ، نمودار ترافیک، IOC یا proof-of-access منتشر نکرده است.
در نهایت، مهمترین خلأ پرونده همچنان نبود کالبدشکافی عمومی است. تا زمانی که بانک مرکزی، شرکت خدمات انفورماتیک یا یک نهاد فنی مستقل گزارشی درباره نوع حمله، دامنه اثر، مسیر نفوذ، اقدامات مهار و روند بازیابی منتشر نکند، بخش مهمی از این رخداد در همان لایه خاکستری حمله، مهار و بازیابی باقی میماند.
تایملاین رخداد؛ از «مشکل فنی» تا «حمله محدود»
مرحله اول: اختلال عمومی: گزارشهای اولیه از اختلال در خدمات چهار بانک منتشر شد. برای کاربران، مسئله در سطح خدمات روزمره دیده شد: کارتخوانها خطا میدادند، خودپردازها و همراهبانکها دچار مشکل بودند، انتقال وجه با محدودیت روبهرو شد و برخی مشتریان حتی در مراجعه به شعب نیز پاسخ روشنی دریافت نکردند.
مرحله دوم: نسبت دادن به خدمات انفورماتیک: روایت اولیه، مشکل را به زیرساخت شرکت خدمات انفورماتیک نسبت داد. همین روایت از ابتدا نشان میداد اختلال احتمالا در یک نقطه مشترک میان چند بانک رخ داده، نه در یک اپلیکیشن، شعبه یا سرویس منفرد.
مرحله سوم: تغییر روایت به حمله سایبری: شورای هماهنگی بانکها و منابع رسمی بعدتر از «حمله سایبری محدود» سخن گفتند. با این تغییر روایت، پرونده از سطح اختلال فنی وارد سطح حادثه امنیتی شد؛ اما همچنان جزئیات فنی حمله، بردار نفوذ، دامنه واقعی اثر و شواهد قابل راستیآزمایی منتشر نشد.
مرحله چهارم: بازگشت نامتقارن خدمات: خدمات کارتی زودتر از برخی سرویسهای دیگر برگشت، اما ساتنا، پایا، چک، خدمات شعب و برخی سرویسهای غیرحضوری دیرتر پایدار شدند یا با محدودیت ادامه یافتند. این نامتقارن بودن، خودش یک نشانه فنی مهم است: بازگشت کارت به معنی بازگشت کامل بانک نیست.
مرحله پنجم: روایت مهار: شرکت خدمات انفورماتیک اعلام کرد برخی خدمات برای پیشگیری از دسترسی غیرمجاز موقتا از دسترس خارج شدهاند. این یعنی بخشی از آنچه کاربران بهعنوان اختلال دیدند، ممکن است نتیجه تصمیم دفاعی برای مهار ریسک بوده باشد، نه فقط اثر مستقیم حمله.
مرحله ششم: بازگشت اعلامی خدمات و باقی ماندن سه بانک در وضعیت پیگیری: در مرحله بعد، بانک مرکزی اعلام کرد خدمات همه بانکها، بهجز بانک ملی، بانک صادرات و بانک تجارت، به وضعیت عادی بازگشته است. همزمان وعده داده شد مشکل این سه بانک نیز تا پایان روز دوم تیر ۱۴۰۵ برطرف شود. این اطلاعیه نشان میداد از نگاه رسمی، بحران وارد مرحله پایانی بازیابی شده است؛ اما باقی ماندن سه بانک بزرگ در وضعیت پیگیری، همچنان نشان میداد بازگشت خدمات کامل، یکدست و فوری نبوده است.
این توالی نشان میدهد بحران فقط یک حمله لحظهای نبوده؛ یک چرخه کامل حادثه شامل شناسایی، مهار، قطع اضطراری، بازیابی، آزمون پایداری و اطلاعرسانی ناقص بوده است.
نقشه معماری؛ حادثه در کدام لایه رخ داد؟
برای فهم اختلال بانکی اخیر، باید میان آنچه کاربر میبیند و آنچه در لایههای عملیاتی بانکداری رخ میدهد تفکیک کرد. خطای کارتخوان، قطع همراهبانک یا محدودیت انتقال وجه فقط نشانههای بیرونی بحراناند؛ نقطه اصلی حادثه ممکن است در لایهای پایینتر و مشترکتر قرار داشته باشد. در سادهترین شکل، معماری این رخداد را میتوان در پنج لایه دید.
لایه اول، کانالهای کاربر است: کارتخوان، خودپرداز، همراهبانک، اینترنتبانک و شعبه. این همان سطحی است که شهروندان مستقیما با آن روبهرو شدند.
لایه دوم، سرویسهای بانکی هر بانک است: Core Banking، سوئیچ کارت، سرویس احراز، ماندهگیری، انتقال وجه و چک. این لایه تعیین میکند درخواست کاربر چگونه در داخل بانک پردازش شود.
لایه سوم، سامانههای مشترک و بینبانکی است: ساتنا، پایا، شتاب، شاپرک، مسیرهای ارتباطی، سوئیچها و سرویسهای مشترک. اختلال در این لایه میتواند روی ارتباط میان بانکها، پرداختها و انتقالهای بینبانکی اثر بگذارد.
لایه چهارم، شرکت خدمات انفورماتیک و هسته خدمات مشترک است: جایی که چند بانک ممکن است از یک سرویس، مسیر، پلتفرم یا هسته عملیاتی مشترک استفاده کنند. اگر رخداد در این لایه اتفاق افتاده باشد، میتواند همزمان چند بانک را درگیر کند، بدون اینکه لازم باشد هر بانک جداگانه هدف قرار گرفته باشد.
لایه پنجم، مدیریت حادثه است: DR، failover، قطع ارتباط، ایزولهسازی، تغییر سختافزار و بازیابی تدریجی. این لایه توضیح میدهد چرا بخشی از اختلال ممکن است نه اثر مستقیم حمله، بلکه نتیجه تصمیمهای دفاعی و فرایند بازیابی باشد.
اگر حادثه در لایه کاربر بود، احتمالا فقط یک اپلیکیشن، یک کانال یا یک نوع خدمت مختل میشد. اگر در شتاب یا شاپرک بود، دامنه اثر باید بسیار گستردهتر و سراسریتر میبود. محدود ماندن بحران به چند بانک، در کنار اثرگذاری همزمان بر چند نوع خدمت، نشانهای است که باید به لایه میانی و هسته خدماتی مشترک نگاه کرد.
حمله، مهار یا خرابی ثانویه؟ سه سناریوی فنی
دادههای عمومی منتشرشده تا این مرحله، برای تعیین قطعی نوع حمله کافی نیست. اما الگوی رخداد نشان میدهد که با یک اختلال ساده و تکعاملی روبهرو نیستیم. دستکم سه سناریوی فنی را باید همزمان بررسی کرد: فشار ترافیکی بیرونی، حمله یا اختلال در یک هسته خدماتی مشترک، و تصمیمهای دفاعی برای ایزولهسازی و بازیابی مرحلهای.
سناریوی اول: DDoS سنگین علیه سرویسهای بیرونی: این سناریو با ادعای TRoLL Team و بخشی از اختلالی که کاربران تجربه کردند همخوان است. اگر سرویسهای بیرونی بانک، از جمله موبایلبانک، اینترنتبانک، APIها، Load Balancerها، فایروالها یا مسیرهای عمومی ارتباطی تحت فشار DDoS قرار گرفته باشند، نتیجه میتواند به شکل خطای اپلیکیشن، کندی سرویس، ناتوانی در ورود، اختلال در انتقال وجه یا از دسترس خارج شدن بخشی از خدمات دیده شود.
اما محدودیت این سناریو روشن است: DDoS بهتنهایی نفوذ به Core Banking، دسترسی به دیتابیس داخلی یا استخراج دادههای مشتریان را ثابت نمیکند. حمله DDoS حمله به دسترسپذیری است، نه لزوما حمله به محرمانگی یا تمامیت داده. بنابراین، حتی اگر بخشی از رخداد ناشی از فشار ترافیکی بوده باشد، این توضیح برای همه ابعاد بحران کافی نیست.
سناریوی دوم: حمله به هسته خدماتی مشترک یا مسیرهای اتصال: این سناریو با روایت رسمی جدید همخوانی بیشتری دارد. مقامها از «زیرساخت مشترک» یا «هسته خدماتی مشترک» میان بانکهای درگیر سخن گفتهاند. اگر نقطه اثرگذاری رخداد در چنین لایهای بوده باشد، لازم نیست هر بانک بهصورت جداگانه هدف قرار گرفته باشد؛ اختلال در یک سرویس، مسیر، پلتفرم یا گره مشترک میتواند همزمان چند بانک را درگیر کند.
این سناریو همچنین توضیح میدهد چرا بحران فقط در سطح یک اپلیکیشن یا یک کانال بانکی باقی نماند و خدمات متفاوتی از کارت و همراهبانک تا پایا، ساتنا، شعب و چک را تحت تأثیر قرار داد. چنین الگویی بیشتر به رخدادی در لایه میانی بانکداری الکترونیکی شباهت دارد؛ جایی که بانکها، سامانههای مشترک، مسیرهای ارتباطی و ارائهدهنده خدمات زیرساختی به هم متصل میشوند.
سناریوی سوم: قطع اضطراری و failover ناموفق یا کند: سناریوی سوم، اثر تصمیمهای دفاعی و فرایند بازیابی را توضیح میدهد. شرکت خدمات انفورماتیک اعلام کرده بود برخی خدمات برای جلوگیری از دسترسی غیرمجاز بهطور موقت از دسترس خارج شدهاند. این یعنی بخشی از آنچه کاربران بهعنوان اختلال دیدند، ممکن است اثر مستقیم حمله نبوده باشد، بلکه نتیجه ایزولهسازی، قطع اضطراری، آزمون پایداری یا بازیابی مرحلهای بوده است.
در چنین شرایطی، پرسش اصلی فقط این نیست که مهاجم چه کرده است؛ پرسش مهمتر این است که چرا سازوکارهای پشتیبان، DR و failover نتوانستند بازگشت سریعتر، امنتر و یکدستتری ایجاد کنند. اگر بازیابی خدمات روزها طول کشیده و برخی سرویسها زودتر و برخی دیرتر برگشتهاند، مسئله به کیفیت معماری افزونگی، استقلال عملیاتی بانکها و آمادگی پاسخ به حادثه برمیگردد.
رخداد اخیر احتمالا تکعلتی نیست. محتملتر است که با ترکیبی از فشار یا حمله، تصمیم دفاعی برای ایزولهسازی و ضعف در بازیابی سریع سرویسهای مشترک روبهرو باشیم. به همین دلیل، توضیحهایی مانند «فقط DDoS بود»، «فقط اختلال فنی بود» یا «فقط حمله به یک بانک بود» تصویر کامل بحران را نشان نمیدهد. نقطه مهمتر این است که یک رخداد در لایه میانی زیرساخت بانکی توانست هم سطح کاربر، هم سرویسهای عملیاتی بانکها و هم اعتماد عمومی را همزمان درگیر کند.
TRoLL Team؛ ادعای هکتیویستی یا شاهد فنی؟
با انتشار پستهای TRoLL Team این رخداد از یک حمله DDoS علیه بانک ملی فراتر رفت. این گروه در پیامهای بعدی، مدعی نفوذ عمیق به زیرساختهای بانک پاسارگاد و بانک کشاورزی شد و فهرستی از جزئیات فنی منتشر کرد: بهرهبرداری از API Gateway، حرکت جانبی در شبکه، دسترسی به محیطهای VMware و Active Directory، نصب WebShell و Cobalt Strike، دسترسی به Oracle Core Banking، استخراج چند ترابایت داده، حمله DDoS لایه ۷، غیرفعالسازی سامانههای نظارتی و حتی استقرار ransomware.
از نظر تحلیلی، این ادعاها مهماند، چون نشان میدهند گروه تلاش میکند رخداد را نه فقط یک اختلال دسترسی، بلکه یک نفوذ چندمرحلهای و تخریبی معرفی کند. اگر چنین ادعاهایی درست باشد، موضوع از سطح availability attack فراتر میرود و به حوزه دسترسی داخلی، exfiltration، تخریب، اخاذی و تهدید زنجیرهای علیه زیرساخت بانکی میرسد.
اما تا این مرحله، این ادعاها هنوز به سطح شاهد فنی قابل اتکا نرسیدهاند. TRoLL Team اصطلاحات و جزئیات زیادی به کار برده، اما شواهدی مانند لاگ قابل راستیآزمایی، IOC، نمونه داده معتبر و redacted، نمودار ترافیک، sample بدافزار، اسکرینشات قابل تأیید از محیط داخلی یا گزارش مستقل منتشر نکرده است. اشاره به یک hash ناقص یا یک query ادعایی علیه پایگاه داده، بهتنهایی اثبات دسترسی محسوب نمیشود.
بخشی از ادعاها قابل تصور است: DDoS علیه سرویسهای بیرونی، فشار بر موبایلبانک و اینترنتبانک، اختلال در APIها یا سوءاستفاده از ضعفهای قدیمی در سامانههای بانکی. اما بخشهایی مانند دسترسی به Core Banking، استخراج چند ترابایت داده، دستیابی به HSM keys، استقرار باجافزار روی بخش بزرگی از سرورها و wipe کردن بکاپها، ادعاهای بسیار سنگینی هستند و بدون شواهد مستقل نباید قطعی تلقی شوند.
ادعاهای TRoLL Team دامنه احتمالی حادثه را بزرگتر و جدیتر نشان میدهد، اما تا زمانی که شواهد فنی قابل راستیآزمایی منتشر نشود، این ادعاها در مرز میان سرنخ هکتیویستی، عملیات روانی و ادعای اثباتنشده باقی میمانند.
DDoS لایه ۴ و ۷؛ چرا از کار افتادن سرویس با نفوذ یکی نیست
در ادعاهای TRoLL Team و برخی روایتهای اولیه درباره اختلال بانکی، بارها به حملات DDoS لایه ۴ و ۷ اشاره شده است. برای فهم این ادعا، باید یک تفکیک مهم را روشن کرد: DDoS حمله به دسترسپذیری است. یعنی میتواند سرویس را کند، ناپایدار یا از دسترس خارج کند، اما بهتنهایی نشان نمیدهد مهاجم وارد شبکه داخلی شده، به Core Banking دسترسی گرفته یا دادهای از مشتریان استخراج کرده است.
حمله DDoS در لایه ۴ به سطح انتقال شبکه مربوط است؛ جایی که TCP و UDP، مسیرهای ارتباطی، فایروالها، Load Balancerها و ظرفیت پهنای باند درگیر میشوند. در چنین حملهای، مهاجم تلاش میکند با حجم بالای بستهها یا اتصالهای نیمهکاره، مسیر ارتباطی یا تجهیزات لبه شبکه را تحت فشار قرار دهد. نتیجه برای کاربر میتواند کندی، خطا در اتصال، قطع سرویس یا ناتوانی در استفاده از اپلیکیشن باشد.
حمله DDoS در لایه ۷ به سطح اپلیکیشن مربوط است؛ جایی که درخواستها به وبسایت، API، صفحه ورود، موبایلبانک، اینترنتبانک یا سرویسهای احراز هویت ارسال میشوند. این نوع حمله ممکن است با ترافیک کمتر اما هدفمندتر انجام شود، چون به بخشهایی فشار میآورد که پردازش بیشتری نیاز دارند: ورود کاربر، دریافت مانده، انتقال وجه، دریافت تاریخچه تراکنش یا ارتباط با سرویسهای پشتصحنه.
اما همینجا مرز مهمی وجود دارد. Core Banking نباید مستقیما از اینترنت عمومی قابل DDoS باشد. اگر سامانههای اصلی بانک، تراکنشهای داخلی یا خدمات شعب هم مختل شدهاند، باید دنبال توضیحهای دیگری هم رفت: وابستگی معماری میان سرویسهای بیرونی و داخلی، قطع دفاعی برای مهار ریسک، اختلال در سرویسهای واسط، مشکل در مسیرهای مشترک یا نفوذ جداگانه به شبکه داخلی.
بنابراین، اگر حمله واقعا فقط DDoS بوده باشد، بحران اصلی نه در نفوذ، بلکه در اتصال بیش از حد سرویسهای حیاتی به لایههای قابل فشار و نبود جداسازی کافی است. اما اگر رخداد فراتر از DDoS بوده، بحران اصلی نبود شفافیت درباره سطح دسترسی مهاجم، دامنه واقعی اختلال و وضعیت دادههاست.
یک نکته مهم در تحلیل حملات DDoS این است که اختلال در دسترسپذیری همیشه هدف نهایی نیست. در ادبیات امنیت سایبری، الگوهایی مانند diversionary DDoS یا DDoS as a smokescreen شناخته شدهاند؛ یعنی مهاجم با ایجاد اختلال گسترده، تیم فنی و امنیتی را مشغول نگه میدارد، در حالی که همزمان ممکن است فعالیتهای پنهانتری مانند دسترسی غیرمجاز، انتقال پول، تغییر تنظیمات امنیتی، خروج داده یا نصب بدافزار انجام شود.
این الگو در بخش مالی سابقه دارد. در برخی پروندهها، اختلال پر سر و صدا در سطح سرویس یا تماسهای انبوه با قربانیان، برای منحرف کردن توجه از عملیات اصلی به کار رفته است. نهادهایی مانند CISA نیز هشدار دادهاند که DDoS میتواند بهعنوان عامل حواسپرتی برای پنهان کردن فعالیتهای مخرب دیگر استفاده شود. بنابراین، در رخداد بانکی اخیر، اگرچه DDoS بهتنهایی اثبات نفوذ نیست، اما نمیتوان احتمال استفاده از آن بهعنوان پوشش برای عملیات عمیقتر را هم نادیده گرفت.
بنابراین پرسش اصلی فقط این نیست که آیا سرویسها با DDoS از کار افتادهاند یا نه؛ پرسش مهمتر این است که در زمان اختلال چه اتفاق دیگری در شبکه رخ داده است. آیا دسترسیهای غیرعادی ثبت شده؟ آیا تنظیمات امنیتی تغییر کرده؟ آیا لاگها پاک شدهاند؟ آیا نشانهای از انتقال داده، lateral movement یا دسترسی داخلی وجود داشته است؟ پاسخ به این پرسشها بدون انتشار گزارش فنی، IOC، لاگ قابل راستیآزمایی یا خلاصه incident response ممکن نیست.
بازگشت خدمات، ابهام دادهها؛ چرا پایان اختلال به معنی پایان بحران نیست؟
بازگشت بخشی از خدمات بانکی به معنی پایان کامل بحران نبود. خدمات بانکی یکپارچه و همسطح نیستند؛ ممکن است خرید با کارت، ماندهگیری یا برخی انتقالهای ساده دوباره فعال شود، اما ساتنا، پایا، چک، خدمات شعب، موبایلبانک یا انتقالهای کلان همچنان به سرویسهایی وابسته باشند که در وضعیت ایزولهسازی، بازیابی، آزمون پایداری یا محدودیت عملیاتی قرار دارند. به همین دلیل، رفع اختلال کارتخوان لزوما به معنی بازگشت کامل بانک نیست؛ فقط نشان میدهد یکی از کانالهای دسترسی دوباره فعال شده است. همین بازگشت نامتقارن خدمات، پرسشهای فنی مهمی ایجاد میکند.
در کنار مسئله بازیابی، وضعیت دادههای مشتریان نیز همچنان به شفافیت بیشتری نیاز دارد. مقامات میگویند اطلاعات مشتریان افشا نشده است و تا این مرحله نیز شواهد عمومی قابل اتکایی که خلاف این ادعا را ثابت کند منتشر نشده است. اما نبود نمونه داده، بهتنهایی به معنی اثبات نبود دسترسی غیرمجاز نیست. چون هنوز گزارش فنی مستقل، IOC، گزارش forensic یا خلاصهای از روند پاسخ به حادثه منتشر نشده، ادعای امنیت کامل دادهها قابل راستیآزمایی عمومی نیست.
بنابراین، در حال حاضر دقیقترین فرمول این است: شواهد عمومی برای نشت داده مشتریان وجود ندارد، اما نبود شواهد عمومی از نشت، با اثبات نبود دسترسی غیرمجاز یکی نیست. اگر رخداد فقط از جنس حمله به دسترسپذیری بوده باشد، عدم نشت داده قابل تصور است. اما اگر حمله واقعا به هسته خدماتی مشترک یا لایههای حساستر زیرساخت بانکی رسیده باشد، سطح شفافیت باید بسیار بالاتر از اطلاعیههای کلی باشد.
تمرکز زیرساختی؛ نقطه قوتی که به نقطه شکست تبدیل شد
بانکداری مدرن بدون سرویسهای مشترک، سامانههای مرکزی و مسیرهای هماهنگ بینبانکی قابل تصور نیست. شتاب، شاپرک، ساتنا، پایا، سوئیچهای مشترک، هستههای خدماتی و ارائهدهندگان زیرساختی، همگی برای افزایش سرعت، استانداردسازی و اتصال میان بانکها ساخته شدهاند. اما همین تمرکز، اگر با افزونگی، تفکیک مناسب، شفافیت فنی و پاسخگویی نهادی همراه نباشد، میتواند از یک مزیت عملیاتی به یک ریسک سیستمی تبدیل شود.
در این بخش، یک ابهام اسمی هم باید روشن شود. تعبیر «شرکت ملی خدمات انفورماتیک» دقیق نیست. در ساختار بانکی ایران، باید میان «شرکت ملی انفورماتیک» بهعنوان سطح هلدینگی و «شرکت خدمات انفورماتیک» یا رانفور بهعنوان بازوی عملیاتی تفکیک کرد. شرکت خدمات انفورماتیک صرفا یک پیمانکار عادی نیست؛ این شرکت در شبکه بانکی ایران با سرویسهای پایه، زیرساختهای مشترک و مسیرهای فنی مرتبط با بانک مرکزی، سامانههای کارت، شتاب، شاپرک، پایا، ساتنا و دیگر خدمات مشترک نسبت دارد. این به آن معنا نیست که همه این سامانهها در رخداد اخیر آسیب دیدهاند؛ مقامها حتی گفتهاند برخی از این زیرساختها فعال بودهاند. مسئله این است که رخداد اعلامشده ظاهرا در «هسته خدماتی مشترک» چند بانک رخ داده و اگر اختلال یا حمله در چنین لایهای اتفاق بیفتد، اثر آن میتواند همزمان روی چند بانک دیده شود، بدون اینکه الزاماً هر بانک جداگانه هک شده باشد. این تمرکز دستکم سه پیامد دارد.
- نخست، تمرکز عملیاتی: وقتی چند بانک بزرگ به یک سرویس، مسیر، پلتفرم یا هسته مشترک وابستهاند، اختلال در همان نقطه میتواند همزمان چند بانک را درگیر کند. در چنین معماریای، لازم نیست هر بانک بهطور جداگانه از کار بیفتد؛ آسیب یا اختلال در لایه مشترک میتواند اثر زنجیرهای ایجاد کند.
- دوم، تمرکز ریسک: برای مهاجم، نقطه مشترک جذابتر از حمله جداگانه به هر بانک است. اگر مهاجم بتواند به یک گره مرکزی، مسیر مشترک، سرویس واسط یا ارائهدهنده زیرساختی فشار بیاورد، اثر آن میتواند از یک بانک فراتر برود و به بحرانی چندبانکی تبدیل شود.
- سوم، تمرکز ابهام: وقتی حادثه رخ میدهد، مسئولیت میان بانکها، بانک مرکزی، شرکت خدمات انفورماتیک، سامانههای مشترک و پیمانکاران فنی پخش میشود. در نتیجه، پاسخ عمومی اغلب کلی، دیرهنگام و ناقص میماند. برای شهروندی که کارت، همراهبانک یا انتقال وجه او کار نمیکند، روشن نیست مسئول نهایی کیست و کدام لایه واقعاً آسیب دیده است.
به همین دلیل، تمرکز زیرساختی تنها زمانی قابل دفاع است که با معماری افزونه، failover قابل اتکا، جداسازی سرویسهای حیاتی، گزارشدهی شفاف و پاسخگویی عمومی همراه باشد. در غیر این صورت، همان سازوکاری که قرار بوده بانکداری را سریعتر و یکپارچهتر کند، در زمان بحران میتواند به نقطه شکست مشترک تبدیل شود.
جمعبندی؛ امنیت بانکی یعنی تابآوری، نه فقط جلوگیری از نفوذ
حمله به زیرساخت مالی فقط حمله به یک بانک یا یک شرکت نیست؛ حمله به اعتماد عمومی، دسترسی مردم به پول و تصور ثبات است. در چند سال اخیر، بخش مالی ایران هم هدف اخاذی و سرقت بوده، هم هدف عملیات اختلالی و روانی. این سابقه، احتمال حمله در رخداد اخیر را معنادار میکند، اما جایگزین شواهد فنی برای انتساب، تعیین سطح نفوذ یا اثبات نشت داده نمیشود.
پرسشهای اصلی هنوز بیپاسخاند: هسته خدماتی مشترک دقیقاً کدام سامانه یا مجموعه سامانهها بود؟ حمله فقط بانک ملی را هدف گرفت یا زیرساخت مشترک چند بانک را؟ اگر DDoS بود، چرا بازیابی اینقدر طول کشید؟ اگر فراتر از DDoS بود، سطح دسترسی مهاجم چه بود؟ وضعیت DR، failover، قطع دفاعی، تغییر سختافزار و نقش گروههایی مانند TRoLL Team هنوز به گزارش فنی نیاز دارد.
حتی اگر TRoLL Team بزرگنمایی کرده باشد، حتی اگر دادهای نشت نکرده باشد و حتی اگر بخشی از قطعیها تصمیم دفاعی بوده باشد، رخداد اخیر یک واقعیت مهم را نشان داد: زیرساخت مالی ایران در لایه خدمات مشترک، از نظر تمرکز ریسک، بازیابی و اطلاعرسانی حادثه آسیبپذیر است. امنیت بانکی فقط این نیست که مهاجم وارد شده یا نه؛ امنیت یعنی مردم در زمان بحران همچنان به پول، کارت، انتقال وجه و خدمات ضروری خود دسترسی داشته باشند.