Zscaler จับมือ IBM และ Red Hat อุดช่วงรอแพตช์ แต่ยังอยู่ Early Access

เมื่อวันที่ 5 ตุลาคม 2569 ที่เมืองซานโฮเซ สหรัฐอเมริกา Zscaler ประกาศความร่วมมือกับ IBM และ Red Hat เพื่อเชื่อม Autonomous Application Shield เข้ากับ Lightwell สำหรับป้องกันแอปภายในองค์กรระหว่างรอแพตช์ โดย Joby Menon ผู้บริหารฝ่ายผลิตภัณฑ์ของ Zscaler อธิบายเป้าหมายของความร่วมมือนี้ว่า “reduce risk during that gap”. แนวทางที่ประกาศให้ระบบของ Zscaler สกัดความพยายามใช้ช่องโหว่แบบ inline ที่ระดับเครือข่าย ขณะที่ Lightwell จัดหาวิธีแก้ซอฟต์แวร์โอเพนซอร์สที่ผ่านการตรวจสอบแล้ว ส่วน Autonomous Application Shield ยังเปิดให้ใช้ผ่านโครงการ Early Access

รายงานของ Dow Jones Newswires อธิบายขอบเขตความร่วมมือว่าเริ่มจากประเมินความเสี่ยงของแอป ป้องกันระหว่างเตรียมวิธีแก้ และส่งมอบการแก้ช่องโหว่ต้นเหตุ โดยระบุสถานะ Early Access ของผลิตภัณฑ์ Zscaler เช่นกัน ประเด็นสำคัญคือการป้องกันบนเส้นทางเข้าถึงแอปช่วยลดความเสี่ยงในช่วงรอได้ แต่ไม่ได้เปลี่ยนส่วนประกอบซอฟต์แวร์ที่มีช่องโหว่ องค์กรจะปิดช่องโหว่ในระบบของตนได้เมื่อรับวิธีแก้ ทดสอบ และนำซอฟต์แวร์ที่แก้แล้วขึ้นใช้งานจริง

Autonomous Application Shield ป้องกันตรงไหนของแอป

จุดเริ่มต้นของสถาปัตยกรรมที่ประกาศคือการมองแอปภายในองค์กรเป็นรายตัว ผ่าน App Connectors บนแพลตฟอร์ม Zero Trust Exchange ตัวเชื่อมต่อเหล่านี้ทำการประเมินจุดเปิดรับความเสี่ยงและช่องโหว่อย่างต่อเนื่อง จากนั้นระบบคลาวด์ของ Zscaler ประเมินข้อมูลของแต่ละแอป เพื่อเลือกมาตรการป้องกันที่สัมพันธ์กับความเสี่ยงของแอปนั้น วิธีนี้ทำให้การตัดสินใจผูกกับแอปที่กำลังใช้งาน แทนการสมมติว่าทุกแอปมีจุดเสี่ยงเหมือนกัน

เมื่อมีช่องโหว่ใหม่ มาตรการของ Autonomous Application Shield ถูกออกแบบให้ทำงานแบบ inline กับการเข้าถึงแอปที่เกี่ยวข้อง คำขอซึ่งเข้าข่ายความพยายามใช้ช่องโหว่จึงอาจถูกสกัดบนเส้นทางเครือข่าย ก่อนจะไปถึงแอปที่มีความเสี่ยง การตอบสนองลักษณะนี้มีความหมายในช่วงที่ทีมพัฒนายังต้องตรวจสอบส่วนประกอบ สร้างซอฟต์แวร์รุ่นแก้ไข และเตรียมการติดตั้ง แต่ผลที่ประกาศเป็นความสามารถของสถาปัตยกรรมและผลิตภัณฑ์ใน Early Access ยังไม่ใช่ผลรับประกันสำหรับทุกแอปหรือทุกสภาพแวดล้อม

คำว่า inline บอกตำแหน่งที่การควบคุมทำงาน: มาตรการเข้าแทรกระหว่างการเข้าถึงแอป ไม่ได้เข้าไปเปลี่ยนซอร์สโค้ดหรือไลบรารีในแอปนั้นโดยตรง ดังนั้นขอบเขตที่มาตรการคุ้มครองได้จึงสัมพันธ์กับเส้นทางเข้าถึงที่อยู่ภายใต้การควบคุม และรูปแบบความพยายามโจมตีที่ระบบระบุได้ หากส่วนประกอบเดิมยังอยู่ในแอป ความเสี่ยงจากช่องโหว่ต้นเหตุยังต้องได้รับการจัดการในขั้นตอนแก้ซอฟต์แวร์

Zscaler วาง Shield ไว้ร่วมกับกลไกอื่นในแพลตฟอร์มสำหรับแอปภายในองค์กร Zscaler Private Access มีหน้าที่ลดการเปิดเผยตัวแอปต่อผู้ที่ไม่ควรเข้าถึง ส่วน Autonomous User-to-App Segmentation จำกัดขอบเขตที่ผู้ใช้หรือผู้บุกรุกซึ่งได้สิทธิ์บางส่วนจะเข้าถึงแอปอื่นได้ Shield เพิ่มการสกัดความพยายามใช้ช่องโหว่กับแอปที่ยังเข้าถึงได้ แต่ละชั้นจึงตอบปัญหาคนละจุดในเส้นทางโจมตี

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

