بانکی که در دسترس نیست، امن نیست

به گزارش سیتنا، رضا قربانی، نائب رئیس کمیسیون تحول، نوآوری و بهره‌وری اتاق بازرگانی تهران در کنکاش شماره 128 ماهنامه نسل چهارم آورده است:

اختلال اخیر چهار بانک نشان داد مسئله شبکه بانکی ایران فقط جلوگیری از نفوذ و سرقت اطلاعات نیست؛ امنیت زمانی معنا پیدا می‌کند که بانک بتواند در میانه بحران نیز خدمات اصلی خود را ادامه دهد، بازیابی کند و درباره آنچه رخ داده پاسخگو باشد.

صبح از خواب بیدار شده‌اید و باید تا ظهر حساب جاری را پر کنید. پول در حساب دیگری است، اما همراه‌بانک باز نمی‌شود. کارت‌به‌کارت انجام نمی‌شود. اینترنت‌بانک در دسترس نیست و شعبه هم پاسخ روشنی نمی‌دهد. شما پول دارید، اما نمی‌توانید آن را جابه‌جا کنید. چند ساعت بعد، چک برگشت می‌خورد و سامانه اعتباری شما را نه به‌عنوان قربانی یک اختلال بانکی، بلکه به‌عنوان مشتری بدحساب می‌شناسد.

برای آن مشتری، تفاوت چندانی ندارد که مهاجم به اطلاعات حسابش دست پیدا کرده باشد یا نه. او در ساعتی که به بانک نیاز داشته، بانکی در اختیار نداشته است.

اختلال اخیر در خدمات بانک‌های ملی، صادرات، تجارت و توسعه صادرات را باید از همین زاویه دید. شورای هماهنگی بانک‌ها اعلام کرده بود این اختلال ناشی از یک «حمله سایبری محدود به زیرساخت ارتباطی مشترک» بوده و دسترسی غیرمجاز به اطلاعات مشتریان یا حذف داده‌ها رخ نداده است. بانک مرکزی نیز تأکید کرد سامانه‌های حاکمیتی مانند شتاب و شاپرک درگیر این اختلال نبوده‌اند. این اطلاع‌رسانی، به‌ویژه درباره سلامت اطلاعات مردم، ضروری و امیدوارکننده است؛ اما همه ماجرا نیست.

در امنیت اطلاعات، سه مفهوم پایه وجود دارد: محرمانگی، یکپارچگی و دسترس‌پذیری. محرمانگی یعنی اطلاعات در اختیار افراد غیرمجاز قرار نگیرد. یکپارچگی یعنی داده‌ها بدون مجوز تغییر یا تخریب نشوند. دسترس‌پذیری نیز یعنی کاربر مجاز بتواند هر زمان که نیاز دارد به سامانه و اطلاعات خود دسترسی داشته باشد. بنابراین، اگر هیچ داده‌ای سرقت نشده باشد، اما مشتری نتواند به حساب، کارت، پول نقد یا خدمات بانکی دسترسی پیدا کند، یکی از پایه‌های امنیت آسیب دیده است.

تقلیل امنیت بانکی به جمله «اطلاعات مشتریان نشت نکرده است» شبیه آن است که درباره بیمارستانی که برق آن قطع شده بگوییم پرونده پزشکی بیماران دزدیده نشده است. درست است؛ اما دستگاه‌های درمانی هم از کار افتاده‌اند. بانکداری دیجیتال فقط مجموعه‌ای از پایگاه‌های داده نیست که باید از چشم مهاجم دور بماند. بانکداری دیجیتال یک خدمت پیوسته است که حقوق، مستمری، خرید روزانه، چک، اقساط، مالیات، ضمانت‌نامه و گردش نقدینگی کسب‌ وکارها به آن وابسته است.

بانک خدمتی نیست که بتوان در زمان بحران موقتاً آن را کنار گذاشت. بانک بخشی از زیرساخت زندگی روزمره است. پولی که نتوان آن را منتقل کرد، هرچند برای چند ساعت، عملاً بخشی از کارکرد خود را به‌عنوان پول از دست می‌دهد.

