HTTPS และ TLS คืออะไร? คู่มือสำหรับธุรกิจ SaaS สตาร์ทอัพ และบริษัทเทคโนโลยี

ทีม Engineering ของ SaaS ส่วนใหญ่เปิด HTTPS ไว้ตั้งแต่วันแรกที่ deploy เพราะ Hosting และ Framework สมัยใหม่บังคับใช้อยู่แล้ว แต่คำถามที่มักไม่มีคำตอบชัดเจนภายในทีมคือ Certificate ครอบคลุมทุก Subdomain ที่ทีม Growth เพิ่งสร้างขึ้นเพื่อแคมเปญใหม่หรือยัง เวอร์ชัน TLS ที่ Load Balancer ใช้อยู่ตอนนี้คือเวอร์ชันไหน และถ้าลูกค้าองค์กรขอเชื่อม Custom Domain เข้ากับระบบ ใครเป็นคนรับผิดชอบ Certificate ของโดเมนนั้น

บทความนี้อธิบาย HTTPS และ TLS ในมุมของทีมที่ต้องลงมือตั้งค่าและดูแลจริง ครอบคลุมการจัดการ Certificate หลาย Domain การเลือกเวอร์ชัน TLS การเปิด HSTS อย่างปลอดภัย ปัญหา Mixed Content ที่กระทบทีม Growth และขั้นตอนทดสอบใน Staging กับ CI ก่อนปล่อยจริงบน Production

HTTPS และ TLS คืออะไร สัมพันธ์กันอย่างไร

HTTPS คือ HTTP ที่ถูกส่งผ่านช่องทางที่เข้ารหัสด้วย TLS (Transport Layer Security) พูดง่ายๆ คือ HTTP เป็นตัวโปรโตคอลที่กำหนดรูปแบบ Request และ Response ส่วน TLS เป็นชั้นที่ทำหน้าที่เข้ารหัสข้อมูลระหว่างเดินทาง ยืนยันตัวตนของเซิร์ฟเวอร์ด้วย Certificate และป้องกันไม่ให้ข้อมูลระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์ถูกอ่านหรือแก้ไขระหว่างทาง

เวลาเบราว์เซอร์เชื่อมต่อกับเซิร์ฟเวอร์ครั้งแรก จะมีขั้นตอนที่เรียกว่า TLS Handshake เซิร์ฟเวอร์ส่ง Certificate มาให้เบราว์เซอร์ตรวจสอบว่าออกโดย Certificate Authority ที่เบราว์เซอร์เชื่อถือหรือไม่ ตรงกับชื่อโดเมนที่กำลังเชื่อมต่อหรือไม่ และยังไม่หมดอายุ จากนั้นทั้งสองฝ่ายจึงตกลงกุญแจเข้ารหัสสำหรับการสื่อสารในเซสชันนั้น

TLS กับ SSL คือเรื่องเดียวกันหรือไม่

หลายทีมยังพูดว่า SSL Certificate ทั้งที่จริงแล้ว SSL เป็นโปรโตคอลรุ่นก่อนหน้าที่ถูกแทนที่ด้วย TLS มานานแล้ว คำว่า SSL ยังติดปากในอุตสาหกรรมและใน UI ของผู้ให้บริการหลายเจ้า แต่สิ่งที่ใช้งานจริงบนเว็บและ API ทุกวันนี้คือ TLS ทีม Engineering ควรใช้คำว่า TLS ให้ถูกต้องในเอกสารภายใน เพื่อไม่ให้สับสนตอนอ้างอิงเวอร์ชันหรือ Cipher Suite

ทำไม SaaS ต้องดูแลเรื่องนี้ต่างจากเว็บทั่วไป

เว็บบริษัททั่วไปมักมีโดเมนหลักโดเมนเดียว แต่สถาปัตยกรรมของ SaaS มักกระจายออกเป็นหลาย Subdomain เช่น app ของแอปพลิเคชันหลัก api สำหรับนักพัฒนาภายนอก docs สำหรับเอกสารประกอบ status สำหรับหน้าสถานะระบบ และหน้า Marketing ที่ทีม Growth ดูแลแยกต่างหาก แต่ละ Subdomain ต้องมี Certificate ที่ถูกต้องและได้รับการต่ออายุตรงเวลา

