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

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

เช็กจุดที่ 1: สคริปต์ในระบบนัดหมายและฟอร์มรับข้อมูลสุขภาพ

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

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

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

เช็กจุดที่ 3: ข้อมูลสุขภาพที่เสี่ยงรั่วผ่านสคริปต์ที่ไม่ได้อยู่ในรายการอนุญาต

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

เช็กจุดที่ 4: การประสานงานระหว่างทีมการตลาดกับทีมพัฒนาเว็บก่อนเปิดใช้งานจริง

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

เช็กจุดที่ 5: เอกสารที่ผู้ดูแลข้อมูลควรเก็บไว้หลังเปิดใช้งาน

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

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

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

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

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

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

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

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

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

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

สรุป

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

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

• OWASP HTTP Headers Cheat Sheet
• OWASP Secure Headers Project

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