เหตุใดความปลอดภัยของข้อมูลจึงเป็นชั้นที่ขาดหายไปในทุกกลยุทธ์การปรับปรุงเมนเฟรมให้ทันสมัย

ในธนาคารขนาดใหญ่แห่งหนึ่ง ทีมวิศวกรเพิ่งเสร็จสิ้นการแปลโค้ด COBOL สองล้านบรรทัดเป็น Java — การย้ายระบบที่ใช้เวลาสิบสี่เดือน ผ่านการทดสอบทุกชุด และเปิดใช้งานตามกำหนด แต่แล้วทีมความปลอดภัยก็ค้นพบในสัปดาห์แรกว่าหมายเลขบัตรเครดิต หมายเลขประกันสังคม และยอดคงเหลือในบัญชีกำลังไหลผ่าน API endpoints, Kafka pipeline และ analytics data lake โดยไม่มีการป้องกัน ซึ่งสถาปัตยกรรม mainframe เดิมไม่เคยเปิดเผยข้อมูลเหล่านี้มาก่อน

การปรับปรุงระบบประสบความสำเร็จ แต่การปกป้องข้อมูลกลับล้มเหลว และสถานการณ์เช่นนี้เกิดขึ้นบ่อยกว่าที่องค์กรส่วนใหญ่จะยอมรับ

การใช้จ่ายด้านการปรับปรุง mainframe กำลังเร่งตัวขึ้น แต่การสนทนายังคงมุ่งเน้นไปที่การแปลโค้ด โครงสร้างพื้นฐานคลาวด์ และการลดต้นทุนเป็นหลัก ในขณะที่ความปลอดภัยของข้อมูล — ปัจจัยเดียวที่กำหนดว่าโครงการปรับปรุงจะสร้างความเสี่ยงหรือขจัดมันออกไป — แทบไม่ได้รับความสนใจเท่าที่ควรจนกว่าจะมีบางอย่างเสียหาย

ปัญหาขอบเขตที่การปรับปรุงระบบสร้างขึ้น

Legacy mainframe ไม่เคยถูกออกแบบมาให้ปลอดภัยในแบบสมัยใหม่ แต่ถูกออกแบบมาให้เข้าถึงไม่ได้ สภาพแวดล้อม IBM z/OS พึ่งพาการแยกทางกายภาพ การควบคุมการเข้าถึง RACF และความซับซ้อนเฉพาะของสถาปัตยกรรมในการปกป้องข้อมูลที่ละเอียดอ่อน และเป็นเวลาหลายทศวรรษที่ข้อมูลยังคงอยู่ภายในขอบเขตเพราะไม่มีที่อื่นให้ไป

การปรับปรุงระบบเปลี่ยนสมการนี้อย่างพื้นฐาน เพราะในทันทีที่องค์กรย้ายแอปพลิเคชัน COBOL ไปยังคลาวด์หรือจำลอง DB2 tables ลงใน data warehouse ข้อมูลที่ละเอียดอ่อนก็เริ่มข้ามขอบเขตความน่าเชื่อถือที่ไม่เคยมีมาก่อน และแต่ละจุดเชื่อมต่อใหม่ — ไม่ว่าจะเป็น API call, data pipeline หรือ analytics platform ปลายทาง — กลายเป็น attack surface ที่โมเดลความปลอดภัยเดิมไม่ได้สร้างมาเพื่อป้องกัน

ความท้าทายยิ่งทวีขึ้นจากอายุของระบบเหล่านี้ — โค้ด COBOL ถูกผูกติดอย่างแน่นหนากับ business logic ที่ไม่มีใครจัดทำเอกสารอย่างครบถ้วน นักพัฒนาที่เขียนโค้ดเหล่านี้กำลังเกษียณ และแทบทุกองค์กรที่ใช้งาน mainframe มีนโยบายเดียวกัน: ห้ามติดตั้ง agent ห้ามแก้ไขโค้ด production และห้ามเสี่ยงรบกวน workload ที่ประมวลผลธุรกรรมสำคัญ

เหตุใดการแปลโค้ดเพียงอย่างเดียวจึงไม่เพียงพอ

เครื่องมือแปลโค้ดที่ใช้ AI ช่วยเร่งกระบวนการย้ายระบบ — สิ่งที่เคยใช้เวลาหลายปีตอนนี้สามารถทำได้ในไม่กี่เดือน — แต่การแปล COBOL เป็น Java หรือ Python ไม่ได้แปลการควบคุมความปลอดภัยที่ปกป้องข้อมูลขณะที่อยู่ภายใน mainframe ในการปรับใช้ z/OS ทั่วไป การเข้ารหัสจะถูกจัดการที่ระดับฮาร์ดแวร์ผ่านโปรเซสเซอร์เข้ารหัสเฉพาะ การควบคุมการเข้าถึงถูกบังคับใช้ผ่าน RACF หรือ ACF2 และข้อมูลไม่เคยออกไปโดยไม่ผ่านกระบวนการ batch ที่ควบคุมอย่างเข้มงวด

