บริหารน้ำท่วมแบบ SOC: พิมพ์เขียวระบบตรวจจับและตอบสนองอุทกภัยสำหรับโรงงาน นิคมอุตสาหกรรม และท้องถิ่นไทย

เดือนกรกฎาคม 2569 รัฐบาลเปิดตัวแพลตฟอร์ม ThaiWater เวอร์ชันใหม่ของสถาบันสารสนเทศทรัพยากรน้ำ (สสน.) ซึ่งรวมข้อมูลจาก 56 หน่วยงานภายใต้ 13 กระทรวง ไว้บนแผนที่เดียว ทั้งเรดาร์ฝน ระดับน้ำ สถานการณ์เขื่อน และพื้นที่เฝ้าระวัง พร้อมเว็บไซต์ศูนย์ข้อมูลน้ำระดับจังหวัดครบทั้ง 76 จังหวัด เช่น chiangrai.thaiwater.net หรือ nan.thaiwater.net

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

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

นี่คือโจทย์เดียวกับที่ศูนย์ปฏิบัติการความปลอดภัยไซเบอร์ (SOC) ถูกสร้างขึ้นมาแก้ บทความนี้จึงเสนอแนวคิด "Flood SOC" — นำรูปแบบการตรวจจับและตอบสนองที่เราใช้กับภัยไซเบอร์ มาใช้กับน้ำ

1. น้ำท่วมกับการโจมตีไซเบอร์ มีโครงสร้างการปฏิบัติการเหมือนกัน

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

แนวคิด SOC	สิ่งที่เทียบเท่าในงานน้ำท่วม
แหล่ง log (ไฟร์วอลล์ เครื่องลูกข่าย VPN)	เซ็นเซอร์ระดับน้ำ เครื่องวัดฝน เรดาร์ กล้อง CCTV รายงานจากประชาชน
การรับและถอดรหัส log ใน SIEM	แปลงข้อมูลเซ็นเซอร์และข้อมูลภาครัฐให้อยู่ในรูปแบบเดียวกัน
กฎ correlation	"น้ำต้นทางขึ้นเร็ว และ มีพยากรณ์ฝนหนัก และ ประตูระบายน้ำปลายทางใช้การไม่ได้"
การตรวจจับ impossible travel	การคาดการณ์เวลาเดินทางของน้ำ: มวลน้ำจะมาถึงเราเมื่อไร
คะแนนความเสี่ยงและระดับความรุนแรง	คะแนนความเสี่ยงน้ำท่วมเฉพาะพื้นที่
ระบบจัดการเคส (DFIR-IRIS)	เหตุน้ำท่วมหนึ่งครั้ง = หนึ่งเคส มีไทม์ไลน์และผู้รับผิดชอบ
SOAR playbook	แจ้งเตือนชุมชน เริ่มแผน BCP ของโรงงาน ส่งทีมภาคสนาม
ปัญหาแจ้งเตือนมากเกินไปและการจูน	เตือนผิดบ่อยจนคนเลิกเชื่อ
แจ้งเตือนเมื่อ agent เงียบ	เซ็นเซอร์ที่หยุดส่งข้อมูลกลางพายุ

สองแถวสุดท้ายสำคัญกว่าที่เห็น โครงการเตือนภัยน้ำท่วมส่วนใหญ่ล้มเหลวเพราะสองเรื่องนี้ ไม่ใช่เพราะเซ็นเซอร์

2. บทเรียนปี 2554: ใครแบกความเสียหาย

มหาอุทกภัยปี 2554 สร้างความเสียหายและความสูญเสียรวม 1.43 ล้านล้านบาท โดยภาคการผลิตแบกรับราว 70% จากการที่นิคมอุตสาหกรรม 6 แห่งในอยุธยาและปทุมธานีจมน้ำ และราว 90% ของความเสียหายทั้งหมดตกอยู่กับภาคเอกชน

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

