วิธี Audit HTTPS และ TLS ของธุรกิจ SaaS พร้อม Evidence ที่ควรเก็บ

ระบบที่เปิด HTTPS มาตั้งแต่วันแรกไม่ได้แปลว่าการตั้งค่าวันนี้ยังปลอดภัยเท่าวันนั้น Cipher ที่เคยยอมรับได้อาจถูกจัดเป็นความเสี่ยงในภายหลัง ใบรับรองบางตัวอาจถูกตั้งต่ออายุอัตโนมัติไว้แต่ไม่มีใครตรวจว่าทำงานจริง และ Subdomain ใหม่ที่ทีม Growth เพิ่มเข้ามาอาจไม่ได้อยู่ในขอบเขตของใบรับรองเดิม การ Audit คือขั้นตอนตรวจสอบสภาพจริง ไม่ใช่เชื่อ Dashboard หรือความทรงจำของทีมว่าตั้งค่าไว้ถูกต้องแล้ว

สัญญาณว่าการตั้งค่า HTTPS/TLS อาจมีช่องโหว่อยู่แล้ว

สัญญาณแรกที่ควรสังเกตคือมี Subdomain หรือบริการย่อยที่เพิ่มเข้ามาทีหลังโดยทีมอื่นที่ไม่ใช่ Core Engineering เช่น หน้า Landing Page ของทีม Marketing หรือระบบย่อยที่ทีม Growth ตั้งขึ้นเองอย่างรวดเร็ว จุดเหล่านี้มักหลุดออกจากกระบวนการตรวจสอบใบรับรองส่วนกลาง สัญญาณที่สองคือไม่มีใครในทีมตอบได้ทันทีว่าปัจจุบันเปิด TLS เวอร์ชันใดบ้าง เพราะแปลว่าไม่มีการตรวจสอบซ้ำมาระยะหนึ่งแล้ว

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

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

วิธีตรวจสอบใบรับรองที่ใช้งานอยู่จริง

อย่าเชื่อเฉพาะข้อมูลในระบบจัดการใบรับรองภายในทีม แต่ให้ตรวจจากมุมมองของ Client จริง คือยิง Request ไปยังโดเมนแต่ละตัวแล้วอ่านใบรับรองที่เซิร์ฟเวอร์ส่งกลับมาโดยตรง เทียบว่า Subject Alternative Name ครอบคลุมโดเมนที่ใช้งานจริงหรือไม่ วันหมดอายุตรงกับที่ระบบแจ้งเตือนบันทึกไว้หรือไม่ และห่วงโซ่ใบรับรอง (Chain) สมบูรณ์จนถึง Root ที่เบราว์เซอร์ส่วนใหญ่เชื่อถือหรือไม่

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

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

ตรวจเวอร์ชัน TLS และ Cipher ที่เซิร์ฟเวอร์ตอบกลับจริง

การตั้งค่าที่เขียนไว้ใน Config อาจไม่ตรงกับพฤติกรรมจริงของเซิร์ฟเวอร์ โดยเฉพาะเมื่อมี Load Balancer หลายชั้นหรือ CDN คั่นกลาง ให้ทดสอบจากภายนอกว่าเซิร์ฟเวอร์ยังตอบรับ TLS เวอร์ชันเก่าอยู่หรือไม่ และ Cipher Suite ที่เปิดใช้จริงตรงกับที่ทีมตั้งใจไว้หรือไม่ บางครั้งทีมปิด TLS 1.0 ที่ต้นทางแล้ว แต่ CDN ชั้นหน้ายังเปิดอยู่โดยไม่รู้ตัว ทำให้การปิดที่ต้นทางไม่มีผลจริงกับผู้ใช้ปลายทาง

ผลตรวจควรระบุด้วยว่ามีเซิร์ฟเวอร์หรือ Endpoint ใดที่ตั้งค่าไม่ตรงกับ Policy ส่วนกลาง เช่น Environment ทดสอบที่หลุดเปิด TLS เก่าไว้เพราะไม่มีใครอัปเดต Config มานาน จุดเหล่านี้แม้ไม่ใช่ Production แต่ถ้าเข้าถึงได้จากอินเทอร์เน็ตก็ยังเป็นความเสี่ยงที่ควรบันทึกไว้

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