ปัญหาที่พบบ่อยคือทีม Growth สร้าง Landing Page หรือ Subdomain ใหม่สำหรับแคมเปญโดยไม่ผ่านการรีวิวของ Engineering ทำให้เกิด Subdomain ที่ไม่มีใครดูแล Certificate หรือถูกลืมไปหลังแคมเปญจบ ยิ่งไปกว่านั้น SaaS ที่รองรับ Custom Domain ของลูกค้า เช่น ให้ลูกค้าชี้ CNAME จาก app.customer.com มายังระบบ ต้องมีกระบวนการออก Certificate ให้โดเมนของลูกค้าแต่ละรายโดยอัตโนมัติ ไม่ใช่ทำมือทีละราย

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

การจัดการ Certificate สำหรับหลาย Domain และ Custom Domain ของลูกค้า

แนวทางที่ทีม Engineering ของ SaaS ใช้กันทั่วไปคือการออก Certificate ผ่านระบบอัตโนมัติด้วยโปรโตคอล ACME เช่นผ่านผู้ให้บริการอย่าง Let's Encrypt หรือบริการที่ผูกกับ CDN และ Load Balancer ที่ใช้งานอยู่ แทนที่จะขอ Certificate ปีละครั้งด้วยมือ ระบบจะต่ออายุให้อัตโนมัติก่อนหมดอายุ ลดความเสี่ยงที่จะลืม

สำหรับ Subdomain ภายในองค์กรเอง อาจเลือกใช้ Wildcard Certificate ที่ครอบคลุมทุก Subdomain ระดับเดียวกัน หรือ Certificate แบบ SAN ที่ระบุรายชื่อโดเมนที่ต้องการคุ้มครองไว้ชัดเจน แต่ละแบบมีข้อดีข้อเสียต่างกัน Wildcard สะดวกเวลาสร้าง Subdomain ใหม่บ่อยๆ แต่ถ้ากุญแจรั่วจะกระทบทุก Subdomain พร้อมกัน ส่วน SAN ต้องเพิ่มชื่อโดเมนใหม่ทุกครั้งที่มี Subdomain เพิ่ม แต่จำกัดผลกระทบได้ดีกว่า

ส่วน Custom Domain ของลูกค้า ต้องมีกระบวนการอัตโนมัติที่ตรวจสอบว่าลูกค้าชี้ CNAME หรือ DNS record มาที่ระบบจริง ก่อนออก Certificate ให้โดเมนนั้น และต้องมีระบบตรวจสอบวันหมดอายุของ Certificate ทุกโดเมนลูกค้าแยกจากโดเมนหลักของบริษัท เพราะจำนวนโดเมนอาจมีเป็นร้อยเป็นพันรายการเมื่อฐานลูกค้าโต

สิ่งที่ทีมมักมองข้ามคือการแจ้งเตือนเมื่อการต่ออายุอัตโนมัติล้มเหลว ไม่ใช่แค่แจ้งเตือนก่อน Certificate หมดอายุ เพราะสาเหตุที่ทำให้ต่ออายุไม่สำเร็จ เช่น ติด Rate Limit ของผู้ออก Certificate หรือ DNS Validation ล้มเหลว มักเกิดขึ้นเงียบๆ และถ้าไม่มีการแจ้งเตือนแยกต่างหาก ทีมจะรู้ตัวอีกทีตอนที่ Certificate หมดอายุจริงแล้วเท่านั้น

TLS Version และ Cipher Suite ที่ควรตั้งค่า

