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

เว็บคลินิกทั่วไปมักฝังวิดเจ็ตนัดหมายจากผู้ให้บริการภายนอกไว้ที่หน้าแรก และฝังฟอร์มกรอกประวัติสุขภาพเบื้องต้นไว้ก่อนเข้าพบแพทย์ ทั้งสองจุดนี้โหลดสคริปต์จากโดเมนที่ทีมการตลาดอาจไม่เคยตรวจสอบเลยว่ามีอะไรทำงานอยู่บ้าง Content Security Policy (CSP) คือ HTTP Response Header ที่บอกเบราว์เซอร์ว่าอนุญาตให้โหลดสคริปต์ สไตล์ หรือฝัง iframe จากโดเมนใดได้บ้าง เพื่อลดโอกาสที่สคริปต์แปลกปลอมจะแทรกตัวเข้ามาบนหน้าที่กำลังรับข้อมูลผู้ป่วยอยู่

ทำไมธุรกิจสุขภาพต้องให้น้ำหนักกับ CSP มากกว่าเว็บทั่วไป

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

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

สำรวจสคริปต์ที่ระบบนัดหมายและฟอร์มสุขภาพของคุณใช้งานจริง

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

ระบบนัดหมายหรือจองคิวออนไลน์

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

ฟอร์มประวัติสุขภาพจากผู้ให้บริการภายนอก

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

พิกเซลการตลาดและวิดเจ็ตแชท

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

ขั้นตอนวางนโยบาย CSP ทีละขั้น

ขั้นที่ 1 เริ่มด้วย Content-Security-Policy-Report-Only

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

ขั้นที่ 2 กำหนด script-src และ frame-src ตามโดเมนที่สำรวจไว้

นำรายชื่อโดเมนจากขั้นตอนสำรวจมาใส่ใน directive script-src สำหรับสคริปต์ และ frame-src สำหรับ iframe ของฟอร์มสุขภาพหรือระบบนัดหมาย หลีกเลี่ยงการใช้ค่ากว้างเกินไปแบบอนุญาตทุกโดเมนเพราะทำให้ CSP แทบไม่มีความหมาย

ขั้นที่ 3 ทดสอบบนหน้าที่มีข้อมูลผู้ป่วยก่อนเปิดใช้จริง

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

ขั้นที่ 4 เปลี่ยนจาก Report-Only เป็นบังคับใช้จริง

เมื่อรายการ Violation ในโหมด Report-Only นิ่งแล้วและไม่มีสิ่งจำเป็นถูกบล็อก จึงเปลี่ยน Header เป็น Content-Security-Policy แบบบังคับใช้จริง แล้วเฝ้าดูอีกรอบหลังเปิดใช้งานจริงเพื่อจับปัญหาที่อาจหลุดจากการทดสอบ

ทีมการตลาดกับทีมพัฒนาเว็บไซต์ต้องคุยกันเรื่องอะไรบ้าง

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

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

Directive อื่นที่มักถูกมองข้ามนอกเหนือจาก script-src และ frame-src

ทีมพัฒนาส่วนใหญ่โฟกัสที่ script-src และ frame-src เป็นอันดับแรกเพราะกระทบการทำงานของหน้าเว็บชัดเจนที่สุด แต่เว็บธุรกิจสุขภาพยังมี directive อื่นที่ควรตั้งค่าให้ครบ เพื่อไม่ให้เหลือช่องโหว่ที่ยังไม่ถูกปิด

connect-src สำหรับการเชื่อมต่อ API และวิดีโอปรึกษาแพทย์ทางไกล

คลินิกที่มีบริการปรึกษาแพทย์ผ่านวิดีโอคอลมักใช้บริการ WebRTC หรือ API เชื่อมต่อภายนอกที่ทำงานผ่าน fetch หรือ XHR ไม่ใช่ผ่านสคริปต์แบบปกติ หากไม่กำหนด connect-src ให้ครอบคลุมโดเมนของบริการวิดีโอคอลเหล่านี้ ระบบปรึกษาแพทย์ทางไกลอาจเชื่อมต่อไม่ได้ทันทีที่เปิดใช้ CSP บังคับใช้จริง ควรทดสอบฟีเจอร์นี้แยกต่างหากในโหมด Report-Only เพราะการเชื่อมต่อ API มักไม่แสดงอาการผิดพลาดชัดเจนบนหน้าจอเท่ากับสคริปต์ที่โหลดไม่ขึ้น

