การจัดการวงจรชีวิตใบรับรอง ISO 15118 ในปี 2026: จากความเร่งด่วนของ TLS สู่การปฏิบัติตามข้อกำหนด CRA

TL;DR (สรุปการดำเนินการสำหรับผู้บริหาร)

• การเปลี่ยนไปใช้ TLS เป็นขอบเขตที่ชัดเจน (ไม่ใช่ข้อเสนอแนะ): จาก 24 กุมภาพันธ์ 2569DigiCert จะ หยุดรับ คำขอใบรับรอง TLS สาธารณะที่มีความถูกต้อง มากกว่า 199 วันและใบรับรองที่ออกตั้งแต่วันนั้นเป็นต้นไปจะมี อายุการใช้งานสูงสุด 199 วันนี่คือขั้นตอนการเปลี่ยนผ่านที่ใช้งานได้จริงสำหรับผู้ประกอบการหลายราย ซึ่งทำให้ความเร็วในการต่ออายุเพิ่มขึ้นทันที
• แผนงาน 200→100→47 วัน ได้ถูกกำหนดไว้แล้ว: ข้อกำหนดพื้นฐานของ CA/Browser Forum กำหนดให้มีการลดลงเป็นระยะ: 200 วันนับจากวันที่ 15 มีนาคม 2569, 100 วันนับจากวันที่ 15 มีนาคม 2560, และ 47 วันนับจากวันที่ 15 มีนาคม 2562.
• CRA เพิ่มตัวนับเวลาการปฏิบัติตามกฎระเบียบ: กฎการรายงานของ CRA กำหนดไว้ว่า แจ้งเตือนล่วงหน้าภายใน 24 ชั่วโมง, แจ้งผลให้ทราบภายใน 72 ชั่วโมงและกำหนดกรอบเวลาการรายงานขั้นสุดท้ายสำหรับช่องโหว่ที่ถูกใช้ประโยชน์อย่างจริงจังและเหตุการณ์ร้ายแรงต่างๆ
• ความเสี่ยงแฝงที่สำคัญที่สุดไม่ใช่การหมดอายุ: รูปแบบความล้มเหลวของระบบคือ ความไว้วางใจ จุดยึด การเคลื่อนตัว—การเปลี่ยนแปลงของ root/intermediate/cross-signing ไม่ตรงกันระหว่าง EVSE, ตัวควบคุมในพื้นที่ และเส้นทางการตรวจสอบความถูกต้องของแบ็กเอนด์
• การลงทุนครั้งแรกเพื่อปกป้องเวลาการทำงานของระบบ: ระบบอัตโนมัติที่ขับเคลื่อนด้วยระบบ (ACME + สินค้าคงคลัง + การทยอยเปิดใช้งาน) บวกกับ ความต่อเนื่องของขอบ (การตรวจสอบ/แคชข้อมูลในพื้นที่, บันทึกหลักฐาน และการกำกับดูแลการซิงค์เวลา)

บทนำ: ปี 2026 จะเปลี่ยนระบบ Plug & Charge ให้เป็นระบบที่ใช้งานได้จริง

ในปี 2026 ฟังก์ชัน Plug & Charge (P&C) จะไม่ใช่แค่ฟีเจอร์ “ตั้งค่าแล้วไม่ต้องดูแลอีกต่อไป” อีกต่อไป แต่จะกลายเป็นฟังก์ชันที่ใช้งานง่ายและมีประสิทธิภาพมากขึ้น ระบบปฏิบัติการต่อเนื่อง.
ปัจจุบันระนาบความเชื่อถือของ ISO 15118 (PKI + TLS + การเพิกถอน + การอัปเดต) ถูกควบคุมโดยกรอบเวลาที่ไม่เอื้อต่อขั้นตอนการทำงานแบบแมนนวล

เพื่อให้เข้าใจขอบเขตของระบบ—ว่า ISO 15118 รับผิดชอบอะไรบ้าง และ OCPP รับผิดชอบอะไรบ้าง—ให้เริ่มจากเอกสารประกอบของเราก่อน:
ISO 15118 เทียบกับความเป็นจริงในการนำ OCPP ไปใช้ในปี 2026.

แรงกดดันในทันทีคือ การบีบอัดวงจรชีวิต TLSในทางปฏิบัติ คุณไม่สามารถ "รอจนถึงเดือนมีนาคม" ได้
DigiCert จะ หยุดรับ คำขอ TLS สาธารณะที่เกิน 199 วัน เริ่มต้น 24 กุมภาพันธ์ 2569,
และใบรับรองที่ออกตั้งแต่วันนั้นเป็นต้นไปจะมี อายุการใช้งานสูงสุด 199 วัน.
DigiCert ยังเน้นย้ำรายละเอียดการดำเนินงานที่สำคัญอีกประการหนึ่ง นั่นคือ ระยะเวลาการใช้งานสูงสุดที่อนุญาตนั้นถูกควบคุมโดย... วันที่ออกเอกสารไม่ใช่ตอนที่ทำการสั่งซื้อ

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

คู่มือนี้มุ่งเน้นไปที่สถาปัตยกรรมและการควบคุมความเสี่ยงสำหรับการใช้งานใบรับรอง ISO 15118 ภายใต้ข้อจำกัดเหล่านี้