به همین دلیل، ادبیات حرفه‌ای بانکداری در جهان سال‌هاست از تمرکز صرف بر امنیت سایبری عبور کرده و به تاب‌آوری عملیاتی رسیده است. کمیته بال تعریف ساده و دقیقی ارائه می‌کند: «تاب‌آوری عملیاتی یعنی توان بانک برای ادامه ارائه خدمات اصلی هنگام وقوع اختلال.» در این نگاه، بانک باید فرض کند اختلال دیر یا زود رخ خواهد داد. پرسش این نیست که آیا حادثه‌ای اتفاق می‌افتد یا نه؛ پرسش این است که بانک چه میزان اختلال را تاب می‌آورد، کدام خدمات را فعال نگه می‌دارد و با چه سرعتی به وضعیت پایدار بازمی‌گردد.

این تغییر زاویه مهم است. وقتی تمام توجه بر جلوگیری از ورود مهاجم متمرکز شود، مدیران ممکن است دیوارهای بلندتری بسازند، دسترسی‌ها را محدودتر کنند و سامانه‌ها را بیش از پیش از محیط بیرونی جدا کنند. اما مسیر ورود مهاجم فقط اینترنت عمومی نیست. دسترسی یک پیمانکار، حساب کاربری آلوده، نیروی داخلی، به‌روزرسانی مخدوش، زنجیره تأمین، تجهیزات قدیمی یا حتی یک خطای عملیاتی، هرکدام می‌تواند آغازگر بحران باشد.

هیچ دیواری نفوذناپذیر نیست. امنیت واقعی از جایی آغاز می‌شود که سازمان بپذیرد ممکن است این دیوار فرو بریزد.
در چنین شرایطی، سؤال اصلی این است که پس از شناسایی نخستین نشانه غیرعادی چه اتفاقی می‌افتد. آیا محیط آلوده به‌سرعت از مدار خارج می‌شود؟ آیا مرکز پشتیبان واقعاً آماده تحویل بار عملیاتی است؟ آیا نسخه پشتیبان سالم، به‌روز و مستقل وجود دارد؟ آیا تراکنش‌های معلق قابل شناسایی و تطبیق هستند؟ آیا بانک می‌تواند حداقل خدمات ضروری را از یک مسیر جایگزین ارائه کند؟

اطلاعاتی که تاکنون منتشر شده نشان می‌دهد بازیابی این چهار بانک با پیچیدگی جدی همراه بوده است. مدیرعامل شرکت خدمات انفورماتیک از نگهداری اطلاعات در چند موقعیت جغرافیایی، زمان‌بر بودن بازیابی، استفاده از مین‌فریم‌های فاقد پشتیبانی رسمی سازنده و تکرار رخدادی مشابه پس از یک مرحله بازیابی سخن گفته است. بنابراین، با یک قطعی ساده روبه‌رو نبودیم که با روشن کردن چند سرور پایان یابد. مسئله، بازگرداندن سامانه‌های چند بانک بزرگ، بدون ایجاد مغایرت در حساب‌ها و تراکنش‌ها بوده است.

این توضیحات بخشی از ابهام را برطرف می‌کند، اما پرسش مهم‌تری را پیش می‌کشد: اگر اطلاعات در چند موقعیت جغرافیایی نگهداری می‌شده و مراکز پشتیبان وجود داشته‌اند، چرا بازگشت پایدار خدمات تا این اندازه دشوار و زمان‌بر شده است؟

داشتن مرکز داده پشتیبان با داشتن قابلیت بازیابی یکسان نیست. مرکز پشتیبانی که سوئیچ به آن آزمایش نشده باشد، نسخه پشتیبانی که صحت آن به‌طور مستمر راستی‌آزمایی نشده باشد و برنامه تداوم کسب ‌وکار که فقط در قالب سند و نمودار باقی مانده باشد، هنگام بحران کار چندانی از پیش نمی‌برد. نسخه پشتیبان باید قابل بازگردانی باشد، مرکز جایگزین باید توان تحمل بار واقعی را داشته باشد و کارکنان باید پیش از وقوع حادثه، سناریوی خروج از محیط اصلی را بارها تمرین کرده باشند.