มาตรฐานทั่วไปในปัจจุบันคือกำหนด TLS 1.2 เป็นเวอร์ชันขั้นต่ำ และเปิดรองรับ TLS 1.3 ควบคู่กันเพื่อให้ Client ที่รองรับได้ใช้การเชื่อมต่อที่เร็วและปลอดภัยกว่า โปรโตคอลรุ่นเก่าอย่าง TLS 1.0 และ TLS 1.1 ถือว่าล้าสมัยและเบราว์เซอร์หลักไม่รองรับแล้ว การตั้งค่านี้มักทำที่ Load Balancer หรือ Reverse Proxy หน้าระบบ ไม่ใช่ที่โค้ดแอปพลิเคชันโดยตรง

เรื่อง Cipher Suite ทีมไม่จำเป็นต้องเลือกเองทีละตัว ผู้ให้บริการ CDN และ Load Balancer ส่วนใหญ่มีชุด Cipher ที่แนะนำเป็นค่าเริ่มต้นซึ่งอัปเดตตามคำแนะนำของอุตสาหกรรมอยู่แล้ว สิ่งที่ทีมควรทำคือตรวจสอบว่าไม่มีการเปิด Cipher รุ่นเก่าที่ไม่รองรับ Forward Secrecy ค้างอยู่จากการตั้งค่าเดิม โดยเฉพาะระบบที่ Migrate มาจาก Infrastructure เก่า

เครื่องมือที่ใช้ตรวจสอบการตั้งค่าจริงบน Production ได้แก่บริการทดสอบ TLS แบบสาธารณะที่นักพัฒนาใช้กันทั่วไป และเครื่องมือ Command Line ที่สแกนโปรโตคอลกับ Cipher ที่เซิร์ฟเวอร์เปิดรับ ควรรันตรวจสอบเป็นระยะ ไม่ใช่ตรวจครั้งเดียวตอนตั้งค่าเสร็จแล้วไม่กลับมาดูอีก

HSTS และความเสี่ยงที่ต้องรู้ก่อนเปิดใช้งานจริง

HTTP Strict Transport Security หรือ HSTS คือ Header ที่บอกเบราว์เซอร์ว่าให้เชื่อมต่อโดเมนนี้ผ่าน HTTPS เท่านั้นตลอดระยะเวลาที่กำหนดใน max-age แม้ผู้ใช้จะพิมพ์ http:// เอง เบราว์เซอร์ก็จะเปลี่ยนเป็น https:// ให้อัตโนมัติโดยไม่ต้องรอ Redirect จากเซิร์ฟเวอร์

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

แนวทางที่ปลอดภัยกว่าคือทยอยเปิดใช้ เริ่มจาก max-age สั้นๆ ก่อนเพื่อสังเกตผลกระทบ ตรวจสอบให้แน่ใจว่าทุก Subdomain มี Certificate และ Redirect HTTPS ครบก่อนจึงเพิ่ม includeSubDomains และเก็บการส่งเข้ารายการ preload ไว้เป็นขั้นตอนสุดท้ายเมื่อมั่นใจว่าการตั้งค่าเสถียรแล้วจริงๆ

Mixed Content และผลกระทบต่อทีม Growth

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

สาเหตุที่พบบ่อยในทีม SaaS คือทีม Growth หรือ Marketing ฝัง Snippet ของเครื่องมือติดตามผลที่ยังอ้างอิง URL แบบ http:// หรือคัดลอกโค้ดฝังจากเอกสารเก่าที่ไม่ได้อัปเดต เมื่อสคริปต์เหล่านั้นถูกบล็อก การติดตาม Conversion หรือ Pixel ของแคมเปญโฆษณาจะไม่ทำงานโดยที่ทีม Marketing อาจไม่รู้ตัวจนยอดตัวเลขผิดปกติ

วิธีป้องกันคือกำหนดเป็นข้อตกลงร่วมกันว่าสคริปต์หรือ Tag ใดๆ ที่ทีม Growth จะเพิ่มบนเว็บ ต้องใช้ https:// หรือ URL แบบ Protocol-relative เสมอ และควรมีการตรวจสอบ Mixed Content เป็นส่วนหนึ่งของการรีวิวก่อนปล่อย Tag ใหม่ ไม่ใช่ปล่อยให้ทีม Marketing เพิ่ม Tag เองโดยไม่มีขั้นตอนตรวจสอบ