img-src สำหรับรูปถ่ายและเอกสารที่คนไข้อัปโหลด

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

form-action สำหรับหน้ายืนยันการนัดหมายและชำระเงินมัดจำ

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

style-src และผลกระทบต่อวิดเจ็ตที่ฉีด CSS แบบ inline

วิดเจ็ตนัดหมายหรือฟอร์มสุขภาพบางตัวใช้วิธีฉีด CSS แบบ inline เข้ามาโดยตรงเพื่อจัดสไตล์ให้เข้ากับธีมของเว็บไซต์ หากตั้งค่า style-src แบบเข้มงวดโดยไม่อนุญาต unsafe-inline หรือไม่ใช้ nonce ที่เหมาะสม วิดเจ็ตอาจแสดงผลแบบไม่มีสไตล์เลย ซึ่งดูเผินๆ อาจไม่เหมือนถูกบล็อก แต่จริงๆ แล้วเป็นผลจาก CSP เช่นกัน ทีมพัฒนาจึงควรตรวจสอบทั้งการทำงานของฟังก์ชันและหน้าตาของวิดเจ็ตหลังเปิดใช้ CSP ไม่ใช่แค่ตรวจว่าโหลดสำเร็จหรือไม่

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

CSP ทำให้เว็บคลินิกช้าลงหรือไม่ โดยทั่วไป CSP เป็นเพียง Header ที่เบราว์เซอร์อ่านก่อนโหลดทรัพยากร ไม่ได้เพิ่มภาระการประมวลผลที่มีนัยสำคัญ ผลกระทบด้านความเร็วที่พบบ่อยกว่ามาจากการปรับ Whitelist ผิดจนต้องโหลดซ้ำ ไม่ใช่จาก CSP เอง

ถ้าเปิด CSP แล้วระบบนัดหมายพัง ต้องทำอย่างไร ให้กลับไปโหมด Report-Only ทันทีเพื่อไม่ให้คนไข้ใช้งานหน้านัดหมายไม่ได้ แล้วตรวจดูรายการที่ถูกบล็อกจาก Console เพื่อหาโดเมนที่ตกหล่นก่อนเปิดใช้จริงอีกครั้ง

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

• สำรวจโดเมนสคริปต์ทั้งหมดของระบบนัดหมาย ฟอร์มสุขภาพ และวิดเจ็ตแชทก่อนเริ่มตั้งค่า CSP
• เริ่มด้วย Content-Security-Policy-Report-Only เสมอ ไม่บังคับใช้จริงทันที
• ทดสอบหน้านัดหมายและหน้าฟอร์มสุขภาพในโหมด Report-Only อย่างน้อยหลายวันก่อนเปลี่ยนโหมด
• ให้ทีมการตลาดส่งรายชื่อเครื่องมือใหม่ทุกครั้งก่อนติดตั้งจริงบนเว็บ
• ทบทวนรายการ Violation หลังเปลี่ยนเป็นบังคับใช้จริงอย่างน้อยหนึ่งสัปดาห์แรก
• เก็บรายชื่อโดเมนที่อนุญาตไว้เป็นเอกสารกลาง ไม่ใช่ความจำของทีมพัฒนาคนเดียว

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

• เปิดใช้ CSP แบบบังคับใช้จริงทันทีโดยไม่ผ่านโหมด Report-Only ก่อน ทำให้ระบบนัดหมายใช้งานไม่ได้กะทันหัน
• ทีมการตลาดติดตั้งพิกเซลหรือวิดเจ็ตใหม่โดยไม่แจ้งทีมพัฒนา ทำให้เครื่องมือถูกบล็อกโดยไม่รู้ตัว
• ตั้งค่า script-src แบบกว้างเกินไปจนเปิดช่องให้โดเมนที่ไม่จำเป็นโหลดสคริปต์ได้
• ลืมทบทวน CSP หลังผู้ให้บริการระบบนัดหมายเปลี่ยนโดเมนสคริปต์ที่ใช้งาน
• ไม่แยกความสำคัญของหน้าที่มีข้อมูลผู้ป่วยออกจากหน้าเว็บทั่วไป ทำให้การทดสอบไม่ครอบคลุมจุดเสี่ยงจริง

สรุป

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

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

• OWASP HTTP Headers Cheat Sheet
• เช็กลิสต์ CSP สำหรับธุรกิจสุขภาพ
• ศูนย์ความรู้ Website Security ของ trusty