ระบบเก่าหมด support แต่ยังต้องใช้ต่อ: ลดความเสี่ยงอย่างไรระหว่างรอ modernize

ระบบงานหลักบางระบบยังรันอยู่บน Windows Server 2012 R2, CentOS 7 หรือ PHP 7.4 งบ modernize อาจยังไม่อนุมัติ ผู้ผลิตซอฟต์แวร์รายเดิมอาจเลิกพัฒนาไปแล้ว หรือระบบผูกกับงานที่หยุดไม่ได้ ระบบจึงต้องใช้ต่อไปอีกระยะหนึ่ง ทั้งที่รู้ว่าไม่ได้รับ security update แล้ว

บทความนี้เขียนสำหรับ IT Manager และเจ้าของระบบที่อยู่ในช่วงนั้น คือ ช่วงก่อนหรือระหว่างการ modernize ไม่ได้อธิบายว่าระบบเก่าคืออะไรหรือควรปรับปรุงด้วยวิธีไหน ซึ่งอ่านได้ที่ แนวทางปรับปรุงระบบเก่า (Legacy Modernization) และไม่ได้พูดถึงการรับช่วงระบบจากผู้รับจ้างเดิม ซึ่งอยู่ใน เช็กลิสต์รับมอบระบบจากผู้รับจ้างเดิม หากระบบไม่มีเอกสารเลย ให้อ่าน การรับช่วงระบบเก่าที่ไม่มีเอกสาร ประกอบ

จะรู้ได้อย่างไรว่าระบบเก่าของเราหมดระยะ support (EOL) แล้ว?

ให้แยกระบบออกเป็นชั้น คือ ระบบปฏิบัติการ runtime หรือภาษาโปรแกรม ฐานข้อมูล และ framework แล้วเทียบเวอร์ชันที่ใช้อยู่จริงกับหน้า lifecycle ของผู้ผลิตแต่ละราย ชั้นใดชั้นหนึ่งหมดอายุ (end-of-life, EOL) ก็ถือว่าระบบมีส่วนที่ไม่ได้รับ security fix แล้ว

ตารางด้านล่างสรุป stack ที่พบบ่อยในระบบเก่า ข้อมูล ณ วันที่เขียน (ตุลาคม 2026) จากเว็บไซต์ของผู้ผลิตแต่ละราย ช่อง "—" หมายถึงแหล่งอ้างอิงที่ใช้ไม่ได้กล่าวถึงโปรแกรมขยายระยะ ไม่ได้แปลว่าไม่มีแน่นอน ควรตรวจซ้ำกับผู้ผลิตก่อนตัดสินใจ

php.net อธิบายสถานะ EOL ไว้ตรงไปตรงมาว่า ผู้ใช้รุ่นที่ไม่ได้รับ support แล้วควรอัปเกรดโดยเร็ว เพราะอาจเผชิญช่องโหว่ที่ไม่มีการแก้ไข หลักเดียวกันใช้กับทุกแถวที่หมด support แล้ว

สิ่งที่ควรได้จากขั้นนี้คือทะเบียนระบบ (inventory) ที่ระบุเวอร์ชันจริงของทุกชั้น วันสิ้นสุด support และระบบงานที่พึ่งพาแต่ละชั้น เพื่อใช้จัดลำดับความเสี่ยงในหัวข้อถัดไป

Extended support หรือ ESU ช่วยให้ใช้ระบบเก่าต่อได้นานแค่ไหน?

Extended support ช่วยซื้อเวลาได้ตามระยะที่ผู้ผลิตกำหนดเท่านั้น และควรถือเป็นสะพานระหว่างทาง ไม่ใช่ปลายทาง ช่วงเวลานั้นควรใช้ย้ายระบบให้เสร็จ ไม่ใช่เลื่อนการตัดสินใจออกไป

