วิธี Audit HTTPS และ TLS ของเอเจนซีและฟรีแลนซ์ทำเว็บไซต์ พร้อม Evidence ที่ควรเก็บ

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

ทำไม Agency ต้อง Audit HTTPS/TLS เป็นประจำให้ทุกเว็บลูกค้า

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

ขั้นตอน Audit ทีละเว็บที่ควรทำให้ครบ

ตรวจใบรับรอง โปรโตคอล และ Mixed Content

ต่อเว็บไซต์หนึ่งเว็บ ทีมควรตรวจ 3 จุดหลัก คือใบรับรอง HTTPS ว่ายังไม่หมดอายุและครอบคลุมโดเมนที่ใช้จริง โปรโตคอลและ Cipher ที่เซิร์ฟเวอร์ยังเปิดใช้งานว่ามีรุ่นเก่าที่ควรปิดหรือไม่ และ Mixed Content บนหน้าเว็บหลักรวมถึงหน้าฟอร์มติดต่อหรือหน้าตะกร้าสินค้าถ้ามี การตรวจ 3 จุดนี้ใช้เวลาไม่นานต่อเว็บถ้าทำเป็นประจำ แต่จะกลายเป็นงานหนักถ้าปล่อยไว้นานแล้วค่อยไล่ตรวจทีเดียวหลายสิบเว็บ

ตรวจโดเมนย่อยและซับโดเมนที่ลูกค้าอาจเพิ่มเองภายหลัง

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

การจัดการเมื่อดูแลเว็บไซต์หลายสิบเว็บพร้อมกัน

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

สิ่งที่ต้องระบุในรายงานลูกค้า กับสิ่งที่ต้องให้ลูกค้าตัดสินใจเอง

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

Evidence ที่ควรเก็บไว้เพื่อยืนยันการตรวจแต่ละรอบ

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

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

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

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

ต้องแจ้งลูกค้าทุกครั้งที่พบปัญหา HTTPS เล็กน้อยหรือไม่ ควรแจ้งอย่างน้อยในรายงานสรุปรอบ แต่ปัญหาที่มีความเสี่ยงสูง เช่น ใบรับรองใกล้หมดอายุหรือ Mixed Content บนหน้าฟอร์มรับข้อมูล ควรแจ้งทันทีไม่ต้องรอรอบรายงาน

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

เครื่องมือและ Workflow ที่ช่วยลดงานซ้ำ

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

การรับช่วงเว็บไซต์จากทีมเดิมหรือเอเจนซีเดิม

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

สแตจิ้งกับโปรดักชัน ต้องตรวจแยกกัน

เว็บไซต์ที่มีสภาพแวดล้อมทดสอบ (staging) แยกจากเว็บจริง (production) มักมีใบรับรอง HTTPS คนละชุด บางครั้งทีมพัฒนาใช้ใบรับรองแบบทดสอบ (self-signed) บนสแตจิ้งซึ่งเป็นเรื่องปกติ แต่ต้องตรวจให้แน่ใจว่าเมื่อขึ้นเว็บจริงบนโปรดักชันแล้ว ใบรับรองถูกเปลี่ยนเป็นใบรับรองที่ถูกต้องสำหรับการใช้งานจริง ไม่ใช่ใบรับรองทดสอบที่หลงเหลือมาจากขั้นตอนพัฒนา เอเจนซีควรมีขั้นตอนตรวจ HTTPS เป็นส่วนหนึ่งของ Checklist ก่อนส่งมอบเว็บไซต์ทุกครั้งที่ Launch จริง

ตัวอย่างสถานการณ์ที่พบระหว่างการรับช่วงงานลูกค้าใหม่

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

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

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

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

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

สรุป

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

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

• OWASP HTTP Security Response Headers Cheat Sheet