HTTPS และ TLS คืออะไร? คู่มือกำกับดูแลสำหรับองค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูง

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

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

HTTPS และ TLS คืออะไร และทำไมองค์กรความเสี่ยงสูงต้องดูแลต่างจากเว็บทั่วไป

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

แต่สำหรับองค์กรการเงิน ประกัน หรือธุรกิจที่มีความเสี่ยงสูง สถานการณ์ต่างออกไปในสามมิติ มิติแรกคือปริมาณข้อมูลอ่อนไหวที่ไหลผ่านช่องทางนี้ ทั้งข้อมูลบัญชี ข้อมูลกรมธรรม์ หรือข้อมูลธุรกรรม มิติที่สองคือจำนวนโดเมนและแบรนด์ที่มักมีมากกว่าหนึ่งชื่อ เกิดจากการซื้อกิจการ การเปิดผลิตภัณฑ์ใหม่ หรือการทำแคมเปญการตลาดเฉพาะกิจ และมิติที่สามคือระดับความคาดหวังจากคู่ค้า ผู้ถือหุ้น และหน่วยงานกำกับ ที่มักตั้งคำถามเรื่องการดูแลความปลอดภัยของข้อมูลระหว่างทางเป็นส่วนหนึ่งของการประเมินความเสี่ยงคู่ค้า (Third-party Risk Assessment) เป็นประจำ

โครงสร้างการกำกับดูแล HTTPS และ TLS เมื่อองค์กรมีหลายโดเมนและหลายแบรนด์

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

ทำไมองค์กรที่มีหลายแบรนด์มักมีปัญหาเรื่องนี้เป็นพิเศษ

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

ใครควรเป็นเจ้าของใบรับรองและนโยบาย TLS ในองค์กร

ในทางปฏิบัติ บทบาทความรับผิดชอบมักแบ่งเป็นสามระดับ ระดับแรกคือทีม Security หรือ Infrastructure ส่วนกลาง ซึ่งควรเป็นเจ้าของนโยบายทางเทคนิค เช่น เวอร์ชัน TLS ขั้นต่ำที่ยอมรับได้และการตั้งค่า HSTS ระดับที่สองคือเจ้าของธุรกิจ (Business Owner) ของแต่ละโดเมนหรือแบรนด์ ซึ่งควรรับผิดชอบเรื่องการจดทะเบียนโดเมนและงบประมาณต่ออายุใบรับรอง และระดับที่สามคือผู้ให้บริการภายนอกอย่าง CDN หรือ Hosting ที่มักเป็นผู้ดำเนินการออกและต่ออายุใบรับรองอัตโนมัติในทางปฏิบัติจริง

จุดที่ฝ่ายกฎหมายและ Compliance ควรเข้าไปตรวจสอบคือช่องว่างระหว่างสามระดับนี้ เพราะเมื่อเกิดเหตุใบรับรองหมดอายุโดยไม่มีใครรู้ตัว มักเป็นเพราะไม่มีใครยอมรับว่าตนเองคือเจ้าของขั้นสุดท้าย (Accountable Owner) ไม่ใช่แค่ผู้รับผิดชอบปฏิบัติงาน (Responsible Party) การเขียนตารางความรับผิดชอบแบบ RACI สำหรับแต่ละโดเมนจึงเป็นเครื่องมือที่ช่วยปิดช่องว่างนี้ได้ตรงจุด

การต่ออายุใบรับรองและความเสี่ยงจากใบรับรองหมดอายุโดยไม่รู้ตัว

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

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

HSTS และ HSTS Preload: ผลกระทบเชิงนโยบายเมื่อใช้กับหลายโดเมน