เหตุการณ์สำคัญและสิ่งที่ต้องดำเนินการในปี 2024–2026 (แผนภูมิแกนต์แบบข้อความ)

หมายเหตุการใช้งาน: วันที่ 24 กุมภาพันธ์ 2569 มักเป็นจุดเปลี่ยนสำคัญ เนื่องจากพฤติกรรมการออกบัตรจะเปลี่ยนแปลงไปสำหรับหน่วยงานออกบัตรหลักๆ

หมายเหตุเกี่ยวกับนโยบาย: การลดอายุการใช้งานแบบเป็นขั้นเป็นตอนถูกกำหนดไว้ในข้อกำหนดพื้นฐาน (200/100/47 วัน)

ภาพรวมวงจรชีวิต: การจัดหา → การดำเนินงาน → การต่ออายุ → การยกเลิก

แผนผังวงจรชีวิต (สิ่งที่คุณต้องสามารถใช้งานได้)

1. การจัดเตรียมอุปกรณ์ OEM: สร้าง/ป้อนคีย์แล้ว; สร้างรากฐานความเชื่อมั่นแล้ว (HSM/องค์ประกอบความปลอดภัย)
2. การลงทะเบียนตามสัญญา: ใบรับรองสัญญาที่ผูกติดกับสัญญาของผู้ใช้ (ขึ้นอยู่กับระบบนิเวศ)
3. การทดสอบระบบสถานีชาร์จรถยนต์ไฟฟ้า (EVSE): มีการกำหนดค่าพื้นฐาน นโยบาย และค่าพื้นฐานการซิงค์เวลาของ Trust-store แล้ว
4. การตรวจสอบความถูกต้องในการปฏิบัติงาน: การจับมือ TLS, การสร้างเชน, การตรวจสอบการเพิกถอน, การบังคับใช้นโยบาย
5. การต่ออายุ / การออกบัตรใหม่: ระบบอัตโนมัติ + การทยอยเปิดใช้งาน + การย้อนกลับ
6. การเพิกถอน / การตอบสนองต่อเหตุการณ์: การรั่วไหล/การออกบัตรผิดพลาด/การแสวงประโยชน์ → เพิกถอน/หมุนเวียน/กู้คืน
7. การฟื้นฟูและการคืนดี: คืนค่าการให้บริการพร้อมทั้งรักษาความสามารถในการตรวจสอบและความถูกต้องของการเรียกเก็บเงิน

จุดอ่อนที่ถูกมองข้าม: การเคลื่อนตัวของจุดยึดความเชื่อมั่น

ความล้มเหลวในการตรวจสอบความปลอดภัยและประกันภัย (P&C) ที่ไม่ทราบสาเหตุส่วนใหญ่ในสภาพแวดล้อมที่มีผู้ผลิตหลายราย ไม่ได้เกิดจากใบรับรองหมดอายุเพียงใบเดียว แต่เกิดจากสาเหตุอื่นๆ
ความล้มเหลวในการตรวจสอบเส้นทาง สาเหตุเกิดจากการเคลื่อนตัวของจุดยึดความเชื่อมั่น:

• รากใหม่/รากกลางปรากฏขึ้น (ความเป็นจริงที่มีรากหลายราก)
• การลงนามไขว้ การเปลี่ยนแปลงจะส่งผลต่อห่วงโซ่ที่เป็นไปได้
• ระบบจัดเก็บข้อมูลความน่าเชื่อถือส่วนหลัง (Backend trust stores) อัปเดตได้เร็วกว่าสถานีชาร์จรถยนต์ไฟฟ้า (EVSE) หรือตัวควบคุมในพื้นที่ (local controllers)
• เอกสารการเพิกถอนจะหมดอายุเมื่อถึงขอบเขตที่กำหนด

ถือว่าการอัปเดตจุดยึดความน่าเชื่อถือเป็นกระบวนการเปลี่ยนแปลงที่สำคัญต่อความปลอดภัย:

• ที่เก็บความเชื่อถือแบบมีเวอร์ชัน
• การทดสอบระบบ Canary
• แผนการย้อนกลับ
• ข้อมูลการวัดระยะทางเกี่ยวกับความล้มเหลวในการตรวจสอบความถูกต้องโดยผู้ออก/หมายเลขซีเรียล/เส้นทาง
• ระบุผู้รับผิดชอบอย่างชัดเจนสำหรับ “ใครเป็นผู้อัปเดตอะไร เมื่อไหร่”

