لماذا تُعدّ أمان البيانات الطبقة المفقودة في كل استراتيجية تحديث للحواسيب المركزية

في مكان ما داخل أحد البنوك الكبرى، أنهى فريق من المهندسين مؤخراً ترجمة مليوني سطر من كود COBOL إلى Java — وهي عملية ترحيل استغرقت أربعة عشر شهراً، واجتازت جميع مجموعات الاختبار، وانطلقت في الموعد المحدد، ليكتشف فريق الأمان خلال الأسبوع الأول أن أرقام بطاقات الائتمان وأرقام الضمان الاجتماعي وأرصدة الحسابات كانت تتدفق دون حماية عبر نقاط نهاية API، وخط أنابيب Kafka، وبحيرة بيانات تحليلية لم تكن بنية الحاسوب المركزي الأصلية قد كشفت عنها قط.

نجح التحديث، لكن حماية البيانات فشلت، وهذا السيناريو يتكرر في الواقع أكثر بكثير مما تودّ معظم المؤسسات الاعتراف به.

تتسارع الإنفاق على تحديث الحاسوب المركزي، غير أن النقاشات لا تزال تتمحور بشكل شبه كامل حول ترجمة الكود والبنية التحتية السحابية وخفض التكاليف، في حين أن أمن البيانات — العامل الوحيد الذي يحدد ما إذا كان مشروع التحديث يُولّد مخاطر أم يُزيلها — نادراً ما يحظى بالاهتمام الذي يستحقه حتى يقع خطأ ما.

مشكلة المحيط الأمني التي يُفرزها التحديث

لم تُصمَّم الحواسيب المركزية القديمة لتكون آمنة بالمفهوم الحديث؛ بل صُمِّمت لتكون بعيدة المنال. اعتمدت بيئات IBM z/OS على العزل المادي، وضوابط وصول RACF، وغموض بنيتها المعقدة لحماية البيانات الحساسة، وظلت البيانات داخل المحيط الأمني لعقود لأنه لم يكن ثمة مكان آخر تذهب إليه.

يُغيِّر التحديث هذه المعادلة جذرياً، إذ بمجرد أن تُعيد مؤسسة ما نشر تطبيق COBOL على السحابة أو تنسخ جداول DB2 إلى مستودع بيانات، تبدأ البيانات الحساسة في عبور حدود الثقة التي لم تكن موجودة من قبل، ويُصبح كل نقطة تكامل جديدة — سواء كانت استدعاء API أو خط أنابيب بيانات أو منصة تحليلات تابعة — سطحاً للهجوم لم يُبنَ نموذج الأمان الأصلي لحمايته.

يزيد التحدي تعقيداً قِدَمُ هذه الأنظمة — إذ يرتبط كود COBOL ارتباطاً وثيقاً بمنطق الأعمال الذي لا يوثقه أحد بالكامل، والمطورون الذين كتبوه يحالون إلى التقاعد، وتكاد كل مؤسسة تُشغِّل حاسوباً مركزياً تشترك في السياسة ذاتها: لا تثبيت عوامل، لا تعديل لكود الإنتاج، لا مجازفة بتعطيل أعباء العمل التي تعالج المعاملات الحيوية.

لماذا لا تكفي ترجمة الكود وحدها

سرّعت أدوات ترجمة الكود المدعومة بالذكاء الاصطناعي عملية الترحيل — ما كان يستغرق سنوات بات يُنجز في أشهر — لكن ترجمة COBOL إلى Java أو Python لا تُترجم ضوابط الأمان التي كانت تحمي البيانات حين كانت داخل الحاسوب المركزي. في نشر z/OS النموذجي، يُعالَج التشفير على مستوى الأجهزة من خلال معالجات تشفير مخصصة، ويُطبَّق التحكم في الوصول عبر RACF أو ACF2، ولا تغادر البيانات دون المرور بعمليات دُفعية خاضعة لرقابة مشددة.

غير أنه حين تنتقل تلك البيانات ذاتها إلى بيئة سحابية أصيلة، يتغير نموذج الحماية كلياً: تُوزَّع البيانات الآن عبر خدمات ومناطق ومزودين متعددين، ويتسع نطاق الامتثال في إطار PCI DSS وHIPAA وGDPR ليشمل كل نظام يلمس البيانات الحساسة بعد مغادرتها z/OS. وبدون استراتيجية لحماية البيانات تُصمَّم قبل بدء الترحيل، ستجد المؤسسات أنها لم تُحدِّث أمانها بقدر ما رحّلت مخاطرها.

حماية البيانات دون المساس بالحاسوب المركزي

تعمل أكثر المناهج عملية لتأمين البيانات أثناء التحديث وبعده على طبقة الشبكة بدلاً من طبقة التطبيق، وهذا التمييز مهم لأن تعديل تطبيقات COBOL القديمة نادراً ما يكون مجدياً وتثبيت العوامل على الحواسيب المركزية الإنتاجية يُدخل مخاطر تشغيلية غير مقبولة. تعترض حلول حماية البيانات عديمة العوامل البياناتِ حين تتدفق بين الحاسوب المركزي والأنظمة الفرعية — مُرمِّزةً أو محجوبةً أو مشفِّرةً الحقول الحساسة في الوقت الفعلي دون تغييرات على كود الحاسوب المركزي أو مخططات قواعد البيانات أو مسارات العمل القائمة — وأفضل حلول ترقية الحاسوب المركزي وتحديثه تدمج الآن هذا النوع من الأمان المضمّن كمكوّن أساسي لا كفكرة لاحقة.

برز التوكنة تحديداً بوصفها الأسلوب المفضل لدى المؤسسات العاملة في بيئات الحاسوب المركزي. تحافظ الرموز المميزة المحافِظة على التنسيق على بنية البيانات التي تتوقعها فحوصات التحقق القديمة — كالتحقق من خوارزمية Luhn لأرقام بطاقات الائتمان — مع إزالة العلاقة الرياضية بين الرمز والقيمة الأصلية، مما يعني أن الرموز يمكنها التدفق عبر خطوط الأنابيب السحابية ومنصات التحليلات والتكاملات مع أطراف ثالثة دون كشف البيانات الحساسة أو تعطيل الأنظمة الفرعية التي تعتمد على تنسيقات متسقة.

ما يجب على المؤسسات تقييمه قبل الترحيل

ينبغي للمؤسسات التي تخطط لبرامج تحديث الحاسوب المركزي أن تُقيِّم وضعها الأمني للبيانات قبل نقل أول عبء عمل — تحديداً: أين تقع البيانات الحساسة عبر قواعد بيانات الحاسوب المركزي ومخازن بيانات التطبيقات، وأي مسارات الترحيل ستكشف تلك البيانات لبيئات جديدة، وكيف ستستمر الحماية بعد وصول البيانات إلى السحابة. المؤسسات التي تُحسن التحديث تتعامل مع أمن البيانات بوصفه قيداً تصميمياً منذ اليوم الأول، لا مربع امتثال يُطبَّق بأثر رجعي، بينما تلك التي تُخفق فيه تميل إلى الاكتشاف — في الغالب متأخرة جداً — أنها بنت نسخة أسرع وأرخص وأكثر ضعفاً مما كانت تمتلكه أصلاً.