อัปเดต HTTPS และ TLS ปี 2026: สิ่งที่คลินิก โรงพยาบาล และธุรกิจสุขภาพต้องทบทวน

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

บทความนี้สรุปเฉพาะส่วนที่ควรกลับไปทบทวนใหม่ในปี 2026 สำหรับเว็บไซต์คลินิก โรงพยาบาล และธุรกิจสุขภาพ ไม่ใช่คู่มือ HTTPS และ TLS ตั้งแต่ต้น เพราะสมมติว่าเว็บไซต์มี HTTPS ใช้งานอยู่แล้ว แต่ยังไม่เคยตรวจซ้ำว่าจุดที่สัมผัสข้อมูลผู้ป่วยยังปลอดภัยเท่าที่ควรหรือไม่

อะไรเปลี่ยนไปที่ต้องทบทวนใหม่

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

TLS เวอร์ชันเก่าที่ไม่ควรเหลืออยู่แล้ว

TLS 1.0 และ TLS 1.1 ถูกผู้ผลิตเบราว์เซอร์และหน่วยงานมาตรฐานถอดออกจากรายการที่แนะนำมาหลายปีแล้ว เหลือเพียง TLS 1.2 และ TLS 1.3 ที่ควรใช้งาน ปัญหาคือ Hosting หรือ Server บางตัวของคลินิกขนาดเล็กยังเปิดให้เวอร์ชันเก่าทำงานคู่ขนานไปด้วยเพื่อความเข้ากันได้กับระบบเก่า ซึ่งเป็นช่องโหว่ที่ไม่จำเป็นต้องมีอยู่แล้วในปี 2026 ทีมไอทีควรขอให้ผู้ดูแล Server ปิดเวอร์ชันเก่าและยืนยันด้วยเครื่องมือตรวจสอบ TLS ภายนอกว่าเหลือเฉพาะเวอร์ชันที่แนะนำ

อายุใบรับรองที่สั้นลง กระทบตารางต่ออายุ

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

ทำไมคลินิกและโรงพยาบาลต้องทบทวนเรื่องนี้เป็นพิเศษ

เว็บไซต์ทั่วไปที่ HTTPS หลุดชั่วคราวอาจแค่ทำให้ผู้ใช้เห็นคำเตือนแล้วปิดหนีไป แต่เว็บไซต์สุขภาพต่างออกไป เพราะข้อมูลที่ไหลผ่านฟอร์มนัดหมายมักเป็นชื่อ เบอร์โทร อาการเบื้องต้น หรือแม้แต่ประเภทการรักษาที่ต้องการ ซึ่งเข้าข่ายข้อมูลสุขภาพที่มีความอ่อนไหวสูงกว่าข้อมูลทั่วไป ช่องโหว่ HTTPS/TLS ที่ทำให้ข้อมูลเหล่านี้เดินทางแบบไม่เข้ารหัส หรือเสี่ยงถูกดักฟังระหว่างทาง จึงมีน้ำหนักความเสี่ยงมากกว่าธุรกิจทั่วไปตามหลัก TRUSTY-20 ที่แยกความเสี่ยงข้อมูลอ่อนไหวออกจากความเสี่ยงทางเทคนิคทั่วไป

ฟอร์มนัดหมายและอัปโหลดเอกสารทางการแพทย์

คลินิกจำนวนมากเพิ่มฟอร์มให้ผู้ป่วยอัปโหลดผลตรวจเดิม ใบส่งตัว หรือรูปถ่ายอาการก่อนเข้ารับบริการ ฟอร์มเหล่านี้มักถูกเพิ่มเข้ามาทีหลังโดยทีมการตลาดผ่านปลั๊กอินหรือบริการภายนอก โดยไม่มีใครตรวจซ้ำว่าฟอร์มทำงานอยู่บนหน้าที่เข้ารหัสครบทุกจุดจริงหรือไม่ หากฟอร์มฝังมาจากโดเมนอื่นที่ไม่ได้ใช้ HTTPS หรือมี Mixed Content เกิดขึ้น ข้อมูลที่ผู้ป่วยกรอกอาจเสี่ยงมากกว่าที่ทีมการตลาดคาดคิด

วิดเจ็ตจองคิวและแชทจากผู้ให้บริการภายนอก

