همایش «چشمانداز اقتصاد ایران ۱۴۰۵» در تاریخ بیستونهم و سیام تیر در هتل المپیک تهران برگزار شد و پویا پیرحسینلو، همبنیانگذار و مدیرعامل آروانکلاد هم یکی از سخنرانهای این همایش بود. پیرحسینلو در دومین روز همایش با موضوع «بانکها و اقتصاد ابری» دربارهی ضرورت وجود و استفاده از یک معماری زیرساخت ابری مناسب گفت. بهنظر او این زیرساخت برای زمان پیش، حین و پس از بحران در خدمات مالی و بانکی میتواند به تداوم کسبوکارها در زمان رخدادهای ناگهانی کمک کند.
مواجههی جن و بسمالله بانکها با زیرساختهای ابری!
ماجرای آمادگی پس از حادثهها برای برخی از صنایع مالی و بانکی، شبیه فردی است که پس از مواجهه با «جن»، تازه به یاد گفتن بسمالله میافتد؛ یا شبیه وضعیتی است که شهابسنگها به زمین نزدیک شدهاند و انسان تازه در آن لحظه به دنبال راهحل میگردد؛ احتمالن میتوان حدس زد که در چنین زمانی، دیگر کمی دیر شده است!
برای دقیقتر شدن در این مساله باید به وضعیت اقتصاد دیجیتال در یک سال گذشته توجه کنیم؛ وضعیتی که بهطور جزییتر روی صنعت بانکداری کشور آسیبهای بسیار جدی و در مواردی جبرانناپذیر وارد کرده است. در چنین آسیبهایی، مهمترین مساله از بین رفتن اعتماد است، بنابراین در این وضعیت باید به این فکر کنیم که با چه اقداماتی میتوانیم این آسیبها را کاهش دهیم تا در بلندمدت، اعتماد به اقتصاد دیجیتال کشور برگردد.
اگر دوباره بخواهیم به رخدادهایی که اتفاق افتاد نگاه کنیم اهمیت پیشگیری از بحران در وضعیت خاص و ناگهانی بیشتر روشن میشود. هنگامیکه اینترنت قطع میشود، تنها یک ابزار ارتباطی از دسترس خارج نمیشود، بلکه پایهها و ریشههای فعالیت اقتصادی دچار اختلال میشوند. با این حال، مساله تنها به قطعی اینترنت محدود نیست؛ خارجشدن سامانهها از شبکه، از دسترس خارجشدن سرویسها و بستهشدن درگاهها نیز بخشی از پیامدهای بحران است.
در بعضی موارد اعلام شد که حمله به دلیل عوامل سختافزاری رخ داده و از آنجا که برخی تجهیزات آمریکایی بودهاند، احتمال وجود «Backdoor» در آنها مطرح شده است. اما پذیرش چنین توضیحی، درعمل نوعی سلب مسوولیت و پذیرفتن تسلیم در برابر مساله است. این بحث را میتوان به سه بخش تقسیم کرد؛ نخست، موضوعی است که از آن با عنوان Backdoo سختافزاری یاد میشود. در برندهای معتبر، تقریبن گزارش اتکاپذیری نداریم که نشان دهد تولیدکننده بهطور عمدی در تجهیزات خود Backdoo قرار داده است. البته در تجهیزات شرکتهایی مانند Cisco و سایر برندهای بزرگ، گزارشهایی دربارهی آسیبپذیریهای Zero Day منتشر شده، اما «بکدور» و «آسیبپذیری روز صفر» دو موضوع متفاوت هستند.
هنگامیکه از «بکدور» صحبت میکنیم، منظور این است که سازندهی سختافزار بهشکل عمدی راهی پنهان در محصول قرار داده و مسیر حمله را رایگان یا در ازای پول در اختیار هکرها گذاشته است که گزارش اتکاپذیری برای چنین ادعایی درباره برندهای معتبر دردسترس نیست.
تفاوت بکدور و آسیبپذیری روز صفر در چیست؟
«آسیبپذیری روز صفر» یا Zero-day به ضعفی گفته میشود که هنوز بهشکل عمومی منتشر نشده، اما یک گروه هکری میتواند از آن بهرهبرداری کند و به سیستم نفوذ داشته باشد. ممکن است در برخی فرضیات، چنین آسیبپذیریای با همکاری سازنده ایجاد شده باشد، اما همانطور که گفتم گزارش معتبری برای این ادعا دردسترس نیست. بهعلاوه، در حملهی زنجیرهی تامین، یک عامل مخرب در مسیر تولید، تامین یا توزیع سختافزار قرار میگیرد و از راه تغییر Firmware یا روشهای دیگر، یک «بکدور» یا سامانهی مخرب را روی تجهیزات نصب میکند و بعدتر از آن برای آسیبزدن استفاده میشود. دربارهی حملاتی که در یک سال گذشته در ایران اتفاق افتاده، هیچ گزارش معتبری وجود ندارد که نشان دهد این حملات بر پایهی آسیبپذیری روز صفر یا بکدور سختافزاری انجام شدهاند. اگر چنین اتفاقی در تجهیزات یک برند معتبر رخ داده باشد، احتمالن اتفاقی کمسابقه و حتا بینظیر در جهان خواهد بود.
بنابراین بهجای آنکه مسوولیت را از خودمان سلب کنیم و بگوییم سازندگان آمریکایی چنین کاری انجام دادهاند، بهتر است بررسی کنیم چه بخشهایی را میتوان اصلاح کرد و برای اقدامات بعدی برنامه داشت. باید بپرسیم آیا بهدرستی تمام مسیرهای نفوذ شناختهشده را بسته بودیم؟ و مهاجمان ناچار شدند از یک آسیبپذیری ناشناخته استفاده کنند؟ یا آنکه اصول و اقدامات شناختهشده امنیتی را بهدرستی اجرا نکرده بودیم؟
بهعلاوه، با وجود گزارشهایی که پس از حمله ارایه شد، در یکی از بانکها مهاجمان از یک آسیبپذیری One-day استفاده کرده بودند؛ یعنی آسیبپذیریای که پیشتر منتشر شده، جزییات و حتا ابزار بهرهبرداری از آن در اینترنت وجود داشته و سازمان نیز میتوانسته از وجود آن آگاه باشد.
تابآوری و معماری چندشهری؛ مساله این است!
با اشارهای به جملهی معروف «بودن یا نبودن» از نمایشنامهی «هملت» این پرسش مطرح میشود که آیا باید ضربهها و مشکلات روزگار را تحمل کنیم یا سلاح به دست بگیریم و با انبوه مشکلات بجنگیم؟ اگر گزینهی دوم را انتخاب کنیم، مسیر پیشرو خالی نیست و اقدامات بزرگ و متعددی وجود دارد که میتوان انجام داد.
قرار نیست یک تجهیز یا راهکار واحد، تمام مشکلات امنیت و تابآوری بانکداری را حل کند. در این بحث تنها میخواهم بر یکی از بخشهای مساله تمرکز کنم و آن، معماری سامانههاست. پرسش این است که آیا بانکهای ما معماریهای دقیق و مناسبی برای تابآوری در وضعیت بحرانی داشتهاند یا خیر؟ پاسخ این سوال برای همهی ما تا حد زیادی روشن است.
در سادهترین حالت، دادهها تنها در یک نقطه ذخیره و نگهداری میشوند. ممکن است چند نسخه یا چند نمونه از داده وجود داشته باشد، اما همهی آنها همچنان در یک موقعیت جغرافیایی قرار گرفتهاند. در مرحلهی بعد، بهجای ذخیرهسازی چند نمونه در یک نقطه، داده در چند Rack یا چند بخش متفاوت یک مرکز داده نگهداری میشود. در سطح بالاتر، اطلاعات تنها در یک دیتاسنتر ذخیره نمیشود، بلکه در چند مرکز دادهی متفاوت قرار میگیرد. این الگو را میتوان معماری چندناحیهای یا Multi-AZ دانست که معمولن در محدودهی یک شهر اجرا میشود.
بهعلاوه، استانداردهای این حوزه پیشنهاد میکنند که دستکم سه دیتاسنتر با فاصلهای کمتر از حدود ۵۰ کیلومتر از یکدیگر وجود داشته باشند تا ارتباط با تاخیر بسیار پایین برقرار شود. اجرای چنین الگویی هزینهها را افزایش میدهد، اما باعث میشود بعد از حملهی فیزیکی یا از دسترس خارجشدن یک مرکز داده، پایداری سرویس حفظ شود. از نکتههای مهم دیگر در این زمینه هم باید گفت که معماری چند ناحیهای یا Multi-AZ خوب است اما برای همهی سطوح خصوصن سطوح حساس مناسب نیست. برای سامانههای بحرانی و حساس مانند بانکها، معماری موردنیاز باید یک سطح بالاتر باشد. در این حالت، تنها ذخیرهسازی داده در چند مرکز داده داخل یک شهر کافی نیست، بلکه باید اطلاعات در یک یا چند دیتاسنتر در شهرهای مختلف و با فاصله بیش از ۲۰۰ کیلومتر از مرکز اصلی نیز ذخیره و پردازش شود. این همان معماری چندمنطقهای یا Multi-region است. علاوهبر این، وجود ساختارهای ایزوله، نسخههای پشتیبان قفلشده و BackUpهایی که امکان تغییر یا حذف آنها وجود نداشته باشد نیز بخشی از یک معماری کامل و تابآور است.
چرایی اجرایی نشدن این معماری
این معماری، معماری جدیدی نیست اما متاسفانه اجرایی نمیشود. این موضوع سالهاست در معماری سامانههای بانکی جهان شناخته شده است. اگر این اصول را برای یک متخصص بانکی در کشورهای دیگر توضیح دهید، ممکن است تعجب کند که چرا موضوعی تا این اندازه روشن، هنوز برای ما مساله محسوب میشود! اگر همه این موضوع را میدانند، پرسش این است که چرا اجرایی نمیشود؟ دربارهی دلایل ذهنی، سازمانی و مدیریتی که مانع از این تصمیمگیری میشود، میتوان کتابها و مقالات متعددی نوشت، اما یکی از دلایل اصلی، هزینهی بسیار بالای اجرای معماری چندناحیهای و چندمنطقهای در ساختار سنتی است.
شاید مهمترین دلیل اجرایی نشدن این معماری، هزینهی سنگین آن برای بانکهاست. برای اجرای این معماری به روش سنتی، بانک باید دیتاسنترهای اختصاصی خود را داشته باشد؛ برای نمونه سه دیتاسنتر در تهران، چند دیتاسنتر در خارج از تهران و یک شبکهی اختصاصی که همهی آنها را به یکدیگر متصل کند. هزینهی این پروژه آنقدر بالا میرود که در عمل اجرای آن بسیار دشوار یا حتا غیرممکن میشود.
فناوری Cloud برای نخستینبار اصل این مساله را کشف نکرده است. پیش از فناوری ابری نیز در ساختارهای زیرساختی و فناوریهای مجازیسازی، راهکارهایی مانند Mirror و معماریهای چندمرکزی وجود داشتهاند. البته که میتوان با استفاده از راهکارهای ابری هزینهها را تا حد چشمگیری پایین آورد و این مسیر را سادهتر، دسترسپذیرتر و اقتصادیتر کرده است.
دربارهی اطمینان استفاده از فناوری ابری هم موسسههای پژوهشی معتبری، سالهاست که گزارشهای مختلفی منتشر میکنند و نشان میدهند که بانکهای جهان چگونه از زیرساختهای کلاد استفاده میکنند و این فناوری تا چه میزان در افزایش تابآوری، کاهش هزینه و تسریع توسعهی خدمات به آنها کمک کرده است.
بنابراین میتوان ادعا کرد که اگر سازمانها چشمانداز درست و ۵ساله یا ۱۰سالهای نداشته باشند، نمیتوانند برای بقا و انجام این تحول برنامهریزی کنند. اگر بانکهای ایران به سمت این تغییر حرکت نکنند، نهتنها مشکلات فعلی برطرف نمیشوند، بلکه همزمان با پیشرفت فناوری، فاصلهی آنها با نظام بانکی جهان بیشتر خواهد شد. تیمهای امنیتی باید بهجای اصرار بر برخی سیاستهایی که ممکن است متعلق به گذشته باشند، بررسی کنند که چه محدودیتهایی واقعن برای امنیت ضروریاند؟ و کدام محدودیتها به بهانهی امنیت ایجاد شدهاند؟ چراکه امروزه میبینیم که بخشی از اقداماتی که در گذشته با هدف حفاظت از سازمانها انجام شده، امروز خود به پاشنهآشیل بانکها و سازمانهای بزرگ تبدیل شده است.
مهاجرت ۳۴درصدی به کلاد
با توجه به اهمیت معماری و زیرساخت درست برای بانکداریها و ضرورتی که بالاتر اشاره شد، برخی آمارهای جهانی هم در ادامه خواهد آمد تا تصویر درستتری از اهمیت موضوع داشته باشیم:
سرویسهای بانکی را میتوان به چهار دستهی کلی تقسیم کرد؛ سامانههای اصلی یا Core Banking، سرویسهای جانبی و کانالهایی مانند موبایلبانک، سرویسهای پرداخت و سامانههای داخلی مورد استفاده خود بانکها. در دستههای مختلف سرویسهای بانکی، آمار مهاجرتی متفاوتی وجود دارد؛ Core Banking حساسترین و قدیمیترین بخش نرمافزاری بانکهاست و به همین دلیل، کمترین نرخ مهاجرت به کلاد را دارد. با این حال، نرخ استفادهی جهانی از «کلاد» حتا در این بخش هم به حدود ۱۰ درصد رسیده است. در سرویسهای جانبی، پرداختی و سامانههای جدیدتر، نرخ استفاده از کلاد بهمراتب بالاتر است. Core Banking بهدلیل قدمت و حساسیت زیاد، با فاصلهی زمانی بیشتری وارد این مسیر میشود.
در یک بررسی که حدود ۱۰۰ بانک را بهعنوان نمونه مورد مطالعه قرار داده، مشخص شده است که در آمریکای شمالی حدود ۳۴ درصد بانکها بخشی از سرویسهای خود را به کلاد منتقل کردهاند و ۴۴ درصد نیز برای انجام این کار برنامه دارند. براساس بخشی از آمارهای ارایهشده، نرخ استفاده یا برنامهریزی برای استفاده از کلاد در میان بانکهای آمریکایی به حدود ۷۸ درصد میرسد؛ در حالی که تا سال ۲۰۲۲، میانگین مهاجرت کامل برخی بخشها در اروپا حدود هفت درصد بوده است. اینکه در آمریکا یا کشورهای دیگر نیز نرخ استفاده از کلاد هنوز به ۱۰۰ درصد نرسیده، نباید بهانهای برای متوقفکردن حرکت باشد.
نکتهای که دربارهی صنایع مالیوبانکی وجود دارد آن است که نمیتوان انتظار داشت که یک بانک صبح تصمیم بگیرد و روز بعد همهی سامانههای خود را به کلاد منتقل کند. این تحول یک مسیر تدریجی است. معمولن ابتدا سرویسهای کوچکتر و کمریسکتر به کلاد منتقل میشوند، سپس بخشهای بزرگتر و در نهایت سامانههای اصلی بانکی وارد این معماری میشوند. دشواری این تغییر گاهی نیز از سمت تیمهای فناوری و کلاد است، گاهی سنگهای بزرگی پیش پای خودمان قرار میدهیم که حرکت بانکها را در مسیر تحول دیجیتال غیرممکن میکند. تیمهای فناوری و کلاد هم گاهی در وضعیتی شبیه همان ضربالمثل شترمرغ قرار میگیرند؛ زمانی که از آنها انتظار حمل بار میرود، به پرندهبودنشان اشاره میشود و وقتی انتظار پرواز وجود دارد، شتربودن آنها یادآوری میشود. در نتیجه، نه اجازه اجرای کامل فناوری داده میشود و نه مسوولیتها متناسب با اختیارات تعریف میشوند.
درنهایت باید گفت که معماری چندمنطقهای، در کنار معماری کامل و اصولی سامانهها، باید به هدف اصلی ما تبدیل شود. این موضوع برای همهی متخصصان بانکی روشن است، اما نقطهضعف امروز ما این است که از ظرفیتهای موجود به اندازهی کافی استفاده نمیکنیم. کلاد بهتنهایی راهکار کامل حل مساله نیست. بانکهای ما برای افزایش تابآوری باید به سمت معماریهای چندشهری و چندمنطقهای حرکت کنند. کلاد تنها یک کمککننده و تسهیلگر است که میتواند سرعت ورود خدمات به بازار را افزایش دهد، مدیریت ریسک را بهبود ببخشد و هزینهها را کاهش دهد. برای بهرهمندی از آن لازم است تصویری یکپارچه از افق پیشرو داشته باشیم، معیارهای جهانی را کامل و دقیق بررسی کنیم، بهترین تجربهها را از نقاط مختلف جهان برداریم و متناسب با نیاز صنعت و کشور خود از آنها استفاده کنیم.
