เช็กลิสต์ HTTPS และ TLS สำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์: ต้องตรวจอะไรบ้างก่อนเปิดใช้งาน

เอเจนซีที่ดูแลเว็บไซต์ลูกค้า 30-50 เว็บพร้อมกันมักเจอปัญหาเดียวกันซ้ำ ๆ เว็บที่ทำ HTTPS ไว้ถูกต้องตั้งแต่วันส่งมอบงาน กลับกลายเป็น \"ไม่ปลอดภัย\" ในเบราว์เซอร์ของลูกค้าอีก 8-12 เดือนต่อมา สาเหตุมักไม่ใช่การตั้งค่าผิดตั้งแต่แรก แต่เป็นใบรับรองหมดอายุโดยไม่มีใครต่ออายุ หรือลูกค้าย้ายโฮสต์เองแล้วลืมตั้งค่า HTTPS ใหม่บนโฮสต์ปลายทาง

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

เอเจนซีรับผิดชอบอะไรบ้างเรื่อง HTTPS และ TLS ของลูกค้า

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

งานเปิดใช้งานครั้งเดียว (One-time Setup)

ครอบคลุมการติดตั้งใบรับรอง TLS ตั้งค่า Redirect จาก HTTP ไป HTTPS ทั้งเว็บไซต์ และแก้ Mixed Content ที่พบตอนเปิดตัว งานประเภทนี้จบเมื่อส่งมอบ และเอเจนซีไม่มีหน้าที่ต่ออายุใบรับรองในอนาคต เว้นแต่จะระบุไว้ในสัญญา

งานดูแลต่อเนื่อง (Ongoing Maintenance / Retainer)

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

เอเจนซีที่ไม่แยกสองงานนี้ให้ชัดในสัญญา มักเจอสถานการณ์ที่ลูกค้าคาดหวังว่า \"เว็บที่จ้างทำแล้วต้องปลอดภัยตลอดไป\" ทั้งที่ไม่ได้จ่ายค่าดูแลต่อเนื่อง

เช็กก่อนโอนเว็บไซต์ให้ลูกค้า (Pre-launch)

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

ใบรับรองครอบคลุมโดเมนที่ใช้งานจริงครบทุกตัว

ตรวจว่าใบรับรองครอบคลุมทั้ง www และไม่มี www ของโดเมนหลัก รวมถึงซับโดเมนที่ใช้งานจริง เช่น shop. หรือ blog. เอเจนซีที่ทำเว็บให้ลูกค้าหลายรายมักพลาดจุดนี้เพราะใช้ใบรับรองฟรีแบบ Single-domain ให้เว็บที่จริง ๆ มีซับโดเมนใช้งานอยู่

Redirect จาก HTTP ไป HTTPS ครบทุกเส้นทาง ไม่ใช่แค่หน้าแรก

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

Mixed Content จากธีมและปลั๊กอินของลูกค้าเดิม

เมื่อรับงานต่อจากเว็บไซต์เก่าที่เคยเป็น HTTP ให้ตรวจสอบว่ารูปภาพ ฟอนต์ หรือสคริปต์ที่ฝังไว้ในเนื้อหาเก่ายังอ้างอิง URL แบบ http:// อยู่หรือไม่ เพราะจะทำให้เบราว์เซอร์ขึ้นเตือน Mixed Content แม้ตัวเว็บไซต์จะเป็น HTTPS แล้ว

บันทึกวันหมดอายุใบรับรองไว้ในระบบของเอเจนซี ไม่ใช่แค่ในหัวคนทำ

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

ระบบติดตามใบรับรองข้ามหลายเว็บไซต์ (Certificate Tracking ระดับพอร์ตโฟลิโอ)

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

แยกกลุ่มเว็บไซต์ตามวิธีต่ออายุใบรับรอง

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

ตั้งการแจ้งเตือนล่วงหน้าอย่างน้อย 30 วันก่อนหมดอายุ

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

ทบทวนรายชื่อเว็บไซต์ที่ดูแลอยู่ทุกไตรมาส

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

อะไรควรอยู่ในรายงานให้ลูกค้า และอะไรต้องให้ลูกค้าตัดสินใจเอง

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

สิ่งที่ใส่ในรายงานได้ทันที

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

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

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

ข้อจำกัดของแพลตฟอร์มที่เอเจนซีควบคุมไม่ได้

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

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

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

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

Wildcard certificate กับ SAN certificate ต่างกันอย่างไร เลือกแบบไหนให้ลูกค้าที่มีหลายซับโดเมน Wildcard certificate ครอบคลุมซับโดเมนทั้งหมดภายใต้โดเมนหลักด้วยใบเดียว เหมาะกับลูกค้าที่เพิ่มซับโดเมนบ่อยและคาดเดาชื่อไม่ได้ล่วงหน้า ส่วน SAN certificate ระบุรายชื่อโดเมนและซับโดเมนที่ต้องการคุ้มครองไว้ชัดเจนในใบเดียว เหมาะกับลูกค้าที่มีรายชื่อโดเมนคงที่และต้องการควบคุมว่าใบรับรองครอบคลุมเฉพาะที่ระบุไว้เท่านั้น

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

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

• ตกลงในสัญญาให้ชัดว่างาน HTTPS และ TLS เป็นแบบเปิดใช้งานครั้งเดียวหรือดูแลต่อเนื่อง
• ตรวจใบรับรองครอบคลุมทุกโดเมนและซับโดเมนที่ใช้งานจริงก่อนส่งมอบ
• ทดสอบ Redirect จาก HTTP ไป HTTPS ครบทุกเส้นทาง ไม่ใช่แค่หน้าแรก
• ตรวจ Mixed Content จากธีมและปลั๊กอินเดิมของลูกค้าก่อนโอนงาน
• บันทึกโดเมน วันหมดอายุ และผู้รับผิดชอบต่ออายุ ลงระบบติดตามกลางของเอเจนซี
• แยกกลุ่มเว็บไซต์ตามวิธีต่ออายุใบรับรองอัตโนมัติหรือด้วยมือ
• ตั้งแจ้งเตือนล่วงหน้าอย่างน้อย 30 วันก่อนใบรับรองหมดอายุ
• ทบทวนรายชื่อเว็บไซต์ในความดูแลทุกไตรมาสเพื่อตัดเว็บที่เลิกจ้างแล้วออก
• แจ้งข้อจำกัดของแพลตฟอร์มที่ควบคุมไม่ได้ให้ลูกค้าทราบตรง ๆ

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

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

สรุป

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

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

• OWASP HTTP Security Response Headers Cheat Sheet
• ศูนย์ความรู้ด้านความปลอดภัยเว็บไซต์ของ trusty
• วิธีวางระบบ HTTPS และ TLS สำหรับร้านค้าออนไลน์แบบเป็นขั้นตอน