• Microsoft อธิบายใน ESU FAQ ว่า ESU เป็นทางเลือกแบบเสียเงินที่ใช้เป็นทางสุดท้าย ไม่ได้ตั้งใจให้เป็นทางออกระยะยาว แต่เป็นสะพานชั่วคราวระหว่างย้ายไปแพลตฟอร์มที่ยังได้รับ support โดยให้เฉพาะ security update ระดับ Critical และ Important นานสูงสุดสามปีหลังสิ้นสุด extended support ไม่ได้ยืด lifecycle ของผลิตภัณฑ์ และไม่มี technical support เพิ่มเติม
• NCSC ของสหราชอาณาจักร ระบุใน แนวทางจัดการผลิตภัณฑ์ที่ล้าสมัย (obsolete products) ว่าเมื่อผลิตภัณฑ์เข้าสู่ extended support ไม่มีอะไรรับประกันว่าช่องโหว่ในอนาคตทั้งหมดจะได้รับการแก้ไข จึงไม่ควรมองว่าเป็นทางเลือกระยะยาวแทนการย้ายไประบบปฏิบัติการที่ยังได้รับ support
• Red Hat ระบุว่า ELS ของ RHEL 7 ครอบคลุม security fix ระดับ critical-impact บางรายการ bug fix เร่งด่วนที่คัดเลือก และ troubleshooting สำหรับ RHEL 7.9 ซึ่งแคบกว่าการดูแลตามรอบปกติ

สำหรับ Windows Server 2012 และ 2012 R2 สะพานนี้สิ้นสุดไปแล้วเมื่อ 13 ตุลาคม 2026 ระบบที่ยังรันอยู่จึงไม่ได้รับ security update จาก Microsoft อีก ทางที่เหลือคือมาตรการชดเชยในหัวข้อถัดไป ควบคู่กับแผนย้ายระบบที่มีกำหนดชัดเจน

ถ้า patch ไม่ได้ ต้องมีมาตรการชดเชย (compensating controls) อะไรบ้าง?

ใช้หลายมาตรการซ้อนกัน โดยเริ่มจากแยกระบบออกจากเครือข่ายส่วนอื่น จำกัดเส้นทางที่ข้อมูลจะเข้าถึงระบบ แล้วเฝ้าระวังและทบทวนความเสี่ยงเป็นระยะ ไม่มีมาตรการเดียวที่ทดแทน patch ได้

NIST SP 800-40 Rev. 4 ระบุว่าบางครั้ง patch จะไม่มีวันออกมา เพราะผู้ผลิตเลิก support ซอฟต์แวร์นั้นแล้ว และจัดระบบลักษณะนี้เป็น "unpatchable assets" ซึ่งรับมือด้วยการแยกระบบ (isolation) หรือวิธีอื่นที่ลดความเสี่ยง เช่น ใช้ firewall และ network segmentation เพื่อลดพื้นที่ที่ถูกโจมตีได้ NIST แนะนำให้วางแผนใช้มาตรการหลายประเภทร่วมกัน และให้ประเมินทางเลือกใหม่เป็นระยะ ด้วยการประเมินความเสี่ยงและวิเคราะห์ต้นทุนเทียบกับประโยชน์ ว่าระบบยังคุ้มค่ากับต้นทุนการลด โอน หรือยอมรับความเสี่ยงหรือไม่

แนวทางของ NCSC ลงรายละเอียดมากขึ้น:

• ถือว่าเซิร์ฟเวอร์ที่ล้าสมัยไม่น่าไว้ใจ (untrusted): ระบบอื่นในองค์กรควรจัดการข้อมูลและบริการที่มาจากเซิร์ฟเวอร์นั้นตามความเสี่ยง
• ปิดเส้นทางที่ข้อมูลอันตรายจะเข้าถึง: NCSC ยกตัวอย่างอีเมล การท่องเว็บ file share พอร์ตเครือข่าย และสื่อบันทึกข้อมูลแบบถอดได้ และแนะนำให้ปิดให้มากที่สุดเท่าที่ทำได้ ถ้าทำได้ให้ใช้ air gap
• ลด data flow ที่เข้าออกเซิร์ฟเวอร์: พิจารณาทุก flow อย่างรอบคอบ และควบคุมผ่าน network firewall แยกต่างหากเมื่อทำได้
• แบ่งโซนเครือข่าย (network zoning): เพื่อลดโอกาสที่มัลแวร์จะแพร่ไปยังส่วนอื่นขององค์กร

