การเลือก Data Diode สำหรับโรงงานไทย: แนวทางเชื่อมข้อมูล OT ไป IT ทางเดียว

ก่อนเลือก Data Diode สำหรับโรงงาน ควรเริ่มจากเส้นทางของข้อมูล ไม่ใช่ชื่อรุ่นอุปกรณ์: ข้อมูลการผลิตใดต้องออกจาก OT ไปที่ไหน และมีขั้นตอนใดต้องส่งคำสั่งกลับเข้ามาหรือไม่ โรงงานในไทยมักต้องการส่งข้อมูลเครื่องจักรไปยังสำนักงานใหญ่ ระบบคุณภาพ หรือระบบวิเคราะห์บนคลาวด์ โดยไม่เพิ่มช่องทางเข้าถึงตัวควบคุมจากภายนอก บทความนี้อธิบายขอบเขตที่เหมาะกับการส่ง OT→IT ทางเดียว ข้อควรตรวจสอบของ OPC UA และ MQTT วิธีเขียน RFP และเกณฑ์ FAT/SAT ที่ใช้งานได้จริง

เริ่มจากทิศทางของข้อมูลก่อนติดตั้ง Data Diode

นิยามของ NIST ระบุว่า Data Diode เป็นอุปกรณ์เครือข่ายที่ยอมให้ข้อมูลไหลได้เพียงทิศทางเดียว แต่ผลิตภัณฑ์แต่ละรายต่างกันทั้งฮาร์ดแวร์แสง ซอฟต์แวร์รับส่ง และตัวแปลงโปรโตคอล คำถามหลักของการจัดซื้อคือ ขอบเขตนี้เป็น OT→IT โดยไม่มีเส้นทางเครือข่ายย้อนกลับได้จริงหรือไม่ การตั้งกฎไฟร์วอลล์ให้ดูเหมือนส่งทางเดียวกับการใช้ลิงก์ที่ส่งกลับไม่ได้ทางกายภาพ ต้องใช้หลักฐานการออกแบบและการทดสอบต่างกัน ใน RFP ควรแยกอุปกรณ์ที่บังคับทิศทางออกจากซอฟต์แวร์ที่รวบรวมและจำลองข้อมูล

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

NIST SP 800-82 Rev.3 กล่าวถึงเกตเวย์ทางเดียวเป็นทางเลือกในบางขอบเขต OT โดยให้คำนึงถึงความปลอดภัย ความเชื่อถือได้ และประสิทธิภาพของระบบควบคุม การติดตั้งไม่ได้กำจัดความเสี่ยง OT ทั้งหมด เครื่องปลายทาง สื่อถอดเสียบ สิทธิ์ภายใน และการควบคุมการเปลี่ยนแปลงยังต้องจัดการ ถ้ามีหลายโรงงาน ควรตรวจความต้องการด้านการควบคุมของแต่ละแห่งก่อนทำแบบมาตรฐานร่วมกัน

*ลูกศรสีส้มในภาพหมายถึงความพยายามส่งย้อนกลับที่ถูกปิดกั้น ไม่ใช่เส้นทางข้อมูลขากลับที่อนุญาต*

งานที่เหมาะกับทางเดียว และงานที่ต้องมีวิธีอื่น

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

วางขอบเขต OT→IT ตรงไหนในโรงงานไทย

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

แผนภาพต้องมีทางเชื่อมจริงทั้งหมด เช่น วงจรรีโมตของผู้รับเหมา ไฟล์ที่นำเข้าทาง USB ระบบตั้งเวลา การอัปเดต Antivirus และเส้นทางกู้คืน Backup หากมีเส้นทางสองทิศทางอื่นเข้าสู่โซน OT เดียวกัน จะอ้างว่าโซนนั้นแยกทางเดียวทั้งหมดไม่ได้ ระบุว่า Data Diode ป้องกันเส้นทางใด และเส้นทางใดยังเหลืออยู่

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

คอลัมน์ที่ควรมีในทะเบียน Data Flow