ความล้มเหลวในการลงนามร่วมและการสร้างเส้นทาง (ความเป็นจริงในปี 2026): ในระบบนิเวศ ISO 15118 แบบหลายรูท
การชาร์จแบบเสียบปลั๊กมักล้มเหลว ไม่ใช่เพราะใบรับรองไม่ถูกต้อง แต่เป็นเพราะเครื่องชาร์จ EVSE ไม่สามารถสร้างใบรับรองที่ถูกต้องได้
เส้นทางใบรับรอง หลังจากการเปลี่ยนแปลงการลงนามไขว้ (ตัวกลางใหม่, CA เชื่อมโยง, ห่วงโซ่ที่ออกใหม่)
เมื่อมีผู้ผลิตอุปกรณ์ (OEM) และโดเมน PKI เข้าร่วมมากขึ้น ความซับซ้อนของเส้นทางก็จะเพิ่มขึ้น หากใช้ที่เก็บข้อมูลความเชื่อถือที่ขอบ (EVSE/ตัวควบคุมในพื้นที่)
เนื่องจากความล่าช้าในการอัปเดตแบ็กเอนด์ การเชื่อมต่อ TLS อาจล้มเหลวแม้ว่าใบรับรองแบ็กเอนด์จะดู "ถูกต้อง" เมื่อพิจารณาแยกต่างหากก็ตาม

รูปที่ 1 (ภาพประกอบที่แนะนำ): การตรวจสอบความถูกต้องของเส้นทางในระบบไฟล์หลายรูท ISO 15118

(แสดง V2G Root / OEM Root / Contract Root, ตัวกลาง และสะพานเชื่อมสัญญาณไขว้)
(ระบุจุดที่ตัวกลางที่ลงนามร่วมกันใหม่ขัดขวางการสร้างเส้นทางบน EVSE หากที่เก็บข้อมูลความน่าเชื่อถือไม่ได้รับการอัปเดตให้ตรงกัน)

ข้อความหลัก: การหยุดชะงักของระบบ P&C ส่วนใหญ่ที่ถูกกล่าวโทษว่าเป็นเพราะ "PKI" นั้น จริงๆ แล้วไม่ใช่สาเหตุที่แท้จริง ความล้มเหลวในการตรวจสอบเส้นทาง เกิดจากความคลาดเคลื่อนของการลงนามข้ามแพลตฟอร์มและแหล่งเก็บข้อมูลความน่าเชื่อถือที่ไม่ตรงกัน

ACME และระบบอัตโนมัติ: การทำงานที่นำโดยมนุษย์เทียบกับการทำงานที่นำโดยระบบ ภายใต้ช่วงอายุการใช้งาน 199/200 วัน

เหตุใดการต่ออายุด้วยตนเองจึงกลายเป็นตัวก่อให้เกิดไฟฟ้าดับอย่างแน่นอน

อายุการใช้งานสั้นทำให้ต้องต่ออายุอย่างต่อเนื่อง การที่ DigiCert เปลี่ยนไปใช้แนวทางนี้ 199 วันนับจากวันที่ 24 กุมภาพันธ์ พ.ศ. 2569
ทำให้ระบบนี้ใช้งานได้ทันทีสำหรับกองยานหลายแห่ง และกรอบเวลาโดยรวมของอุตสาหกรรมก็ได้รับการกำหนดไว้แล้ว:
200 วัน (ตั้งแต่วันที่ 15 มีนาคม 2026) จากนั้น 100 วัน, แล้ว 47 วัน.

สำหรับยานพาหนะทุกประเภท การต่ออายุใบอนุญาตจะมีขนาดดังนี้:

จำนวนครั้งการต่ออายุต่อปี ≈ N × (365 / L)

ที่ไหน เอ็น คือจำนวนของเอนด์พอยต์ TLS และ แอล อายุการใช้งานของใบรับรอง (วัน) คือเท่าใด
เช่น แอล เมื่อเวลาการทำงานลดลง การต่ออายุสัญญาโดยมนุษย์จะไม่สามารถสอดคล้องกับเป้าหมายเวลาการทำงานได้ตามหลักคณิตศาสตร์

สถานการณ์จำลอง (การกำหนดขนาดในระดับคณะกรรมการ)

สำหรับการดำเนินงานของ CPO 5,000 จุดเชื่อมต่ออายุขัย 199 วัน หมายความว่า:

จำนวนครั้งการต่ออายุต่อปี ≈ 5000 × (365 / 199) ≈ 9,171

ในระดับนี้ แม้แต่... อัตราความผิดพลาดของมนุษย์ 1% แปลได้ประมาณ
เกิดเหตุขัดข้องเนื่องจากปัญหาใบรับรอง 92 ครั้งต่อปี—ก่อนที่จะพิจารณาผลกระทบในช่วงชั่วโมงเร่งด่วน
บทลงโทษตามข้อตกลงระดับบริการ (SLA) หรือความล้มเหลวที่เกิดขึ้นต่อเนื่องกันทั่วทั้งศูนย์กลาง

ACME ในเครือข่ายการชาร์จ: ควรนำระบบอัตโนมัติมาใช้ในส่วนใดบ้าง

ACME (Automated Certificate Management Environment) เปลี่ยนการต่ออายุใบรับรองให้เป็นการดำเนินการที่ขับเคลื่อนด้วยนโยบายสำหรับ:

• EVSE ↔ TLS ฝั่งแบ็กเอนด์
• ตัวควบคุมภายใน / พร็อกซีขอบเครือข่าย TLS
• เกตเวย์ไซต์และตัวควบคุมฮับ

เวิร์กโฟลว์ที่ขับเคลื่อนด้วยระบบ (รูปแบบสถาปัตยกรรม)