NCSC ยังย้ำว่าแนวทางนี้ช่วยลดความเสี่ยง แต่ไม่ได้ทำให้การใช้ผลิตภัณฑ์ที่ล้าสมัยปลอดภัยโดยสมบูรณ์ วิธีเดียวที่ได้ผลเต็มที่คือเลิกใช้ผลิตภัณฑ์นั้น

Virtual patching ด้วย WAF ใช้แทนการ patch ได้ไหม?

ไม่ได้ Virtual patching ช่วยลดความเสี่ยงระหว่างรอ แต่ช่องโหว่ในโค้ดยังอยู่ จึงต้องเดินหน้าแก้โค้ดหรือย้ายระบบต่อไปด้วย

OWASP Virtual Patching Cheat Sheet นิยาม virtual patch ว่าเป็นชั้นบังคับใช้นโยบายความปลอดภัยที่ตรวจจับและบล็อกความพยายามโจมตีช่องโหว่ที่รู้จัก โดยไม่แก้โค้ดที่มีช่องโหว่ OWASP ระบุชัดว่าวิธีนี้ลดความเสี่ยงได้เฉพาะ traffic ที่ผ่านชั้นตรวจ และเฉพาะรูปแบบการโจมตีที่กฎรู้จัก และไม่ได้ลบช่องโหว่ที่อยู่ข้างใต้ จึงแนะนำให้ทดสอบว่ามีทางเลี่ยงกฎหรือไม่ และเดินหน้าแก้โค้ดหรือรอ fix จากผู้ผลิตต่อไป

OWASP ยังระบุว่าการแก้ในระดับโค้ดกับ virtual patching ไม่ได้เป็นทางเลือกที่ต้องเลือกอย่างใดอย่างหนึ่ง และยกเหตุผลที่แก้โค้ดทันทีไม่ได้ซึ่งตรงกับสถานการณ์ระบบเก่า เช่น ขาดทรัพยากร เป็นซอฟต์แวร์ของผู้ผลิตภายนอกที่ผู้ใช้แก้โค้ดเองไม่ได้ หรือเป็นงานที่จ้างพัฒนาภายนอกซึ่งการแก้ต้องเปิดโครงการใหม่ ขั้นตอนตามแนวทางของ OWASP มีหกเฟส คือ Preparation, Identification, Analysis, Virtual Patch Creation, Implementation/Testing และ Recovery/Follow Up

หลักเดียวกันใช้กับเครื่องมือประเภท application control ด้วย Microsoft ระบุว่าเครื่องมือ application control ของผู้ผลิตรายอื่นไม่ใช่สิ่งทดแทน security fix ของผลิตภัณฑ์

Backup ของระบบเก่าควรทำอย่างไรให้กู้คืนได้จริง?

ทำตามหลัก 3-2-1 เก็บสำเนาแบบ offline และเข้ารหัส และทดสอบกู้คืนอย่างสม่ำเสมอ สำหรับระบบเก่า ให้เก็บสิ่งที่ใช้ติดตั้งระบบใหม่ได้ด้วย ไม่ใช่แค่ข้อมูล

• หลัก 3-2-1: เอกสาร Data Backup Options ของ CISA สรุปว่า เก็บไฟล์สำคัญ 3 ชุด คือต้นฉบับ 1 ชุดและ backup 2 ชุด บนสื่อ 2 ประเภทเพื่อป้องกันความเสียหายต่างรูปแบบ และเก็บ 1 ชุดไว้นอกสถานที่
• Offline และเข้ารหัส: #StopRansomware Guide ของ CISA แนะนำให้เก็บ backup ข้อมูลสำคัญแบบ offline และเข้ารหัส เพราะ ransomware หลายตัวพยายามค้นหาแล้วลบหรือเข้ารหัส backup ที่เข้าถึงได้ และให้ทดสอบความพร้อมใช้และความครบถ้วนของ backup ในสถานการณ์กู้คืนจากภัยพิบัติเป็นประจำ
• เก็บสิ่งที่ใช้ติดตั้งใหม่ด้วย: คู่มือเดียวกันแนะนำให้เก็บ golden image ของระบบ และเก็บซอร์สโค้ดหรือไฟล์ executable ไว้กับ backup แบบ offline พร้อมเอกสาร escrow และสัญญา license ซึ่งเหมาะกับระบบเก่าที่ติดตั้งซ้ำจากศูนย์ได้ยาก