การประเมินเป็นรายแอปยังส่งผลต่อความแม่นของการควบคุม หากแอปหนึ่งไม่ได้ใช้ส่วนประกอบที่ได้รับผลกระทบ การใช้มาตรการเดียวกับแอปที่มีช่องโหว่อาจเพิ่มภาระโดยไม่จำเป็น ในทางกลับกัน แอปที่มีส่วนประกอบเสี่ยงต้องได้รับการคุ้มครองตามลักษณะการเข้าถึงจริง แนวคิดของ Shield จึงอยู่ที่การเลือกการป้องกันเฉพาะแอป ขณะรอให้การแก้ซอฟต์แวร์ตามมาทัน

Lightwell รับช่วงแก้ส่วนประกอบซอฟต์แวร์

Lightwell ของ IBM และ Red Hat รับหน้าที่อีกด้านของลำดับงาน คือจัดหาวิธีแก้ที่ผ่านการตรวจสอบสำหรับซอฟต์แวร์โอเพนซอร์สที่ได้รับผลกระทบ หากแอปพึ่งพาไลบรารีที่มีช่องโหว่ การสกัดคำขออันตรายช่วยป้องกันการใช้ช่องโหว่ผ่านเส้นทางที่ถูกควบคุมได้ แต่ไลบรารีเดิมยังคงอยู่จนกว่าจะมีการนำรุ่นที่แก้แล้วไปแทนที่ การแก้ในระดับซอร์สจึงมีเป้าหมายต่างจากการลดความเสี่ยงบนเครือข่าย

เส้นทางที่ความร่วมมือนี้ต้องการเชื่อมเริ่มจากการพบว่าแอปใดเปิดรับความเสี่ยง ต่อด้วยมาตรการเฉพาะแอปเพื่อขวางความพยายามโจมตี แล้วจึงส่งมอบวิธีแก้ซอฟต์แวร์ที่ผ่านการตรวจสอบ ขั้นตอนสุดท้ายไม่ได้จบเมื่อผู้ผลิตส่งแพตช์ องค์กรยังต้องนำส่วนประกอบที่แก้แล้วเข้าสู่กระบวนการสร้างแอป ตรวจสอบผลกระทบ และติดตั้งในระบบที่ได้รับผลกระทบ จึงจะเปลี่ยนสถานะของโค้ดที่ใช้งานจริงได้

ความแตกต่างนี้ช่วยอธิบายเหตุผลที่มีทั้ง Shield และ Lightwell ในความร่วมมือเดียวกัน ฝั่งหนึ่งต้องตอบสนองในเวลาที่การโจมตีอาจเกิดขึ้นแล้ว อีกฝั่งต้องแก้ข้อบกพร่องโดยไม่ทำให้แอปหยุดทำงานระหว่างการเปลี่ยนส่วนประกอบ การจัดหาวิธีแก้ที่ผ่านการตรวจสอบช่วยลดงานวิศวกรรมบางส่วน แต่การตัดสินใจนำวิธีแก้ไปใช้กับแอปเฉพาะองค์กรยังต้องอาศัยการทดสอบในระบบขององค์กรนั้น

เมื่อวันที่ 6 ตุลาคม 2569 IBM และ Red Hat ประกาศว่า Lightwell พบและแก้ช่องโหว่ที่ไม่เคยทราบมาก่อนมากกว่า 400 รายการ ในไลบรารี Java ที่ใช้อย่างแพร่หลาย พร้อมเปิด Lightwell Clearinghouse ให้ใช้ทั่วไปสำหรับการส่งส่วนประกอบโอเพนซอร์สเข้ารับการพิจารณาและแก้ไขตามลำดับความสำคัญ ตัวเลขดังกล่าวเป็นผลงานด้านการแก้ซอฟต์แวร์ของ Lightwell ไม่ใช่ผลทดสอบว่าการเชื่อมกับ Shield ป้องกันการโจมตีได้กี่ครั้ง

งานของ Lightwell รวมถึงการนำวิธีแก้กลับไปใช้กับซอฟต์แวร์รุ่นเก่าที่ยังอยู่ในระบบจริง วิธีนี้เกี่ยวข้องกับองค์กรที่ไม่สามารถย้ายแอปไปใช้รุ่นใหม่ทั้งหมดได้ทันที เพราะการอัปเกรดใหญ่บางครั้งต้องเปลี่ยนส่วนอื่นตามไปด้วย วิธีแก้ที่เข้ากับรุ่นที่ใช้อยู่ช่วยให้การจัดการช่องโหว่เดินต่อได้ โดยยังต้องผ่านกระบวนการทดสอบและเผยแพร่ซอฟต์แวร์ของผู้ใช้งาน