1. รายการสิ่งของ ทุกจุดสิ้นสุด (ผู้ออก, หมายเลขซีเรียล, ห่วงโซ่, วันหมดอายุ, การหมุนเวียนครั้งสุดท้าย)
2. นโยบายการต่ออายุก่อน (ต่ออายุเมื่อถึงเกณฑ์ที่กำหนด ไม่ใช่ "ใกล้หมดอายุ")
3. ปุ่มกดที่รองรับด้วยฮาร์ดแวร์ หากเป็นไปได้ ควรหลีกเลี่ยงการส่งออกคีย์ส่วนตัว
4. การทยอยเปิดตัว พร้อมการตรวจสอบสถานะสุขภาพ (การจับมือ + การอนุญาต + การเริ่มต้นเซสชัน)
5. การย้อนกลับอัตโนมัติ เนื่องจากอัตราความล้มเหลวที่สูงขึ้น
6. บันทึกหลักฐาน สำหรับทุกการออก/ใช้งาน (การตรวจสอบย้อนกลับระดับมาตรฐานการปฏิบัติตามกฎระเบียบ)

การนำโดยมนุษย์เทียบกับการนำโดยระบบ

• การจัดการโดยมนุษย์: ตั๋ว, สเปรดชีต, การต่ออายุล่าช้า, ความเป็นเจ้าของที่ไม่ชัดเจน, การเปลี่ยนแปลงฉุกเฉินที่มีความเสี่ยง
• การดำเนินงานโดยระบบ: นโยบายที่กำหนดไว้ล่วงหน้า การออกเอกสารอัตโนมัติ การดำเนินการอย่างเป็นระบบ การตรวจสอบข้อมูลอย่างต่อเนื่อง หลักฐานที่ตรวจสอบได้

การตรวจสอบการเพิกถอน: “ตัวทำลาย P&C” (CRL เทียบกับ OCSP, เครือข่ายที่อ่อนแอ และนโยบายที่สามารถป้องกันได้)

เหตุใด OCSP/CRL จึงใช้งานไม่ได้ผลในอู่ซ่อมรถและศูนย์ซ่อมบำรุง

• สัญญาณ LTE/5G อ่อน/ขาดๆ หายๆ
• การจำกัดการเข้าออก (ไฟร์วอลล์/แคปทีฟพอร์ทัล)
• ขั้นตอนการตรวจสอบความถูกต้องที่ไวต่อเวลาแฝง
• ปัจจัยภายนอกที่เกี่ยวข้อง (ตัวตอบสนอง OCSP, จุดกระจาย CRL)

ผลลัพธ์: EVSE สามารถเริ่มต้นเซสชันได้ แต่ไม่สามารถดำเนินการให้เสร็จสมบูรณ์ได้ การตรวจสอบการเพิกถอน อย่างน่าเชื่อถือ

CRL เทียบกับ OCSP: ข้อแลกเปลี่ยนในทางปฏิบัติ

• CRL: ไฟล์ดาวน์โหลดมีขนาดใหญ่กว่า แต่สามารถแคชและรีเฟรชได้ตามกำหนดเวลา (เหมาะสำหรับความต่อเนื่องของระบบ Edge Computing)
• โอซีเอสพี: มีน้ำหนักเบาต่อการร้องขอ แต่บ่อยครั้งที่ต้องอาศัยการเข้าถึงแบบเรียลไทม์ ณ จุดที่อ่อนแอที่สุด

ในปี 2026 ท่าทางที่ถูกต้องจะถูกจัดเรียงเป็นชั้นๆ ดังนี้:

• การแคช CRL ตามกำหนดเวลาเพื่อความยืดหยุ่น
• OCSP ที่มีการเชื่อมต่อที่เชื่อถือได้
• นโยบายที่ชัดเจนสำหรับสภาวะที่เสื่อมโทรม

เหตุใดการ "สอบตกแบบไม่ร้ายแรง" จึงยากที่จะหาเหตุผลมาแก้ตัวได้

ในอดีต การใช้ "soft-fail" (อนุญาตให้ใช้งานเซสชันต่อไปได้หากการตรวจสอบการเพิกถอนหมดเวลา) ช่วยรักษาความพร้อมใช้งานไว้ได้
ในปี 2026 การให้เหตุผลสำหรับความล้มเหลวที่ไม่ร้ายแรง (soft-fail) จะทำได้ยากขึ้นเนื่องจาก:

• ช่วงอายุขัยสั้นลง (ความอดทนต่อสมมติฐานที่ล้าสมัยน้อยลง)
• ระบบการรายงานของ CRA บังคับให้มีการตรวจสอบเหตุการณ์และรวบรวมหลักฐานอย่างเข้มงวดมากขึ้น

การออกแบบที่สมเหตุสมผลต้องมีนโยบายที่ชัดเจนและมีการบันทึกไว้เป็นอย่างดี:

• ล้มเหลวอย่างสิ้นเชิง สำหรับพื้นที่สาธารณะ/พื้นที่เสี่ยงสูง
• พระคุณพร้อมหลักฐาน สำหรับกลุ่มยานพาหนะแบบปิด (ช่วงเวลาจำกัด + การควบคุมชดเชย)
• การบันทึกหลักฐาน สำหรับทุกการตัดสินใจที่เสื่อมถอย