NIST SP 800-34 Rev. 1 ซึ่งเป็นคู่มือวางแผนรองรับเหตุฉุกเฉิน กล่าวถึง backup แบบเทปว่าควรทดสอบเป็นประจำ เพื่อให้แน่ใจว่าข้อมูลถูกเก็บถูกต้องและดึงกลับมาได้โดยไม่ผิดพลาดหรือสูญหาย และระบุว่าการทดสอบแผนควรทำในสภาพที่ใกล้กับการใช้งานจริงมากที่สุด โดยครอบคลุมการกู้คืนระบบบนแพลตฟอร์มสำรองจาก backup และการกลับสู่การทำงานปกติ

การทดสอบกู้คืนระบบเก่าบนเครื่องอื่นอาจเผยปัญหาที่ไม่เคยเห็น เช่น ไฟล์ติดตั้งหรือ license ที่หาไม่ได้แล้ว การทดสอบจึงไม่ได้ตอบแค่ว่าข้อมูลครบ แต่ตอบด้วยว่าองค์กรสร้างระบบขึ้นมาใหม่ได้หรือไม่

ระหว่างที่ระบบเก่ายังรันอยู่ ต้องเฝ้าระวังและเก็บ log อะไรบ้าง?

ต้องเฝ้าระวังแบบเชิงรุก คือมี alert ที่มีคนรับไปจัดการ ไม่ใช่แค่เก็บ log ไว้ดูย้อนหลัง NCSC ระบุว่าเมื่อใช้ผลิตภัณฑ์ที่ล้าสมัย การมี protective monitoring ที่มีประสิทธิภาพและเชิงรุกยิ่งสำคัญ และชี้ว่าหลายองค์กรบันทึก security event ได้ แต่ไม่ได้แจ้งเตือนหรือลงมือทำอะไรจาก event เหล่านั้น

สำหรับระบบเก่า สิ่งที่ควรเห็นอย่างน้อยคือ:

• การล็อกอิน โดยเฉพาะบัญชีผู้ดูแลระบบและการล็อกอินจากที่ที่ไม่คาดคิด
• การเปลี่ยนแปลงไฟล์ระบบ ไฟล์ configuration และไฟล์ของแอปพลิเคชัน (file integrity monitoring)
• การเชื่อมต่อเครือข่ายที่อยู่นอก data flow ที่อนุญาตไว้
• งาน backup ที่ล้มเหลว และพื้นที่ดิสก์ใกล้เต็ม

เครื่องมือแบบ open source อย่าง Wazuh เป็นทางเลือกหนึ่งสำหรับรวม log และทำ file integrity monitoring อ่านภาพรวมได้ที่ คู่มือ Wazuh SIEM/XDR และ หน้าผลิตภัณฑ์ Wazuh ก่อนติดตั้ง agent บนระบบปฏิบัติการรุ่นเก่า ให้ตรวจกับเอกสารของเครื่องมือว่ารองรับรุ่นนั้นหรือไม่ หรือเก็บ log ผ่านช่องทางอื่นแทน ทั้งนี้เครื่องมือช่วยให้มองเห็นเหตุการณ์ แต่ไม่ได้ปิดช่องโหว่ และยังต้องมีคนดู alert ตามขั้นตอนที่ตกลงไว้

การควบคุมการเปลี่ยนแปลงช่วยลดความเสี่ยงของระบบเก่าอย่างไร?

ช่วยให้ระบบที่เปราะบางไม่พังจากการเปลี่ยนแปลงที่ไม่ได้วางแผน และการทบทวนเป็นรอบช่วยให้มาตรการชดเชยยังได้ผลอยู่ ถ้าความรู้เรื่องระบบอยู่กับคนเพียงไม่กี่คน ก็เป็นความเสี่ยงอีกด้านหนึ่งนอกจากช่องโหว่