การทดสอบใน Staging และ CI ก่อนขึ้น Production

การตั้งค่า TLS ควรถูกทดสอบเหมือนโค้ดส่วนอื่นของระบบ ไม่ใช่ปรับที่ Production โดยตรงแล้วดูผลลัพธ์ทีหลัง Staging ควรใช้ Reverse Proxy หรือ Load Balancer Config ชุดเดียวกับ Production เพื่อให้ผลการทดสอบสะท้อนของจริง

ทีมที่มี CI Pipeline อยู่แล้วสามารถเพิ่มขั้นตอนตรวจสอบอัตโนมัติ เช่น สแกนเวอร์ชัน TLS ที่เซิร์ฟเวอร์เป้าหมายเปิดรับ ตรวจวันหมดอายุของ Certificate และตรวจว่า Header HSTS ถูกส่งออกมาถูกต้องหลังจาก Deploy แต่ละครั้ง หากพบว่าเวอร์ชัน TLS เปลี่ยนไปโดยไม่ตั้งใจหรือ Certificate ใกล้หมดอายุ Pipeline ควรแจ้งเตือนก่อนที่จะปล่อยขึ้น Production

ข้อควรระวังอีกอย่างคือการใช้ Self-signed Certificate ใน Staging เป็นเวลานาน เพราะทำให้ทีมชินกับการกดข้ามคำเตือนของเบราว์เซอร์ และอาจมองข้ามคำเตือนจริงบน Production ในอนาคต ถ้าเป็นไปได้ควรใช้ Certificate จากผู้ออกที่เบราว์เซอร์เชื่อถือแม้ใน Staging เพื่อให้พฤติกรรมการทดสอบใกล้เคียงของจริงที่สุด

การประสานงานกับทีม Privacy

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

แนวทางที่ใช้งานได้จริงคือเมื่อ Engineering เพิ่ม Subdomain หรือ API endpoint ใหม่ที่รับส่งข้อมูลผู้ใช้ ให้แจ้งทีม Privacy เป็นส่วนหนึ่งของขั้นตอน Deploy ตามปกติ พร้อมเก็บหลักฐานผลการตรวจสอบ TLS เช่น วันที่ทดสอบ เครื่องมือที่ใช้ และผลลัพธ์ ไว้เป็นข้อมูลอ้างอิงภายใน แทนที่จะรอให้ทีม Privacy มาถามทีหลัง ดูรายละเอียดเรื่องการจัดทำรายการข้อมูลเพิ่มเติมได้ที่ คู่มือ Data Inventory และการจัดทำบัญชีข้อมูล

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

Wildcard Certificate กับ SAN Certificate ต่างกันอย่างไร เลือกแบบไหนดีสำหรับ SaaS ที่มีหลาย Subdomain

Wildcard Certificate ครอบคลุมทุก Subdomain ในระดับเดียวกันด้วยใบเดียว สะดวกเมื่อสร้าง Subdomain ใหม่บ่อย ส่วน SAN Certificate ระบุรายชื่อโดเมนที่ต้องการคุ้มครองไว้ชัดเจนทีละรายการ จำกัดผลกระทบได้ดีกว่าหากกุญแจรั่วไหล ทีมที่มี Subdomain เปลี่ยนแปลงถี่มักเลือก Wildcard ส่วนทีมที่ต้องการควบคุมขอบเขตชัดเจนมักเลือก SAN หรือใช้ทั้งสองแบบผสมกันตามลักษณะของแต่ละกลุ่มโดเมน

เปิด HSTS แล้วส่งผลกับ Subdomain ที่ยังไม่มี Certificate หรือไม่

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

TLS 1.3 จำเป็นต้องเปิดใช้ทันทีหรือไม่ ถ้ายังใช้ TLS 1.2 อยู่