หนึ่งแถวควรระบุระบบต้นทาง แท็กหรือไฟล์ ความหมายและหน่วย เวลาของเหตุการณ์ เวลาหน่วงที่ยอมรับได้ วิธีรับมือข้อมูลขาด วิธีอ่านฝั่ง OT รูปแบบที่ข้ามขอบเขต ปลายทาง IT ระยะเก็บรักษา และผู้รับผิดชอบ ค่าอุณหภูมิที่ไม่มี ID จุดวัด หน่วย เวลา และ Quality Flag อาจใช้วิเคราะห์ไม่ได้ การทดสอบรับมอบต้องตรวจความหมายของข้อมูล ไม่ใช่แค่เชื่อมต่อได้

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

ใช้ OPC UA และ MQTT ผ่านขอบเขตทางเดียวอย่างไร

OPC UA แบบ Client/Server ปกติให้ Client เชื่อมต่อ Server ส่งคำขออ่านหรือ Subscribe และรับคำตอบ การสนทนานี้ไม่สามารถผ่านลิงก์ทางเดียวทางกายภาพโดยไม่เปลี่ยนโครงสร้าง วิธีหนึ่งคือให้ซอฟต์แวร์ฝั่ง OT อ่าน Server ภายใน ส่งค่าที่เลือกออกทางเดียว แล้วสร้าง Replica Server หรือแอปรับข้อมูลฝั่ง IT จากนั้น Client ฝั่ง IT ต่อกับ Replica เอกสาร OPC UA Data Access ของ Waterfall อธิบายบทบาท Client ต้นทางและ Replica ปลายทาง นี่เป็นตัวอย่างของผู้ผลิตหนึ่งราย ไม่ใช่ความสามารถที่ทุกผลิตภัณฑ์มี

OPC UA PubSub เป็นรูปแบบสื่อสารอีกแบบ ข้อกำหนด Part 14 ของ OPC Foundation นิยาม Publisher, Subscriber, Dataset และวิธีผ่าน Broker รวมทั้ง MQTT จึงไม่ถูกต้องทั้งการบอกว่า OPC UA ทุกแบบต้องผ่านสองทาง หรือ PubSub ทุกแบบผ่าน Data Diode ได้ทันที ตรวจ Profile, Encoding, Metadata, รูปแบบความปลอดภัย และวิธีเปลี่ยนค่าในผลิตภัณฑ์จริง แสดง Publisher ฝั่ง OT ตัวส่งผ่าน และ Subscriber/Broker ฝั่ง IT เป็นคนละส่วน

MQTT ปกติที่เชื่อม Broker มีการสร้างการเชื่อมต่อและข้อความตอบรับสองทาง การต่อแพ็กเก็ต MQTT เข้ากับสายไฟเบอร์ทางเดียวตรง ๆ จึงไม่ใช่แผนปฏิบัติ เกตเวย์อาจรับข้อมูลที่ฝั่งต้นทาง ห่อเพื่อส่งทางเดียว แล้วเผยแพร่ใหม่ไปยัง Broker ฝั่ง IT หรือใช้ Adapter แบบอื่น คำอธิบาย Cloud Gateway ของ Owl กล่าวถึง MQTT ภายใต้สถาปัตยกรรมของตนเอง ให้ผู้ขายทดสอบด้วยข้อมูลและ Broker ปลายทางของโรงงาน

*ลูกศรสีส้มในภาพหมายถึงความพยายามส่งย้อนกลับที่ถูกปิดกั้น ไม่ใช่เส้นทางข้อมูลขากลับที่อนุญาต*

อย่าเลือกจากชื่อโปรโตคอลเพียงอย่างเดียว

แม้ข้อมูลข้ามขอบเขตทางเดียว กระบวนการเปลี่ยนงานอาจเป็นการสื่อสารระหว่างคนสองทาง ฝ่าย IT ขอแท็กใหม่ผ่าน Ticket แล้ว OT อนุมัติและตั้งค่าภายในได้ แต่ห้ามอธิบายว่า IT ส่งคำสั่งตั้งค่ากลับผ่าน Data Diode โดยอัตโนมัติ เขียนทางเดินข้อมูลและขั้นตอนอนุมัติแยกกัน อ่านเพิ่มเติมเกี่ยวกับการเชื่อม OPC UA กับคลาวด์ และการใช้ MQTT Sparkplug B