• Runbook: มีขั้นตอนเริ่ม หยุด และกู้คืนระบบที่คนอื่นนอกจากผู้ดูแลหลักทำตามได้ ถ้ายังไม่มี runbook เลย ดูวิธีเขียนใน การรับช่วงระบบเก่าที่ไม่มีเอกสาร
• Configuration ที่บันทึกไว้: ค่าที่ตั้งด้วยมือบนเซิร์ฟเวอร์ กฎ firewall และ data flow ที่อนุญาต เพื่อให้ตรวจได้ว่ามีอะไรเปลี่ยนไป
• การควบคุมการเปลี่ยนแปลง: ทุกการเปลี่ยนแปลงต้องมีผู้อนุมัติ ทดสอบบนสำเนาของระบบก่อนเมื่อทำได้ และมีแผนย้อนกลับ
• ทบทวนเป็นรอบ: ทบทวนกฎ firewall บัญชีผู้ใช้ และผลการทดสอบกู้คืน เพื่อให้มาตรการชดเชยยังได้ผลอยู่

ถ้าระบบมีปัญหาด้านประสิทธิภาพร่วมด้วย ดูแนวทางใน การดูแลประสิทธิภาพระบบ และถ้ากำลังตัดสินใจว่าจะดูแลเองหรือใช้ผู้ให้บริการ อ่าน Managed Services หรือทีม IT ภายใน

เมื่อไรที่การ "ใช้ต่อไปก่อน" ไม่ใช่ทางเลือกที่ยอมรับได้แล้ว?

เมื่อระบบเปิดสู่อินเทอร์เน็ต เก็บข้อมูลอ่อนไหว ไม่ได้รับ update ใดๆ แล้ว หรือองค์กรไม่มีคนที่ดูแลและกู้คืนระบบได้ ยิ่งตรงหลายข้อ ยิ่งต้องเร่งแผน modernize แทนการเพิ่มมาตรการชดเชยไปเรื่อยๆ

แคตตาล็อก Bad Practices ของ CISA (เผยแพร่ปี 2021 และปัจจุบันถูกจัดเป็นเนื้อหาเก็บถาวร) จัดการใช้ซอฟต์แวร์ที่หมด support ในระบบที่ให้บริการโครงสร้างพื้นฐานสำคัญเป็นแนวปฏิบัติที่อันตราย โดยเฉพาะในระบบที่เข้าถึงได้จากอินเทอร์เน็ต และสนับสนุนให้ทุกองค์กรดำเนินการแก้ไข

เมื่อเข้าเกณฑ์ ให้เริ่มจากเลือกแนวทางปรับปรุงตาม แนวทาง Legacy Modernization และหากแผนคือย้ายขึ้น Cloud อ่านต่อที่ คู่มือย้ายระบบขึ้น Cloud

ตัวอย่างสมมติ: ระบบงานภายในบน Windows Server 2012 R2

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

• ยืนยันจากทะเบียนระบบว่า ESU ของ Windows Server 2012 R2 สิ้นสุดแล้ว จึงไม่มี security update อีก
• ย้ายเซิร์ฟเวอร์ไปโซนแยก firewall อนุญาตเฉพาะการเชื่อมต่อจากเครือข่ายผู้ใช้ภายในไปยังพอร์ตของแอปพลิเคชัน และปิดการท่องเว็บกับ file share บนเครื่อง
• ตั้ง alert การล็อกอินของผู้ดูแลระบบและการเปลี่ยนแปลงไฟล์ของแอปพลิเคชัน โดยกำหนดผู้รับ alert ชัดเจน
• ทดสอบกู้คืนบนเครื่องสำรอง พบว่าไฟล์ติดตั้งของ component หนึ่งไม่มีในที่เก็บ จึงเพิ่มเข้า backup แบบ offline
• กำหนดวันทบทวนความเสี่ยงร่วมกับเจ้าของระบบ และผูกกับกำหนดการของแผนย้ายระบบ

ประเด็นคือมาตรการเหล่านี้ทำให้ใช้ระบบต่อได้อย่างมีการควบคุมระหว่างรอ แต่ไม่ได้ทำให้ระบบกลับมาได้รับ support อีก

เช็กลิสต์ดูแลระบบเก่าระหว่างรอ modernize มีอะไรบ้าง?

ใช้ทบทวนร่วมกับเจ้าของระบบเป็นระยะ ข้อที่ยังไม่มีหลักฐานให้บันทึกเป็นความเสี่ยงที่ต้องตัดสินใจ

