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

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

เริ่มตรวจที่หน้าไหนก่อน: จุดที่ข้อมูลสุขภาพไหลผ่านมากที่สุด

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

ตรวจว่า Header CSP ที่ใช้งานจริงตรงกับที่ตั้งใจไว้หรือไม่

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

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

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

ตรวจว่าใครแก้ Header ได้บ้าง และแก้ผ่านช่องทางไหน

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

อ่านรายงานจากโหมด Report-Only เพื่อประเมินความเสี่ยงก่อนบังคับใช้จริง

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

เก็บ Evidence อะไรบ้างสำหรับรอบตรวจสอบข้อมูลสุขภาพ

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

จัดลำดับความเสี่ยงที่พบและมอบหมายผู้รับผิดชอบแก้ไข

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

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

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

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

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

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

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

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

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

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

สรุป

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

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

• OWASP HTTP Headers Cheat Sheet
• OWASP Secure Headers Project

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