วิธี Audit HTTPS และ TLS ของคลินิก โรงพยาบาล และธุรกิจสุขภาพ พร้อม Evidence ที่ควรเก็บ

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

ทำไมเว็บไซต์สุขภาพต้องเข้มงวดกับ HTTPS และ TLS มากกว่าเว็บทั่วไป

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

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

ขั้นตอน Audit HTTPS และ TLS แบบทำเองได้

ขั้นที่ 1 ตรวจใบรับรอง (Certificate) ของทุกโดเมนที่เกี่ยวข้อง

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

ขั้นที่ 2 ตรวจโปรโตคอลและ Cipher ที่เซิร์ฟเวอร์ยังเปิดใช้งาน

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

ขั้นที่ 3 ตรวจ Mixed Content บนหน้าฟอร์มนัดหมายและฟอร์มถามอาการ

เปิดหน้าฟอร์มนัดหมายและหน้าฟอร์มถามอาการเบื้องต้นด้วยเครื่องมือนักพัฒนาในเบราว์เซอร์ (Developer Tools) แล้วดูที่แท็บ Console ว่ามีคำเตือน Mixed Content หรือไม่ ปัญหานี้เกิดเมื่อหน้าเว็บโหลดผ่าน HTTPS แต่มีบางองค์ประกอบ เช่น รูปภาพ สคริปต์ หรือ iframe จองคิวจากผู้ให้บริการภายนอก ยังโหลดผ่าน HTTP ธรรมดา ซึ่งเบราว์เซอร์บางตัวจะบล็อกหรือแจ้งเตือนผู้ป่วยทันที และอาจทำให้ผู้ป่วยเลิกกรอกฟอร์มกลางคัน

จุดที่มักหลุดเฉพาะเว็บไซต์สุขภาพ

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

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

การประสานงานระหว่างทีมการตลาดกับผู้ดูแลระบบ

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

ขั้นที่ 4 ตรวจการบังคับเปลี่ยนเส้นทางจาก HTTP ไป HTTPS

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

Evidence ที่ควรเก็บไว้หลังตรวจทุกครั้ง

เก็บภาพหน้าจอของใบรับรองพร้อมวันหมดอายุ ผลสแกนโปรโตคอล/Cipher พร้อมวันที่สแกน และภาพหน้าจอ Console ที่แสดงผล Mixed Content (หรือไม่มี) พร้อมระบุว่าตรวจจากหน้าใดบ้าง เอกสารชุดนี้ไม่ใช่ใบรับรองทางกฎหมาย แต่เป็นหลักฐานภายในที่ทีมสามารถใช้ยืนยันว่าได้ตรวจสอบตามรอบเวลาที่กำหนดจริง หากธุรกิจมีข้อมูลสุขภาพปริมาณมากหรือซับซ้อน ควรให้ผู้เชี่ยวชาญด้านความปลอดภัยตรวจเชิงลึกเพิ่มเติมจากผลสแกนอัตโนมัตินี้ เก็บไฟล์ Evidence แยกตามรอบเวลา เช่น ปีและไตรมาส เพื่อให้ค้นย้อนหลังได้ง่ายเมื่อต้องอธิบายให้ผู้บริหารหรือผู้ตรวจสอบภายในฟัง

ตัวอย่างสถานการณ์ที่พบระหว่างการตรวจจริง

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

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

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

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

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

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

เมื่อไหร่ควรส่งต่อให้ผู้เชี่ยวชาญด้านความปลอดภัยตรวจเพิ่มเติม

ผลสแกน HTTPS/TLS แบบอัตโนมัติที่ทำเองได้ตามขั้นตอนข้างต้นช่วยจับปัญหาพื้นฐานได้ในระดับหนึ่ง เช่น ใบรับรองหมดอายุ โปรโตคอลรุ่นเก่าที่ยังเปิดใช้ หรือ Mixed Content บนหน้าฟอร์ม แต่ผลสแกนแบบนี้ไม่เท่ากับการตรวจเจาะระบบ (Penetration Test) หรือการตรวจโค้ดโดยผู้เชี่ยวชาญ หากคลินิกหรือโรงพยาบาลมีระบบเก็บประวัติผู้ป่วย ระบบชำระเงินค่ารักษาออนไลน์ หรือมีการเชื่อมต่อกับหน่วยงานภายนอกที่รับส่งข้อมูลผู้ป่วยจำนวนมาก ควรให้ทีมความปลอดภัยหรือผู้เชี่ยวชาญภายนอกตรวจเชิงลึกเพิ่มเติมจากผลสแกนพื้นฐานนี้ โดยเฉพาะก่อนเปิดใช้งานฟีเจอร์ใหม่ที่เกี่ยวข้องกับข้อมูลสุขภาพของผู้ป่วยโดยตรง การตรวจภายในทีมเองเหมาะสำหรับติดตามความเรียบร้อยระหว่างรอบ ส่วนการตรวจเชิงลึกเหมาะสำหรับช่วงก่อนเปิดระบบใหม่หรือหลังพบความผิดปกติที่อธิบายไม่ได้ด้วยเครื่องมือพื้นฐาน

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

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

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

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

สรุป

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

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

• OWASP HTTP Security Response Headers Cheat Sheet