TLS 1.2 ยังถือเป็นเวอร์ชันที่ใช้งานได้และเบราว์เซอร์หลักยังรองรับ แต่ TLS 1.3 มีขั้นตอน Handshake ที่สั้นกว่าและเข้ารหัสข้อมูลได้เร็วกว่า ทีมที่ Load Balancer หรือ CDN รองรับอยู่แล้วควรเปิดใช้ควบคู่กับ TLS 1.2 เพื่อให้ Client ที่รองรับได้ประโยชน์ โดยไม่จำเป็นต้องปิด TLS 1.2 ทันทีถ้ายังมี Client เก่าที่เชื่อมต่อผ่านเวอร์ชันนั้นอยู่

Custom Domain ของลูกค้าองค์กรต้องขอ Certificate เองหรือให้ระบบ SaaS ออกให้

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

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

• สำรวจรายชื่อ Domain และ Subdomain ทั้งหมดที่ระบบใช้งานอยู่ รวมถึง Subdomain ที่ทีม Growth สร้างเอง
• ตั้งค่าออก Certificate และต่ออายุอัตโนมัติผ่านโปรโตคอล ACME แทนการต่ออายุด้วยมือ
• ตั้งการแจ้งเตือนเมื่อการต่ออายุอัตโนมัติล้มเหลว ไม่ใช่แค่แจ้งเตือนก่อนหมดอายุ
• กำหนด TLS 1.2 เป็นเวอร์ชันขั้นต่ำ และเปิด TLS 1.3 ควบคู่ที่ Load Balancer
• ทดสอบการตั้งค่า TLS และ Certificate ใน Staging ด้วย Config ชุดเดียวกับ Production ก่อนทุกครั้ง
• เพิ่มขั้นตอนสแกน TLS Version และวันหมดอายุของ Certificate เข้าไปใน CI Pipeline
• ทยอยเปิด HSTS โดยเริ่มจาก max-age สั้น ก่อนเพิ่ม includeSubDomains และ preload
• ตรวจสอบ Mixed Content ของ Tag หรือ Script ที่ทีม Growth เพิ่มก่อนปล่อยใช้งานจริง
• แจ้งทีม Privacy ทุกครั้งที่มี Subdomain หรือช่องทางรับส่งข้อมูลใหม่เกิดขึ้น

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

• สร้าง Subdomain ใหม่สำหรับแคมเปญโดยไม่แจ้ง Engineering ทำให้ไม่มี Certificate ครอบคลุม
• เปิด includeSubDomains ใน HSTS ทั้งที่ยังมี Subdomain ที่ไม่มี Certificate ที่ถูกต้อง
• ส่งโดเมนเข้ารายการ preload ตั้งแต่ยังไม่แน่ใจว่าทุก Subdomain รองรับ HTTPS เสถียรแล้ว
• ปล่อยให้ทีม Marketing ฝัง Script ที่อ้างอิง URL แบบ http:// โดยไม่มีขั้นตอนตรวจสอบก่อนปล่อยใช้งาน
• ใช้ Self-signed Certificate ใน Staging นานเกินไปจนทีมชินกับการมองข้ามคำเตือนของเบราว์เซอร์
• ไม่มีระบบแจ้งเตือนเมื่อการต่ออายุ Certificate ของ Custom Domain ลูกค้าล้มเหลว

สรุป

HTTPS และ TLS สำหรับ SaaS ไม่ใช่การตั้งค่าครั้งเดียวจบ เพราะจำนวน Subdomain และ Custom Domain ของลูกค้าเพิ่มขึ้นตามการเติบโตของธุรกิจ ทีม Engineering ต้องมีระบบออกและต่ออายุ Certificate อัตโนมัติ กำหนดเวอร์ชัน TLS ที่ชัดเจน ทดสอบใน Staging และ CI ก่อนขึ้น Production ทุกครั้ง และประสานกับทีม Growth กับ Privacy อย่างสม่ำเสมอเพื่อไม่ให้เกิดช่องโหว่จากจุดที่ไม่มีใครดูแล

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

• OWASP HTTP Headers Cheat Sheet
• หน้ารวมความรู้ Website Security ของ trusty
• วิธีวางระบบ HTTPS และ TLS แบบเป็นขั้นตอนสำหรับ SaaS