กฎหมาย Active Cyber Defense ของญี่ปุ่นเริ่มบังคับใช้ 1 ตุลาคม: บริษัทไทยในซัพพลายเชนญี่ปุ่นต้องเตรียม SOC อย่างไร

ญี่ปุ่นผ่านกฎหมายว่าด้วยการป้องกันความเสียหายจากการกระทำโดยมิชอบต่อระบบคอมพิวเตอร์สำคัญเมื่อเดือนพฤษภาคม 2568 ในญี่ปุ่นมักเรียกว่า "กฎหมายเสริมสร้างขีดความสามารถรับมือภัยไซเบอร์" หรือ "กฎหมาย Active Cyber Defense" กฎหมายนี้ทยอยมีผลบังคับใช้เป็นระยะ และบทบัญญัติหลักจะมีผลในวันที่ 1 ตุลาคม 2569 ตั้งแต่วันนั้น ผู้ประกอบการโครงสร้างพื้นฐานสำคัญของญี่ปุ่นมีหน้าที่รายงานเหตุการณ์ไซเบอร์ต่อรัฐบาล และคณะกรรมการแลกเปลี่ยนข้อมูลภาครัฐ–เอกชนก็เริ่มทำงานจริง

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

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

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

1. อะไรเริ่ม 1 ตุลาคม และอะไรยังไม่เริ่ม

ช่วงเวลา	สิ่งที่มีผลบังคับใช้
1 ก.ค. 2568	บททั่วไป (หมวด 1)
1 เม.ย. 2569	จัดตั้งคณะกรรมการกำกับดูแลการใช้ข้อมูลการสื่อสาร
1 ต.ค. 2569	บทบัญญัติหลัก: หน้าที่รายงานเหตุการณ์ การแบ่งปันข้อมูลจากรัฐ และคณะกรรมการร่วม
1 เม.ย. 2570 (คาดการณ์)	กำหนดส่งรายการทรัพย์สินครั้งแรก (ตามบทวิเคราะห์ของ PwC Japan)
ภายใน 22 พ.ย. 2570	การที่รัฐได้มาและใช้ข้อมูลการสื่อสาร (หมวด 3–7) ยังไม่กำหนดวันแน่นอน

2. ขอบเขตไปไกลกว่า 257 บริษัท

ระบบที่ต้องรายงานเรียกว่า "คอมพิวเตอร์สำคัญเฉพาะ" หมายถึงระบบที่หากถูกโจมตีแล้วอาจทำให้สิ่งอำนวยความสะดวกสำคัญหยุดทำงานหรือทำงานได้ลดลง PwC Japan สรุปจากร่างกฎกระทรวงว่า นอกจากตัวสิ่งอำนวยความสะดวกสำคัญเองแล้ว ขอบเขตยังน่าจะครอบคลุมสิ่งต่อไปนี้:

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

รายการนี้แทบจะตรงกับแหล่ง log ชุดแรกที่ SOC ส่วนใหญ่เชื่อมต่อเข้า SIEM ไม่ว่าจะเป็นไฟร์วอลล์ VPN หรือ Active Directory

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

3. แปลงหน้าที่รายงานเป็นงานของ SOC

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

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

รายงาน 2 ขั้น ร่างกฎกระทรวงกำหนดให้ส่งรายงานเบื้องต้นโดยเร็วหลังรับรู้เหตุ และรายงานฉบับละเอียดภายใน 30 วัน ถึงรัฐมนตรีที่กำกับดูแลอุตสาหกรรมและนายกรัฐมนตรี การส่ง "โดยเร็ว" ได้จริงต้องกำหนดไว้ล่วงหน้าว่าใครเป็นผู้ประกาศว่ารับรู้เหตุแล้ว และใช้เกณฑ์อะไร

รายงานฉบับละเอียดต้องมีข้อมูลทางเทคนิค เช่น วิธีโจมตี ต้นทางและปลายทางในกรณี DDoS หรือช่องทางการเจาะระบบและชนิดของ ransomware บันทึกการสืบสวนจึงควรเป็นร่างรายงานไปในตัว

