วิธีวางระบบ HTTPS และ TLS สำหรับคลินิก โรงพยาบาล และธุรกิจสุขภาพ แบบเป็นขั้นตอน

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

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

ก่อนเริ่ม: ระบุจุดที่เก็บข้อมูลสุขภาพผู้ป่วยบนเว็บไซต์

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

ขั้นตอนที่ 1: ติดตั้งใบรับรอง TLS ให้ครอบคลุมระบบนัดหมายและพอร์ทัลผู้ป่วย

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

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

ขั้นตอนที่ 2: ตรวจฟอร์มรับข้อมูลผู้ป่วยว่าส่งผ่าน HTTPS ตลอดเส้นทาง

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

ขั้นตอนที่ 3: ตั้งค่า HSTS และปิดเส้นทาง HTTP สำหรับโดเมนที่รับข้อมูลสุขภาพ

เปิดใช้งาน HTTP Strict Transport Security สำหรับโดเมนหลักและโดเมนของพอร์ทัลผู้ป่วย เพื่อบังคับให้เบราว์เซอร์เชื่อมต่อผ่าน HTTPS เสมอโดยไม่มีช่วงที่หลุดไปเป็น HTTP แม้เพียงชั่วขณะ สำหรับเว็บไซต์ที่รับข้อมูลอ่อนไหวอย่างข้อมูลสุขภาพ ควรพิจารณาตั้งค่าระยะเวลา HSTS ให้ยาวเพียงพอ และ Redirect ทุกคำขอ HTTP ไป HTTPS ด้วยสถานะ 301 ทุกเส้นทางโดยไม่มีข้อยกเว้น

ขั้นตอนที่ 4: ตรวจวิดเจ็ตนัดหมายและระบบแชทที่ฝังจากผู้ให้บริการภายนอก

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

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

ขั้นตอนที่ 5: เชื่อมโยง HTTPS กับแนวทาง PDPA สำหรับข้อมูลสุขภาพที่เป็นข้อมูลอ่อนไหว

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

ขั้นตอนที่ 6: วางแผนต่ออายุใบรับรองและมอบหมายผู้รับผิดชอบตรวจสอบต่อเนื่อง

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

ทำตารางสรุปวันหมดอายุใบรับรองของทุกระบบที่คลินิกใช้งาน

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

มอบหมายผู้รับผิดชอบตรวจสอบต่อเนื่องแยกจากผู้ดูแลเนื้อหาเว็บไซต์

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

ตรวจซ้ำหลังผู้ให้บริการพอร์ทัลผู้ป่วยปรับปรุงระบบ

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

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

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

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

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

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

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

• ไล่รายการจุดที่เว็บไซต์รับข้อมูลผู้ป่วยทั้งหมดก่อนเริ่มตั้งค่า
• ติดตั้งใบรับรอง TLS ครอบคลุมโดเมนหลักและซับโดเมนของระบบนัดหมาย
• ขอหลักฐานใบรับรองที่ยังไม่หมดอายุจากผู้ให้บริการพอร์ทัลผู้ป่วยภายนอก
• ตรวจฟอร์มนัดหมายว่าอยู่บน HTTPS ตั้งแต่โหลดครั้งแรกจนถึงปลายทางรับข้อมูล
• เปิดใช้งาน HSTS สำหรับโดเมนหลักและโดเมนที่รับข้อมูลสุขภาพ
• Redirect ทุกคำขอ HTTP ไป HTTPS ด้วยสถานะ 301 โดยไม่มีข้อยกเว้น
• ตรวจวิดเจ็ตนัดหมายและระบบแชทถามอาการว่าอ้างอิง https:// ทั้งหมด
• พิจารณามาตรการอื่นควบคู่กับ HTTPS เช่นการจำกัดสิทธิ์เข้าถึงข้อมูลผู้ป่วย

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

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

สรุป

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

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

• OWASP HTTP Security Response Headers Cheat Sheet
• ศูนย์ความรู้ด้านความปลอดภัยเว็บไซต์ของ trusty
• วิธี Audit HTTPS และ TLS ของร้านค้าออนไลน์พร้อม Evidence ที่ควรเก็บ