در شبکه بانکی، دو شاخص از همین‌جا اهمیت پیدا می‌کند: زمان هدف بازیابی (RTO) و نقطه هدف بازیابی (RPO). اولی مشخص می‌کند هر خدمت حداکثر چه مدت می‌تواند از دسترس خارج بماند. دومی نشان می‌دهد بانک در بدترین حالت، از دست رفتن چه میزان از آخرین داده‌ها را می‌تواند تحمل کند. ممکن است برای یک سامانه داخلی، توقف چندساعته قابل‌تحمل باشد؛ اما آیا همین زمان برای کارت، انتقال پول، اعلام موجودی، چک یا واریز حقوق نیز پذیرفتنی است؟

هنوز نمی‌دانیم استاندارد الزام‌آور بانک مرکزی برای RTO و RPO بانک‌های بزرگ چیست، این چهار بانک چه اعدادی را تعهد کرده‌اند و آیا در رخداد اخیر از محدوده مجاز عبور کرده‌اند یا نه. بدون انتشار این سنجه‌ها، عبارت‌هایی مانند «بازیابی در کوتاه‌ترین زمان ممکن» عملاً قابل ارزیابی نیستند. کوتاه‌ترین زمان ممکن برای مدیر فنی، نهاد ناظر، صاحب کسب ‌وکار و مشتری‌ای که چک او برگشت خورده، الزاماً یک معنا ندارد.

رخداد اخیر واقعیت دیگری را نیز آشکار کرد: وابستگی چند بانک بزرگ به یک زیرساخت یا ارائه‌دهنده مشترک می‌تواند ریسک یک شرکت را به ریسک کل شبکه تبدیل کند. اشتراک زیرساخت به‌خودی‌خود اشتباه نیست. استفاده از یک ارائه‌دهنده تخصصی می‌تواند هزینه‌ها را کاهش دهد، استانداردسازی ایجاد کند و کیفیت عملیات را بالا ببرد. مسئله از جایی آغاز می‌شود که این تمرکز، بدون مسیر خروج، بدون جایگزین واقعی و بدون امکان مهاجرت اضطراری شکل گرفته باشد.

وقتی خرابی یک نقطه بتواند هم‌زمان چند بانک و میلیون‌ها مشتری را تحت تأثیر قرار دهد، دیگر با یک قرارداد معمولی برون‌سپاری روبه‌رو نیستیم؛ با تمرکز ریسک در یک نقطه حساس مواجه‌ایم. کمیته بال نیز در اصول مدیریت ریسک اشخاص ثالث، وابستگی گسترده بانک‌ها به تأمین‌کنندگان و تمرکز خدمات نزد تعداد محدودی از آن‌ها را یکی از مهم‌ترین مخاطرات تاب‌آوری عملیاتی می‌داند.

پاسخ به این مسئله، الزاماً پراکنده کردن بی‌قاعده زیرساخت‌ها یا مهاجرت شتاب‌زده نیست. مهاجرت اضطراری خود می‌تواند منشأ مغایرت داده، آسیب امنیتی و اختلالی تازه باشد. آنچه لازم است، معماری خروج است؛ یعنی بانک پیش از بحران بداند چگونه می‌تواند بخشی از خدمات را به زیرساخت جایگزین منتقل کند، داده‌ها را تطبیق دهد و اگر مهاجرت با شکست روبه‌رو شد، به وضعیت قبلی بازگردد.

موضوع «مین‌فریم» نیز نباید به یک نزاع ساده میان «فناوری قدیمی» و «فناوری جدید» تبدیل شود. مین‌فریم‌ها در بسیاری از بانک‌های بزرگ جهان همچنان به دلیل پایداری، ظرفیت پردازش و کنترل‌پذیری مورد استفاده قرار می‌گیرند. از سوی دیگر، هر فناوری زمانی قابل اتکاست که قطعه، به‌روزرسانی، مستندات، نیروی متخصص و پشتیبانی آن در دسترس باشد. خروج از مین‌فریم لزوماً به معنای افزایش امنیت نیست و باقی ماندن روی مین‌فریم نیز به‌خودی‌خود پایداری ایجاد نمی‌کند. امنیت محصول نام سخت‌افزار نیست؛ محصول معماری، نگهداری، مهارت، آزمون و حکمرانی است.

