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

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

ทำไม Header ถึงสำคัญกับข้อมูลสุขภาพมากกว่าเว็บทั่วไป

ข้อมูลสุขภาพจัดเป็นข้อมูลอ่อนไหวตามหลัก PDPA ความเสี่ยงด้าน Header จึงไม่ใช่แค่เรื่องความปลอดภัยทางเทคนิค แต่ซ้อนทับกับความเสี่ยงด้านข้อมูลส่วนบุคคลอ่อนไหว หากหน้าฟอร์มนัดหมายที่มีชื่อ เบอร์โทร อาการเบื้องต้น ถูกฝัง (Frame) โดยเว็บอื่นได้เพราะไม่มี X-Frame-Options หรือ frame-ancestors ความเสี่ยงจาก Clickjacking จะกระทบข้อมูลที่อ่อนไหวกว่าฟอร์มสมัครสมาชิกทั่วไป ทีมการตลาดและทีมดูแลข้อมูลจึงควรมองเรื่องนี้เป็นความเสี่ยงร่วม ไม่ใช่งานของฝ่าย IT ฝ่ายเดียว

ขั้นตอน Audit ทีละหน้า

1. ทำรายการหน้าที่ต้องตรวจ

เริ่มจากลิสต์หน้าที่รับหรือแสดงข้อมูลคนไข้: หน้าแรก, หน้านัดหมาย/จองคิว, หน้าฟอร์มประวัติ/อาการเบื้องต้น, หน้าแชทหรือ Live Chat, หน้าผลตรวจ/พอร์ทัลคนไข้ (ถ้ามี) แต่ละหน้าอาจมาจากระบบคนละตัว เช่น เว็บหลักใช้ WordPress แต่ระบบจองคิวเป็น Widget จากผู้ให้บริการภายนอกที่ฝัง iframe เข้ามา ต้องตรวจแยกทีละโดเมนที่เกี่ยวข้อง

2. ตรวจ Response Header จริง ไม่ใช่จากเอกสาร

ใช้เครื่องมือตรวจ Header ของเบราว์เซอร์ (Network tab) หรือคำสั่ง curl แบบ curl -I https://โดเมนของคลินิก เพื่อดู Response Header จริงที่เซิร์ฟเวอร์ส่งกลับ อย่าเชื่อว่า Header ถูกตั้งค่าไว้แล้วเพียงเพราะเคยสั่งให้ผู้พัฒนาเว็บทำ เพราะการอัปเดตปลั๊กอิน เปลี่ยน Hosting หรือเปลี่ยนผู้ให้บริการ Widget อาจทำให้ค่าที่เคยตั้งหายไปโดยไม่มีใครแจ้ง

3. เทียบกับรายการ Header หลักที่ควรมี

รายการที่ควรตรวจตาม OWASP Secure Headers ได้แก่ Strict-Transport-Security (บังคับ HTTPS), X-Content-Type-Options: nosniff (กัน MIME sniffing), X-Frame-Options หรือ Content-Security-Policy แบบมี frame-ancestors (กัน Clickjacking บนหน้าฟอร์มนัดหมาย), Referrer-Policy (ควบคุมข้อมูลที่รั่วผ่าน Referrer เวลาคนไข้คลิกออกไปหน้าอื่น) และ Permissions-Policy (จำกัดสิทธิ์กล้อง/ไมค์ที่ Widget แชทอาจขอโดยไม่จำเป็น)

4. ตรวจ Widget และฟอร์มจากผู้ให้บริการภายนอกแยกต่างหาก

Widget จองคิวหรือฟอร์มประวัติที่ฝังจากโดเมนอื่นมี Header เป็นของตัวเอง ไม่ได้สืบทอดจากเว็บหลัก ต้องตรวจ Header ของโดเมนนั้นด้วย และตรวจว่า Content-Security-Policy ของเว็บหลักอนุญาต (allow-list) ให้โหลด Widget นั้นอย่างถูกต้องหรือไม่ ถ้า CSP เข้มเกินไปแบบไม่ทดสอบก่อน อาจทำให้ Widget จองคิวใช้งานไม่ได้ ซึ่งกระทบธุรกิจโดยตรง

วิธีเก็บ Evidence ให้ตรวจสอบย้อนหลังได้

เก็บภาพหน้าจอ Response Header พร้อมวันที่ตรวจ, บันทึกผล curl เป็นไฟล์ text, และทำตารางสรุปว่าแต่ละหน้ามี Header อะไรอยู่/ขาดอะไร พร้อมช่อง “ผู้รับผิดชอบแก้ไข” เพื่อให้ทีมการตลาดที่ดูแล Widget กับทีม IT ที่ดูแล Hosting คุยกันได้บนข้อมูลชุดเดียวกัน แนะนำให้ตั้งรอบตรวจซ้ำอย่างน้อยทุกไตรมาส หรือทุกครั้งที่เปลี่ยนผู้ให้บริการ Widget ใหม่

ใครควรเป็นเจ้าของงานนี้ในองค์กร

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

ตัวอย่างสถานการณ์ที่พบบ่อยในธุรกิจสุขภาพ