HTTP Strict Transport Security (HSTS) เป็นคำสั่งที่เว็บไซต์ส่งให้เบราว์เซอร์บันทึกไว้ว่าโดเมนนี้ต้องเข้าถึงผ่าน HTTPS เท่านั้นในช่วงเวลาที่กำหนด หากตั้งค่า includeSubDomains ร่วมด้วย คำสั่งนี้จะครอบคลุมโดเมนย่อยทั้งหมดโดยอัตโนมัติ ส่วน HSTS Preload คือการส่งโดเมนเข้าไปอยู่ในรายการที่ฝังมากับตัวเบราว์เซอร์เองตั้งแต่ต้น ทำให้แม้แต่การเชื่อมต่อครั้งแรกก็ถูกบังคับให้ใช้ HTTPS โดยไม่ต้องรอคำสั่งจากเซิร์ฟเวอร์ก่อน

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

สัญญาและ SLA กับผู้ให้บริการ CDN และผู้ออกใบรับรองที่ฝ่ายกฎหมายควรตรวจ

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

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

Audit Trail และหลักฐานที่ฝ่าย Compliance ควรเก็บไว้

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

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

ใบรับรอง TLS หมดอายุแล้วเว็บไซต์จะเกิดอะไรขึ้น

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

องค์กรที่มีหลายโดเมนควรรวมศูนย์การจัดการใบรับรองหรือไม่

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

HSTS Preload คืออะไร และควรเปิดใช้เมื่อไร

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

ใครควรเป็นผู้อนุมัติการเปลี่ยนแปลงค่า TLS ในองค์กร

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

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

• ทำบัญชีโดเมนและใบรับรอง TLS ทั้งหมดขององค์กรไว้ในที่เดียว พร้อมวันหมดอายุของแต่ละใบ
• กำหนดเจ้าของรับผิดชอบขั้นสุดท้าย (Accountable Owner) ต่อโดเมนหรือแบรนด์แต่ละกลุ่มให้ชัดเจนด้วยตาราง RACI
• ตั้งระบบแจ้งเตือนล่วงหน้าก่อนใบรับรองหมดอายุอย่างน้อยสามสิบวัน ไม่พึ่งพาความจำของพนักงานคนใดคนหนึ่ง
• ทบทวนสัญญาและข้อกำหนดความรับผิดชอบกับผู้ให้บริการ CDN และผู้ออกใบรับรองอย่างน้อยปีละครั้ง
• กำหนดกระบวนการอนุมัติก่อนเปิดใช้หรือแก้ไขค่า HSTS โดยเฉพาะ includeSubDomains และการส่งเข้ารายการ Preload
• เก็บบันทึกการเปลี่ยนแปลงค่า TLS และ HSTS ทุกครั้งไว้เป็นหลักฐานสำหรับผู้ตรวจสอบภายในและคู่ค้า

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

• ปล่อยให้แต่ละทีมหรือแต่ละแบรนด์จัดการใบรับรองของตัวเองโดยไม่มีบัญชีกลาง จนไม่มีใครรู้ภาพรวมว่าองค์กรมีโดเมนใดบ้างที่ต้องดูแล
• เปิดใช้ HSTS Preload บนโดเมนหลักโดยไม่ตรวจสอบก่อนว่าโดเมนย่อยทุกตัวพร้อมใช้ HTTPS จริง จนบางส่วนใช้งานไม่ได้หลังเปิด
• รอจนใบรับรองหมดอายุแล้วค่อยแก้ปัญหาแบบเร่งด่วน แทนที่จะมีระบบแจ้งเตือนล่วงหน้าและปฏิทินต่ออายุที่ชัดเจน
• เซ็นสัญญากับผู้ให้บริการ CDN หรือโฮสติ้งโดยไม่ระบุความรับผิดชอบเรื่องการเฝ้าระวังและต่ออายุใบรับรองให้ชัดเจนเป็นลายลักษณ์อักษร

สรุป

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

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

• OWASP HTTP Headers Cheat Sheet
• OWASP Transport Layer Security Cheat Sheet
• คู่มือ Website Security ทั้งหมดของ trusty
• วิธี Audit HTTPS และ TLS พร้อม Evidence สำหรับองค์กรความเสี่ยงสูง