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

ฝ่าย Compliance หรือ Security มักได้รับคำถามจากผู้บริหารว่า "เรามี CSP หรือยัง" แต่คำถามที่ควรตอบก่อนคือ Header ที่ใช้งานอยู่จริงตอนนี้ตรงกับสิ่งที่ทีมคิดว่ามีหรือไม่ องค์กรการเงินและประกันจำนวนมากมี Content-Security-Policy อยู่บ้างแล้ว บางโดเมนมาจากทีมพัฒนาเดิมที่ลาออกไป บางโดเมนมาจาก CDN หรือ WAF ที่ตั้งค่าไว้โดยไม่มีเอกสารประกอบ การ Audit จึงเริ่มจากการตรวจสภาพจริง ไม่ใช่การออกแบบใหม่ บทความนี้เขียนสำหรับฝ่าย Compliance ฝ่าย Security และทีมกฎหมายภายในที่ต้องรายงานสถานะนี้ต่อผู้บริหารหรือผู้ตรวจสอบภายนอก โดยเน้นกระบวนการตรวจสอบและการเก็บหลักฐาน มากกว่าการสอนเขียน Directive ตั้งแต่ศูนย์

เริ่มตรวจที่ไหนก่อน: สำรวจว่าองค์กรมี Header อยู่บนโดเมนไหนบ้าง

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

เทียบค่า Header ที่ใช้งานจริงกับนโยบายที่บันทึกไว้

เมื่อพบว่าโดเมนไหนมี Header อยู่แล้ว ขั้นต่อไปคือดึงค่า Directive จริงออกมาทั้งหมดแล้ววางเทียบกับเอกสารนโยบายที่เคยผ่านการอนุมัติ หลายองค์กรพบช่องว่างสามแบบซ้ำ ๆ กันคือ นโยบายที่บันทึกไว้เก่ากว่าค่าที่ใช้งานจริงเพราะมีคนแก้โดยไม่ได้อัปเดตเอกสาร นโยบายกว้างกว่าที่จำเป็นเพราะเคยเปิดกว้างไว้ตอนแก้ปัญหาเฉพาะหน้าแล้วไม่มีใครปิดกลับ และมี Directive สำคัญบางตัวหายไปเงียบ ๆ เช่น object-src หรือ base-uri ที่ไม่มีใครตั้งใจถอดออกแต่หายไปหลัง Deploy ครั้งหนึ่ง การ Audit ที่ดีจึงต้องบันทึกทั้งค่าที่ควรเป็นและค่าที่เป็นจริง ไม่ใช่เชื่อเอกสารอย่างเดียว ควรทำรายการ Directive ต่อโดเมนในรูปแบบตารางง่าย ๆ ที่มีคอลัมน์ค่าที่บันทึกไว้ ค่าที่ตรวจพบจริง และผลต่างที่พบ เพื่อให้ทีมกฎหมายและทีมเทคนิคอ่านผลเดียวกันได้โดยไม่ต้องตีความเอง

ตรวจว่าใครมีสิทธิ์แก้ Header จริง และแก้ผ่านช่องทางไหน

ในองค์กรที่มีความเสี่ยงสูง คำถามด้าน Governance สำคัญพอ ๆ กับคำถามด้านเทคนิค เพราะ Header อาจถูกกำหนดได้จากหลายจุด เช่น โค้ดในแอปพลิเคชัน การตั้งค่าใน Reverse Proxy การตั้งค่าใน CDN หรือกฎใน WAF การ Audit ต้องระบุให้ชัดว่าค่าที่เห็นจริงมาจากจุดไหน เพราะถ้าไม่รู้ว่าแก้ที่ไหนได้บ้าง ทีมอาจแก้โค้ดในแอปแต่ค่าที่ผู้ใช้เห็นจริงมาจาก CDN ที่ Override ทับอยู่โดยไม่มีใครทราบ นอกจากนี้ต้องตรวจว่าใครมีสิทธิ์ Access เข้าไปแก้ค่าเหล่านี้ได้บ้าง และการแก้แต่ละครั้งผ่านกระบวนการอนุมัติเดียวกับการเปลี่ยนแปลงระบบอื่นหรือไม่ องค์กรจำนวนมากพบว่า CDN Console เข้าถึงได้จากหลายคนโดยไม่มีการอนุมัติเป็นลายลักษณ์อักษร ซึ่งเป็นช่องว่างที่ฝ่าย Compliance ควรบันทึกไว้เป็น Finding

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

