---
title: "นาฬิกา 24 ชั่วโมงของ CRA เริ่มเดินวันที่ 11 กันยายน 2026: ต้องมั่นใจว่ามีคนรับสาย"
description: "ตั้งแต่ 11 กันยายน 2026 กฎหมาย EU Cyber Resilience Act ให้ผู้ผลิตมีเวลา 24 ชั่วโมงในการส่งคำเตือนเบื้องต้น ผ่านเบราว์เซอร์ โดยไม่มี API สำหรับรายงาน นี่คือวิธีเปลี่ยนทริกเกอร์นั้นให้เป็นสายโทรด้วย Echobell และสิ่งที่การแจ้งเตือนที่ดังขึ้นก็ยังแก้ไม่ได้"
date: 2026-08-21
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - Cyber Resilience Act
  - การรายงานตาม CRA
  - การรายงานเหตุการณ์
  - การเปิดเผยช่องโหว่
  - แจ้งเตือนด้วยสายโทรเข้า
---

# ทำให้คำเตือนเบื้องต้น 24 ชั่วโมงของ CRA โทรเข้ามือถือก่อนเวลาจะหมด

ในวันที่ **11 กันยายน 2026** ภาระหน้าที่ด้านการรายงานของ EU Cyber Resilience Act จะเริ่มมีผลบังคับใช้ นับจากวันนั้น ผู้ผลิตที่รับรู้ว่ามีช่องโหว่ซึ่งกำลังถูกโจมตีอยู่จริงในผลิตภัณฑ์ที่มีองค์ประกอบดิจิทัล หรือรับรู้ถึงเหตุการณ์ร้ายแรงที่กระทบผลิตภัณฑ์นั้น จะมีเวลา **24 ชั่วโมง** ในการส่งคำเตือนเบื้องต้นไปยัง CSIRT ที่ทำหน้าที่ประสานงานและไปยัง ENISA ([คณะกรรมาธิการยุโรป](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting), [Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng))

เส้นตายนี้มีคุณสมบัติที่เส้นตายด้านการปฏิบัติตามกฎเกณฑ์ส่วนใหญ่ไม่มี: มันเดินตามเวลานาฬิกาจริง ไม่มีข้อยกเว้นให้นับเฉพาะวันทำการ ไม่มีการหยุดพักช่วงสุดสัปดาห์ และไม่มีช่วงผ่อนผันขณะที่ผู้รับผิดชอบการรายงานของคุณกำลังนั่งอยู่บนเครื่องบิน ส่วนแพลตฟอร์มที่คุณต้องยื่นผ่านอย่าง Single Reporting Platform ของ ENISA ก็เป็นแบบฟอร์มบนเว็บ โดยระบุว่า "จะยังไม่มีการให้ Application Programming Interface ในระยะนี้" ([คำถามที่พบบ่อยของ ENISA](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions)) ต้องมีคนที่ระบุตัวตนได้เข้าสู่ระบบและกดส่งเอง

นั่นทำให้กฎ 24 ชั่วโมงเป็นปัญหาเรื่องการแจ้งเตือนก่อนจะเป็นปัญหาเรื่องเอกสาร คู่มือนี้จะแสดงวิธีส่งช่วงเวลาแห่งการรับรู้ให้กลายเป็นเสียงโทรศัพท์ที่ดังขึ้นด้วย [Echobell](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-cra-24-hour-reporting-alerts-th&mt=8) และจะพูดตรง ๆ ถึงส่วนใหญ่ของความพร้อมตาม CRA ที่ไม่มีเครื่องมือแจ้งเตือนใดแตะต้องได้

## วันที่ 11 กันยายน 2026 จะเริ่มอะไรกันแน่

**ผู้ผลิตผลิตภัณฑ์ที่มีองค์ประกอบดิจิทัลต้องรายงานช่องโหว่ที่กำลังถูกโจมตีอยู่จริงและเหตุการณ์ร้ายแรงผ่านแพลตฟอร์มเดียวของสหภาพยุโรป ตามนาฬิกาที่แบ่งเป็นระยะ ซึ่งเริ่มเดินตั้งแต่วินาทีที่พวกเขารับรู้** ส่วนอื่น ๆ ของ CRA ทั้งเครื่องหมาย CE ข้อกำหนดสำคัญใน Annex I และการประเมินความสอดคล้อง จะมีผลตั้งแต่ 11 ธันวาคม 2027 การรายงานมาถึงก่อนหน้านั้นสิบห้าเดือน และใช้กับผลิตภัณฑ์ที่วางตลาดไปแล้วด้วย ไม่ใช่เฉพาะสิ่งที่คุณจะส่งออกหลังวันดังกล่าว ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/reporting.html))