มาตรการบรรเทาผลกระทบทางสถาปัตยกรรม (รูปแบบ ไม่ใช่คำมั่นสัญญาของผลิตภัณฑ์)

รูปแบบที่ 1: การตรวจสอบความถูกต้องเบื้องต้นที่ขอบเครือข่าย + การแคชข้อมูล

• แคช CRL ที่มีช่วงเวลาความสดใหม่ที่กำหนดไว้
• แคชข้อมูลระดับกลางและสายโซ่ที่ผ่านการตรวจสอบแล้ว
• ดึงข้อมูลล่วงหน้าในช่วงที่มี "การเชื่อมต่อที่ดี"

รูปแบบที่ 2: การเย็บด้วยลวดเย็บ OCSP (ในกรณีที่ทำได้)

OCSP stapling ช่วยย้ายการส่งมอบหลักฐานการเพิกถอนออกจากส่วนที่อ่อนแอที่สุด ซึ่งช่วยลดการพึ่งพาโครงสร้างพื้นฐานของ CA ในระหว่างการสร้างเซสชัน

หมายเหตุการใช้งาน (เทคโนโลยีความเป็นจริงเสมือนฝังตัว): ในสภาพแวดล้อม EVSE ให้ตรวจสอบการรองรับส่วนขยายที่เกี่ยวข้องกับการเย็บกระดาษ
ในระบบ TLS แบบฝังตัวของคุณ และสร้างการกำหนดค่า (เช่น mbedTLS, wolfSSL) และตรวจสอบการทำงานบนฮาร์ดแวร์รุ่นเก่า
เนื่องจากความสมบูรณ์ของฟีเจอร์และข้อจำกัดด้านหน่วยความจำ/ระบบปฏิบัติการแบบเรียลไทม์นั้นแตกต่างกันไป

รูปแบบที่ 3: การกำกับดูแลความไว้วางใจแบบหลายราก

• ช่องทางการอัปเดตคลังข้อมูลความน่าเชื่อถือแบบรวมศูนย์สำหรับจุดเชื่อมต่อ OEM หลายจุด
• การอัปเดตแบบ Canary + การย้อนกลับเมื่อเกิดข้อผิดพลาดในการสร้างเส้นทางเพิ่มขึ้นอย่างรวดเร็ว

รูปแบบที่ 4: การกำกับดูแลการซิงค์เวลา (ไม่สามารถต่อรองได้)

• นโยบาย NTP (หรือ PTP ในกรณีที่เหมาะสม)
• การตรวจสอบการเปลี่ยนแปลงและเกณฑ์การแจ้งเตือน
• พฤติกรรมที่กำหนดไว้เมื่อนาฬิกาไม่น่าเชื่อถือ

ความต่อเนื่องในการใช้งานแบบออฟไลน์: รักษาความสามารถในการใช้งาน Plug & Charge แม้ในขณะที่การเชื่อมต่อระหว่างอุปกรณ์ปลายทางกับระบบคลาวด์ถูกตัดการเชื่อมต่อ

ความต่อเนื่องแบบออฟไลน์คืออะไร (และไม่ใช่อะไร)

ความต่อเนื่องแบบออฟไลน์ไม่ได้หมายความว่า “เป็นการหลีกเลี่ยง PKI” แต่เป็นการลดทอนอย่างมีระบบที่ช่วยรักษาคุณสมบัติต่างๆ ไว้ดังนี้:

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

ตัวควบคุมท้องถิ่น / พร็อกซีขอบเครือข่าย ในฐานะองค์ประกอบพื้นฐานด้านความพร้อมใช้งาน

• รักษาแคชความเชื่อถือในพื้นที่ (แองเคอร์/ตัวกลาง/CRL)
• บังคับใช้นโยบายการอนุญาตในระดับท้องถิ่นอย่างจำกัด
• บันทึกการวัด/เก็บข้อมูลไว้เพื่อใช้ในการตรวจสอบความถูกต้องในภายหลัง
• ลดขอบเขตการส่งสัญญาณ WAN โดยทำหน้าที่เป็นจุดสิ้นสุดในพื้นที่สำหรับ EVSE

รูปที่ 2 (ภาพประกอบที่แนะนำ): Edge Proxy ทำหน้าที่เป็น Trust Cache ในเว็บไซต์ที่มีเครือข่ายอ่อนแอ

(แสดงการเชื่อมต่อ EVSE กับ Edge Proxy/Local Controller ในสถานที่ Proxy จะเก็บรักษาแคชของ Trust Anchor/Intermediate ไว้)
มีการกำหนดเวลารีเฟรช CRL, การตรวจสอบการซิงค์เวลา และบันทึกหลักฐาน; และจะบัฟเฟอร์เหตุการณ์ไปยัง CSMS/PKI บนคลาวด์เมื่อการเชื่อมต่ออัปลิงก์ไม่เสถียร)

ข้อความหลัก: พร็อกซี Edge ช่วยลดการพึ่งพาปลายทาง OCSP/CRL ภายนอกแบบเรียลไทม์ และช่วยให้สามารถใช้งานแบบออฟไลน์ได้อย่างต่อเนื่องโดยไม่ต้องข้าม PKI