เปรียบเทียบ Data Diode กับ Firewall อย่างไร

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

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

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

ระบุว่า “ทางเดียว” พิสูจน์ถึงส่วนใด

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

คำว่า “รองรับ OPC UA” หรือ “รองรับ MQTT” ไม่ได้หมายถึงทุกฟังก์ชัน ระบุชนิดข้อมูล Certificate การเข้ารหัส การเชื่อมต่อใหม่ จำนวนผู้ใช้ และความหมายข้อมูลที่ต้องใช้ ตัวอย่าง Replica ของ Waterfall กับ Adapter สำหรับคลาวด์ของ Owl แสดงว่าซอฟต์แวร์รอบลิงก์ทางเดียวอาจต่างกันมาก

เขียนข้อกำหนด RFP ที่เปรียบเทียบได้

เริ่มจากขอบเขตที่ป้องกันและจุดรับส่ง ไม่ใช่หมายเลขรุ่น ระบุโรงงาน สายการผลิต แผนภาพ OT/IT ปัจจุบัน ช่วงเวลาที่หยุดระบบได้ และเวอร์ชัน OPC UA, MQTT, Historian ที่ใช้ ให้ทีมอุปกรณ์ ผู้รวมระบบ และผู้ขายใช้ข้อมูลตั้งต้นเดียวกัน

แยกข้อกำหนดบังคับกับข้อเสนอเพิ่มเติม ข้อบังคับอาจเป็นไม่มีการไหล IT→OT ผ่านขอบเขตที่กำหนด รักษาความหมายข้อมูล ไม่กระทบระบบควบคุมเมื่อเกตเวย์เสีย ตรวจพบเหตุผิดปกติ และมี Log ส่วน Dashboard หรือการขยายในอนาคตอาจเป็นข้อเสนอเพิ่มเติม แม้เป้าหมายคือคลาวด์ ให้ถามก่อนว่าจำเป็นต้องเก็บข้อมูลรับรองคลาวด์ใกล้ PLC หรือไม่ หรือแยกการอ่านฝั่ง OT กับการส่งขึ้นคลาวด์ฝั่ง IT ได้

ตารางตรวจ RFP พร้อมช่องคำตอบผู้ขาย

ตัวเลข “แท็กสูงสุด” หรือ “Throughput สูงสุด” ต้องดูเงื่อนไขที่ใช้วัดด้วย รอบอัปเดต ขนาด Payload, Buffer, การแปลง การเข้ารหัส และระบบสำรองทำให้สมรรถนะจริงต่างกัน วัดข้อมูลตัวอย่างของโรงงานก่อนกำหนดเป้าและแนบเงื่อนไขทดสอบ การตั้งตัวเลขทั่วไปโดยไม่มีฐานอาจทำให้ซื้อเกินหรือไม่พอ

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

FAT และ SAT ต้องรับมอบอะไร

FAT ทดสอบการแปลงข้อมูลและการทำงานเมื่อเสียในชุดจริงหรือชุดจำลองที่ใกล้เคียง SAT ยืนยันอีกครั้งด้วยสาย ไฟฟ้า ปลายทาง และวิธีปฏิบัติของหน้างาน การเห็นค่าบนหน้าจออย่างเดียวไม่พอ ต้องรู้ว่าความหมายข้อมูลต้นทางกับปลายทางตรงกัน ผู้ใช้เห็นเมื่อข้อมูลหยุด และอธิบายช่วงที่ขาดหลังฟื้นตัวได้

เตรียมข้อมูลมากกว่าค่าปกติ: การตัดการสื่อสาร ข้อมูลเข้ามากพร้อมกัน แท็กเปลี่ยนชื่อ ค่า NULL หรือ Quality ไม่ดี และเวลาไม่ตรงกัน OPC UA ให้เทียบค่า Quality และเวลาพร้อมกัน MQTT ให้เทียบ Topic, Payload, การส่งซ้ำ และข้อมูลซ้ำ Historian ต้องทดสอบการไล่ข้อมูลย้อนหลังหลังหยุดนาน การเติมประวัติอัตโนมัติไม่ใช่ความสามารถมาตรฐานของทุกผลิตภัณฑ์ ต้องระบุเป็นข้อกำหนดถ้าต้องใช้