มาตรา 14 กำหนดเส้นทางคู่ขนานสองเส้นที่มีรูปแบบเหมือนกัน:

| ระยะ | ช่องโหว่ที่ถูกโจมตีอยู่จริง — มาตรา 14(2) | เหตุการณ์ร้ายแรง — มาตรา 14(4) |
| --- | --- | --- |
| คำเตือนเบื้องต้น | ภายใน **24 ชั่วโมง** นับจากที่รับรู้ | ภายใน **24 ชั่วโมง** นับจากที่รับรู้ |
| การแจ้ง | ภายใน **72 ชั่วโมง** นับจากที่รับรู้ | ภายใน **72 ชั่วโมง** นับจากที่รับรู้ |
| รายงานฉบับสุดท้าย | ไม่ช้ากว่า **14 วัน** หลังมีมาตรการแก้ไขหรือบรรเทาผลกระทบพร้อมใช้ | ภายใน **หนึ่งเดือน** หลังการแจ้งภายใน 72 ชั่วโมง |

ถ้อยคำในกฎหมายคือ "โดยไม่ชักช้าเกินควร และไม่ว่ากรณีใดต้องภายใน 24 ชั่วโมงนับจากที่ผู้ผลิตรับรู้เรื่องดังกล่าว" ([มาตรา 14](https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_14.html)) ยี่สิบสี่ชั่วโมงคือเพดาน ไม่ใช่เป้าหมาย

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

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

## ใครคือผู้มีหน้าที่กันแน่

**ผู้ผลิตผลิตภัณฑ์ที่มีองค์ประกอบดิจิทัล ไม่ว่าจะจัดตั้งอยู่ที่ใด รวมถึงผู้ดูแลซอฟต์แวร์โอเพนซอร์ส (steward) ในขอบเขตที่แคบกว่า** บริษัทนอกสหภาพยุโรปที่ขายเข้าไปในสหภาพไม่พ้นหน้าที่นี้ กฎหมายคาดหวังให้มีผู้ประกอบการทางเศรษฐกิจในสหภาพยุโรปเป็นผู้รับผิดชอบภาระหน้าที่ที่เกี่ยวข้อง ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/explained.html))

คุณต้องรายงานต่อ CSIRT ที่ถูกกำหนดให้เป็นผู้ประสานงานในรัฐสมาชิกที่คุณมีสถานประกอบการหลักในสหภาพ และรายงานต่อ ENISA พร้อมกัน แต่คุณยื่นเพียง **ครั้งเดียว** ผ่าน Single Reporting Platform ซึ่งจะส่งต่อไปยังทั้งสองฝ่ายให้เอง ([คณะกรรมาธิการยุโรป](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting))

ผู้ดูแลซอฟต์แวร์โอเพนซอร์สอยู่ในขอบเขตเฉพาะบางส่วนที่กำหนดไว้: ภาระหน้าที่ตามมาตรา 14(1) ใช้เท่าที่พวกเขามีส่วนร่วมในการพัฒนาผลิตภัณฑ์ที่มีองค์ประกอบดิจิทัล ส่วนมาตรา 14(3) และ (8) ใช้เท่าที่เหตุการณ์ร้ายแรงกระทบระบบเครือข่ายและสารสนเทศที่พวกเขาจัดหาไว้สำหรับการพัฒนานั้น หากคุณดูแลโครงการที่มีคนใช้อย่างกว้างขวาง ให้อ่านมาตรา 24 ควบคู่ไปกับมาตรา 14 แทนที่จะสมมติเอาไปทางสุดขั้วด้านใดด้านหนึ่ง

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

## ทำไมเส้นตาย 24 ชั่วโมงจึงเป็นปัญหาเรื่องการแจ้งเตือน

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

