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

องค์กรการเงิน ประกัน หรือธุรกิจที่มีความเสี่ยงสูงส่วนใหญ่ตั้งค่า HTTPS และใบรับรองไว้เรียบร้อยแล้ว แต่ HTTP Security Header ชุดที่เหลือ ได้แก่ Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy และ Permissions-Policy มักถูกข้ามไปเพราะไม่มีผู้รับผิดชอบชัดเจนในองค์กร

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

Header ห้าตัวที่ต้องอยู่ในเช็กลิสต์ก่อนอนุมัติ

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

ใครควรเป็นเจ้าของนโยบาย Header เมื่อองค์กรมีหลายแบรนด์หลายโดเมน

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

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

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

เช็กลิสต์ก่อนเปิดใช้งานจริงบน Production

การเปิดใช้งาน Header บนระบบที่มีธุรกรรมทางการเงินจริงต้องผ่านการควบคุมการเปลี่ยนแปลง ไม่ใช่แก้ค่าตรงบนเซิร์ฟเวอร์ Production ทันที

ก่อนอนุมัติ ผู้ตรวจสอบควรถามว่าเคยทดสอบค่าเหล่านี้บนสภาพแวดล้อม Staging แล้วหรือยัง โดยเฉพาะ Strict-Transport-Security ที่หากตั้งค่า max-age ยาวแล้วมีปัญหาภายหลัง การย้อนกลับต้องรอจนหมดอายุ และ X-Frame-Options ที่อาจกระทบ Widget หรือระบบภายในที่ฝังหน้าเว็บไว้ในหน้าจออื่น

ทุกการเปลี่ยนแปลงควรมี Ticket อ้างอิงในระบบควบคุมการเปลี่ยนแปลงขององค์กร ระบุผู้ขออนุมัติ ผู้อนุมัติ วันที่เปลี่ยนแปลง และเหตุผล เพื่อให้ย้อนดูได้เมื่อเกิดปัญหา

หลักฐานที่ต้องเก็บสำหรับ Audit Trail และสัญญาผู้ให้บริการ

เมื่อฝ่ายตรวจสอบภายในหรือคู่ค้าทางธุรกิจขอดูหลักฐานว่าองค์กรมีการตรวจสอบ Header เหล่านี้จริง เอกสารที่ควรมีคือผลตรวจ Header แบบดิบ (raw response) พร้อมวันที่ตรวจ รายชื่อโดเมนที่ตรวจแล้ว และ Ticket การเปลี่ยนแปลงที่เกี่ยวข้อง

หากสัญญากับผู้ให้บริการโฮสติ้งหรือ CDN มีข้อความอ้างอิงถึงมาตรฐานความปลอดภัย เช่น การตั้งค่า Header พื้นฐาน ควรตรวจสอบว่าข้อความในสัญญาตรงกับสิ่งที่ตั้งค่าจริง ไม่ใช้คำที่บ่งชี้ว่าผ่านการรับรองมาตรฐานใดหากยังไม่ได้ผ่านกระบวนการรับรองจริง ทีมที่ต้องการขั้นตอนตรวจสอบเชิงลึกกว่านี้สามารถอ่านต่อได้ที่ วิธี Audit HTTP Security Headers พร้อม Evidence

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

ความเสี่ยงเชิงธุรกิจเมื่อไม่มีเจ้าของนโยบายชัดเจน

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

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

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

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

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

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

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

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

• ระบุเจ้าของนโยบาย Header ระดับองค์กรอย่างชัดเจน ไม่ใช่ปล่อยให้แต่ละทีมตั้งค่าตามใจ
• ตรวจว่าโดเมนหลักและ Subdomain ทั้งหมดมี Strict-Transport-Security พร้อม max-age ที่เหมาะสม
• ตรวจว่าทุกโดเมนตั้งค่า X-Content-Type-Options เป็น nosniff
• ตรวจหน้า Login และหน้าธุรกรรมว่ามีการควบคุมการฝัง iframe ผ่าน X-Frame-Options หรือ frame-ancestors
• ตรวจค่า Referrer-Policy ว่าไม่รั่วไหลข้อมูลใน URL ไปยังปลายทางภายนอก
• ตรวจ Permissions-Policy ว่าปิดฟีเจอร์เบราว์เซอร์ที่ไม่จำเป็นสำหรับแต่ละหน้า
• ทดสอบค่า Header บน Staging ก่อนนำขึ้น Production ทุกครั้ง
• บันทึกผลตรวจและ Ticket การเปลี่ยนแปลงไว้เป็นหลักฐานสำหรับรอบตรวจสอบ

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

• ตั้งค่า Header เฉพาะโดเมนหลัก แต่ลืม Subdomain หรือไมโครไซต์การตลาด
• ตั้งค่า Strict-Transport-Security ด้วย max-age ยาวมากโดยไม่ทดสอบก่อน แล้วแก้ไขย้อนหลังไม่ได้ทันที
• ไม่มีเจ้าของนโยบายชัดเจน ทำให้แต่ละทีมตั้งค่าไม่สอดคล้องกัน
• ระบุในสัญญาผู้ให้บริการว่าผ่านมาตรฐานความปลอดภัยทั้งที่ยังไม่ได้ตรวจสอบจริง
• ไม่มีหลักฐานการตรวจสอบเก็บไว้ ทำให้ตอบผู้ตรวจสอบภายในไม่ได้เมื่อถูกถาม

สรุป

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

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

• OWASP HTTP Headers Cheat Sheet
• OWASP Secure Headers Project