*ลูกศรสีส้มในภาพหมายถึงความพยายามส่งย้อนกลับที่ถูกปิดกั้น ไม่ใช่เส้นทางข้อมูลขากลับที่อนุญาต*

ตัวอย่างกรณีทดสอบรับมอบ

ทุกเกณฑ์ควรมีวิธีวัดและหลักฐาน เปลี่ยน “หน่วงน้อย” เป็นเวลาที่รับได้ต่อชุดข้อมูล จุดเริ่ม/จบการวัด และวิธีตั้งนาฬิกา เปลี่ยน “ข้อมูลไม่หาย” เป็นระยะเวลาล่ม ความจุ Buffer เวลาส่งย้อนหลัง และวิธีแจ้งช่องว่าง ตัวเลขในสัญญาต้องมาจากกระบวนการและการวัดของโรงงาน

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

ข้อจำกัดเรื่องระบบสำรอง การกู้คืน และการบำรุงรักษา

ทางเดียวไม่ได้ทำให้ระบบพร้อมใช้เอง ตัวเก็บข้อมูล OT ลิงก์ ตัวเผยแพร่ซ้ำ IT, Historian หรือ Broker หยุดตัวใดตัวหนึ่งก็ทำให้ข้อมูลปลายทางเก่าได้ เฝ้าระวังสถานะปกติ หน่วง หยุด และกำลังกู้คืน พร้อมแสดงเวลาที่ได้รับข้อมูลถูกต้องล่าสุด ค่าที่เก่าแต่หน้าจอดูเหมือนปัจจุบันอาจอันตรายกว่าการแจ้งว่าเชื่อมต่อไม่ได้

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

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

การเพิ่มแท็ก เปลี่ยนชื่อแท็ก เปลี่ยนช่วงค่า หรือ Topic ใหม่เป็นคำขอเปลี่ยนงาน การเพิ่มปลายทาง IT อาจเปลี่ยนภาระอ่านฝั่ง OT หรือระดับความลับข้อมูล กำหนดผู้ขอ ผู้อนุมัติ ผู้ลงมือ ผู้ทดสอบ และผู้ดูแล แล้วตรวจข้อมูลหลังเปลี่ยน อ่านคู่มือ RFP ความปลอดภัย OT เพื่อวางขอบเขตจัดซื้อโดยรวม

เริ่มจากโครงการพิสูจน์ขนาดเล็ก

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

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

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

อนุมัติงานที่ยังต้องใช้ทิศทางย้อนกลับ

งานที่ยากในการออกแบบทางเดียวมักไม่ใช่การเก็บข้อมูลประจำวัน แต่เป็นงานย้อนทิศที่เกิดไม่บ่อย เช่น สูตรผลิตใหม่ การเปลี่ยนค่าจากผู้ผลิตเครื่อง Patch, Certificate, การตั้งเวลา หรือการตอบรับ Alarm ถ้าตัดงานที่เกิดน้อยออกจากรายการข้อกำหนด อาจเกิดทางลัดที่ไม่มีการควบคุมหลังเริ่มใช้งาน ระบุว่าใครนำข้อมูลอะไร เข้าอุปกรณ์ OT ใด เมื่อใด แล้วแยกเส้นทางที่ปิดทางเทคนิคออกจากวิธีเปลี่ยนงานที่ได้รับอนุมัติ

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

การตอบรับ Alarm ต้องแยกความหมาย การส่งเหตุการณ์จาก OT ไป IT กับการส่งการกดยืนยันของคนกลับไปเปลี่ยนสถานะ Alarm ใน OT เป็นคนละ Data Flow ถ้าเพียงทำเครื่องหมาย “อ่านแล้ว” ในระบบ IT อาจไม่ต้องมีทางย้อน แต่ถ้าจะเปลี่ยนสถานะในระบบควบคุม ต้องมีวิธีส่งกลับ ระบุความหมายที่ RFP และ FAT ทดสอบให้ชัด โดยเฉพาะหน้าจอที่ผู้ควบคุมใช้ในเหตุฉุกเฉิน