ลองดูว่าข้อเท็จจริงนั้นมักมาจากไหน นักวิจัยด้านความปลอดภัยส่งอีเมลถึง `security@` ตอน 23:40 ของวันเสาร์ ลูกค้าปลายน้ำเปิดตั๋วซัพพอร์ตที่อธิบายว่ามีการโจมตีเกิดขึ้น ฟีด CVE หรือ KEV สว่างขึ้นในคอมโพเนนต์ที่คุณส่งมอบ หรือระบบ EDR ของคุณเองตั้งธงว่ามีการรันโค้ดในระบบบิลด์ บันทึกความพร้อมของ DLA Piper ชี้ถึงเวอร์ชันซัพพลายเชนของเรื่องนี้ไว้โดยเฉพาะ: ผู้ผลิตมักไม่ใช่คนแรกที่รู้ และข้อมูลมาถึงผ่านผู้นำเข้า ผู้จัดจำหน่าย นักวิจัย หรือซัพพลายเออร์คอมโพเนนต์ ([DLA Piper](https://www.dlapiper.com/en-us/insights/publications/2026/08/the-cras-24-hour-rule-preparing-for-the-cyber-resilience-acts-september-2026-reporting-obligations))

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

มีรายละเอียดสามข้อที่ทำให้ช่องว่างนี้แย่กว่าที่เห็น:

- **ไม่มี API** ENISA ระบุตรง ๆ ว่าจะยังไม่มี API สำหรับการรายงานในระยะนี้ คุณจึงไม่สามารถให้สคริปต์ยื่นคำเตือนเบื้องต้นแทนคุณระหว่างที่ทุกคนหลับได้
- **การเข้าถึงเป็นการตั้งค่ารายบุคคลที่ต้องทำไว้ล่วงหน้า** ผู้แทนที่ได้รับมอบอำนาจต้องลงทะเบียนด้วยบัญชี EU Login และ CSIRT ผู้ประสานงานที่กำหนดไว้จะตรวจสอบอำนาจของพวกเขาหลังการเข้าใช้ครั้งแรก มีทั้งผู้แทนหลักและผู้แทนสำรอง โดยคำเชิญสำหรับผู้แทนสำรองจะหมดอายุใน 7 วัน ([คำถามที่พบบ่อยของ ENISA](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions), [cyberresilienceact.eu](https://www.cyberresilienceact.eu/news/enisa-srp-step-by-step-instructions-31-july-2026.html)) หากคนเดียวที่ยื่นได้ติดต่อไม่ได้ เส้นตายก็ไม่สนใจ
- **ระดับบทลงโทษอยู่ในชั้นสูงสุด** มาตรา 64 จัดการไม่ปฏิบัติตามภาระหน้าที่ในมาตรา 13 และ 14 ไว้ในกลุ่มค่าปรับทางปกครอง "สูงสุด 15,000,000 ยูโร หรือหากผู้กระทำผิดเป็นกิจการ ให้สูงสุด 2.5% ของยอดหมุนเวียนรวมทั่วโลกต่อปีของปีบัญชีก่อนหน้า แล้วแต่จำนวนใดจะสูงกว่า" ([มาตรา 64](https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_64.html))

มีข้อแม้ที่ควรพูดตรง ๆ เกี่ยวกับข้อสุดท้าย เพราะมันเปลี่ยนการคำนวณสำหรับทีมเล็ก ๆ: มาตรา 64 ยกเว้นผู้ผลิตที่เข้าข่ายวิสาหกิจรายย่อยหรือวิสาหกิจขนาดเล็กจากค่าปรับทางปกครอง **สำหรับการไม่ทันเส้นตาย** ในมาตรา 14(2)(a) หรือ 14(4)(a) นั่นคือเฉพาะคำเตือนเบื้องต้น 24 ชั่วโมงเท่านั้น หน้าที่ในการรายงานยังคงอยู่ และข้อยกเว้นนี้ไม่ครอบคลุมการแจ้งภายใน 72 ชั่วโมงหรือส่วนที่เหลือของมาตรา 14 ให้อ่านตัวบทและปรึกษาผู้เชี่ยวชาญ แทนที่จะเชื่อบล็อกโพสต์ว่าบริษัทของคุณอยู่ตรงไหน

## คำเตือนเบื้องต้น 24 ชั่วโมงต้องมีเนื้อหาอะไรบ้าง

**น้อยมาก ซึ่งนั่นแหละคือประเด็น** แนวทางของ ENISA อธิบายชุดฟิลด์บังคับเล็ก ๆ ในระยะคำเตือนเบื้องต้น ได้แก่ ประเภทของการแจ้ง (ช่องโหว่หรือเหตุการณ์) ระดับของการแจ้ง เวลาที่รายงาน ข้อมูลผู้รายงาน ชื่อผู้ผลิตหรือผู้ดูแล ผลิตภัณฑ์ หัวเรื่อง และสำหรับกรณีเหตุการณ์ก็ต้องระบุว่าสงสัยว่ามีการกระทำที่ผิดกฎหมายหรือมุ่งร้ายหรือไม่ ส่วนฟิลด์ที่ไม่บังคับในระยะนั้นรวมถึง CVE ID หรือ EUVD ID

ภาพทางเทคนิคที่ครบถ้วนกว่านั้น ทั้งลักษณะทั่วไปของช่องโหว่หรือการโจมตี การประเมินเบื้องต้น และมาตรการแก้ไขและบรรเทาผลกระทบ เป็นของการแจ้งภายใน 72 ชั่วโมง ไม่ใช่ของ 24 ชั่วโมงแรก

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

## จะวางโทรศัพท์ที่ดังได้ไว้หน้านาฬิกา 24 ชั่วโมงอย่างไร

Echobell เปลี่ยนการเรียก webhook หรืออีเมลให้เป็นการแจ้งเตือนที่ดังและสั่นเหมือนสายเรียกเข้า ซึ่งเป็นวิธีที่มันทะลุโหมดโฟกัสและห้ามรบกวนของ iOS ได้ (ดู[การทะลุโหมดโฟกัสของ iOS](/th/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)) การตั้งค่าด้านล่างนี้อยู่คู่ไปกับระบบตั๋วและกระบวนการ PSIRT ที่คุณมีอยู่แล้ว ไม่ได้มาแทนที่มัน

### ขั้นตอนที่ 1 — สร้างช่องแบบโทรเข้าที่สงวนไว้สำหรับกรณีเข้าข่าย CRA

ในแอป ให้สร้างช่องแล้วตั้งประเภทการแจ้งเตือนเป็น **โทรเข้า** ([ประเภทการแจ้งเตือน](/th/docs/notification)) ตั้งชื่อตามการตัดสินใจที่มันกระตุ้น ไม่ใช่ตามแหล่งข้อมูล เช่น "CRA — นาฬิกา 24 ชม. อาจเริ่มเดินแล้ว" ดีกว่า "การแจ้งเตือนความปลอดภัย"

ช่องนี้ต้องเงียบอยู่เสมอ ถ้ามันดังทุกครั้งที่มีประกาศเตือน มีการสแกนล้มเหลว หรือมีการอัปเดต dependency คนก็จะเลิกรับสาย และคุณก็จะเสียช่องที่ดังที่สุดเพียงช่องเดียวไปกับสัญญาณรบกวน ให้ส่งเรื่องพวกนั้นไปที่อื่น โดย[คู่มือแก้อาการล้าจากการแจ้งเตือน](/th/blog/fix-alert-fatigue-developer-guide)อธิบายการแบ่งไว้แล้ว

คัดลอก URL ของ webhook ของช่องจากหน้ารายละเอียด ซึ่งมีหน้าตาแบบ `https://hook.echobell.one/t/<channel-token>` ให้ถือว่ามันเป็นความลับ เพราะใครที่ถือมันไว้ก็ทำให้มือถือทั้งทีมของคุณดังได้ ([คู่มือ webhook](/th/docs/webhook))

ตั้งเทมเพลตที่คนครึ่งหลับครึ่งตื่นอ่านจากหน้าจอล็อกตอนตีสองแล้วเข้าใจ:

```
Title: Possible CRA report — {{product}}
Body: {{kind}} — {{summary}} (aware since {{time}} UTC)
```

`{{time}}`, `{{date}}`, `{{hour}}` และ[ตัวแปรเวลาของระบบ](/th/docs/template)ตัวอื่น ๆ ถูกใส่ให้เป็นเวลา UTC เสมอ การแจ้งเตือนจึงบันทึกเวลาไว้แม้ผู้ส่งจะลืมส่งมาก็ตาม เวลานั้นไม่ใช่หลักฐานทางกฎหมายว่าการรับรู้เริ่มขึ้นเมื่อใด แต่เป็นหมุดยึดที่มีประโยชน์เมื่อคุณต้องประกอบไทม์ไลน์ขึ้นมาใหม่ในภายหลัง

### ขั้นตอนที่ 2 — ชี้เส้นทางการตรวจจับของคุณมาที่ช่องนี้

ระบบใดก็ตามที่เรียก webhook ได้ก็ทริกเกอร์ช่องนี้ได้ ฟิลด์ที่คุณส่งมาจะกลายเป็นตัวแปรของเทมเพลต:

```bash
curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "actively exploited vulnerability",
    "summary": "researcher report, working exploit attached",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'
```

ตัวแปรพิเศษ `externalLink` จะกลายเป็นลิงก์ที่คลิกได้ในบันทึกการแจ้งเตือน การรับสายจึงพาผู้รับผิดชอบไปถึงตั๋วที่เก็บรายละเอียดได้ในแตะเดียว

สิ่งที่ควรต่อเข้ามา เรียงคร่าว ๆ ตามความถี่ที่มันมักเป็นสัญญาณแรก:

- **คิวรับเรื่อง PSIRT หรือคิวรับเรื่องด้านความปลอดภัยของคุณ** — ให้ยิง webhook เมื่อมีการติดป้ายว่าเรื่องนั้นเข้าข่าย CRA
- **GitHub security advisory และการแจ้งเตือนของ Dependabot** ในรีโปที่ใช้บิลด์ผลิตภัณฑ์ที่ส่งมอบจริง ([การเชื่อมต่อ GitHub](/th/docs/developer/github))
- **SIEM, EDR หรือ WAF ของคุณ** สำหรับการตรวจจับที่เกี่ยวกับระบบบิลด์ ระบบปล่อยเวอร์ชัน หรือระบบเซ็นรับรอง เพราะมาตรา 14(5) ครอบคลุมเหตุการณ์ที่อาจนำไปสู่การใส่โค้ดที่มุ่งร้ายไว้อย่างชัดเจน
- **ฟีดข่าวกรองช่องโหว่** ที่คุณใช้อยู่แล้ว โดยกรองเฉพาะคอมโพเนนต์ที่ปรากฏใน SBOM ของคุณเอง

### ขั้นตอนที่ 3 — ใช้เงื่อนไขเพื่อให้ดังเฉพาะกรณีที่เป็นไปได้จริง

**นี่คือขั้นตอนที่รักษาความน่าเชื่อถือของช่องนี้ไว้** [เงื่อนไข](/th/docs/conditions)ของ Echobell ประเมินตัวแปรและ HTTP header ชุดเดียวกับที่เทมเพลตของคุณใช้ และช่องจะทำงานก็ต่อเมื่อนิพจน์นั้นเป็นจริง:

```
craCandidate == true && confirmed == true
```

หรือจะกำหนดเงื่อนไขที่ header หากระบบผู้ส่งไม่สามารถจัดรูป body ได้:

```
header["x-cra-severity"] == "reportable"
```

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

### ขั้นตอนที่ 4 — เก็บระบบที่ส่งได้แต่อีเมล

การติดต่อครั้งแรกจากภายนอกบริษัทส่วนใหญ่มาถึงในรูปอีเมล ทั้งจากนักวิจัย ลูกค้า CSIRT ระดับชาติ หรือผู้ขายคอมโพเนนต์ ทุกช่องของ Echobell มีที่อยู่อีเมลของตัวเองได้ กฎการส่งต่อเพียงข้อเดียวบน `security@` จึงเปลี่ยนข้อความเหล่านั้นเป็นสายโทรได้ ([ทริกเกอร์อีเมล](/th/docs/email-trigger))

ทริกเกอร์อีเมลเปิดให้ใช้ `from`, `to`, `subject`, `text` และ `html` เป็นตัวแปร คุณจึงกรองได้โดยไม่ต้องแยกวิเคราะห์อะไรเลย:

```
subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")
```

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

### ขั้นตอนที่ 5 — ให้ผู้แทนที่ลงทะเบียนไว้ทุกคนอยู่ในช่องนี้

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

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

### ขั้นตอนที่ 6 — ซ้อมก่อน 11 กันยายน ไม่ใช่หลังจากนั้น

มีสองการซ้อมที่ควรทำในเดือนนี้:

1. **เส้นทางการแจ้งเตือน** ยิงคำสั่ง `curl` ข้างต้นขณะเปิดโหมดห้ามรบกวนไว้จริง ๆ บนมือถือเครื่องที่จะวางอยู่ข้างเตียงจริง ๆ แล้วเปิด **Retry Failed Call** ในแอป เพื่อให้สายที่ล้มเหลวครั้งแรกถูกโทรซ้ำ เส้นทางการยกระดับที่ไม่เคยทดสอบก็เป็นเพียงข้อสันนิษฐาน
2. **เส้นทางการยื่นรายงาน** ลองเดินผ่านรายงานหนึ่งฉบับบนกระดาษ โดยใช้คู่มือการลงทะเบียนและการยื่นแบบทีละขั้นของ ENISA ซึ่งอัปเดตมาจนถึงเดือนสิงหาคม 2026 ([ENISA SRP](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp)) สร้างบัญชี EU Login เสียตั้งแต่ตอนนี้ ยืนยันว่า CSIRT รายไหนเป็นผู้ประสานงานของคุณ และส่งคำเชิญผู้แทนสำรองแต่เนิ่น ๆ เพราะมันหมดอายุใน 7 วัน

การซ้อมข้อที่สองมีเงื่อนไขที่ควรรู้ไว้: ณ แนวทางของ ENISA เมื่อเดือนกรกฎาคม URL สาธารณะของแพลตฟอร์มยังระบุว่า "จะแจ้งให้ทราบตอนเปิดใช้งาน" การทดสอบแบบครบวงจรจริง ๆ จึงยังทำไม่ได้ ([cyberresilienceact.eu](https://www.cyberresilienceact.eu/news/enisa-srp-step-by-step-instructions-31-july-2026.html)) ENISA ให้คำมั่นว่าแพลตฟอร์มจะพร้อมใช้งานภายใน 11 กันยายน 2026 ให้ซ้อมทุกอย่างที่คุณควบคุมได้ และอย่าเอาความพร้อมของแพลตฟอร์มมาเป็นเหตุผลที่จะเลื่อนความพร้อมของตัวเอง

## สิ่งที่ Echobell ไม่ได้ทำ

การพูดให้ชัดเรื่องนี้สำคัญกว่าปกติ เพราะหัวข้อนี้เกี่ยวกับกฎระเบียบ:

- **มันไม่ได้ทำให้คุณปฏิบัติตามกฎหมายได้** Echobell เป็นช่องทางแจ้งเตือน การกำหนดขอบเขตผลิตภัณฑ์ การมีกระบวนการจัดการช่องโหว่ การตัดสินว่ามาตรา 14 ถูกกระตุ้นหรือไม่ การลงทะเบียนกับ SRP และการยื่นให้ทันเวลา ล้วนเป็นหน้าที่ของคุณ ไม่เคยมีเครื่องมือแจ้งเตือนใดทำให้ภาระหน้าที่ด้านการรายงานสำเร็จได้
- **มันไม่ยื่นอะไรให้** ไม่มี API ให้ยื่นอยู่แล้ว และต่อให้มี Echobell ก็ไม่ใช่ตัวที่จะเรียกมัน มันแค่ทำให้โทรศัพท์ดัง ส่วนที่เหลือเป็นหน้าที่ของคนที่ลงทะเบียนไว้
- **มันไม่ใช่ตราประทับเวลาทางกฎหมาย** ตัวแปร `{{time}}` บันทึกเวลาที่ทริกเกอร์มาถึง Echobell ในรูปแบบ UTC ส่วน "การรับรู้" เริ่มเมื่อใดเป็นคำถามเชิงข้อเท็จจริงเกี่ยวกับองค์กรของคุณ และสิ่งที่บันทึกเรื่องนั้นคือระบบบันทึกเหตุการณ์ของคุณ ไม่ใช่การแจ้งเตือนแบบพุช
- **มันไม่มีนโยบายการยกระดับหรือการตอบรับ** ไม่มีเงื่อนไข "ถ้าไม่มีใครรับใน 10 นาที ให้โทรหาคนถัดไป" ไม่มีตารางเวร ไม่มีร่องรอยตรวจสอบว่าใครรับทราบอะไร หากต้องการสิ่งเหล่านั้น คุณต้องใช้แพลตฟอร์มจัดการเหตุการณ์ ดู[ทางเลือกแทน Opsgenie](/th/blog/opsgenie-end-of-life-alternatives)
- **มันรับประกันการส่งไม่ได้** สายหนึ่งสายขึ้นอยู่กับโครงสร้างพื้นฐานของระบบพุช เครือข่าย และมือถือที่มีแบตเตอรี่ ให้ถือว่ามันเป็นชั้นที่ย่นระยะเวลาระหว่างการมาถึงของข้อเท็จจริงกับการรับรู้ของคน ไม่ใช่กลไกควบคุมที่คุณจะชี้ให้ผู้ตรวจสอบดูได้
- **มันไม่ติดตามเวลาท้องถิ่น** ตัวแปรเวลาที่มีมาให้เป็น UTC เท่านั้นและไม่ปรับตามเวลาออมแสง เงื่อนไขที่ล้อมรั้วช่วงเวลาจึงต้องปรับด้วยมือปีละสองครั้ง

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

### การใช้ Echobell ทำให้เราปฏิบัติตาม CRA ได้หรือไม่

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

### นาฬิกา 24 ชั่วโมงเริ่มเดินตอนไหนกันแน่

ตอนที่ผู้ผลิตรับรู้ถึงช่องโหว่ที่กำลังถูกโจมตีอยู่จริงหรือเหตุการณ์ร้ายแรงนั้น กฎหมายไม่ได้นิยามช่วงเวลาที่แน่นอน และการรับรู้ขึ้นอยู่กับข้อเท็จจริงและความเร็วในการยืนยันข้อเท็จจริงเหล่านั้น ([DLA Piper](https://www.dlapiper.com/en-us/insights/publications/2026/08/the-cras-24-hour-rule-preparing-for-the-cyber-resilience-acts-september-2026-reporting-obligations)) ในทางปฏิบัติจึงควรมีการคัดกรองที่รวดเร็วและมีบันทึกไว้ เพราะยิ่งช่องว่างระหว่างการมาถึงของสัญญาณกับการประเมินยาวเท่าไร ก็ยิ่งอธิบายในภายหลังได้ยากเท่านั้น

### เราเป็นบริษัทเล็ก เราได้รับการยกเว้นไหม

ไม่ได้รับการยกเว้นจากการรายงาน มาตรา 64 ยกเว้นวิสาหกิจรายย่อยและวิสาหกิจขนาดเล็กจากค่าปรับทางปกครองเฉพาะกรณีพลาดเส้นตาย 24 ชั่วโมงในมาตรา 14(2)(a) หรือ 14(4)(a) เท่านั้น ภาระหน้าที่ในการรายงานยังคงอยู่ การแจ้งภายใน 72 ชั่วโมงและรายงานฉบับสุดท้ายไม่ได้รับผลกระทบ และนิยามของวิสาหกิจรายย่อยกับวิสาหกิจขนาดเล็กก็ไม่ใช่สิ่งที่คุณจะสมมติเอาเอง ให้ถือว่าเป็นการผ่อนปรนในวงแคบ ไม่ใช่บัตรผ่าน

### กล่องอีเมลด้านความปลอดภัยของเรามีคนดูในเวลาทำการ แค่นั้นไม่พอหรือ

พอ ก็ต่อเมื่อคุณยอมเสียเวลาไปถึงสองในสามของกรอบเวลาในสุดสัปดาห์ธรรมดา ๆ รายงานที่มาถึงตอน 18:00 ของวันศุกร์ทำให้เส้นตายของคุณคือ 18:00 ของวันเสาร์ การเฝ้าดูเฉพาะเวลาทำการเป็นค่าเริ่มต้นที่ดีสำหรับเรื่องอื่น ๆ แต่นาฬิกา 24 ชั่วโมงคือกรณีที่มันครอบคลุมไม่ถึงพอดี

### ฝ่ายกำกับดูแล ฝ่ายกฎหมาย และฝ่ายวิศวกรรมรับการแจ้งเตือนเดียวกันได้ไหม

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

### เรื่องนี้ช่วยเรื่องหน้าที่แจ้งผู้ใช้ตามมาตรา 14(8) ไหม

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

### เรารายงานตาม NIS2 หรือ DORA อยู่แล้ว มันเรื่องเดียวกันไหม

ไม่ใช่ แม้รูปแบบจะคล้ายกัน NIS2 และ DORA กำหนดหน้าที่ไว้กับหน่วยงานตามภาคส่วนและความสำคัญ ส่วน CRA กำหนดหน้าที่ไว้กับผู้ผลิตตามผลิตภัณฑ์ที่วางในตลาดสหภาพยุโรป องค์กรเดียวอาจอยู่ภายใต้ทั้งสามกฎหมาย โดยมีนาฬิกาคนละเรือนและผู้รับคนละราย หากกฎเกณฑ์เหล่านั้นอยู่ในขอบเขตของคุณด้วย ดู[การแจ้งเตือนการรายงานเหตุการณ์ตาม DORA และ NIS2](/th/blog/dora-nis2-incident-reporting-alerts) และพึงสังเกตว่าชั้นการแจ้งเตือนใช้ร่วมกันได้แม้ภาระหน้าที่จะต่างกัน

### สายโทรจะทะลุโหมดห้ามรบกวนได้จริงไหม

การแจ้งเตือนแบบโทรเข้าถูกส่งมาในรูปการแจ้งเตือนแบบสายเรียกเข้า ซึ่งเป็นสิ่งที่ทำให้มันทะลุโหมดโฟกัสบน iOS ได้ แต่มันไม่ใช่เวทมนตร์ เพราะยังขึ้นอยู่กับการตั้งค่าของระบบปฏิบัติการ เครือข่าย และมือถือที่มีแบตเตอรี่ ให้ทดสอบบนเครื่องจริงโดยเปิดโหมดโฟกัสไว้จริง ๆ ก่อนจะพึ่งพามัน และอย่าลืมเปิด **Retry Failed Call**

### ใช้ได้เฉพาะ iOS ใช่ไหม

ไม่ใช่ Echobell มีทั้งบน iOS และบน [Android ผ่าน Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid) ([การเปิดตัวเวอร์ชัน Android](/th/blog/echobell-android-release)) พฤติกรรมของการแจ้งเตือนแบบสายโทรต่างกันไปในแต่ละแพลตฟอร์ม จึงควรทดสอบบนเครื่องที่ผู้รับผิดชอบจะพกจริง

### ควรใส่อะไรใน payload ของ webhook

เท่าที่จำเป็นต่อการตัดสินใจว่าจะลุกจากเตียงหรือไม่: ผลิตภัณฑ์ ประเภทของสัญญาณ บริบทหนึ่งบรรทัด และ `externalLink` ที่ชี้ไปยังตั๋วที่เก็บรายละเอียดไว้ Echobell เก็บเนื้อหาและประวัติการแจ้งเตือนไว้บนเครื่อง และเก็บไว้บนเซิร์ฟเวอร์เพียงข้อมูลบัญชี ช่อง และการติดตามเท่านั้น ([โมเดลความเป็นส่วนตัว](/th/docs/features)) ถึงอย่างนั้น นิสัยที่ถูกต้องกับข้อมูลอ่อนไหวด้านความปลอดภัยก็ยังคือส่งตัวชี้ ไม่ใช่ส่งเนื้อหา

---

## เนื้อหาที่เกี่ยวข้อง

- [การแจ้งเตือนการรายงานเหตุการณ์ตาม DORA และ NIS2](/th/blog/dora-nis2-incident-reporting-alerts)
- [วิธีแก้อาการล้าจากการแจ้งเตือน](/th/blog/fix-alert-fatigue-developer-guide)
- [วิธีทะลุโหมดโฟกัสของ iOS สำหรับการแจ้งเตือนวิกฤต](/th/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)
- [ทางเลือกแทน Opsgenie ที่สิ้นสุดอายุการใช้งาน](/th/blog/opsgenie-end-of-life-alternatives)
- [คู่มือการเชื่อมต่อ webhook](/th/docs/webhook)
- [ทริกเกอร์อีเมล](/th/docs/email-trigger)
- [คู่มือเงื่อนไข](/th/docs/conditions)