วิธีวางระบบ HTTPS และ TLS สำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์แบบเป็นขั้นตอน

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

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

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

ขั้นตอนที่ 1 ตรวจสถานะ HTTPS/TLS ของเว็บไซต์ลูกค้าเดิม

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

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

ขั้นตอนที่ 2 ออกและติดตั้งใบรับรองให้ตรงกับ Hosting และ CDN ของลูกค้าแต่ละราย

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

• ถ้าลูกค้าใช้ Hosting ที่มีระบบออกใบรับรองอัตโนมัติในตัว ให้ตรวจสอบว่าระบบต่ออายุอัตโนมัติเปิดใช้งานจริง ไม่ใช่แค่ออกใบรับรองครั้งแรกแล้วจบ
• ถ้าลูกค้าใช้ CDN แยกจาก Hosting ต้องตรวจว่าใบรับรองที่ CDN ออกให้ครอบคลุมโดเมนหลักและซับโดเมนที่ใช้งานจริงทั้งหมด
• ถ้าดูแล Server เอง ต้องวางระบบต่ออายุอัตโนมัติตั้งแต่ต้น ไม่ควรปล่อยให้ต้องต่ออายุด้วยมือทุกครั้ง เพราะเอเจนซีดูแลหลายเว็บไซต์พร้อมกันจะลืมง่าย
• ทดสอบว่าใบรับรองใช้งานได้ทั้งบน Staging และ Production แยกกัน เพราะใบรับรองของ Staging มักตั้งค่าไม่เหมือน Production

ขั้นตอนที่ 3 บังคับ Redirect และตั้งค่า HSTS อย่างระมัดระวัง

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

• ตั้งค่า Redirect 301 จาก http:// ไปยัง https:// ที่ระดับ Server หรือ CDN ไม่ใช่ตั้งค่าผ่าน JavaScript ฝั่ง Client
• ตรวจว่าทั้งเวอร์ชัน www และไม่มี www ถูก Redirect ไปยัง HTTPS อย่างถูกต้องและสอดคล้องกัน
• เปิด Header HSTS ตามแนวทางของ OWASP เฉพาะเมื่อมั่นใจว่า HTTPS ทำงานเสถียรแล้วบน Production เพราะ HSTS มีผลผูกพันกับเบราว์เซอร์ของผู้ใช้ในระยะเวลาหนึ่ง
• อย่าเปิด HSTS บนโดเมน Staging ที่ยังทดสอบ HTTPS ไม่เสร็จ เพราะอาจทำให้ทีมงานเข้าเว็บไซต์ Staging ผ่าน HTTP ไม่ได้อีกเลยแม้จะปิด HTTPS ชั่วคราว

ขั้นตอนที่ 4 ทดสอบ Mixed Content และสคริปต์บุคคลที่สาม

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

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

ขั้นตอนที่ 5 บันทึกผลและส่งมอบในรายงานลูกค้า

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

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

ข้อควรระวังเมื่อแพลตฟอร์มของลูกค้าแต่ละรายไม่เหมือนกัน

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

• เว็บไซต์ที่ใช้ CMS สำเร็จรูปมักมีปลั๊กอินหรือธีมที่ฝังสคริปต์จากโดเมนอื่นโดยที่เอเจนซีไม่ได้เพิ่มเอง ต้องตรวจ Mixed Content ซ้ำหลังติดตั้งปลั๊กอินใหม่ทุกครั้ง ไม่ใช่ตรวจแค่ตอนส่งมอบงาน
• เว็บไซต์อีคอมเมิร์ซที่เชื่อมกับระบบชำระเงินมักมี Endpoint แยกสำหรับหน้าชำระเงินซึ่งต้องตรวจ HTTPS แยกต่างหากจากหน้าเว็บไซต์ทั่วไป เพราะบางครั้งอยู่คนละโดเมนย่อย
• เว็บไซต์ที่พัฒนาแบบกำหนดเองและดูแล Server เองทั้งหมด เอเจนซีต้องรับผิดชอบการตั้งค่า TLS ตั้งแต่ต้น ไม่มีระบบอัตโนมัติของ Hosting มาช่วยเหมือนแพลตฟอร์มสำเร็จรูป
• เมื่อรับช่วงดูแลเว็บไซต์ที่ทีมเดิมทำไว้ ควรตรวจสถานะ HTTPS/TLS ใหม่ทั้งหมดตามขั้นตอนที่ 1 เสมอ ไม่ควรเชื่อเอกสารส่งมอบจากทีมเดิมทั้งหมดโดยไม่ตรวจซ้ำ

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

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

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

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

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

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

• ตรวจสถานะ HTTPS/TLS เดิมของเว็บไซต์ลูกค้าก่อนเริ่มงานทุกครั้ง
• ยืนยันว่าใบรับรองต่ออายุอัตโนมัติและครอบคลุมซับโดเมนที่ใช้งานจริง
• ตั้งค่า Redirect 301 จาก HTTP ไป HTTPS ที่ระดับ Server หรือ CDN
• เปิด Header HSTS หลังยืนยันว่า HTTPS เสถียรบน Production แล้วเท่านั้น
• ทดสอบ Mixed Content บนหน้าฟอร์มและสคริปต์การตลาดทุกครั้งที่มีการเปลี่ยนแปลง
• เขียนรายงานส่งมอบระบุผู้รับผิดชอบต่ออายุใบรับรองและขอบเขตงานให้ชัดเจน

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

• เปิด HSTS ตั้งแต่วันแรกโดยยังไม่ทดสอบ HTTPS บน Production ให้เสถียรก่อน
• ลืมตรวจใบรับรองบน Staging แยกจาก Production แล้วสรุปว่าทุกอย่างพร้อมแล้ว
• ส่งมอบงานโดยไม่ระบุว่าใครรับผิดชอบต่ออายุใบรับรองต่อจากนี้
• ไม่แจ้งลูกค้าว่าการเพิ่มปลั๊กอินหรือสคริปต์ใหม่อาจทำให้เกิด Mixed Content ย้อนหลัง

เมื่อใดควรแจ้งลูกค้าให้หาผู้เชี่ยวชาญด้านความปลอดภัยเพิ่มเติม

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

สรุป

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

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

• OWASP HTTP Security Response Headers Cheat Sheet
• คู่มือรวม Website Security ของ trusty
• คู่มือ HTTPS และ TLS สำหรับเอเจนซีฉบับเต็ม