สรุปการตัดสินใจก่อนสั่งซื้อในหน้าเดียว

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

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

คำถามที่พบบ่อย: การเลือก Data Diode สำหรับโรงงาน

Q1. มี Data Diode แล้วไม่ต้องใช้ Firewall หรือไม่?

ไม่ใช่ Data Diode จัดการทางย้อนผ่านขอบเขตเฉพาะ การแบ่งโซน OT พอร์ตบริหาร การเชื่อมสองทางที่จำเป็น และสิทธิ์ฝั่ง IT ยังอาจต้องใช้มาตรการอื่น กำหนดบทบาทในแผนภาพการเชื่อมต่อทั้งหมด

Q2. OPC UA Client เดิมบน IT ต่อ Server ใน OT ตรงได้หรือไม่?

อย่าสมมติว่า Session แบบโต้ตอบจะผ่านลิงก์ทางเดียวได้โดยไม่เปลี่ยนโครงสร้าง ตรวจการใช้ Collector ฝั่ง OT กับ Replica ฝั่ง IT ที่ผู้ผลิตรองรับ และทดสอบ Node, Quality, เวลา, Certificate และการปรับโครงสร้างข้อมูล

Q3. MQTT ตั้งค่าให้เป็นทางเดียวอย่างเดียวได้หรือไม่?

การต่อ Broker ปกติมีข้อความสองทิศทาง สถาปัตยกรรม Data Diode ต้องมี Adapter หรือ Broker ในตำแหน่งที่เหมาะสม ทดสอบ Topic, QoS, การต่อใหม่ ข้อมูลซ้ำ และความปลอดภัยด้วยข้อมูลจริง

Q4. สำนักงานใหญ่ส่งสูตรหรือไฟล์ตั้งค่าเข้าโรงงานได้หรือไม่?

ส่งย้อนผ่านลิงก์ OT→IT นี้ไม่ได้ ต้องออกแบบวิธีอื่นที่อนุมัติ เช่น สื่อที่ควบคุม วงจรที่บริหารแยก หรือการเปลี่ยนค่าที่หน้างาน

Q5. เปรียบเทียบค่าใช้จ่ายอย่างไร?

ขอใบเสนอราคาขอบเขตเดียวกัน ทั้งอุปกรณ์ ซอฟต์แวร์เก็บ/จำลอง Adapter เซิร์ฟเวอร์ทั้งสองฝั่ง ไฟเบอร์ FAT/SAT การสนับสนุน และแท็กที่จะเพิ่ม พร้อมข้อจำกัดหยุดเครื่องและการกู้คืน ราคาแบบไม่ระบุขอบเขตทำให้ตัดสินใจผิด

Q6. ถ้า Data Diode เสีย สายการผลิตจะหยุดหรือไม่?

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

สรุป: กำหนดข้อมูลและเกณฑ์รับมอบก่อนเลือกอุปกรณ์

แยกข้อมูลที่ออก OT→IT จากการปฏิบัติงานที่ต้องย้อน IT→OT แล้วกำหนดความหมายข้อมูล จุดสิ้นสุดโปรโตคอล ขอบเขตหลักฐานทางเดียว การส่งย้อนหลังหลังเสีย และเกณฑ์ผ่าน FAT/SAT วิธีนี้ทำให้การเทียบผลิตภัณฑ์เป็นการออกแบบที่โรงงานอนุมัติได้ งานย้อนทิศต้องมีแบบและขั้นตอนควบคุมแยกต่างหาก

หากโรงงานในไทยยังอยู่ช่วงร่าง Data Flow หรือ RFP เราสามารถช่วยเริ่มจาก OPC UA และ MQTT ที่ใช้อยู่กับข้อมูลที่ผู้ใช้งานต้องการจริง ติดต่อ TOMAS TECH

แหล่งอ้างอิง

• NIST, Data Diode Glossary
• NIST, SP 800-82 Rev.3
• OPC Foundation, OPC UA Part 14: PubSub
• Waterfall Security, Waterfall for OPC UA Data Access
• Owl Cyber Defense, Secure Connections to the Cloud
• OPSWAT, MetaDefender Optical Diode