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

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

บทความนี้เป็นขั้นตอนวางระบบ HTTP Security Headers สำหรับคลินิก โรงพยาบาล และธุรกิจสุขภาพ ทีละ Header พร้อมจุดที่ต้องระวังเป็นพิเศษเมื่อเว็บไซต์มีหน้านัดหมายหรือฟอร์มกรอกข้อมูลสุขภาพจากบุคคลภายนอกฝังอยู่

ทำไมช่องโหว่ Header เล็ก ๆ ถึงกระทบข้อมูลสุขภาพ

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

Header ที่ต้องตั้งค่าและวิธีตั้งทีละตัว

เริ่มจาก Strict-Transport-Security ซึ่งบังคับให้เบราว์เซอร์เชื่อมต่อผ่าน HTTPS เท่านั้นในครั้งถัดไป ตั้งค่าตัวอย่างเช่น max-age=31536000; includeSubDomains เพื่อให้ครอบคลุม Subdomain ที่อาจใช้แยกระบบนัดหมายออกจากเว็บไซต์หลัก ต่อมาคือ X-Content-Type-Options ตั้งค่าเป็น nosniff เพื่อป้องกันเบราว์เซอร์เดาประเภทไฟล์ผิดจนเปิดช่องให้ไฟล์แปลกปลอมทำงานเป็นสคริปต์

Header ถัดมาคือการป้องกันการฝังหน้าเว็บในเฟรมของเว็บอื่นโดยไม่ได้รับอนุญาต ทำได้ผ่าน X-Frame-Options หรือ directive frame-ancestors ใน Content-Security-Policy เช่น frame-ancestors 'self' เพื่อป้องกันหน้าฟอร์มนัดหมายถูกนำไปฝังในเว็บอื่นแล้วหลอกให้ผู้ป่วยกรอกข้อมูลโดยไม่รู้ตัวว่าอยู่บนเว็บปลอม ส่วน Referrer-Policy แนะนำให้ตั้งเป็น strict-origin-when-cross-origin เพื่อลดการรั่วไหลของ URL ที่อาจมีคำค้นหาหรือพารามิเตอร์เกี่ยวกับอาการป่วยติดไปกับ Referrer เวลาผู้ป่วยคลิกออกไปยัง Widget จองคิวของบุคคลภายนอก และ Permissions-Policy ควรจำกัดสิทธิ์การใช้กล้องหรือไมโครโฟนเฉพาะหน้าที่ใช้งานจริง เช่นหน้าปรึกษาแพทย์ทางไกล ไม่เปิดให้ทุกหน้าของเว็บไซต์เรียกใช้ได้โดยไม่จำเป็น

การฝัง Widget จองคิวและฟอร์มสุขภาพจากบุคคลภายนอกอย่างปลอดภัย

ก่อนฝัง Widget จองคิวหรือฟอร์มกรอกข้อมูลสุขภาพจากผู้ให้บริการภายนอก ควรตรวจสอบก่อนว่าโดเมนของผู้ให้บริการนั้นใช้ HTTPS จริง แล้วเพิ่มโดเมนนั้นลงใน frame-src หรือ connect-src ของ Content Security Policy ให้ตรงกับที่ใช้งานจริงเท่านั้น ไม่ใช้เครื่องหมาย wildcard ครอบคลุมทั้งโดเมนเพื่อความสะดวก และควรมีช่องทางติดต่อฝ่ายเทคนิคของผู้ให้บริการแต่ละรายไว้ เพื่อให้แจ้งได้ทันทีเมื่อพบปัญหาการเชื่อมต่อ หรือเมื่อเปลี่ยนไปใช้ผู้ให้บริการรายใหม่จะได้ปิดการเชื่อมต่อของรายเก่าออกจาก Allowlist ให้ครบ ไม่ปล่อยค้างไว้เหมือนกรณีตัวอย่างข้างต้น

การประสานงานระหว่างทีมการตลาดกับทีมพัฒนา

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

การทดสอบก่อนและหลังตั้งค่า

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

การจัดการเมื่อเปลี่ยนผู้ให้บริการ Widget

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

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

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