ระบบจองคิวออนไลน์ แชทสอบถามอาการเบื้องต้น หรือปุ่มโทรด่วนที่ฝังมาจากผู้ให้บริการภายนอก เป็นจุดที่มักถูกเพิ่มหรือเปลี่ยนผู้ให้บริการระหว่างปีโดยไม่ผ่านการตรวจ HTTPS/TLS ซ้ำ ทีมการตลาดที่สลับผู้ให้บริการแชทจากเจ้าหนึ่งไปอีกเจ้าหนึ่งอาจไม่รู้ว่าสคริปต์ตัวใหม่โหลดทรัพยากรบางส่วนผ่าน HTTP ธรรมดา ซึ่งทำให้เกิด Mixed Content ที่เบราว์เซอร์บล็อกหรือเตือนผู้ใช้โดยไม่มีใครในทีมรู้ตัว

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

จุดที่ควรตรวจซ้ำตอนนี้

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

• ตรวจว่า Server ยังเปิด TLS 1.0 หรือ TLS 1.1 ค้างอยู่หรือไม่ ด้วยเครื่องมือตรวจสอบโปรโตคอลจากภายนอก
• ตรวจวันหมดอายุใบรับรองจริงบน Production ไม่ใช่แค่เชื่อการตั้งเตือนเดิมที่อาจไม่ตรงกับอายุใบรับรองปัจจุบัน
• ไล่ตรวจทุกหน้าที่มีฟอร์มนัดหมายและฟอร์มอัปโหลดเอกสารว่าไม่มี Mixed Content หลงเหลือ
• ตรวจวิดเจ็ตจองคิว แชท และปุ่มติดต่อทุกตัวที่เพิ่มเข้ามาใหม่ในรอบปีที่ผ่านมาว่าโหลดผ่าน HTTPS ทั้งหมด
• ตรวจว่า Header HSTS ยังถูกส่งออกอยู่และไม่ถูกปิดโดยไม่ตั้งใจตอนย้าย Hosting หรือเปลี่ยน CDN

ใครควรเป็นเจ้าของรอบทบทวนนี้ในคลินิก

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

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

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

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

TLS 1.0 กับ 1.1 ยังใช้ได้อยู่ไหมในปี 2026 ไม่แนะนำแล้ว เพราะผู้ผลิตเบราว์เซอร์และหน่วยงานมาตรฐานถอดเวอร์ชันเหล่านี้ออกจากคำแนะนำมาหลายปี ควรเหลือเฉพาะ TLS 1.2 และ TLS 1.3 บน Server ของคลินิก

ทำไมวิดเจ็ตจองคิวจากผู้ให้บริการภายนอกถึงเป็นความเสี่ยง HTTPS เพราะวิดเจ็ตเหล่านี้มักถูกเพิ่มหรือเปลี่ยนผู้ให้บริการโดยทีมการตลาดโดยไม่ผ่านการตรวจของทีมไอที หากสคริปต์บางส่วนโหลดผ่าน HTTP ธรรมดาจะเกิด Mixed Content ที่กระทบข้อมูลผู้ป่วยที่กรอกผ่านวิดเจ็ตนั้นโดยตรง

การตรวจ HTTPS/TLS แบบนี้เท่ากับผ่านการตรวจสอบ PDPA แล้วหรือไม่ ไม่เท่ากัน การตรวจนี้เป็นการตรวจความพร้อมด้านเทคนิคของ HTTPS/TLS เท่านั้น ส่วนความเสี่ยงด้านข้อมูลสุขภาพภายใต้ PDPA ต้องให้ผู้เชี่ยวชาญด้านกฎหมายพิจารณาแยกต่างหาก

เช็กลิสต์ปฏิบัติ

• ตรวจโปรโตคอล TLS ที่ Server เปิดใช้งานจริงด้วยเครื่องมือภายนอกอย่างน้อยปีละครั้ง
• ตรวจวันหมดอายุใบรับรองบน Production จริง ไม่พึ่งความจำหรือปฏิทินเดิม
• ไล่ตรวจฟอร์มนัดหมายและฟอร์มอัปโหลดเอกสารทุกหน้าว่าไม่มี Mixed Content
• ตรวจวิดเจ็ตจองคิว แชท และสคริปต์บุคคลที่สามที่เพิ่มใหม่ในรอบปีล่าสุด
• ยืนยันว่า Header HSTS ยังถูกส่งออกหลังการย้าย Hosting หรือเปลี่ยน CDN ครั้งล่าสุด
• บันทึกวันที่ตรวจและผลตรวจไว้เป็นหลักฐานสำหรับรอบทบทวนถัดไป

ข้อผิดพลาดที่พบบ่อย

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

สรุป

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

แหล่งข้อมูลอ้างอิง

• OWASP HTTP Security Response Headers Cheat Sheet
• คู่มือรวม Website Security ของ trusty
• คู่มือ HTTPS และ TLS สำหรับธุรกิจสุขภาพฉบับเต็ม