CRA & VMP: เปลี่ยนกำหนดส่งรายงานจากเดือนกันยายน 2026 เป็นรูปแบบการดำเนินงานที่ตรวจสอบได้

กฎการรายงานของ CRA: ออกแบบให้สอดคล้องกับระบบเวลา 24 ชั่วโมง/72 ชั่วโมง

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

• แจ้งเตือนล่วงหน้าภายใน 24 ชั่วโมง การตระหนักรู้
• แจ้งผลให้ทราบภายใน 72 ชั่วโมง
• รายงานฉบับสุดท้าย ภายในช่วงเวลาที่กำหนด (ขึ้นอยู่กับประเภทของเหตุการณ์)

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

กระบวนการจัดการช่องโหว่ (VMP): ความสามารถขั้นต่ำที่ใช้งานได้

1. ความจริงเกี่ยวกับกองเรือ: รายการสินทรัพย์และเวอร์ชัน (เฟิร์มแวร์ EVSE, อิมเมจคอนโทรลเลอร์, เวอร์ชัน Trust Store)
2. การบูรณาการ SBOM (แบบไดนามิก): SBOM ถูกแมปไปยังสิ่งประดิษฐ์ที่ใช้งานได้จริง มีความสัมพันธ์อย่างต่อเนื่องกับข้อมูลข่าวกรองด้านช่องโหว่
3. การจัดการความเสี่ยงที่ขับเคลื่อนด้วย VEX: รักษาข้อความ VEX เพื่อแยกแยะระหว่าง “มีอยู่แต่ไม่สามารถใช้ประโยชน์ได้” กับ “สามารถใช้ประโยชน์ได้ในการใช้งานของเรา” ซึ่งจะช่วยให้สามารถกำหนดขอบเขตได้อย่างน่าเชื่อถือภายในกรอบเวลา T+24 ชั่วโมง
4. เหตุใด VEX จึงมีความสำคัญภายใต้ระบบเวลา 24 ชั่วโมง: SBOM บอกคุณว่ามีอะไรอยู่บ้าง ส่วน VEX ช่วยคุณระบุว่าอะไรคืออะไร สามารถใช้ประโยชน์ได้ลดการแจ้งเตือนที่ผิดพลาด และป้องกันไม่ให้ทีมปฏิบัติการเสียเวลาไปกับสิ่งที่ไม่ก่อให้เกิดประโยชน์
5. การรับผู้ป่วยและการคัดกรองเบื้องต้น: คำแนะนำจากผู้จำหน่าย, CVEs, ผลการตรวจสอบภายใน; ให้ความสำคัญกับความเสี่ยงและการเปิดเผยข้อมูลเป็นอันดับแรก
6. ขั้นตอนการทำงานแบบ T+24h: SBOM + VEX + การเชื่อมโยงข้อมูลสินค้าคงคลังเพื่อระบุประชากรที่ได้รับผลกระทบ การตัดสินใจควบคุมเบื้องต้น การรวบรวมหลักฐาน
7. ขั้นตอนการแจ้งเตือน T+72h: ขอบเขตที่ได้รับการยืนยัน มาตรการบรรเทาผลกระทบ แผนการดำเนินการ/ยกเลิก การบันทึกการสื่อสาร
8. ขั้นตอนการจัดทำรายงานฉบับสุดท้าย: หลักฐานการตรวจสอบ + สาเหตุหลัก + การปรับปรุงการป้องกันหลังจากมีมาตรการแก้ไขแล้ว
9. การออกแบบจังหวะแพทช์: การทยอยเปิดใช้งาน, แผนการยกเลิก, เอกสารที่ลงนามแล้ว, ด่านตรวจสอบความถูกต้อง
10. การบังคับใช้ห่วงโซ่ความไว้วางใจ: การบูตที่ปลอดภัย + การอัปเดตเฟิร์มแวร์ที่ปลอดภัย; คีย์ลงนามได้รับการปกป้องใน HSM/องค์ประกอบความปลอดภัย
11. การบันทึกข้อมูลโดยยึดหลักฐานเป็นหลัก: เหตุการณ์เกี่ยวกับใบรับรอง การเปลี่ยนแปลงใน Trust Store ความล้มเหลวในการเพิกถอน สถานะการซิงค์เวลา

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

รายการตรวจสอบการนับถอยหลังการตอบสนองต่อเหตุการณ์ของ CRA (แม่แบบปฏิบัติการ)

T+0 (การตรวจจับ / การรับรู้)

• หลักฐานการหยุดการเปลี่ยนแปลง: บันทึกเหตุการณ์, เหตุการณ์ใบรับรอง, เวอร์ชันของที่เก็บใบรับรองที่เชื่อถือได้, สถานะการซิงค์เวลา
• ระบุส่วนที่ได้รับผลกระทบ: เฟิร์มแวร์ EVSE, ตัวควบคุมในพื้นที่, จุดเชื่อมต่อ TLS ฝั่งแบ็กเอนด์
• ติดต่อผู้ให้บริการ PKI / ผู้ติดต่อด้านความปลอดภัยแบ็กเอนด์

T+24 ชั่วโมง (ความพร้อมในการแจ้งเตือนล่วงหน้า)