• มีทะเบียนระบบที่ระบุเวอร์ชันจริงของระบบปฏิบัติการ runtime ฐานข้อมูล และ framework พร้อมวันสิ้นสุด support
• รู้ว่าชั้นใดยังอยู่ใน extended support และสิ้นสุดเมื่อไร และมีแผนย้ายก่อนวันนั้น
• ระบบเก่าอยู่ในโซนเครือข่ายแยก มี firewall อนุญาตเฉพาะ data flow ที่จำเป็น
• ปิดอีเมล การท่องเว็บ file share พอร์ตที่ไม่ใช้ และสื่อแบบถอดได้บนเครื่องที่ล้าสมัย
• ไม่เปิดระบบเก่าสู่อินเทอร์เน็ตโดยตรง หรือมีเหตุผลและมาตรการรองรับที่บันทึกไว้
• ถ้าใช้ virtual patching หรือ application control รู้ว่าเป็นมาตรการเสริม ไม่ใช่สิ่งทดแทน patch
• Backup ตามหลัก 3-2-1 มีสำเนา offline และเข้ารหัส และเก็บ golden image ไฟล์ติดตั้ง และ license ไว้ด้วย
• ทดสอบกู้คืนบนเครื่องสำรองแล้ว มีวันที่และผู้ทดสอบ
• มี alert การล็อกอิน การเปลี่ยนแปลงไฟล์ และการเชื่อมต่อผิดปกติ พร้อมผู้รับผิดชอบ
• มี runbook และขั้นตอนอนุมัติการเปลี่ยนแปลงพร้อมแผนย้อนกลับ
• มีเกณฑ์และวันทบทวนว่าเมื่อไรต้องเร่งแผน modernize

UNIXDEV ช่วยดูแลระบบเก่าระหว่างรอ modernize ผ่านบริการ Legacy Application Maintenance ตั้งแต่สำรวจทะเบียนระบบและวันสิ้นสุด support วางและปรับแต่ง monitoring ทดสอบ backup และการกู้คืน ไปจนถึงดูแลระบบต่อตามขอบเขตที่ตกลงกัน ส่วนงานโครงสร้างพื้นฐานและ pipeline ทำร่วมกับบริการ DevOps & SRE เพื่อให้ระบบเดิมใช้งานได้อย่างมีการควบคุมจนกว่าแผนปรับปรุงจะเสร็จ

แหล่งอ้างอิงและอ่านต่อ

• NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning
• NCSC — Obsolete products
• OWASP — Virtual Patching Cheat Sheet
• Microsoft — Extended Security Updates FAQ
• Microsoft — Windows Server 2016 lifecycle
• Microsoft — .NET Framework lifecycle
• Red Hat — CentOS Linux end of life
• Red Hat — Legacy errata support policy (ELS)
• CentOS Project — CentOS Linux 8 announcement (2020)
• PHP — Unsupported branches
• PHP — Supported versions
• Oracle — Java SE support roadmap
• Adoptium — Eclipse Temurin support
• Python — Sunsetting Python 2
• Node.js — Release schedule
• Node.js — Previous releases
• MySQL — End of life notice
• PostgreSQL — Versioning policy
• Ubuntu — Release cycle
• CISA — Bad Practices (2021, archived)
• CISA — Data Backup Options
• CISA — #StopRansomware Guide
• NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems
• บทความที่เกี่ยวข้อง: แนวทางปรับปรุงระบบเก่า
• บทความที่เกี่ยวข้อง: เปลี่ยนผู้รับจ้างดูแลระบบ ต้องรับมอบอะไรบ้าง

บทความโดย UNIXDEV Team · 30 ตุลาคม 2026 · วันสิ้นสุด support เป็นข้อมูล ณ วันที่เขียน (ตุลาคม 2026) จากเว็บไซต์ผู้ผลิต ควรตรวจซ้ำก่อนตัดสินใจ สรุปแนวปฏิบัติเพื่อประกอบการวางแผน ไม่ใช่คำแนะนำทางกฎหมาย และตัวอย่างเป็นสถานการณ์สมมติ