กรณีที่พบบ่อยคือคลินิกใช้ระบบจองคิวจากผู้ให้บริการ SaaS ภายนอก ฝังเป็น iframe บนหน้าเว็บหลัก แล้วต่อมาเปลี่ยนไปใช้ผู้ให้บริการรายใหม่เพราะราคาถูกกว่าหรือมีฟีเจอร์ตรงความต้องการมากกว่า ทีมการตลาดที่ตัดสินใจเปลี่ยนมักโฟกัสที่ฟีเจอร์และราคา โดยไม่ได้ตรวจว่าโดเมนของผู้ให้บริการรายใหม่มี Header ครบเท่ากับรายเดิมหรือไม่ และไม่ได้ตรวจว่า Content-Security-Policy ของเว็บหลักอนุญาตให้โหลด iframe จากโดเมนใหม่แล้วหรือยัง ผลคือระบบจองคิวใหม่อาจใช้งานไม่ได้ทันทีหลังเปลี่ยน หรือใช้งานได้แต่ Header ของหน้านั้นขาดหายไปโดยไม่มีใครรู้จนกว่าจะมีการ Audit รอบถัดไป อีกกรณีหนึ่งคือการเพิ่มฟอร์มยินยอมออนไลน์ (Consent Form) สำหรับเก็บประวัติเบื้องต้นก่อนนัดหมาย ซึ่งมักถูกเพิ่มโดยทีมการตลาดที่ต้องการเก็บข้อมูลลูกค้าเพื่อทำ Remarketing โดยไม่ได้ปรึกษาทีมเทคนิคว่าฟอร์มนี้ควรอยู่ภายใต้นโยบาย Header เดียวกับหน้าอื่นในเว็บหรือไม่

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

Header อย่างเดียวเพียงพอต่อการปกป้องข้อมูลคนไข้หรือไม่

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

ใครควรเป็นผู้รับผิดชอบตรวจ Header ของ Widget จองคิว

ควรกำหนดร่วมกันระหว่างทีม IT/Hosting ที่ดูแลเว็บหลักกับทีมการตลาดที่เลือกและติดตั้ง Widget เพราะแต่ละฝ่ายเห็นข้อมูลคนละส่วน

ต้องตรวจ Header บ่อยแค่ไหน

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

ถ้า Widget จากผู้ให้บริการภายนอกไม่มี Header ที่ถูกต้อง คลินิกต้องรับผิดชอบหรือไม่

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

เครื่องมือที่ช่วยให้ Audit เร็วขึ้นเมื่อคลินิกมีหลายหน้าที่ต้องตรวจ

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

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

ตัวอย่างรายงาน Audit ที่ส่งมอบให้ผู้บริหารคลินิกอ่านเข้าใจได้

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

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

ความถี่ของการ Audit ที่เหมาะกับขนาดคลินิก

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

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

เมื่อผลตรวจต่างกันระหว่างโดเมนหลักกับ Subdomain แผนก

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

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

• ทำรายการหน้าเว็บและ Widget ทั้งหมดที่รับหรือแสดงข้อมูลคนไข้
• ตรวจ Response Header จริงด้วย Network tab หรือ curl ทุกหน้าในรายการ
• เทียบผลกับรายการ Header หลัก 5 ตัวตาม OWASP Secure Headers
• ตรวจ Header ของ Widget จองคิว/ฟอร์มจากผู้ให้บริการภายนอกแยกจากเว็บหลัก
• บันทึก Evidence เป็นภาพหน้าจอและไฟล์ผลตรวจพร้อมวันที่
• กำหนดผู้รับผิดชอบแก้ไขแต่ละรายการที่ขาดหรือผิดพลาด
• ตั้งรอบตรวจซ้ำทุกไตรมาสและทุกครั้งที่เปลี่ยนผู้ให้บริการ Widget

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

• ตรวจแค่หน้าแรกของเว็บ แล้วสรุปว่าทั้งเว็บปลอดภัยโดยไม่ได้ตรวจหน้านัดหมายหรือฟอร์มประวัติ
• เชื่อเอกสารเก่าว่าตั้งค่า Header แล้ว โดยไม่ตรวจ Response Header จริงหลังมีการอัปเดตระบบ
• ตั้ง Content-Security-Policy เข้มจนบล็อก Widget จองคิวโดยไม่ทดสอบก่อนใช้งานจริง
• ไม่มีใครรับผิดชอบชัดเจนระหว่างทีมการตลาดที่ดูแล Widget กับทีม IT ที่ดูแล Hosting

สรุป

การ Audit HTTP Security Headers ของธุรกิจสุขภาพต้องครอบคลุมทุกจุดที่รับข้อมูลคนไข้ ไม่ใช่แค่หน้าแรก และต้องตรวจ Widget จากผู้ให้บริการภายนอกแยกต่างหาก การเก็บ Evidence อย่างสม่ำเสมอช่วยให้ทีมการตลาดและทีมดูแลข้อมูลประสานงานแก้ไขได้ตรงจุด แต่ไม่ได้ทำให้ข้อมูลคนไข้ปลอดภัยจากทุกภัยคุกคามในตัวมันเอง

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

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