سیدجواد سجادی، مدیرعامل شرکت توسعه ارتباطات الکترونیک تجارت ایرانیان (تاتا) / بانک تجارت از جمله بانکهایی بود که بسیاری از الزامات امنیتی و تابآوری را رعایت کرده بود و حتی پس از جنگ دوازدهروزه نیز بر شدت این اقدامات افزود و از هیچ اقدامی برای استمرار واقعی کسبوکار فروگذار نکرد. مدیران بانک تجارت عمیقاً باور دارند که مشتری تحت هیچ شرایطی نباید با اختلال در سرویس مواجه شود و هرگونه هزینهکرد در این مسیر را سرمایهگذاری در مشتریمداری تلقی میکنند. این اقدامات، از ایجاد سایت پشتیبان در تهران و سایت بحران در شهرستان تا تخصیص خطوط مستقل برق و شبکه برای سایتها، انتقال لحظهای دادهها و سرویسها به این مراکز و تدوین و اجرای واقعی حدود ۳۰ سند BCP در محیط عملیاتی را دربر میگیرد.
درواقع، بانک تجارت نهتنها الزامات افتا و پدافند غیرعامل را موبهمو اجرا کرد، بلکه اقدامات بسیار بیشتری نیز انجام داد. این بانک حتی پس از جنگ دوازدهروزه و وقوع رخداد هک در بانک سپه، چند نسخه سبک از سامانه تحویلداری و سوئیچ کارت تهیه کرد و آخرین اطلاعات مشتریان خود را با اختلاف زمانی نزدیک به یک دقیقه، در چند نقطه ایران نگهداری کرد. بااینحال، زمانی که پای عمل به میان آمد، اگرچه بانک تجارت سربلند ظاهر شد، واقعیتهای دیگری نیز آشکار شد که بخشی از اقدامات پیشین را تا حدی با علامت سؤال مواجه کرد.
وجود سایتهای پشتیبان و بحران و خرید تجهیزات افزونه و جدید برای بانکی که سرویسهای اصلی خود را از یک شرکت پیمانکار دریافت میکند؛ شرکتی که همزمان بهعنوان یکی از شرکتهای برتر ایران به چند بانک دیگر و بانک مرکزی نیز سرویس میدهد، تنها زمانی کارآمد است که اصول دیگری نیز رعایت شود.
اصولاً در حوزه تابآوری باید چهار مفهوم را بهدرستی شناخت و نباید این مفاهیم را با یکدیگر اشتباه گرفت:
- پایداری یا High Availability: معمولاً برای خرابیهای متعارف، مانند از کار افتادن سرور، Storage، پایگاه داده یا یک نود کاربرد دارد. هدف در این حالت، معمولاً بازیابی خودکار در چند ثانیه یا چند دقیقه است.
- Disaster Recovery: برای زمانی است که یک دیتاسنتر، منطقه جغرافیایی، شبکه یا زیرساخت عمده از دست میرود. این وضعیت معمولاً به انتقال سرویس به سایت دیگری نیاز دارد.
- Cyber Recovery: برای زمانی است که دادهها خراب شدهاند، شناسههای مدیریتی تصاحب شدهاند، PAM و IAM آلوده شدهاند یا بدافزار به سایت DR نیز سرایت کرده است. در چنین وضعیتی، Replication سایت اصلی به سایت DR لزوماً Cyber Recovery محسوب نمیشود؛ زیرا خرابی منطقی، حذف اطلاعات یا باجافزار نیز میتواند در سایت دوم Replicate شود.
- Crisis Management: به تصمیمگیری درباره هریک از موارد فوق و مدیریت صحیح رخداد مربوط است؛ بهگونهای که RTO و RPO تضمینشده در هر مورد، مطابق برنامهریزی و تعهد قبلی رعایت شود.
اختلالی که در شرکت خدمات انفورماتیک رخ داد، ناشی از نوعی حمله سایبری بود؛ بنابراین مدیریت بحران باید متناسب با مسئله شماره سه انجام میشد و بیتردید بر سناریوهای از پیش تدوینشده استوار میبود؛ سناریوهایی که هم اقدامات پیشگیرانه برای جلوگیری از وقوع بحران و هم گامهای مواجهه با آن پس از وقوع را دربر میگرفتند.
طرح چند سؤال میتواند ابعاد موضوع را روشنتر کند:
- ۱- آیا سند مدیریت بحران سایبری و برنامهای تمرینشده برای پوشش این رخداد، بهطور اختصاصی برای هر بانک، از قبل در شرکت تدوین شده بود؟
- ۲- آیا شبکه و تجهیزات اصلی بانکها از یکدیگر جدا شده و ایزولاسیون کامل تجهیزات صورت گرفته بود؟
- ۳- آیا نیروهای انسانی پیمانکار در بخشهای عملیاتی هر بانک، از نیروهای فعال در بانکهای دیگر استقلال کامل داشتند؟
- ۴- آیا تمام الزامات امنیتی در سایت شرکتی که مسئولیت کامل امنیت را پذیرفته بود، رعایت شده بود؟
- ۵- آیا نیروی متخصص متناسب با حجم فعالیتهای مورد تعهد برای چند بانک، بهویژه در شرایط بحران، وجود داشت؟
- ۶- آیا نسخهای مجزا، پاک و ایزوله از سامانه جامع بانکی، با امکان راهاندازی در RTO مورد تعهد، وجود داشت؟
- ۷- آیا نوع اختلال بهدرستی و با سرعت کافی تشخیص داده شد؟
- ۸- آیا علت رخداد بر اساس چکلیستی از پیش تدوینشده تشخیص داده شد؟
- ۹- چه عواملی میتوانست زمان رفع اختلال را از ۳۵ روز به کمتر از یک روز کاهش دهد؟
- ۱۰- آیا از تمام امکانات سختافزاری و محیطی که پیشتر از سوی بانکها تهیه شده بود، به بهترین شکل استفاده شد؟
پاسخ به پرسشهای فوق باید برای همه ما در شبکه بانکی در دستور کار قرار گیرد. بیتردید، هنوز تا رسیدن به پاسخهای روشن فاصله زیادی داریم؛ اما اگر بخواهیم از درسآموختههای این رخداد بهدرستی بهره ببریم، میتوان بر پایه تجربههای کسبشده و مطالعات انجامشده، موارد زیر را بهطور خلاصه پیشنهاد کرد. بدیهی است جزئیات فراوانی نیز وجود دارد که باید با مشارکت تیمهای عملیات و امنیت بانکها و شرکتهای فناوری، بهصورت تفصیلی در دستور کار قرار گیرد:
یک؛ دو بال برای ایستادن، یک ققنوس برای برخاستن
از معماری سهسایته بهره ببریم؛ به این شکل که سایتهای ۱ و ۲ برای Availability و Disaster Recovery و سایت ۳ برای Cyber Recovery در نظر گرفته شوند. به بیان دیگر، در دو خانه به مسیر ادامه میدهیم و در خانه سوم دوباره متولد میشویم. دو سایت نخست، ضامن تداوم و بازیابی خدمتاند و سایت سوم، پناهگاهی امن برای برخاستن از خاکستر یک حمله سایبری است.
دو؛ سرورها کالبدند و دادهها جان
به یاد داشته باشیم که استمرار دادهها از روشن ماندن سرورها مهمتر است. اطلاعات مشتریان را تا حد امکان در کاملترین شکل، اما در قالبهای مختلف و روی منابع سختافزاری متفاوت، بهصورت متمرکز و غیرمتمرکز و در دو حالت آنی و با فاصله زمانی نگهداری کنیم. همه قواعد مرتبط با شرایط بحران را برای دادهها رعایت کنیم. داده را باید همچون حافظه یک ملت نگه داشت: در چند قالب، روی چند بستر و در چند مکان؛ بخشی بهصورت همزمان برای تداوم خدمت و بخشی با فاصله زمانی برای نجات از خطا و حمله.
سه؛ دژ خاموش، اما همیشه گوشبهزنگ
نسخهای پاک و کامل از سامانه جامع بانکی را در دژی جدا از شبکه و کالبد سایتهای عملیاتی نگهداری کنیم؛ نسخهای با تمام پیوندها، قواعد و وابستگیهایش که بهطور مستمر آزموده شود و کوچکترین تغییر در رگهای سیستمعامل، پایگاه داده و میانافزارهای آن ثبت و پایش شود؛ تا در روز بحران، آنچه بیدار میشود نه نسخهای فراموششده، بلکه سامانهای سالم، شناختهشده و آماده خدمت باشد.
همچنین باید نسخهای آماده از برنامههای نصبشده سامانه جامع بانکی را در محیطی ایزوله و جدا از سایتهای ۱ و ۲، همراه با تمام ارتباطات آن با سیستمهای جانبی، در اختیار داشته باشیم؛ محیطی که هم از نظر شبکهای و هم از نظر فیزیکی از سایتهای ۱ و ۲ مجزا باشد و با حفاظت کامل امنیتی و آزمونهای مستمر BCP همراه شود. همچنین باید همواره گزارشی از تغییرات فایلهای سیستمی سیستمعامل، پایگاه داده، میانافزارها و سایر اجزا تهیه، ثبت و بررسی شود.
چهار؛ همزاد را با پشتیبان اشتباه نگیریم
Replication، تصویر زنده امروز است و Backup، حافظه امن دیروز؛ یکی برای ادامه خدمت و دیگری برای بازگشت از خطا و آلودگی. دادههای CDC را نیز باید بیرون از قلمرو فناوری اصلی، روی بستری مستقل و با پایگاه دادهای از برندی متفاوت نگهداری کرد؛ تا اگر یک ضعف، خرابی یا آسیب مشترک، همه سامانههای همخانواده را گرفتار کرد، نسخهای ناهمریشه برای نجات باقی مانده باشد.
پنج؛ قایق نجات، بیرون از بندرهای اصلی
در مکانی امن و مستقل از هر سه سایت، نسخهای سبک اما زنده از سوئیچ کارت و سامانه جامع بانکی نگهداری کنیم؛ سامانهای که شاید در روز بحران، بیش از همه معماریهای پیچیده به کار آید. هرچه این نسخه کاملتر، آزمودهتر و خودکفاتر باشد، بانک در سختترین روزها امکان بیشتری برای ادامه خدمت خواهد داشت؛ زیرا گاهی نجات یک ناو بزرگ، نه از بندر چهارم، بلکه از قایق نجاتی آغاز میشود که همواره آماده حرکت است.
شش؛ نه یک قلعه عظیم، بلکه شبکهای از دژهای هماهنگ
فناوریها، پیمانکاران و اجزای سامانه میتوانند متفاوت باشند، اما باید با زبان مشترک سرویسها، موسیقی واحدی بنوازند. سوئیچ کارت، سپرده، تحویلداری، دفتر کل، تسهیلات، تعهدات و کانالها نباید همگی به یک ریشه، یک فناوری و یک تأمینکننده وابسته باشند؛ زیرا در ارکستری که تنها یک ساز دارد، شکستن همان ساز به معنای پایان موسیقی است. معماری تابآور، تنوع را در زیرساخت میپذیرد، استقلال را در اجزا حفظ میکند و یکپارچگی را در تجربه مشتری میسازد؛ بهگونهای که با خاموش شدن یک ساز، آهنگ خدمت همچنان ادامه یابد.
هفت؛ امنیت را نمیتوان خرید؛ باید آن را در رگهای سازمان ساخت
انباشت ابزار، دیوار امنیت نمیسازد؛ بهویژه زمانی که زنجیره تأمین سختافزار و نرمافزار، خود به مسیری برای نفوذ، وابستگی یا اختلال تبدیل شده باشد. امنیت اثربخش از خرید تجهیزات آغاز نمیشود، بلکه از شناخت داراییها، معماری صحیح، نیروی متخصص، فرایندهای آزموده، پایش مستمر و تصمیمگیری آگاهانه شکل میگیرد. بحرانها نشان دادهاند تجهیزاتی که فقط برای تکمیل فهرستهای نظارتی خریداری میشوند، نهتنها سازمان را ایمن نمیکنند، بلکه هزینه، پیچیدگی و وابستگی میآفرینند و بازار انحصاری تأمینکنندگان را تقویت میکنند. بانک تابآور، بهجای ویترینی از ابزارهای امنیتی، به نظامی دفاعی، زنده، هوشمند و قابل اثبات نیاز دارد؛ نظامی که در آن، هر ابزار پاسخی به یک ریسک واقعی باشد، نه مدرکی برای عبور از یک ممیزی.
هشت؛ ساخت آینده بهجای تنفس مصنوعی به گذشته
دوران خرید پیدرپی سختافزار برای به دوش کشیدن بار نرمافزارهای فرسوده به پایان رسیده است. نمیتوان هر سال پردازنده، حافظه و تجهیزات بیشتری افزود، اما همان معماریها، کدها و سامانههای ده تا بیستساله را دستنخورده نگه داشت و انتظار جهش در سرعت، امنیت و تابآوری داشت. سرمایهای که بانکها و مشتریانشان در طول سالها، در قالب کارمزد تراکنشها و هزینههای سنگین سختافزاری و نرمافزاری پرداختهاند، باید به ساخت آینده نظام بانکی منجر شود؛ نه اینکه صرفاً صرف تمدید عمر سامانههایی شود که نگهداری از آنها هر روز گرانتر، تغییرشان دشوارتر و خطرشان بیشتر میشود. اکنون زمان آن رسیده است که بهجای تقویت مداوم کالبدی فرسوده، ناوگان نرمافزاری بانکها را نوسازی کنیم؛ زیرا سختافزار قدرتمند میتواند ضعف نرمافزار را برای مدتی پنهان کند، اما نمیتواند آن را درمان کند.
نه؛ فیل بیمهار، ضامن امنیت کاروان نیست
سپردن تماموکمال سامانهها و عملیات حیاتی بانک به یک شرکت بزرگ، بدون آنکه بانک از حاکمیت، نظارت و توان مداخله برخوردار باشد، به معنای اعتماد به قدرتی است که افسارش در دست ما نیست. پیمانکار میتواند بازوی توانمند بانک باشد، اما نباید به مغز، حافظه و تنها تکیهگاه آن تبدیل شود؛ زیرا هیچ قرارداد، جریمه یا شرکت بزرگی نمیتواند زیان ناشی از ۳۵ روز توقف خدمت، خروج منابع و ازدسترفتن اعتماد مشتریان را جبران کند. خدمت ممکن است برونسپاری شود، اما مسئولیت هرگز برونسپاری نمیشود.
نام بانک بر درگاه خدمت قرار دارد و مشتری در روز بحران، پیمانکار را پاسخگو نمیداند؛ بلکه بانک را میشناسد. ازاینرو، بانک باید معماری، دانش، دادهها، دسترسیهای حیاتی، اختیار تصمیمگیری، امکان جایگزینی پیمانکار و توان ادامه خدمت در غیاب او را در اختیار داشته باشد؛ وگرنه روزی که آن فیل از حرکت بایستد یا از مسیر منحرف شود، بانک در برابر مشتریانی خواهد ماند که اعتمادشان را به دیگری نسپردهاند.
ده؛ آخرین سنگر تابآوری، انسانهاییاند که هنوز دلشان برای این خانه میتپد
میتوان برای یک بانک چندین سایت، هزاران سرور و دهها نسخه پشتیبان ایجاد کرد؛ اما اگر متخصصان آن دلزده شوند، نیروهای دلسوزش کنار بروند و حافظه سازمانیاش مهاجرت کند، همه این سازهها در روز بحران بیروح خواهند بود. سرمایه اجتماعی همان ریشه پنهانی است که درخت سازمان را در طوفان پابرجا نگه میدارد. هیچ سامانهای بدون نیرویی که آن را بشناسد، هیچ طرح بازیابیای بدون تیمی که پای اجرای آن بایستد و هیچ فناوریای بدون اعتماد و تعلق سازمانی تابآور نخواهد بود. سرمایه اجتماعی با بخشنامه و تجهیزات ساخته نمیشود؛ باید آن را با عدالت، احترام، اعتماد و امید آبیاری کرد؛ زیرا اگر ریشهها را زخمی کنیم، هیچ استحکامی در شاخهها، درخت را نجات نخواهد داد.
اگر دلسوزان و متخصصان را فرسوده، دلزده یا ناگزیر به مهاجرت کنیم، مهمترین لایه دفاعی را پیش از آغاز بحران از دست دادهایم. باید قدر کسانی را بدانیم که دانش، تجربه و دلشان را برای این سرزمین گذاشتهاند. با بیاعتمادی و بیعدالتی، مدافعان سازمان را به انسانهایی بیتفاوت یا خشمگین تبدیل نکنیم؛ زیرا گاهی بزرگترین تهدید، نه از پشت دیوارهای فناوری، بلکه از فروپاشی اعتماد آغاز میشود. BCP، پیش از آنکه از سایت و سرور آغاز شود، با حفظ انسانهایی معنا پیدا میکند که در سختترین روزها میمانند و مسئله حل میکنند.
