در جایی در داخل یک بانک بزرگ، تیمی از مهندسان اخیراً ترجمه دو میلیون خط COBOL به Java را به پایان رساندند — مهاجرتی که چهارده ماه طول کشید، تمام مجموعههای آزمایشی را پشت سر گذاشت و طبق برنامه راهاندازی شد، تا اینکه تیم امنیت در هفته اول متوجه شد که شماره کارتهای اعتباری، شمارههای تأمین اجتماعی و موجودی حسابها بدون هیچ محافظتی از طریق endpoint های API، یک pipeline کافکا و یک data lake تحلیلی که معماری mainframe اصلی هرگز آنها را در معرض نمایش نگذاشته بود، جریان دارند.
مدرنسازی موفق شد، اما حفاظت از دادهها موفق نشد، و این سناریو بسیار بیشتر از آنچه اکثر سازمانها حاضر به اعتراف باشند، اتفاق میافتد.
هزینههای مدرنسازی mainframe در حال افزایش است، اما گفتگوها همچنان به طور چشمگیری بر ترجمه کد، زیرساخت ابری و کاهش هزینه متمرکز هستند، در حالی که امنیت داده — تنها عاملی که تعیین میکند آیا یک پروژه مدرنسازی ریسک ایجاد میکند یا آن را از بین میبرد — به ندرت توجهی که شایسته آن است را دریافت میکند، مگر اینکه چیزی خراب شود.
مشکل محیط امنیتی که مدرنسازی ایجاد میکند
mainframe های قدیمی هرگز برای امنیت به معنای مدرن طراحی نشده بودند؛ آنها برای دستنیافتنی بودن طراحی شده بودند. محیطهای IBM z/OS به انزوای فیزیکی، کنترلهای دسترسی RACF و پیچیدگی معماری خود برای محافظت از دادههای حساس متکی بودند، و برای دههها، دادهها در داخل محیط باقی ماندند زیرا جای دیگری برای رفتن وجود نداشت.
مدرنسازی این معادله را به طور بنیادی تغییر میدهد، زیرا به محض اینکه یک سازمان یک برنامه COBOL را به فضای ابری منتقل میکند یا جداول DB2 را در یک data warehouse تکثیر میکند، دادههای حساس شروع به عبور از مرزهای اعتماد میکنند که قبلاً وجود نداشتند، و هر نقطه یکپارچهسازی جدید — چه یک فراخوانی API، یک pipeline داده، یا یک پلتفرم تحلیلی پاییندستی — به یک سطح حمله تبدیل میشود که مدل امنیتی اصلی هرگز برای محافظت از آن ساخته نشده بود.
این چالش با قدمت این سیستمها پیچیدهتر میشود — کد COBOL به منطق تجاریای گره خورده که هیچکس به طور کامل مستند نمیکند، توسعهدهندگانی که آن را نوشتند در حال بازنشستگی هستند، و تقریباً هر سازمانی که یک mainframe اجرا میکند همان سیاست را دارد: agent نصب نکنید، کد تولیدی را تغییر ندهید، ریسک اختلال در workload هایی که تراکنشهای حیاتی را پردازش میکنند را نپذیرید.
چرا ترجمه کد به تنهایی کافی نیست
ابزارهای ترجمه کد مبتنی بر هوش مصنوعی فرآیند مهاجرت را تسریع کردهاند — آنچه زمانی سالها طول میکشید اکنون میتواند در عرض چند ماه انجام شود — اما ترجمه COBOL به Java یا Python، کنترلهای امنیتی که از دادهها در زمانی که داخل mainframe بودند محافظت میکردند را ترجمه نمیکند. در یک استقرار معمولی z/OS، رمزگذاری در سطح سختافزار از طریق پردازندههای رمزنگاری اختصاصی انجام میشود، کنترل دسترسی از طریق RACF یا ACF2 اعمال میشود، و دادهها هرگز بدون عبور از فرآیندهای batch کنترلشده خارج نمیشوند.
اما وقتی همان دادهها به یک محیط cloud-native منتقل میشوند، مدل حفاظتی به طور کامل تغییر میکند: دادهها اکنون در چندین سرویس، منطقه و ارائهدهنده توزیع شدهاند، و حوزه انطباق تحت PCI DSS، HIPAA و GDPR به هر سیستمی که پس از خروج از z/OS با دادههای حساس در تماس است گسترش مییابد. بدون یک استراتژی حفاظت از داده که قبل از شروع مهاجرت طراحی شده باشد، سازمانها متوجه خواهند شد که امنیت خود را به اندازهای که ریسک خود را مهاجرت دادهاند مدرن نکردهاند.
محافظت از دادهها بدون دست زدن به Mainframe
عملیترین رویکردها برای ایمنسازی دادهها در حین و پس از مدرنسازی در لایه شبکه عمل میکنند نه لایه برنامه، و این تمایز اهمیت دارد زیرا تغییر برنامههای COBOL قدیمی به ندرت امکانپذیر است و نصب agent ها بر روی mainframe های تولیدی ریسک عملیاتی غیرقابل قبولی ایجاد میکند. راهحلهای حفاظت از داده بدون agent، دادهها را در حین جریان بین mainframe و سیستمهای پاییندستی رهگیری میکنند — فیلدهای حساس را در زمان واقعی توکنیزه، ماسک یا رمزگذاری میکنند بدون اینکه تغییری در کد mainframe، schema های پایگاه داده یا جریانهای کاری موجود ایجاد کنند — و بهترین راهحلهای ارتقا و مدرنسازی mainframe اکنون این نوع امنیت inline را به عنوان یک مؤلفه اصلی و نه یک افزوده بعدی یکپارچه میکنند.
توکنیزهسازی، به ویژه، به عنوان روش ترجیحی برای سازمانهایی که در محیطهای mainframe فعالیت میکنند ظهور کرده است. توکنهای حافظ فرمت، ساختار دادهای را که بررسیهای اعتبارسنجی قدیمی انتظار دارند حفظ میکنند — مانند تأیید Luhn برای شماره کارتهای اعتباری — در حالی که رابطه ریاضی بین توکن و مقدار اصلی را از بین میبرند، به این معنی که توکنها میتوانند از pipeline های ابری، پلتفرمهای تحلیلی و یکپارچهسازیهای شخص ثالث بگذرند بدون اینکه دادههای حساس را افشا کنند یا سیستمهای پاییندستی که به فرمتهای ثابت وابسته هستند را خراب کنند.
آنچه سازمانها باید قبل از مهاجرت ارزیابی کنند
سازمانهایی که برنامههای مدرنسازی mainframe را طراحی میکنند باید وضعیت امنیت داده خود را قبل از انتقال اولین workload ارزیابی کنند — به طور خاص، دادههای حساس در کجای پایگاههای داده mainframe و مخازن داده برنامه قرار دارند، کدام مسیرهای مهاجرت آن دادهها را در معرض محیطهای جدید قرار میدهند، و چگونه حفاظت پس از رسیدن دادهها به فضای ابری ادامه خواهد یافت. سازمانهایی که مدرنسازی را به درستی انجام میدهند، امنیت داده را از روز اول به عنوان یک محدودیت طراحی در نظر میگیرند، نه به عنوان یک چکباکس انطباق که به صورت پسنگر اعمال میشود، در حالی که آنهایی که اشتباه میکنند تمایل دارند کشف کنند — اغلب خیلی دیر — که نسخهای سریعتر، ارزانتر و در مجموع آسیبپذیرتر از آنچه داشتند ساختهاند.