ควรตรวจ Cipher Suite แยกตามลำดับความสำคัญ (Preference Order) ด้วย ไม่ใช่แค่ตรวจว่า Cipher ที่ไม่ปลอดภัยถูกปิดหรือไม่ เพราะบางเซิร์ฟเวอร์ปิด Cipher เก่าไปแล้วจริง แต่ยังคงจัดลำดับให้ Cipher ที่อ่อนแอกว่าถูกเลือกใช้ก่อน Cipher ที่แข็งแรงกว่าในกรณีที่ทั้งสองฝั่งรองรับหลายตัวเลือก การตรวจลำดับความสำคัญนี้ต้องใช้เครื่องมือที่จำลองการเจรจา TLS Handshake จริงจากหลายมุมมอง ไม่ใช่แค่อ่านรายชื่อ Cipher ที่เปิดใช้งานทั้งหมด

เก็บ Evidence จากการสแกนสำหรับรายงานทีม

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

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

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

อ่านผลสแกน Mixed Content และ HSTS แล้วแปลเป็น Action

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

สำหรับ HSTS ให้ตรวจว่า Header ที่ตอบกลับจริงตรงกับที่ทีมตั้งใจไว้ ทั้งค่า max-age และพารามิเตอร์ includeSubDomains หากพบว่า Subdomain บางตัวยังไม่บังคับ HTTPS ทั้งที่ Header หลักเปิด includeSubDomains ไว้ ต้องรีบแก้ Subdomain นั้นก่อน เพราะผู้ใช้ที่เข้าผ่าน Subdomain นั้นอาจเจอปัญหาการเข้าถึงเว็บไม่ได้เลยหากยังไม่มี HTTPS รองรับ

แปลผล Audit เป็นแผนแก้ไขที่มีเจ้าภาพ

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

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

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

ควร Audit HTTPS/TLS บ่อยแค่ไหน อย่างน้อยควรมีรอบตรวจสม่ำเสมอ เช่น รายไตรมาส และตรวจเพิ่มทุกครั้งที่เพิ่มโดเมนใหม่หรือเปลี่ยน Infrastructure สำคัญ ไม่ควรรอให้มีปัญหาเกิดขึ้นก่อนถึงจะตรวจ

ผลสแกนอัตโนมัติเพียงพอที่จะสรุปว่าปลอดภัยหรือไม่ ผลสแกนอัตโนมัติช่วยตรวจ HTTPS เวอร์ชัน TLS ใบรับรอง Header และ Mixed Content ได้ในระดับหนึ่ง แต่ไม่ครอบคลุมเรื่อง Authentication, Authorization, Business Logic หรือช่องโหว่ระดับโค้ด การอ่านผลสแกนจึงควรระบุขอบเขตชัดเจนว่าตรวจอะไรได้และอะไรที่ยังต้องตรวจเพิ่ม

พบ Mixed Content แล้วต้องแก้ทุกจุดพร้อมกันไหม ไม่จำเป็นต้องแก้พร้อมกันทั้งหมด แต่ควรจัดลำดับตามความเสี่ยง โดยแก้สคริปต์และ iframe ที่โหลดผ่าน HTTP ก่อน แล้วค่อยไล่แก้ทรัพยากรอื่นตามรอบ

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

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

• ยิงตรวจใบรับรองจากมุมมอง Client จริงในทุกโดเมนแทนการเชื่อ Dashboard ภายใน
• ตรวจว่า TLS เวอร์ชันเก่าถูกปิดจริงในทุกชั้น ทั้งต้นทางและ CDN
• เปรียบเทียบ Cipher Suite ที่เปิดใช้จริงกับ Policy ที่ทีมตั้งใจไว้
• เก็บผลสแกนดิบพร้อมวันที่ตรวจไว้เป็น Evidence ทุกรอบ
• จัดลำดับแก้ Mixed Content ตามความเสี่ยง โดยเริ่มจากสคริปต์และ iframe
• ตรวจว่า HSTS ครอบคลุมทุก Subdomain จริงก่อนเชื่อว่า Header ทำงานถูกต้อง
• ตั้งรอบ Audit สม่ำเสมอ ไม่รอให้มีปัญหาก่อนถึงจะตรวจ

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

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

สรุป

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

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

• OWASP HTTP Headers Cheat Sheet
• OWASP Secure Headers Project

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