หน้าที่การรายงานตามกฎหมาย Cyber Resilience Act (CRA) ของสหภาพยุโรปเริ่มใช้เมื่อวันที่ 11 กันยายน 2026 สำหรับผู้ผลิต IoT ในไทยและอาเซียนที่เตรียมจำหน่ายในสหภาพยุโรป สหราชอาณาจักร สิงคโปร์ และญี่ปุ่น ETSI EN 303 645 สามารถใช้เป็น “เมทริกซ์หลักฐานร่วม” ก่อนปรับเอกสารตามแต่ละตลาดได้ อย่างไรก็ตาม มาตรฐานนี้ไม่ได้ทำให้ผลิตภัณฑ์สอดคล้องกับกฎหมาย ได้รับการรับรอง หรือได้ฉลากโดยอัตโนมัติ บทความนี้อธิบายวิธีจัดหลักฐานด้านอุปกรณ์ เฟิร์มแวร์ การอัปเดต และบันทึกเหตุการณ์เพียงชุดเดียว แล้วนำไปใช้กับ EU CRA, UK PSTI, Singapore CLS และ Japan JC-STAR อย่างถูกต้อง
เหตุใดต้องทบทวน ETSI EN 303 645 ในตอนนี้
ประกาศอย่างเป็นทางการของ ETSI ระบุว่าฉบับปัจจุบันคือ ETSI EN 303 645 V3.1.3 (2024-09) เป็นแนวทางความมั่นคงปลอดภัยไซเบอร์พื้นฐานสำหรับ IoT ผู้บริโภคที่เน้นผลลัพธ์ ไม่บังคับวิธีการทางเทคนิคแบบเดียวกับทุกผลิตภัณฑ์ สำนักงานความมั่นคงปลอดภัยไซเบอร์ของสิงคโปร์ (CSA) อธิบายว่ามาตรฐานนี้ครอบคลุมข้อกำหนดกว้าง ๆ 14 ประการ
คุณค่าต่อโรงงานไทยไม่ได้จำกัดอยู่ที่การส่งออกยุโรป กล้องเครือข่าย เกตเวย์ เซ็นเซอร์ คอนโทรลเลอร์อัจฉริยะ และอุปกรณ์บริการอาจใช้ฮาร์ดแวร์หรือเฟิร์มแวร์ร่วมกัน แล้วแยก SKU ตามภูมิภาค แต่ปลายทางแต่ละแห่งใช้ขอบเขต ผู้รับผิดชอบ กระบวนการประเมิน และคำกล่าวอ้างสาธารณะต่างกัน ได้แก่ EU CRA, Product Security and Telecommunications Infrastructure ของสหราชอาณาจักร, Cybersecurity Labelling Scheme (CLS) ของสิงคโปร์ และ JC-STAR ของญี่ปุ่น
ถ้าตอบแบบสอบถามใหม่ทุกประเทศ ทีมจะทดสอบซ้ำ ใช้ถ้อยคำไม่ตรงกัน และเก็บไฟล์กระจัดกระจาย วิธีที่จัดการได้ดีกว่าคือแปลงหัวข้อ ETSI เป็นมาตรการควบคุมภายใน เชื่อมหลักฐานจากวิศวกรรม การผลิต และการปฏิบัติงาน แล้วทำคอลัมน์ส่วนต่างของแต่ละตลาด สิ่งที่ใช้ร่วมกันคือแหล่งหลักฐานและวิธีควบคุม ไม่ใช่ผลการตัดสินทางกฎหมายหรือการรับรองของหน่วยงานปลายทาง
วันที่ 11 กันยายน 2026 เปลี่ยนอะไรสำหรับ CRA?
คณะกรรมาธิการยุโรประบุว่า ตั้งแต่วันที่ 11 กันยายน 2026 ผู้ผลิตต้องรายงานช่องโหว่ที่ถูกนำไปใช้โจมตีอย่างแข็งขัน และเหตุการณ์ร้ายแรงที่กระทบความปลอดภัยของผลิตภัณฑ์ที่มีองค์ประกอบดิจิทัล กรอบเวลากำหนดการแจ้งเตือนเบื้องต้นภายใน 24 ชั่วโมงหลังรับรู้ และการแจ้งข้อมูลฉบับเต็มภายใน 72 ชั่วโมง ทั้งนี้ไม่ได้หมายความว่าข้อบกพร่องหรือเหตุขัดข้องทุกกรณีต้องรายงาน ทีมต้องพิจารณานิยามอย่างเป็นทางการและข้อเท็จจริงของเหตุการณ์ และใช้คำปรึกษาผู้เชี่ยวชาญเมื่อจำเป็น
กรอบเวลานี้ทำให้ความปลอดภัยผลิตภัณฑ์ไม่ใช่เพียงเช็กลิสต์ก่อนเปิดตัว ภายใน 24 ชั่วโมง ผู้ผลิตต้องระบุรุ่นและเฟิร์มแวร์ที่ได้รับผลกระทบ ภูมิภาคที่ขาย ข้อมูลการโจมตี มาตรการบรรเทา และผู้รับผิดชอบ หากเมทริกซ์ ETSI เชื่อมข้อมูลเหล่านี้ไว้ก่อนเกิดเหตุ ทีมจะลดเวลาค้นหาได้ หน้าที่สำคัญส่วนอื่นของ CRA มีผลเต็มรูปแบบวันที่ 11 ธันวาคม 2027 ดังนั้นการเริ่มรายงานในปี 2026 จึงเป็นบททดสอบความพร้อมตลอดวงจรชีวิตล่วงหน้า
ETSI EN 303 645 ไม่ใช่กฎหมาย ใบรับรอง หรือพาสปอร์ตอัตโนมัติ
ETSI EN 303 645 เป็นมาตรฐานยุโรปที่อธิบายผลลัพธ์พื้นฐานด้านความปลอดภัยของ IoT ผู้บริโภค ไม่ใช่ตัวกฎหมาย CRA ไม่ใช่ Statement of Compliance ตาม UK PSTI และไม่ใช่ฉลาก Singapore CLS หรือ Japan JC-STAR แม้ผลิตภัณฑ์จะออกแบบและทดสอบตาม ETSI ทีมก็ยังต้องตรวจสอบขอบเขตตลาด บทบาทผู้ประกอบการ เอกสารที่บังคับ ระดับการประเมิน ขั้นตอนสมัคร และเงื่อนไขการแสดงฉลากแยกกัน
นอกจากนี้ อุปกรณ์ในโรงงานทุกชิ้นที่เรียกว่า IoT ไม่ได้อยู่ภายใต้กฎสำหรับผู้บริโภคชุดเดียวกัน ผลิตภัณฑ์ผู้บริโภค อุปกรณ์อุตสาหกรรมโดยเฉพาะ โมดูลฝังตัว อุปกรณ์การแพทย์ หรือยานยนต์อาจมีขอบเขตและกฎเฉพาะภาคส่วนต่างกัน ควรบันทึกวัตถุประสงค์การใช้ ช่องทางจำหน่าย เจ้าของแบรนด์ และบทบาทของผู้ผลิต ผู้นำเข้า และผู้จัดจำหน่าย แล้วให้ผู้เชี่ยวชาญยืนยันประเด็นกฎหมายที่ไม่แน่นอน
มาตรฐานยังคงมีประโยชน์มาก เพราะหัวข้อสำคัญซ้ำกันในหลายตลาด เช่น รหัสผ่าน ช่องทางรายงานช่องโหว่ การอัปเดต การปกป้องข้อมูลลับ การสื่อสารปลอดภัย การลดพื้นผิวโจมตี ความสมบูรณ์ของซอฟต์แวร์ ความทนทาน เทเลเมทรี ข้อมูลส่วนบุคคล การลบข้อมูล การติดตั้ง และการตรวจสอบอินพุต การควบคุมจากทะเบียนกลางช่วยให้เห็นข้อกำหนดเพิ่ม ใช้ผลทดสอบซ้ำ แปลเอกสาร และตอบลูกค้าอย่างสม่ำเสมอ
แยกคำว่า “ใช้เป็นฐาน” “ทดสอบแล้ว” “รับรองแล้ว” และ “สอดคล้องกฎหมาย”
| คำกล่าว | ความหมายในการปฏิบัติ | หลักฐานที่ต้องตรวจ |
|---|---|---|
| ใช้เป็นฐานการออกแบบ | นำหัวข้อ ETSI ไปใส่ข้อกำหนดผลิตภัณฑ์ | applicability statement, specification, owner |
| ประเมินตนเองแล้ว | บริษัทตรวจมาตรการด้วยวิธีของตน | checklist, ผลทดสอบ, ช่องว่างที่เปิดอยู่ |
| ทดสอบโดยบุคคลที่สาม | ห้องปฏิบัติการประเมินตัวอย่างและขอบเขตที่กำหนด | ฉบับมาตรฐาน ขอบเขต รายงาน ข้อยกเว้น |
| ได้รับอนุมัติหรือฉลาก | ผ่านกระบวนการของโครงการปลายทาง | เลขทะเบียน SKU ระดับ เงื่อนไขฉลาก |
| ประกาศสอดคล้องกฎหมาย | ผู้รับผิดชอบประกาศตามกฎตลาดนั้น | วิเคราะห์ขอบเขต แฟ้มเทคนิค คำประกาศ |
จึงไม่ควรเขียนว่า “ผ่าน ETSI แล้วจึงผ่าน CRA” ถ้อยคำที่แม่นยำกว่าคือ “ใช้ ETSI EN 303 645 เป็นฐานร่วม และจัดการขอบเขต ข้อกำหนดทางกฎหมาย การรายงาน และเอกสารเทคนิคของ CRA เป็นส่วนต่างเฉพาะ”
มองผลิตภัณฑ์เชื่อมต่อผ่านหลักฐาน 4 ด้าน
เมทริกซ์ที่เริ่มจากฟังก์ชันบนหน้าจอเพียงอย่างเดียวจะพลาดการควบคุมในโรงงานและหลังวางตลาด ควรแบ่งหลักฐานเป็น DEVICE, FIRMWARE, UPDATE และ LOG เพื่อให้ติดตามได้ตั้งแต่พัฒนาถึงบริการภาคสนาม
DEVICE: ระบุผลิตภัณฑ์และขอบเขตความรับผิดชอบ
เก็บชื่อผลิตภัณฑ์ รุ่น revision ฮาร์ดแวร์ SKU ประเทศปลายทาง การเชื่อมต่อ ค่าเริ่มต้น อินเทอร์เฟซผู้ดูแล คลาวด์ แอปมือถือ และไลบรารีภายนอก ชื่อรุ่นบนบรรจุภัณฑ์ต้องตรงกับตัวระบุใน SBOM และเว็บไซต์สนับสนุน ในโครงการ OEM/ODM ต้องกำหนดว่าใครออกแบบ ผลิต เป็นเจ้าของแบรนด์ แจกจ่ายอัปเดต และรับรายงานช่องโหว่
เรื่องรหัสผ่าน ไม่ควรมีเพียงประโยคว่า “ไม่มีรหัสผ่านเริ่มต้น” หลักฐานควรครอบคลุมการสร้าง credential ในโรงงาน ความเฉพาะของแต่ละเครื่อง การตั้งค่าครั้งแรก สภาพหลัง reset บัญชีบริการ การจำกัดความพยายาม และที่เก็บ secret รวมถึงพิสูจน์ว่าบัญชีทดสอบและพอร์ต debug ไม่หลุดไปในรุ่นจำหน่าย
FIRMWARE: ทำให้ระบุสิ่งที่กำลังทำงานได้จริง
เชื่อม source revision, build ID, ลายเซ็น, boot chain, SBOM, compiler และบันทึก CI/CD, configuration variant และผลประเมินช่องโหว่ เมื่อมีการเปิดเผยช่องโหว่ เป้าหมายคือระบุ SKU และเวอร์ชันที่ขายแล้วภายในไม่กี่ชั่วโมง ไม่ใช่หลังส่งสเปรดชีตไปมาหลายวัน
หลักฐานความสมบูรณ์ควรครอบคลุมพฤติกรรมเมื่อการตรวจลายเซ็นล้มเหลว การควบคุม rollback recovery image การเก็บและหมุนเวียนกุญแจ และการ inject key ในโรงงาน สำหรับไลน์ผลิตไทย ต้องระบุว่าผลลัพธ์ที่ลงนามจากทีมพัฒนามาถึงเครื่องเขียนโปรแกรมอย่างไร ใครหรือระบบใดอนุมัติ และ log ใดพิสูจน์ hash ที่ติดตั้ง
UPDATE: พิสูจน์ทั้งคำมั่นและความสามารถในการส่งมอบ
ควบคุมนโยบายอัปเดต ระยะสนับสนุนขั้นต่ำ ลำดับความสำคัญช่องโหว่ เป้าหมายเวลาแก้ไข ลายเซ็น การทยอยปล่อย การกู้คืนเมื่อผิดพลาด การแจ้งลูกค้า และสิ้นสุดการสนับสนุน UK PSTI กำหนดให้เผยแพร่ระยะเวลาขั้นต่ำของการอัปเดตความปลอดภัยเป็นข้อกำหนดพื้นฐานหนึ่งข้อ คำประกาศสาธารณะจึงต้องสอดคล้องกับอายุชิ้นส่วน งบคลาวด์ และกำลังวิศวกรรมจริง
สำหรับ CRA ให้เก็บการตัดสินผลิตภัณฑ์ที่ได้รับผลกระทบ สถานะกระจาย patch มาตรการชั่วคราวต่อลูกค้า และวันที่มาตรการแก้ไขพร้อมใช้งาน ติดตามการแจกจ่ายตามภูมิภาคเพื่อรู้ว่าการแก้ไขเดียวกันไปถึง EU สหราชอาณาจักร สิงคโปร์ และญี่ปุ่นเมื่อใด
LOG: เก็บข้อเท็จจริงที่ใช้ตัดสินการรายงาน
เป้าหมายไม่ใช่เก็บทุกอย่างตลอดไป ให้กำหนดเหตุการณ์ที่จำเป็นต่อการตรวจจับ สืบสวน และกู้คืน เช่น ล้มเหลวในการยืนยันตัวตน การเปลี่ยนค่า ผลอัปเดต ข้อผิดพลาดความสมบูรณ์ การสื่อสารผิดปกติ crash สถานะเวลา และการกระทำของผู้ดูแล กำหนด timestamp, device ID, firmware version, ช่องทางเก็บ ระยะเวลาเก็บ สิทธิ์เข้าถึง และการจัดการข้อมูลส่วนบุคคล
ถ้าผลิตภัณฑ์ไม่ได้ต่อคลาวด์ตลอดเวลา ต้องทดสอบวิธีที่ลูกค้าหรือ distributor ส่งออกข้อมูลวินิจฉัยอย่างปลอดภัย และวิธีที่ support ส่งต่อให้ engineering หากข้อมูลสำหรับคำเตือน 24 ชั่วโมงติดอยู่ในอุปกรณ์และไม่เคยทดสอบการดึงออก ความพร้อมนั้นมีอยู่เพียงบนกระดาษ
วิธีสร้างเมทริกซ์มาตรการและหลักฐาน
ตารางอ้างอิงเลขข้อ ETSI กับเลขข้อกฎหมายอย่างเดียวไม่พอ แต่ละแถวควรมีวัตถุประสงค์ ขอบเขตผลิตภัณฑ์ ผู้รับผิดชอบ evidence ID ที่เก็บ เหตุการณ์ที่ต้องอัปเดต วิธีทดสอบ และช่องว่าง คอลัมน์ตลาดควรใช้สถานะ ใช้ซ้ำได้โดยตรง, ต้องปรับก่อนใช้ซ้ำ, ต้องประเมินแยก, มีแนวโน้มไม่เกี่ยวข้อง แทนการตัดสินผ่าน/ไม่ผ่านที่ไม่มีผู้มีอำนาจรองรับ
| มาตรการร่วม | ตัวอย่างหลักฐานขั้นต่ำ | คำถามถึง product owner |
|---|---|---|
| การยืนยันตัวตนเฉพาะเครื่อง | แบบ credential, reset test, factory check | รวมบัญชีบริการหรือไม่ |
| การเปิดเผยช่องโหว่ | URL, SLA รับเรื่อง, case record | ใครดูแลวันหยุดและหลายภาษา |
| อัปเดตความปลอดภัย | ระยะสนับสนุน, signature test, rollout log | ทุก SKU ภูมิภาคได้รับได้หรือไม่ |
| ปกป้อง secret | key design, storage test, injection record | แยกความรับผิดชอบ ODM หรือไม่ |
| การสื่อสารปลอดภัย | protocol list, certificate failure test | ทำงานหลัง factory proxy หรือไม่ |
| ลดพื้นผิวโจมตี | port list, disabled service, debug lock | ฟังก์ชันทดสอบหลุดสู่ production หรือไม่ |
| ความสมบูรณ์และกู้คืน | boot, rollback, recovery test | เมื่อล้มเหลวกลับสู่สภาพปลอดภัยหรือไม่ |
| เทเลเมทรีและ log | event schema, retention, export, access | ใช้ข้อเท็จจริงได้ใน 24 ชั่วโมงหรือไม่ |
รักษาหลักฐานต้นฉบับเพียงชุดเดียว
อย่าสร้างไฟล์ UK_password_test, JP_password_test และ EU_password_test แยกกัน กำหนด product ID, control ID, evidence ID และ version กลาง เอกสารของตลาดจึงอ้างอิง แปล หรือเปลี่ยนรูปแบบจากต้นฉบับ เมื่อหลักฐานเปลี่ยน ทีมจะตรวจผลกระทบต่อเอกสารปลายทางทั้งหมดได้
หลักฐานไม่ได้หมายถึงรายงานยาวเท่านั้น Git tag, log ตรวจลายเซ็นจาก CI, ticket, หน้า support, เคสช่องโหว่, telemetry การกระจาย และบันทึกตรวจโรงงานล้วนใช้ได้ แต่ลิงก์เสียหรือไฟล์ในบัญชีส่วนตัวของวิศวกรคนเดียวเท่ากับเรียกใช้ไม่ได้ ควรสร้าง audit export เป็นระยะในที่เก็บซึ่งองค์กรควบคุม
กระจายฐานเดียวไป 4 ตลาดโดยไม่กล่าวอ้างเกินจริง
EU CRA: เพิ่มการจัดการวงจรชีวิตและระบบรายงาน
CRA ครอบคลุมผลิตภัณฑ์ที่มีองค์ประกอบดิจิทัลตั้งแต่การออกแบบ พัฒนา ผลิต และหลังวางตลาด หลักฐาน ETSI ช่วยเป็นข้อมูลตั้งต้นได้ แต่ต้องตรวจขอบเขต การจัดประเภท บทบาทผู้ประกอบการ วิธีประเมิน เอกสารเทคนิค และการรายงานของ CRA แยกต่างหาก แบบประเมินตนเอง ETSI ไม่เท่ากับความสอดคล้อง CRA
สำหรับหน้าที่ที่เริ่มวันที่ 11 กันยายน 2026 ให้เชื่อมช่องทางรับช่องโหว่กับ legal triage ทำ contact chain ระหว่าง PSIRT, development, cloud operation, quality โรงงาน ฝ่ายขายภูมิภาค และกฎหมาย กำหนดผู้บันทึกเวลา “รับรู้” ข้อมูลที่ใช้ตัดสิน active exploitation หรือ severe incident และผู้ใช้งาน Single Reporting Platform คำเตือนแรกไม่ใช่รายงาน root cause ฉบับสุดท้าย จึงต้องมีหมายเลขเคสเดียวที่อัปเดตต่อเนื่องสู่การแจ้ง 72 ชั่วโมงและรายงานสุดท้าย
UK PSTI: ระบุ 3 ข้อพื้นฐานและบทบาท supply chain
กฎความปลอดภัยผลิตภัณฑ์เชื่อมต่อสำหรับผู้บริโภคของสหราชอาณาจักรมีผลวันที่ 29 เมษายน 2024 คำแนะนำรัฐบาลเน้นการห้ามรหัสผ่านเริ่มต้นที่ใช้ร่วมกันหรือเดาง่าย การเผยแพร่วิธีรายงานปัญหาความปลอดภัย และการเผยแพร่ระยะขั้นต่ำของอัปเดตความปลอดภัย หัวข้อเหล่านี้สอดคล้องกับ ETSI แต่หน้าที่ตามกฎหมายและ Statement of Compliance ต้องจัดการแยก
เมื่อ OEM/ODM ไทยส่งให้แบรนด์อังกฤษ สัญญาต้องระบุหลักฐานที่โรงงานส่งและคำประกาศที่แบรนด์หรือผู้นำเข้ารับผิดชอบ ระยะ support บนเว็บไซต์ไม่มีผลหากทีมวิศวกรรมสร้างและเซ็น patch ไม่ได้ ต้องวางงบสำหรับ EOL ชิ้นส่วน การติดตามช่องโหว่ OSS กุญแจลายเซ็น ระบบกระจาย และบริการหลังขาย
Singapore CLS: ใช้ฐาน ETSI แต่แยก Level ออกจาก Assessment Tier
ข้อมูลผู้ผลิตของ CSA แยก Cybersecurity Level ซึ่งแสดงจำนวนดาวบนฉลาก ออกจาก Assessment Tier ซึ่งเป็นขั้นการประเมินที่ต้องผ่านตามลำดับ โดย Assessment Tier 1 และ Tier 2 ใช้ ETSI EN 303 645 เป็นฐาน และ CLS Level ที่ได้รับสอดคล้องกับ Tier สูงสุดที่ผ่าน CSA อธิบาย ETSI EN 303 645 ว่ามี 14 broad provisions ดังนั้น self-assessment และทะเบียนหลักฐานร่วมช่วยเตรียมสมัครได้ดี แต่ต้องทำตามขอบเขตผลิตภัณฑ์ Level, Tier, การทดสอบ ใบสมัคร และเงื่อนไขใช้ฉลาก CLS ปัจจุบัน
ทีมภูมิภาคอาจดูแลหลักฐานภาษาอังกฤษส่วนกลางและสกัดชุดส่งสิงคโปร์ แต่อย่ารับปากว่ารายงานห้องปฏิบัติการฉบับเดียวจะได้ทุกการอนุมัติ เว้นแต่หน่วยงานระบุการยอมรับอย่างชัดเจน ให้ยืนยัน edition ตัวอย่าง firmware ขอบเขต และเงื่อนไข retest กับหน่วยประเมิน
Japan JC-STAR: ความสอดคล้องไม่ใช่ความเหมือนกัน
IPA อธิบายว่าเกณฑ์ JC-STAR พัฒนาด้วยการคำนึงถึงความสอดคล้องกับมาตรฐานและแนวทางระหว่างประเทศ เช่น ETSI และ NIST จึงนำหลักฐานร่วมมาใช้ได้ แต่ JC-STAR เป็นโครงการของญี่ปุ่นเอง ต้องผ่านระดับ หลักฐาน การประเมิน และกระบวนการสมัครที่เกี่ยวข้องก่อนใช้ฉลาก
อ่านภาพรวมได้ที่ คู่มือ JC-STAR และฉลากความปลอดภัย IoT และการเตรียมจากไทยได้ที่ JC-STAR สำหรับฐานงานในประเทศไทย ในเมทริกซ์ให้เพิ่มช่องระดับ วิธีประเมิน เอกสารส่ง และข้อกำหนดการแสดงผลเฉพาะ JC-STAR
| ตลาด | วิธีใช้หลักฐาน ETSI | สิ่งที่ต้องตรวจแยก |
|---|---|---|
| EU CRA | การออกแบบฐาน อัปเดต และจัดการช่องโหว่ | ขอบเขต ประเภท การประเมิน แฟ้มเทคนิค รายงาน |
| UK PSTI | รหัสผ่าน ช่องทางรายงาน ระยะสนับสนุน | ผลิตภัณฑ์ บทบาท Statement และบันทึก |
| Singapore CLS | ฐานเตรียม Assessment Tier 1/2 | Level ที่ต้องการ Tier ที่ต้องผ่าน การทดสอบ ใบสมัคร เงื่อนไขฉลาก |
| Japan JC-STAR | ใช้ control ที่สอดคล้องสากลซ้ำ | เกณฑ์ระดับ สมัคร ประเมิน แสดงฉลาก |
สร้างหลักฐานที่เชื่อถือได้ในไลน์ผลิตไทย
ฝ่ายพัฒนาเพียงฝ่ายเดียวทำหลักฐานไม่ครบ การตั้งค่า กุญแจ firmware และผลตรวจในโรงงานกำหนดสิ่งที่ส่งถึงลูกค้า เชื่อม MES เครื่องเขียนโปรแกรม และสถานีตรวจเข้ากับ product register โดยรักษาความพร้อมใช้งานและ segmentation ของ OT หลักการเครือข่ายที่เกี่ยวข้องดูได้จาก แนวทางสร้างเครือข่ายอุตสาหกรรม
ล็อก revision ฮาร์ดแวร์ hash firmware configuration profile ขั้นตอน inject key และข้อกำหนดตรวจใน work order หลังเขียนโปรแกรมให้อ่าน device ID และ build ID กลับ ตรวจลายเซ็น การปิด debug การยืนยันตัวตนเริ่มต้น และการอัปเดต ผูกผลกับ serial number และตลาดปลายทาง กำหนดเงื่อนไข rollback ใน rework และการกักของไม่ผ่าน
ข้อกำหนด supplier ควรครอบคลุม SBOM การแจ้งช่องโหว่ การแก้ไข EOL การจัดการ secret และความร่วมมือเมื่อเกิด incident อย่ารับคำว่า “โมดูลสอดคล้อง ETSI” โดยไม่มี edition ขอบเขต และหลักฐาน รายงานโมดูลไม่ครอบคลุม cloud, app, configuration และ user flow ของสินค้าสำเร็จรูป
เขียนเกณฑ์จัดซื้อความปลอดภัยอุปกรณ์ IoT อย่างไร
| หัวข้อจัดซื้อ | ตัวอย่างข้อกำหนด | วิธีรับมอบ |
|---|---|---|
| ขอบเขต | ระบุรุ่น version และข้อที่ไม่ใช้ | review applicability statement |
| ช่องโหว่ | เผยแพร่ช่องทาง SLA และวิธีแจ้ง | ตรวจ URL และทำ tabletop |
| อัปเดต | ระยะขั้นต่ำ ลายเซ็น recovery และ EOL | update และ rollback test |
| SBOM | ตกลง format version และการแจ้ง | เทียบตัวอย่าง |
| การผลิต | บันทึก key injection, debug lock, version | audit โรงงานและสุ่ม log |
| Incident | ส่งข้อมูลสำหรับ triage 24/72 ชั่วโมง | contact drill และวัด SLA |
เลขมาตรฐานเพียงอย่างเดียวไม่สร้างขอบเขตรับมอบ ผลส่งมอบที่ชัดทำให้เปรียบเทียบผู้ขายและนำไปสร้างแผนทดสอบได้
แผน 90 วัน: SCOPE–EVIDENCE–DRILL
วันที่ 1–30: SCOPE
เลือกผลิตภัณฑ์ตัวแทนหนึ่งตระกูล บันทึกรุ่น version วัตถุประสงค์ ผู้ใช้ ประเทศ แบรนด์ cloud app ความสัมพันธ์ OEM/ODM และเจ้าของ update ในหน้าเดียว แยกสมมติฐานขอบเขตกฎหมายออกจากข้อสรุปที่ยืนยันแล้ว พร้อมแหล่งข้อมูล ผู้ตรวจ และวันที่ตรวจ
แปลง 14 broad provisions เป็น control ภายใน แล้วจัดลง DEVICE, FIRMWARE, UPDATE หรือ LOG ใช้ Secure SDLC, ISO 27001, IEC 62443 และบันทึก quality ที่เกี่ยวข้องซ้ำได้ แต่ขั้นตอนระดับองค์กรไม่ใช่หลักฐานฟังก์ชันของผลิตภัณฑ์โดยอัตโนมัติ
วันที่ 31–60: EVIDENCE
กำหนด evidence ID และตรวจว่าเป็นฉบับปัจจุบัน ครอบคลุม SKU และผู้อื่นทำซ้ำได้ ทดสอบการตั้งค่าจาก factory state, reset password, certificate failure, update interruption, invalid signature, rollback, network loss, log export และ data deletion
แปลงช่องว่างเป็นระดับความรุนแรง เจ้าของ กำหนดเวลา และผลต่อการส่งของ บันทึก interim mitigation การสื่อสารลูกค้า release เป้าหมาย และผู้อนุมัติรับความเสี่ยง ในแต่ละตลาดระบุว่าใช้ซ้ำได้ตรง ต้องแปลหรือเปลี่ยนรูปแบบ หรือต้องทดสอบเพิ่ม
วันที่ 61–90: DRILL
ทำ tabletop exercise ด้วยช่องโหว่สมมติที่ถูกใช้โจมตี เริ่มจากเวลารับเรื่อง แล้วระบุ build ผ่าน SBOM หาตลาดที่ได้รับผลกระทบ ตรวจข้อมูล exploitation เตรียม mitigation ยกระดับถึงผู้บริหารและกฎหมาย และร่างคำเตือน 24 ชั่วโมงกับการแจ้ง 72 ชั่วโมง ไม่ส่งรายงานสมมติให้หน่วยงาน แต่ทดสอบ template และ approval path ภายใน
วัดข้อมูลที่ขาดและเวลารอ หากใช้ 8 ชั่วโมงเพื่อหาภูมิภาคที่ขาย และ 12 ชั่วโมงเพื่อยืนยัน version โมดูล เวลาสำรอง 24 ชั่วโมงแทบหมด ให้นำการเชื่อมระบบและความเป็นเจ้าของเข้า backlog แล้วทำ drill ซ้ำในกรณีเจ้าของงานไม่อยู่หรือเป็นวันหยุด
KPI ที่วัดความพร้อมปฏิบัติการ
- เวลาจาก SKU ที่ขายถึง firmware build และ SBOM
- เวลาจากรับช่องโหว่ถึง product owner
- เวลาประเมินตลาดและจำนวนเครื่องที่ได้รับผล
- เวลาสร้าง อนุมัติ และทยอยปล่อย security update
- อัตราสำเร็จของ update และ recovery
- สัดส่วนหลักฐานร่วมที่ใช้ซ้ำในเอกสารตลาด
- จำนวนหลักฐานหมดอายุ ลิงก์เสีย หรือไม่มีเจ้าของ
- เวลาร่างและอนุมัติคำเตือน 24 ชั่วโมงกับการแจ้ง 72 ชั่วโมง
KPI เหล่านี้ไม่พิสูจน์ความสอดคล้องกฎหมาย แต่แสดงว่าเช็กลิสต์รองรับเหตุจริงได้หรือไม่ รายงานช่องว่างต่อผู้บริหารด้วยผลกระทบการส่งสินค้า ต้นทุนวงจรชีวิต และความเสี่ยงด้านเวลา
ข้อผิดพลาดที่พบบ่อย
ข้อแรก ฝ่ายคุณภาพถือสเปรดชีตอยู่ฝ่ายเดียว ขณะที่ engineering, factory, cloud และ support ไม่อัปเดต ต้องมี owner และ update trigger ทุกแถว
ข้อสอง ตัวอย่างที่ประเมินไม่เหมือนของผลิตหลังเปลี่ยนชิ้นส่วน การตั้งค่า หรือ cloud API ให้เพิ่มการตรวจผลต่อหลักฐานความปลอดภัยและเอกสารตลาดใน engineering change control
ข้อสาม ฝ่ายการตลาดประกาศระยะ support โดยไม่จัดงบวิศวกรรม กุญแจ ระบบกระจาย และช่องทางรับเรื่อง ต้องรวมต้นทุนตลอดวงจรชีวิตในแผนผลิตภัณฑ์
ข้อสี่ มี mailbox ช่องโหว่แต่ไม่ทดสอบวันหยุด ไฟล์แนบ escalation หรือการประสาน supplier ต้องซ้อมทั้ง intake และ response
ข้อห้า เรียกกฎหมาย self-declaration, third-party assessment, label และ recognition ว่า “ใบรับรอง” เหมือนกัน ต้อง review คำกล่าวภายนอกร่วมกันระหว่าง legal, quality และ engineering
คำถามที่พบบ่อย
ETSI EN 303 645 คืออะไร?
เป็นมาตรฐานยุโรปแบบเน้นผลลัพธ์สำหรับความปลอดภัย IoT ผู้บริโภค ฉบับปัจจุบันคือ V3.1.3 (2024-09) ใช้เป็นภาษากลางของหลักฐานได้ แต่ไม่ใช่กฎหมายหรือใบรับรองสากลหลายตลาด
ทำตาม ETSI EN 303 645 แล้วสอดคล้อง EU CRA โดยอัตโนมัติหรือไม่?
ไม่อัตโนมัติ Control และผลทดสอบตาม ETSI ช่วยเตรียม CRA แต่ต้องประเมินขอบเขต การจัดประเภท การประเมินความสอดคล้อง เอกสารเทคนิค การจัดการช่องโหว่ และการรายงานแยกกัน ประเด็นกฎหมายที่ไม่ชัดควรปรึกษาผู้เชี่ยวชาญ
กำหนด 24 ชั่วโมงและ 72 ชั่วโมงของ CRA หมายถึงอะไร?
คณะกรรมาธิการระบุคำเตือนเบื้องต้นภายใน 24 ชั่วโมงหลังรับรู้ และการแจ้งฉบับเต็มภายใน 72 ชั่วโมง สำหรับช่องโหว่ที่ถูกใช้โจมตีอย่างแข็งขันและเหตุร้ายแรงที่กระทบความปลอดภัยของผลิตภัณฑ์ดิจิทัล ไม่ใช่ bug ทุกตัว ทีมต้องมีการวิเคราะห์ trigger และบันทึกข้อเท็จจริง
ใบรับรองความปลอดภัย IoT หนึ่งใบใช้ได้ทุกประเทศหรือไม่?
โดยทั่วไปไม่อัตโนมัติ ผลทดสอบและหลักฐานอาจใช้ซ้ำได้ แต่ขอบเขต ระดับ ผู้สมัคร คำประกาศ และเงื่อนไขฉลากต่างกัน อ้าง recognition เฉพาะที่หน่วยงานประกาศ และอธิบายส่วนอื่นว่าเป็นการเพิ่มประสิทธิภาพการเตรียม
JC-STAR เกี่ยวข้องกับ ETSI EN 303 645 อย่างไร?
IPA ระบุว่า JC-STAR พัฒนาด้วยความสอดคล้องกับมาตรฐานและแนวทางสากล เช่น ETSI และ NIST จึงใช้หลักฐานร่วมได้ แต่การประเมิน ETSI เพียงอย่างเดียวไม่ได้ให้ฉลาก JC-STAR
เกณฑ์จัดซื้อความปลอดภัยอุปกรณ์ IoT ควรมีอะไร?
ควรระบุรุ่นและ version, applicability, password design, ช่องทางช่องโหว่, ระยะ support ขั้นต่ำ, signed update, SBOM, key control ในโรงงาน, log, incident cooperation, acceptance test และรูปแบบหลักฐาน พร้อม owner และเกณฑ์รับทุกข้อ
โรงงานไทยควรเริ่มจากตรงไหน?
เลือกผลิตภัณฑ์หนึ่งตัว รวบรวม DEVICE, FIRMWARE, UPDATE และ LOG แล้วทำวงจร 90 วันตั้งแต่กำหนดขอบเขต เก็บหลักฐาน ถึงซ้อม incident ปรับ template ให้ดีก่อนขยายทั้ง portfolio
สรุป
ETSI EN 303 645 เป็นฐานร่วมที่ใช้งานได้จริงสำหรับผู้ผลิต IoT ในไทยและอาเซียนที่เตรียมหลายตลาด เมทริกซ์ DEVICE, FIRMWARE, UPDATE และ LOG ทำให้เห็นส่วนต่างของ EU CRA, UK PSTI, Singapore CLS และ Japan JC-STAR แต่ไม่แทนการวิเคราะห์ขอบเขตกฎหมาย การสมัคร การประเมิน หรือการใช้ฉลาก เมื่อหน้าที่รายงาน CRA เริ่มแล้ว ความพร้อมที่แท้จริงคือความสามารถในการนำข้อเท็จจริงที่เชื่อถือได้เข้าสู่กระบวนการ 24 ชั่วโมงและ 72 ชั่วโมง
TOMAS TECH สามารถช่วยตั้งแต่ขั้นวางแผน ตรวจหลักฐานผลิตภัณฑ์ เฟิร์มแวร์ การอัปเดต และ log ไปจนถึงออกแบบเมทริกซ์ร่วม ข้อกำหนดจัดซื้อ และ drill 90 วันสำหรับฐานงานในไทย ติดต่อเรา พร้อมแจ้งตระกูลผลิตภัณฑ์และตลาดที่วางแผนไว้ได้
แหล่งอ้างอิง
- ETSI, ETSI EN 303 645 V3.1.3: https://www.etsi.org/newsroom/press-releases/2457-etsi-releases-new-guidelines-to-enhance-cyber-security-for-consumer-iot-devices/
- IPA, รายละเอียด JC-STAR: https://www.ipa.go.jp/security/jc-star/detail.html
- European Commission, CRA implementation: https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation
- European Commission, CRA reporting: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- European Commission, CRA summary: https://digital-strategy.ec.europa.eu/en/policies/cra-summary
- UK Government, consumer connectable product security: https://www.gov.uk/guidance/regulations-consumer-connectable-product-security
- Cyber Security Agency of Singapore, CLS for manufacturers: https://www.csa.gov.sg/our-programmes/certification-and-labelling-schemes/cybersecurity-labelling-scheme/for-manufacturers/
- EUR-Lex, Regulation (EU) 2024/2847: https://eur-lex.europa.eu/eli/reg/2024/2847/2024-11-20/eng
บทความนี้เป็นข้อมูลทั่วไปด้านความปลอดภัยผลิตภัณฑ์ ไม่ใช่คำปรึกษากฎหมายหรือผลการรับรอง โปรดยืนยันขอบเขตและวิธีปฏิบัติสำหรับผลิตภัณฑ์ การใช้งาน ช่องทางจำหน่าย บทบาทผู้ประกอบการ และเอกสารทางการฉบับล่าสุด