• ตรวจสอบว่าหน้าแบบฟอร์มนัดหมายและหน้ากรอกข้อมูลสุขภาพทุกหน้ามี Header ครบ ไม่ใช่แค่หน้าแรก
• ตั้งค่า Strict-Transport-Security ให้ครอบคลุม Subdomain ที่ใช้งานจริงทั้งหมด รวมถึงระบบนัดหมายแยก
• ตรวจสอบ frame-ancestors หรือ X-Frame-Options ว่าไม่มีใครฝังหน้าฟอร์มของคลินิกในเว็บอื่นได้โดยไม่ได้รับอนุญาต
• ทดสอบว่า Widget จองคิวและฟอร์มสุขภาพจากบุคคลภายนอกยังทำงานได้หลังเปิดใช้ Header ทุกครั้งที่แก้ไข
• ทำรายชื่อ Vendor ที่มี Script หรือ iframe ฝังอยู่ในหน้าเว็บ พร้อมผู้ติดต่อฝ่ายเทคนิคของแต่ละราย
• แจ้งทีมการตลาดให้แจ้งทีมพัฒนาก่อนติดตั้ง Widget หรือ Chat ใหม่ทุกครั้ง ไม่ใช่หลังขึ้นระบบแล้ว

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

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

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

HTTP Security Headers เกี่ยวข้องกับ PDPA ของข้อมูลสุขภาพอย่างไร Header เป็นมาตรการเชิงเทคนิคที่ช่วยลดความเสี่ยงให้ Script แปลกปลอมเข้าถึงหน้าที่มีการรับข้อมูลสุขภาพ ซึ่งเป็นข้อมูลอ่อนไหวตาม PDPA แต่ไม่ใช่มาตรการเดียวที่ต้องทำ ยังต้องพิจารณาเรื่องความยินยอมและการจัดการข้อมูลควบคู่กันไป ดูภาพรวมความปลอดภัยได้ที่ คู่มือ Website Security ทั้งหมดของ trusty

ต้องตั้งค่า Header กี่ตัวถึงจะเพียงพอสำหรับคลินิก ชุดพื้นฐานที่ควรมีคือ Strict-Transport-Security, X-Content-Type-Options, frame-ancestors หรือ X-Frame-Options, Referrer-Policy และ Permissions-Policy โดยต้องครอบคลุมทุกหน้าที่มีการรับข้อมูลผู้ป่วย ไม่ใช่แค่หน้าแรก

Widget จองคิวจากภายนอกต้องขออนุญาตอะไรก่อนฝัง ควรตรวจสอบว่าผู้ให้บริการใช้ HTTPS จริง แล้วแจ้งทีมพัฒนาให้เพิ่มโดเมนนั้นลง Allowlist ของ Content Security Policy ก่อนขึ้นใช้งานจริง พร้อมมีช่องทางติดต่อฝ่ายเทคนิคของผู้ให้บริการไว้เผื่อเกิดปัญหา

ทีมการตลาดที่ไม่ใช่สายเทคนิคต้องรู้อะไรบ้าง ไม่จำเป็นต้องตั้งค่า Header เอง แต่ควรรู้ว่าเครื่องมือใหม่ที่จะติดตั้งเรียกใช้โดเมนอะไรบ้าง แล้วแจ้งทีมพัฒนาก่อนขึ้นใช้งานจริงเสมอ ดูขั้นตอนตั้งค่าโดยละเอียดที่ คู่มือ HTTP Security Headers ฉบับเต็ม

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

การมอบหมายผู้รับผิดชอบภายในคลินิกขนาดเล็ก

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

สรุป

การวางระบบ HTTP Security Headers สำหรับธุรกิจสุขภาพต้องเริ่มจากหน้าที่รับข้อมูลผู้ป่วยจริง ไม่ใช่แค่หน้าแรก ตั้งค่า Header ทีละตัวให้ตรงกับ Widget และฟอร์มที่ใช้งานจริง ทดสอบผ่าน Report-Only Mode ก่อนเปิดใช้จริงเสมอ และวางขั้นตอนให้ทีมการตลาดแจ้งทีมพัฒนาก่อนติดตั้งเครื่องมือใหม่ทุกครั้ง เพื่อลดช่องโหว่ที่อาจกระทบข้อมูลสุขภาพของผู้ป่วย

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

• OWASP HTTP Headers Cheat Sheet
• OWASP Secure Headers Project