Lightwell ส่งมอบวิธีแก้ผ่านคลังซอฟต์แวร์ที่มีการป้องกัน เพื่อให้เข้ากับกระบวนการด้านไอทีที่องค์กรใช้อยู่แล้ว ส่วน Lightwell Network เปิดทางให้ทีมเข้าถึงแพตช์ที่ผ่านการตรวจสอบและนำเข้าสู่กระบวนการเดิม การเปิดใช้ทั่วไปของ Clearinghouse หมายถึงช่องทางรับคำขอพิจารณาส่วนประกอบฝั่ง Lightwell มีสถานะพร้อมใช้งานแล้ว ไม่ได้เปลี่ยนสถานะของ Autonomous Application Shield หรือทำให้การทำงานร่วมกันทั้งหมดเปิดใช้ทั่วไปตามไปด้วย

อีกประเด็นหนึ่งคือคำว่า “ผ่านการตรวจสอบ” มีขอบเขตอยู่ที่วิธีแก้ซอฟต์แวร์ซึ่งส่งมอบมา แอปของแต่ละองค์กรอาจมีการตั้งค่า ส่วนเสริม และส่วนประกอบรุ่นอื่นประกอบกัน ผลทดสอบของวิธีแก้จึงไม่อาจแทนการตรวจสอบว่าแอปจริงยังทำงานถูกต้องหลังเปลี่ยนไลบรารี การป้องกันชั่วคราวกับการติดตั้งแพตช์ควรถูกติดตามเป็นคนละสถานะจนกระบวนการนี้เสร็จ

Early Access ครอบคลุมส่วนใดของความร่วมมือ

สถานะที่ยืนยันได้สำหรับ Autonomous Application Shield คือเปิดให้ใช้ผ่าน Early Access Program ขณะที่รายละเอียดความพร้อมใช้งาน ความสามารถ และกำหนดเวลาของความร่วมมืออาจเปลี่ยนแปลงได้ ดังนั้นการประกาศสถาปัตยกรรมร่วมจึงยังไม่เท่ากับการเปิดชุดความสามารถครบถ้วนให้ทุกองค์กรใช้ การมีแพตช์หรือช่องทางรับคำขอแก้ซอฟต์แวร์ของ Lightwell อยู่แล้ว ก็ไม่ได้ยืนยันว่าการป้องกันแบบ inline เชื่อมกับกระบวนการดังกล่าวโดยอัตโนมัติในทุกสภาพแวดล้อม

ข้อความที่ว่ามาตรการป้องกันใช้ได้แบบเรียลไทม์อธิบายวิธีทำงานที่ Zscaler ตั้งใจส่งมอบ เมื่อมีการประเมินแอปและเลือกมาตรการที่เหมาะสมแล้ว ความเร็วของการควบคุมบนเส้นทางเข้าถึงเป็นคนละเรื่องกับความพร้อมของผลิตภัณฑ์สำหรับลูกค้าทั่วไป อีกทั้งไม่บอกด้วยว่าการเชื่อมข้อมูล การกำหนดนโยบาย และการส่งต่อวิธีแก้จาก Lightwell เปิดใช้จริงครบทุกขั้นสำหรับผู้เข้าร่วม Early Access รายใดบ้าง

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

ด้วยเหตุนี้ องค์กรที่สนใจ Early Access จึงต้องทราบว่าแอปประเภทใดอยู่ในขอบเขตของ App Connectors และการประเมินครอบคลุมจุดเข้าถึงใดบ้าง คำตอบจะกำหนดว่าการป้องกันแบบ inline ใช้กับทราฟฟิกที่เกี่ยวข้องจริงเพียงใด หากยังไม่ทราบขอบเขตการมองเห็นของระบบ ก็ยังประเมินช่วงที่มาตรการป้องกันความเสี่ยงได้อย่างมีเหตุผลไม่ได้

คำถามถัดมาคือมาตรการใดเปิดใช้ได้จริงสำหรับช่องโหว่ที่แอปนั้นเผชิญ และองค์กรจะตรวจสอบผลกระทบต่อการทำงานปกติของแอปอย่างไร การควบคุมที่เฉพาะแอปมีประโยชน์เมื่อแยกคำขออันตรายออกจากงานปกติได้ดี รายละเอียดการเปิดใช้และการตรวจสอบผลของมาตรการจึงสำคัญพอ ๆ กับคำอธิบายว่าระบบตอบสนองได้เร็วเพียงใด

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

ผลต่อการจัดการช่องโหว่ของแอปภายในองค์กร

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

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

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

สิ่งที่ยังต้องรอจากความร่วมมือนี้คือขอบเขตความสามารถที่เปิดให้ผู้เข้าร่วม Early Access ใช้จริง เงื่อนไขการเชื่อมงานกับ Lightwell และกำหนดขยายการให้บริการ ข้อมูลเหล่านั้นจะบอกได้ว่าองค์กรสามารถเชื่อมการค้นพบช่องโหว่ การสกัดบนเครือข่าย และการติดตั้งวิธีแก้เข้าด้วยกันได้เพียงใด ระหว่างนี้ การติดตามสถานะการป้องกันชั่วคราวแยกจากสถานะการแก้ส่วนประกอบที่ใช้งานจริงจะให้ภาพความเสี่ยงที่ตรงกว่า