اما شاید مهم‌ترین کاستی رخداد اخیر نه در اتاق سرور، بلکه در شیوه اطلاع‌رسانی پس از حادثه باشد. تا زمان نگارش این یادداشت، توضیحات رسمی پراکنده‌ای درباره منشأ کلی حمله، سلامت داده‌ها، روند بازیابی و استفاده از زیرساخت‌های جایگزین منتشر شده است؛ اما هنوز گزارش عمومی و مستقلی که خط زمانی حادثه، دامنه اثر، علت ریشه‌ای، زمان شناسایی، نحوه مهار و درس‌های آموخته‌شده را یکجا کنار هم قرار دهد، در دسترس نیست.

انتشار گزارش پساحادثه به معنای افشای جزئیاتی نیست که مهاجمان بتوانند از آن سوءاستفاده کنند. می‌توان سه سطح گزارش ارائه کرد: نسخه فنی و محرمانه برای نهاد ناظر، نسخه تخصصی برای مدیران بانکی و نسخه عمومی برای مردم. نسخه عمومی لازم نیست آدرس سرورها یا آسیب‌پذیری‌ها را فاش کند. کافی است روشن کند چه خدماتی آسیب دیده‌اند، چه مدت از دسترس خارج بوده‌اند، آیا داده‌ای از بین رفته یا نیاز به تطبیق داشته است، چه اقدام‌های اصلاحی انجام شده و چه نهادی صحت این ادعاها را راستی‌آزمایی کرده است.

اطمینان‌بخشی جای اعتمادسازی را نمی‌گیرد. اینکه یک مقام رسمی بگوید اطلاعات مردم سالم است، می‌تواند نگرانی اولیه را کاهش دهد؛ اما اعتماد پایدار زمانی شکل می‌گیرد که یک نهاد مستقل همان ادعا را بررسی و تأیید کند. در غیر این صورت، جامعه ناچار است میان اطلاعیه‌های رسمی، تجربه متفاوت مشتریان و گمانه‌زنی‌های فضای مجازی یکی را انتخاب کند.

پرسیدن درباره علت حادثه به معنای سرزنش قربانی حمله نیست. هر سازمان بزرگی ممکن است هدف حمله قرار گیرد. آنچه باید ارزیابی شود، کیفیت آمادگی، سرعت تشخیص، توان مهار، قابلیت بازیابی و صداقت در گزارش‌دهی است. جمله «مورد حمله قرار گرفتیم» شاید توضیح دهد چه کسی آغازگر بحران بوده، اما توضیح نمی‌دهد چرا دامنه اختلال تا این اندازه گسترش یافت و چرا بازگرداندن پایدار خدمات این‌قدر دشوار شد.

حالا که بخشی از هیاهوی اولیه فروکش کرده، شاید زمان طرح پرسش‌های سخت‌تر رسیده باشد: حداکثر زمان مجاز توقف خدمات این بانک‌ها چقدر بوده است؟ آیا مراکز پشتیبان در لحظه حادثه آماده سوئیچ بوده‌اند؟ آخرین مانور واقعی بازیابی چه زمانی انجام شده بود؟ کدام وابستگی مشترک باعث شد چهار بانک هم‌زمان آسیب ببینند؟ چه نهادی به‌طور مستقل سلامت و یکپارچگی داده‌ها را تأیید کرده است؟ هزینه این اختلال برای مردم و کسب‌وکارها چگونه محاسبه می‌شود؟ مسئولیت بانک‌ها، شرکت‌های زیرساختی و نهاد ناظر در قبال این خسارت چیست؟ و گزارش عمومی این حادثه چه زمانی منتشر خواهد شد؟

تا زمانی که پاسخ روشنی برای این پرسش‌ها وجود نداشته باشد، شاید مسئله اصلی این نباشد که چه کسی به بانک‌ها حمله کرد؛ مسئله این است که چرا یک حمله توانست بانک را، هرچند برای مدتی، از دسترس مردم خارج کند.
بانکی که در دسترس نیست، حتی اگر هیچ داده‌ای از آن سرقت نشده باشد، هنوز بانک امنی نیست.

انتهای پیام