แพลตฟอร์มระดับชาติตัดสินใจแทนโรงงานแต่ละแห่งไม่ได้ แต่ Flood SOC ทำได้ เพราะกฎถูกเขียนสำหรับรั้วเดียว ทรัพย์สินชุดเดียว และแผนรับมือชุดเดียว

3. สถาปัตยกรรม

flowchart TD
    S1["เซ็นเซอร์ระดับน้ำแม่น้ำและคลอง"] --> N["ปรับรูปแบบข้อมูลและเสริมบริบท"]
    S2["เครื่องวัดฝนและเรดาร์"] --> N
    S3["ข้อมูล ThaiWater และศูนย์ข้อมูลน้ำจังหวัด"] --> N
    S4["กล้อง CCTV อ่านไม้วัดระดับน้ำ"] --> N
    S5["รายงานจากประชาชนผ่าน LINE"] --> N
    H["ตรวจสัญญาณชีพเซ็นเซอร์"] --> R
    N --> R["เอนจิน correlation และให้คะแนนความเสี่ยง"]
    R -->|"คะแนนต่ำ"| L["บันทึกไว้เท่านั้น"]
    R -->|"คะแนนกลาง"| C["เปิดเคสน้ำท่วม"]
    R -->|"คะแนนสูง"| P["เปิดเคสและปลุกเจ้าหน้าที่เวร"]
    C --> I["จัดการเคสใน DFIR-IRIS"]
    P --> I
    I --> PB["Playbook อัตโนมัติผ่าน SOAR"]
    PB --> A1["แจ้งเตือน LINE และ SMS หลายภาษา"]
    PB --> A2["แผน BCP ของโรงงาน"]
    PB --> A3["แผนที่ TAK สำหรับทีมภาคสนาม"]

ทุกกล่องในแผนภาพนี้มีอยู่แล้วใน SOC ที่ใช้งานจริง สิ่งที่เปลี่ยนคือข้อมูลขาเข้าและ playbook ขาออก

ชั้นสัญญาณ เซ็นเซอร์วัดระดับน้ำแบบเรดาร์หรืออัลตราโซนิกราคาไม่สูง ติดที่คลอง สะพาน และท่อระบายรอบรั้วโรงงาน ส่งข้อมูลผ่าน LoRaWAN หรือ NB-IoT ข้อมูลจาก ThaiWater และศูนย์ข้อมูลน้ำจังหวัดตามเงื่อนไขการแลกเปลี่ยนข้อมูลของผู้ให้บริการ กล้อง CCTV ที่มีอยู่แล้วอ่านไม้วัดระดับน้ำ และรายงานจากประชาชนที่ส่งภาพพร้อมพิกัดเข้า LINE Official Account

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

ชั้นตอบสนอง DFIR-IRIS เก็บเคส Shuffle รัน playbook ส่วนการประสานงานภาคสนาม เคสจะถูกส่งต่อไปยังแผนที่ปฏิบัติการร่วมของ TAK ซึ่งเราเคยอธิบายไว้ในระบบ TAK พลิกโฉมการรับมือภัยพิบัติน้ำท่วม — Flood SOC คือชั้นที่ตัดสินว่า เมื่อไร ควรเรียก TAK เข้ามา

4. กฎตรวจจับ: จากค่าขีดเตือนสู่ correlation

ระดับ 1 — ค่าขีดเตือน "ถ้าระดับน้ำที่สถานี X เกิน Y ให้แจ้งเตือน" ระบบเตือนภัยท้องถิ่นส่วนใหญ่ทำแบบนี้ ดีกว่าไม่มี แต่เสียงดังเกินจริงบ่อย

ระดับ 2 — ให้คะแนนความเสี่ยง รวมสัญญาณอ่อนหลายตัวเป็นคะแนนเดียวที่อธิบายได้ ตัวอย่างสำหรับโรงงานริมแม่น้ำ:

สัญญาณ	คะแนน
ระดับน้ำต้นทางขึ้นเร็วกว่า 20 ซม. ต่อชั่วโมง	+35
สถานีใกล้สุดห่างขอบตลิ่งไม่ถึง 50 ซม.	+30
พยากรณ์ฝนหนักมาก (เกิน 90 มม. ใน 24 ชม.) ในลุ่มน้ำ	+20
ประตูระบายน้ำหรือสถานีสูบน้ำปลายทางใช้การไม่ได้	+15
รายงานจากประชาชนตั้งแต่ 2 รายการในรัศมี 1 กม. ภายใน 30 นาที	+15

70 ขึ้นไป → วิกฤต เปิดเคสและปลุกเจ้าหน้าที่เวร / 40–69 → เปิดเคส ไม่ปลุก / ต่ำกว่า 40 → บันทึกไว้

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

ระดับ 3 — correlation แบบจำสถานะ

• คาดการณ์เวลาเดินทาง แทน impossible travel ใน SOC การล็อกอินสองครั้งที่ห่างกันเกินกว่าจะเดินทางทันถูกตีว่าผิดปกติ ใน Flood SOC มวลน้ำที่สถานีต้นทาง บวกเวลาเดินทางในอดีตตามลำน้ำ ให้ช่วงเวลาที่น้ำจะมาถึงปลายทาง ข้อความเตือนจึงบอกว่า "คาดว่าถึงรั้วโรงงานใน 9–14 ชั่วโมง" ไม่ใช่แค่ "น้ำสูงที่ไหนสักแห่ง"
• ตัดเคสซ้ำ ถ้าช่วงลำน้ำเดิมมีเคสเปิดอยู่แล้ว ข้อมูลใหม่จะต่อท้ายเคสเดิม ไม่เช่นนั้นพายุลูกเดียวจะสร้าง 50 เคสที่ไม่มีใครอ่าน
• ยกระดับตามแนวโน้ม เคสที่ค้างระดับกลางแต่อัตราน้ำขึ้นเร่งตัว จะถูกคำนวณคะแนนใหม่อัตโนมัติ

ผลการตัดสินใจจากเอนจินหน้าตาเหมือนการตัดสินใจใน SOC:

{
  "decision": "create_case_and_page",
  "severity": "critical",
  "risk_score": 80,
  "reach": "upstream-bridge-to-estate-north-gate",
  "reason": "Upstream rise 28 cm/h, bank crest margin 40 cm, very heavy rain forecast",
  "predicted_arrival_hours": [9, 14],
  "playbook": "estate-bcp-level-2"
}

5. ความเงียบคือสัญญาณ

ใน SOC agent ที่หยุดส่ง log ถือเป็นการแจ้งเตือนในตัว simpliSOC มีความสามารถนี้แล้วสำหรับแหล่ง log: ถ้าไม่มีเหตุการณ์เข้ามาในช่วงเวลาที่กำหนด ระบบจะแจ้งเตือน

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

6. จูนก่อนขยาย: เตือนผิดบ่อยแย่กว่าไม่เตือน

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

7. เรื่องที่องค์กรไทยต้องคิดเพิ่ม: PDPA และความปลอดภัยของตัวระบบเอง

รายชื่อผู้รับแจ้งเตือนคือข้อมูลส่วนบุคคล เบอร์โทรศัพท์ LINE ID และที่อยู่ของชาวบ้านหรือพนักงานที่ลงทะเบียนรับแจ้งเตือน อยู่ภายใต้ PDPA ต้องมีฐานทางกฎหมายหรือความยินยอม กำหนดระยะเวลาเก็บ และควบคุมสิทธิ์การเข้าถึง การติดตั้งแบบ on-premise ช่วยให้ข้อมูลเหล่านี้ไม่ต้องออกนอกโครงสร้างพื้นฐานขององค์กร

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

8. อะไรมีแล้ว อะไรสร้างตามโครงการ อะไรอยู่นอกขอบเขต

มีให้ใช้แล้ววันนี้:

• simpliSOC: การตรวจจับด้วย Wazuh การจัดการเคสด้วย DFIR-IRIS ระบบอัตโนมัติด้วย Shuffle และ integrator สำหรับ correlation การตัดเคสซ้ำ และการจับคู่ระดับความรุนแรง ติดตั้งแบบ on-premise ด้วย Docker Compose
• การแจ้งเตือนเมื่อแหล่ง log หยุดส่งข้อมูล
• บริการ TAK Integration รวมถึงการเชื่อมเคสและการแจ้งเตือนเข้าสู่แผนที่ปฏิบัติการร่วม

สร้างตามแต่ละโครงการ (ไม่ใช่ฟีเจอร์สำเร็จรูป):

• การรับข้อมูลเซ็นเซอร์ ตัวถอดรหัส และโครงสร้างเหตุการณ์น้ำท่วม
• กฎ correlation คะแนนความเสี่ยง และการคาดการณ์เวลาเดินทางของน้ำ ที่จูนเฉพาะพื้นที่
• ตัวเชื่อมข้อมูล ThaiWater หรือศูนย์ข้อมูลน้ำจังหวัด ตามเงื่อนไขของผู้ให้ข้อมูล
• ระบบแจ้งเตือนผ่าน LINE Official Account และข้อความหลายภาษา (ไทย อังกฤษ เมียนมา ลาว กัมพูชา) สำหรับแรงงานข้ามชาติ
• Playbook BCP ของโรงงาน และการเชื่อมต่อ ERP
• กฎตรวจสัญญาณชีพเซ็นเซอร์

นอกขอบเขต:

• การประกาศเตือนภัยอย่างเป็นทางการและคำสั่งอพยพ ซึ่งเป็นอำนาจของกรมป้องกันและบรรเทาสาธารณภัย (ปภ.) กรมอุตุนิยมวิทยา และองค์กรปกครองส่วนท้องถิ่น Flood SOC ช่วยการตัดสินใจ ไม่ได้แทนที่การเตือนภัยของรัฐ
• การพยากรณ์อุทกวิทยาในฐานะหน่วยงานรับรอง
• การผลิตฮาร์ดแวร์เซ็นเซอร์ เราเชื่อมต่ออุปกรณ์จากพันธมิตรด้านฮาร์ดแวร์

คำถามที่พบบ่อย

Flood SOC เป็นผลิตภัณฑ์สำเร็จรูปหรือไม่?
ไม่ใช่ เป็นสถาปัตยกรรมอ้างอิงที่ประกอบจากส่วนที่มีอยู่แล้ว (simpliSOC, integrator, TAK integration) บวกงานเฉพาะพื้นที่: เซ็นเซอร์ กฎ playbook และการจูน

ใช้แทน ThaiWater หรือการเตือนภัยของ ปภ. ได้ไหม?
ไม่ได้ ThaiWater เป็นหนึ่งในแหล่งข้อมูลสำคัญที่สุด Flood SOC เพิ่มชั้นปฏิบัติการเฉพาะพื้นที่: กฎ เคส ผู้รับผิดชอบ และแผนรับมือสำหรับรั้วของคุณ

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

ข้อมูลเก็บไว้ที่ไหน?
On-premise หรือ private cloud ขององค์กร เหมือนการติดตั้ง simpliSOC ทั่วไป

คุยกับเรา

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

อีเมล hello@simplico.net หรืออ่านเพิ่มเติมเกี่ยวกับ simpliSOC และบริการ TAK Integration

---

แหล่งที่มา:

• All-in-One Page: Government Revamps ThaiWater App — Thairath English, 17 ก.ค. 2569
• 2011 Thailand Floods — Rapid Assessment for Resilient Recovery and Reconstruction Planning — PreventionWeb / World Bank
• วิธีสร้าง Automated Decision Logic ใน SOC ยุคใหม่ — Simplico
• ระบบ TAK พลิกโฉมการรับมือภัยพิบัติน้ำท่วม — Simplico