เก็บ Evidence อะไรบ้างสำหรับรอบตรวจสอบ

เมื่อการ Audit เสร็จ ฝ่าย Compliance หรือผู้ตรวจสอบภายในมักถามหาหลักฐานที่จับต้องได้ ไม่ใช่แค่คำยืนยันด้วยปาก รายการ Evidence ที่ควรเตรียมไว้มีดังนี้

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

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

ตัวอย่างโครงสร้างตาราง Evidence ที่ใช้งานได้จริง

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

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

ตรวจสัญญาผู้ให้บริการว่าพูดถึง Header Policy หรือไม่

องค์กรการเงินและประกันมักพึ่งพา CDN ผู้ให้บริการ Hosting และผู้ให้บริการ Widget บุคคลที่สาม เช่น ระบบแชทหรือระบบยืนยันตัวตน การ Audit ควรตรวจว่าสัญญากับผู้ให้บริการเหล่านี้พูดถึงเรื่อง Security Header หรือ Content Security Policy หรือไม่ ในกรณีที่ผู้ให้บริการเป็นคนควบคุม Layer ที่ Header ถูกกำหนด เช่น CDN เป็นคนใส่ Header ให้ องค์กรควรมีข้อตกลงชัดเจนว่าใครมีสิทธิ์เปลี่ยนค่านี้ และแจ้งใครก่อนเปลี่ยน จุดนี้ไม่ใช่การเขียนข้อกฎหมายหรือมาตรฐานใหม่ แต่เป็นการตรวจว่าเอกสารที่มีอยู่แล้วครอบคลุมความรับผิดชอบเรื่องนี้หรือยัง

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

รายการ Directive ที่ควรตรวจซ้ำสามารถเทียบกับ เช็กลิสต์ CSP สำหรับองค์กรการเงินและประกัน เพื่อไม่ให้ตกหล่นจุดที่ฝ่าย Compliance มักถาม

อ่านผล Report-Only เพื่อประเมินความเสี่ยงก่อนเปลี่ยนเป็น Enforce

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

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

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

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

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

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

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

Audit แบบนี้เทียบเท่ากับ Security Audit หรือ Penetration Test หรือไม่ ไม่เทียบเท่า การตรวจ CSP เป็นการตรวจ Header ด้าน Security Hygiene ส่วนหนึ่งเท่านั้น ไม่ครอบคลุมช่องโหว่ระดับโค้ดหรือการทดสอบเจาะระบบ องค์กรที่ต้องการความมั่นใจระดับนั้นควรให้ผู้เชี่ยวชาญด้าน Security ตรวจแยกต่างหาก

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

• ทำรายการโดเมนและซับโดเมนทั้งหมดในขอบเขตองค์กร พร้อมเจ้าของแต่ละโดเมน
• ดึงค่า Header จริงจากทุกโดเมนแล้วเทียบกับเอกสารนโยบายที่อนุมัติล่าสุด
• ระบุว่า Header แต่ละโดเมนถูกกำหนดจากแอป, Reverse Proxy, CDN หรือ WAF
• ตรวจสิทธิ์การเข้าถึงและกระบวนการอนุมัติก่อนแก้ไข Header
• รวบรวมรายงาน Violation จากโหมด Report-Only ก่อนเปลี่ยนเป็น Enforce
• ตรวจสัญญาผู้ให้บริการ CDN และ Widget บุคคลที่สามว่าพูดถึง Header Policy หรือไม่
• สรุป Finding เป็นลำดับความเสี่ยงพร้อมเจ้าของงานแก้ไขและกรอบเวลา

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

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

สรุป

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

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

• OWASP HTTP Headers Cheat Sheet
• OWASP Secure Headers Project