อย่างไรก็ตาม เมื่อข้อมูลเดียวกันนั้นย้ายไปยังสภาพแวดล้อม cloud-native โมเดลการปกป้องจะเปลี่ยนไปโดยสิ้นเชิง: ข้อมูลกระจายอยู่ทั่วหลายบริการ ภูมิภาค และผู้ให้บริการ และขอบเขตการปฏิบัติตามข้อกำหนดภายใต้ PCI DSS, HIPAA และ GDPR ขยายไปยังทุกระบบที่สัมผัสข้อมูลที่ละเอียดอ่อนหลังจากออกจาก z/OS หากไม่มีกลยุทธ์การปกป้องข้อมูลที่ออกแบบก่อนการย้ายระบบจะเริ่มต้น องค์กรจะพบว่าตนเองไม่ได้ปรับปรุงความปลอดภัย แต่เพียงแค่ย้ายความเสี่ยงไปเท่านั้น

การปกป้องข้อมูลโดยไม่แตะต้อง Mainframe

แนวทางที่ใช้งานได้จริงที่สุดในการรักษาความปลอดภัยข้อมูลระหว่างและหลังการปรับปรุงระบบทำงานที่ network layer แทนที่จะเป็น application layer และความแตกต่างนี้มีความสำคัญเพราะการแก้ไขแอปพลิเคชัน COBOL แบบเก่านั้นแทบเป็นไปไม่ได้ และการติดตั้ง agent บน production mainframe นำมาซึ่งความเสี่ยงด้านการดำเนินงานที่ยอมรับไม่ได้ โซลูชันปกป้องข้อมูลแบบไม่ใช้ agent จะดักจับข้อมูลขณะที่ไหลระหว่าง mainframe และระบบปลายทาง — โดยการ tokenize, mask หรือเข้ารหัสฟิลด์ที่ละเอียดอ่อนแบบ real time โดยไม่ต้องเปลี่ยนแปลงโค้ด mainframe, database schema หรือ workflow ที่มีอยู่ — และ โซลูชันการอัปเกรดและปรับปรุง mainframe ที่ดีที่สุด ในตอนนี้ได้รวม inline security ประเภทนี้เป็นองค์ประกอบหลัก ไม่ใช่สิ่งที่คิดทีหลัง

โดยเฉพาะอย่างยิ่ง Tokenization ได้กลายเป็นวิธีที่นิยมสำหรับองค์กรที่ดำเนินงานในสภาพแวดล้อม mainframe Token ที่รักษารูปแบบจะคงโครงสร้างข้อมูลที่การตรวจสอบ legacy คาดหวัง — เช่น การตรวจสอบ Luhn สำหรับหมายเลขบัตรเครดิต — ในขณะที่ขจัดความสัมพันธ์ทางคณิตศาสตร์ระหว่าง token และค่าเดิม ซึ่งหมายความว่า token สามารถไหลผ่าน cloud pipeline, analytics platform และการเชื่อมต่อกับบุคคลที่สามโดยไม่เปิดเผยข้อมูลที่ละเอียดอ่อนหรือทำให้ระบบปลายทางที่พึ่งพารูปแบบที่สอดคล้องกันเสียหาย

สิ่งที่องค์กรควรประเมินก่อนการย้ายระบบ

องค์กรที่วางแผนโปรแกรมปรับปรุง mainframe ควรประเมินสถานะความปลอดภัยข้อมูลของตนก่อนที่ workload แรกจะย้าย — โดยเฉพาะอย่างยิ่ง ข้อมูลที่ละเอียดอ่อนอยู่ที่ใดใน mainframe databases และ application data stores เส้นทางการย้ายใดจะเปิดเผยข้อมูลนั้นต่อสภาพแวดล้อมใหม่ และการปกป้องจะดำเนินต่อไปอย่างไรเมื่อข้อมูลไปถึงคลาวด์ องค์กรที่ปรับปรุงระบบได้ถูกต้องจะถือว่าความปลอดภัยข้อมูลเป็นข้อจำกัดด้านการออกแบบตั้งแต่วันแรก ไม่ใช่ checkbox การปฏิบัติตามข้อกำหนดที่ใช้ย้อนหลัง ในขณะที่องค์กรที่ทำผิดพลาดมักค้นพบ — บ่อยครั้งสายเกินไป — ว่าตนเองได้สร้างเวอร์ชันที่เร็วกว่า ถูกกว่า และเปราะบางกว่าในทุกด้านของสิ่งที่มีอยู่เดิม