• วัตถุประสงค์หลัก: ใช้ SBOM + VEX + สินค้าคงคลังของกองเรือ เพื่อกำหนดจำนวนประชากรที่ได้รับผลกระทบและส่งระบบเตือนภัยล่วงหน้าที่มีหลักฐานสนับสนุน
• ตัดสินใจเกี่ยวกับการควบคุม: เพิกถอน/หมุนเวียน, การย้อนกลับไปยังแหล่งเก็บข้อมูลที่เชื่อถือได้, การแยกไซต์
• ร่างชุดระบบเตือนภัยล่วงหน้า: ขอบเขต มาตรการบรรเทาผลกระทบที่กำลังดำเนินการ และท่าทีชั่วคราว

T+72 ชั่วโมง (พร้อมการแจ้งเตือนอย่างสมบูรณ์)

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

หน้าต่างรายงานฉบับสุดท้าย

• ส่งรายงานฉบับสุดท้ายที่สอดคล้องกับข้อกำหนดของ CRA (ระยะเวลาขึ้นอยู่กับประเภทของเหตุการณ์)
• หลักฐานการตรวจสอบหลังการแก้ไข + บทเรียนที่ได้รับ

การประเมินต้นทุนและความเสี่ยง (เทมเพลตที่คุณสามารถนำไปใช้กับยานพาหนะของคุณได้)

แบบจำลองต้นทุนแรงงานการต่ออายุด้วยตนเอง

อนุญาต:

• เอ็น = จำนวนเอนด์พอยต์ TLS (EVSE + คอนโทรลเลอร์ + เกตเวย์ + โหนดแบ็กเอนด์ที่ได้รับการจัดการ)
• แอล = อายุการใช้งานของใบรับรอง (วัน)
• ที = เวลาที่ใช้ในการต่ออายุแต่ละครั้ง (ชั่วโมง)
• ซี = ต้นทุนแรงงานรวมทุกอย่าง (ดอลลาร์สหรัฐ/ชั่วโมง)

ต้นทุนแรงงาน ≈ N × (365 / L) × t × c

แบบจำลองความเสี่ยงการหยุดชะงัก (หมดอายุหรือการติดตั้งล้มเหลว)

อนุญาต:

• พี_มิส = ความน่าจะเป็นของการต่ออายุที่ไม่สำเร็จ/พลาดต่อรอบ
• เอชดาวน์ = จำนวนชั่วโมงที่คาดว่าจะหยุดทำงานต่อเหตุการณ์
• ซี_ชั่วโมง = ผลกระทบต่อธุรกิจต่อชั่วโมง (รายได้ที่สูญเสียไป ค่าปรับ เครดิต SLA)

ต้นทุนการหยุดชะงัก ≈ P_miss × H_down × C_hour

คู่มือการตัดสินใจ: เมื่อการตรวจสอบการเพิกถอนทางออนไลน์ล้มเหลว (OCSP/CRL หมดเวลา)

1. สถานที่สาธารณะหรือสถานที่ปิด/ศูนย์ซ่อมบำรุง?
   • สาธารณะ → ชอบ ล้มเหลวอย่างสิ้นเชิง (หรือความเมตตาที่ควบคุมอย่างเข้มงวดโดยมีหลักฐานและมาตรการควบคุมทดแทน)
   • กองยาน/ศูนย์ซ่อมบำรุง → พระคุณพร้อมหลักฐาน อาจยอมรับได้สำหรับหน้าต่างที่มีข้อจำกัด
2. ความน่าเชื่อถือของเครือข่ายสามารถคาดการณ์ได้หรือไม่?
   • ใช่ → OCSP/CRL ออนไลน์ + การตรวจสอบ
   • ไม่ → การตรวจสอบความถูกต้องเบื้องต้นที่ขอบ + การแคช (หน้าต่างรีเฟรช CRL, เชนที่แคชไว้)
3. คุณสามารถลดการพึ่งพาการเชื่อมต่อออนไลน์ในระหว่างเซสชันได้หรือไม่?
   • หากเป็นไปได้ → นำมาใช้ รูปแบบการเย็บ OCSP (เลื่อนหลักฐานให้ใกล้ขอบมากขึ้น)
4. คุณมีระบบบันทึกหลักฐานและการกำกับดูแลการซิงค์เวลาหรือไม่?
   • ถ้าไม่ → แก้ไขปัญหาเหล่านี้ก่อน นโยบายโหมดลดประสิทธิภาพนั้นยากที่จะปกป้องได้หากไม่มีการแก้ไขปัญหาเหล่านี้

เมทริกซ์ความรับผิดชอบเชิงปฏิบัติ (ขอบเขตที่ป้องกันการหยุดชะงัก)

คำศัพท์เฉพาะ