บทลงโทษ: หากไม่รายงานและไม่ปฏิบัติตามคำสั่งแก้ไข ปรับไม่เกิน 2 ล้านเยน หากไม่ส่งเอกสารตามที่ถูกเรียก ปรับไม่เกิน 3 แสนเยน

4. โฟลว์จากการตรวจจับถึงรายงานฉบับละเอียด

flowchart TD
  A["แหล่ง log FW VPN AD ESXi Sysmon"] --> B["Wazuh ตรวจจับด้วย rule และ IOC"]
  A --> L["เฝ้าระวัง log ที่ขาดหาย"]
  L --> B
  B --> C["SOC Integrator ตัดซ้ำและเปิด alert ใน IRIS"]
  C --> D["นักวิเคราะห์คัดกรอง"]
  D --> E["เกี่ยวกับระบบที่อยู่ในขอบเขตหรือไม่"]
  E -->|"ใช่"| F["บันทึกเวลาที่รับรู้และผู้ตัดสินใจในเคส"]
  E -->|"ไม่ใช่"| G["จัดการเหตุการณ์ตามปกติ"]
  F --> H["รายงานเบื้องต้นโดยเร็ว"]
  H --> I["สืบสวน รวม IOC ทรัพย์สิน ไทม์ไลน์ หลักฐานในเคสเดียว"]
  I --> J["รายงานฉบับละเอียดภายใน 30 วัน"]

5. simpliSOC ทำอะไรได้แล้ว อะไรต้องทำเฉพาะโครงการ

ฟีเจอร์ที่มีอยู่แล้ว (ตามหน้าผลิตภัณฑ์ simpliSOC)

ข้อกำหนด	ความสามารถของ simpliSOC
การตรวจจับ ซึ่งเป็นพื้นฐานของการรับรู้เหตุ	Wazuh custom rules กว่า 50 รายการ ครอบคลุม FortiGate firewall, IPS, VPN, Windows AD, VMware ESXi และ Sysmon
ร่องรอยและสัญญาณเตือน	RDP brute force, port scan, password spraying และ IOC feeds (Feodo Tracker, URLhaus, ThreatFox) ที่อัปเดตอัตโนมัติ
ไม่มีช่องว่างเงียบ	แจ้งเตือนเมื่อไม่มี log เข้ามาภายในเวลาที่กำหนด
การโจมตีหลายขั้น	Correlation rules ข้ามไฟร์วอลล์ VPN endpoint และระบบยืนยันตัวตน
วัตถุดิบสำหรับรายงานฉบับละเอียด	เคสใน DFIR-IRIS รวมสรุป บันทึก ทรัพย์สิน IOC ไทม์ไลน์ งาน และหลักฐาน
ช่วยคัดกรองขั้นแรก	Local LLM อธิบาย alert เป็นภาษาที่เข้าใจง่ายพร้อมประเมิน true/false positive โดยไม่ปิด รวม หรือระงับ alert เอง นักวิเคราะห์เป็นผู้ตัดสินใจทุกครั้ง
ข้อมูลไม่ออกนอกองค์กร	ติดตั้งแบบ on-premise หรือ private cloud

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

การจับคู่ประเภทเหตุการณ์ตามกฎกระทรวงกับ detection rules ของคุณ, runbook สำหรับการตัดสินใจ "รับรู้เหตุ", การส่งออกข้อมูลจากเคส IRIS เป็นร่างรายงานตามแบบฟอร์มของกระทรวง, การขยายการเฝ้าระวังเข้าสู่เครือข่าย OT ด้วยเซนเซอร์แบบ passive และการเตรียมข้อมูลสำหรับแจ้งรายการทรัพย์สิน ส่วนการตัดสินใจทางกฎหมายว่าต้องรายงานหรือไม่ และการยื่นรายงานแทนลูกค้า อยู่นอกขอบเขตของเครื่องมือ SOC

6. มุมมองสำหรับองค์กรในไทย: รายงานหลายระบอบจากเคสเดียว

บริษัทไทยที่อยู่ในซัพพลายเชนญี่ปุ่นมักมีหน้าที่ตามกฎหมายไทยควบคู่กันอยู่แล้ว:

• PDPA กำหนดให้แจ้งเหตุละเมิดข้อมูลส่วนบุคคลต่อสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) ภายใน 72 ชั่วโมงนับจากที่ทราบเหตุ หากเหตุนั้นมีความเสี่ยงต่อสิทธิเสรีภาพของบุคคล
• พ.ร.บ.การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 กำหนดให้หน่วยงานโครงสร้างพื้นฐานสำคัญทางสารสนเทศ (CII) รายงานภัยคุกคามทางไซเบอร์ต่อ สกมช. และหน่วยงานควบคุมหรือกำกับดูแล
• สิทธิประโยชน์ BOI/EEC ทำให้โรงงานญี่ปุ่นจำนวนมากในภาคตะวันออกเป็นส่วนหนึ่งของซัพพลายเชนอุตสาหกรรมสำคัญ

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

เช็กลิสต์ที่เริ่มได้ทันที

1. ระบุสถานะของตัวเอง: เป็นบริษัทลูก ผู้รับจ้าง หรือผู้ให้บริการไอทีของผู้ประกอบการญี่ปุ่นหรือไม่ และตรวจสัญญาเรื่องหน้าที่รายงาน
2. ยืนยันว่า log จากไฟร์วอลล์ VPN และเซิร์ฟเวอร์ยืนยันตัวตนเข้าถึง SIEM จริง และจะรู้ตัวหาก log หยุดส่ง
3. ทบทวน rules ระดับต่ำ เช่น brute force, spraying และการเชื่อมต่อจาก IP อันตราย
4. กำหนดผู้ตัดสินใจ "รับรู้เหตุ" รวมถึงช่วงกลางคืนและวันหยุด
5. ซ้อมเขียนรายงานฉบับละเอียดจากเหตุการณ์ในอดีต 1 เคส ให้เสร็จภายใน 30 วัน

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

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

ติดตั้ง simpliSOC แล้วจะปฏิบัติตามกฎหมายครบหรือไม่?
ไม่มีเครื่องมือใดทำได้ด้วยตัวเอง simpliSOC ให้การตรวจจับ การเฝ้าระวัง log ที่ขาดหาย และบันทึกเคส ซึ่งเป็นพื้นฐานของการรายงาน ส่วนการตัดสินใจและการยื่นรายงานเป็นกระบวนการขององค์กร โดยเราช่วยออกแบบ runbook และการส่งออกรายงานได้ในโครงการ

AI เป็นผู้ตัดสินใจว่าต้องรายงานหรือไม่?
ไม่ใช่ Local LLM ของ simpliSOC ช่วยอธิบาย alert และประเมินเบื้องต้นเท่านั้น การตัดสินใจทุกครั้งเป็นของมนุษย์

สรุป

หน้าที่รายงานสรุปได้เป็น 3 คำถาม: ตรวจพบไหม แสดงได้ไหมว่ารับรู้เหตุเมื่อไร และอธิบายข้อเท็จจริงทางเทคนิคได้ภายใน 30 วันไหม ทั้งหมดนี้คือสิ่งที่ SOC ที่ทำงานได้ดีควรทำอยู่แล้ว สิ่งที่กฎหมายเปลี่ยนคือต้นทุนของการทำไม่ได้

อ่านแนวทางการออกแบบ detection เพิ่มเติมได้ที่ "วิธีสร้าง SOC แบบ Lightweight ด้วย Wazuh + Open Source"

ติดต่อเรา: hello@simplico.net (หัวข้อ: "Active Cyber Defense readiness")
โทร (+66) 97 496 6397 · WhatsApp (+66) 83 001 0222 · LINE: iiitum1984

---

แหล่งที่มา:

• サイバー対処能力強化法はいつから？ — 法改正ナビ (ภาษาญี่ปุ่น)
• 能動的サイバー防御の導入による基幹インフラ事業者への影響（前編） — PwC Japan (ภาษาญี่ปุ่น)
• サイバー対処能力強化法が10月施行 — Nikkei xTECH (ภาษาญี่ปุ่น)
• e-Gov法令検索 — 令和7年法律第42号 (ภาษาญี่ปุ่น)
• simpliSOC — Simplico