• พีไอไอ: โครงสร้างพื้นฐานกุญแจสาธารณะ (การออกกุญแจ การตรวจสอบความถูกต้อง จุดยึดความเชื่อถือ การเพิกถอน)
• เอซีเอ็ม: สภาพแวดล้อมการจัดการใบรับรองอัตโนมัติ (การออก/ต่ออายุใบรับรองอัตโนมัติ)
• OCSP / CRL: โปรโตคอลสถานะใบรับรองออนไลน์ / รายการเพิกถอนใบรับรอง
• การเย็บด้วยลวดเย็บกระดาษ OCSP: เซิร์ฟเวอร์แสดงหลักฐานการเพิกถอนเพื่อลดการพึ่งพา OCSP แบบเรียลไทม์
• จุดยึดเหนี่ยวความไว้วางใจ: ใบรับรองราก/ใบรับรองระดับกลางที่ผู้ตรวจสอบความถูกต้องของคุณเชื่อถือ
• สบีโอเอ็ม: รายการส่วนประกอบซอฟต์แวร์ (รายการส่วนประกอบเพื่อประเมินความเสี่ยงด้านความปลอดภัย)
• เว็กซ์: Vulnerability Exploitability eXchange (รายงานสถานะการใช้ประโยชน์จากช่องโหว่)
• TLS 1.3: โปรไฟล์ TLS สมัยใหม่; การจับมือและการตรวจสอบใบรับรองยังคงไวต่อเวลาแฝง
• วีเอ็มพี: กระบวนการจัดการช่องโหว่ (การรับเรื่อง การคัดกรอง การแก้ไข การรายงาน การรวบรวมหลักฐาน)

ความเสี่ยงในอนาคต: ความคล่องตัวด้านคริปโตเคอร์เรนซีและความพร้อมสำหรับ PQC

แม้ว่าปี 2026 จะเป็นปีที่มีอายุการใช้งาน TLS สั้นและมีการรายงาน CRA เป็นหลัก แต่โครงสร้างพื้นฐานด้านการชาร์จควรเริ่มประเมินสิ่งต่างๆ
ความคล่องตัวด้านคริปโตสำหรับสินทรัพย์ที่มีอายุการใช้งานยาวนาน (เช่น ยานพาหนะและเครื่องชาร์จ) สถาปัตยกรรมควรหลีกเลี่ยงการผูกติดกับฮาร์ดแวร์โดยการรับประกันว่า...
HSM/secure element และ embedded stack สามารถรองรับการอัปเดตอัลกอริธึมและโปรไฟล์ใบรับรองในอนาคตได้โดยไม่จำเป็นต้องเปลี่ยนฮาร์ดแวร์ใหม่

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

ระบบ Plug & Charge สามารถใช้งานแบบออฟไลน์ได้หรือไม่?

บางส่วน—ตามการออกแบบ ระบบ P&C แบบออฟไลน์จะลดประสิทธิภาพลงอย่างมีการควบคุมโดยใช้การแคชข้อมูลที่เชื่อถือได้ในพื้นที่ (แองเคอร์/ตัวกลาง/CRL ในกรณีที่ทำได้)
นโยบายผ่อนผันที่ชัดเจน และบันทึกการตรวจสอบที่จัดเก็บไว้เพื่อการกระทบยอด ไม่ควรข้าม PKI และควรลดการพึ่งพาระบบคลาวด์แบบเรียลไทม์
พร้อมทั้งรักษาความถูกต้องแม่นยำและสามารถตรวจสอบได้

สำหรับใบอนุญาตที่มีอายุการใช้งาน 199/200 วัน เราต้องต่ออายุใบอนุญาตบ่อยแค่ไหน?

วางแผนสำหรับการต่ออายุสัญญาหลายรอบต่อปีต่ออุปกรณ์ปลายทาง สำหรับผู้ให้บริการหลายราย การเปลี่ยนผ่านการดำเนินงานจะเริ่มต้นขึ้น
24 กุมภาพันธ์ 2569 เนื่องจาก DigiCert จะออกใบรับรอง TLS สาธารณะที่มีอายุการใช้งานสูงสุด 199 วัน มีผลบังคับใช้ตั้งแต่วันนั้นเป็นต้นไป
ในระดับระบบนิเวศที่กว้างขึ้น ข้อกำหนดพื้นฐานกำหนดการลดลงเป็นระยะๆ ไปสู่ 200/100/47 วัน.

อะไรคือปัจจัยที่ทำให้เกิดภาระผูกพันในการรายงานต่อ CRA?

กฎการรายงานของ CRA กำหนดไว้ว่า ระบบเตือนภัยล่วงหน้า 24 ชั่วโมง และ การแจ้งเตือนล่วงหน้า 72 ชั่วโมง สำหรับช่องโหว่ที่ถูกใช้ประโยชน์อย่างแข็งขันและเหตุการณ์ร้ายแรงต่างๆ
รวมถึงช่วงเวลาการรายงานขั้นสุดท้าย การหยุดชะงักครั้งใหญ่ของความไว้วางใจใน P&C (เช่น การเพิกถอนโดยเจตนาร้าย หรือการละเมิดการตรวจสอบความถูกต้อง) อาจเข้าข่ายได้ ขึ้นอยู่กับสถานการณ์
โดยพิจารณาจากหลักฐานผลกระทบและการแสวงประโยชน์ แผนการจัดการทรัพย์สินที่พร้อมสำหรับ CRA ควรให้การสนับสนุน SBOM + VEX + สินค้าคงคลังของกองเรือ ตรวจสอบภายใน 24 ชั่วโมงแรก