ข้ามไปยังเนื้อหา
THAI DATA IT BUSINESS
ENTERPRISE
Cloud

Azure keyless TLS เปิดใช้ทั่วไป Application Gateway ถอดรหัส TLS โดยกุญแจอยู่ใน Managed HSM

Azure keyless TLS เปิดใช้ทั่วไป 20 ต.ค. 2026 ให้ Application Gateway ถอดรหัส TLS โดยเซ็น handshake ใน Azure Key Vault Managed HSM กุญแจส่วนตัวไม่ถูกส่งออก

โดย กองบรรณาธิการ THAI DATA อ่าน 5 นาที

แชร์FacebookXLINELinkedIn
แผนภาพ Azure keyless TLS ของ Microsoft: ผู้ใช้เชื่อมต่อ HTTPS ไปที่ Application Gateway และ WAF ซึ่งเรียก Azure Managed HSM ให้เซ็นด้วยกุญแจที่ส่งออกไม่ได้ ระดับ FIPS 140-3 L3 ก่อนส่งคำขอไปยัง backend
ภาพ: Microsoft

สรุปประเด็นสำคัญ

  • Azure Updates ประกาศเมื่อ 20 ตุลาคม 2026 ว่า Azure keyless TLS บน Azure Application Gateway เปิดใช้ทั่วไป (GA) ทุกลายเซ็นของ TLS handshake ทำใน Azure Key Vault Managed HSM และกุญแจส่วนตัวไม่ถูกส่งออกไปที่ gateway
  • Microsoft ระบุว่าองค์กรจะได้หลักฐานทางการเข้ารหัสว่ากุญแจ TLS ถูกสร้างและเก็บใน HSM ที่ผ่านการรับรอง FIPS 140-3 Level 3 และดูการเซ็นแต่ละครั้งได้จาก diagnostic log ของ Managed HSM
  • ต้องใช้ Application Gateway v2, Managed HSM, user-assigned managed identity และเครื่อง Linux ที่มี OpenSSL 3.0.13 สำหรับสร้างใบรับรอง
  • listener ต้องใช้ TLS 1.2 ขึ้นไป และยังไม่รองรับ AGIC, WebSockets, L4 TCP/TLS proxy, FIPS mode และกุญแจแบบ EC
  • วันเดียวกัน Azure เปิดใช้ทั่วไป service tag match ใน WAF ของ Azure Front Door Premium และเปิดพรีวิว disable VNet peering route สำหรับเครือข่าย hub-and-spoke

Microsoft เปิดใช้ทั่วไป (General Availability) Azure keyless TLS บน Azure Application Gateway ตามประกาศใน Azure Updates วันที่ 20 ตุลาคม 2026 ให้ gateway ถอดรหัส TLS ด้วยใบรับรองที่กุญแจส่วนตัวอยู่ใน Azure Key Vault Managed HSM ตลอดเวลา ทุกลายเซ็นของ TLS handshake ทำภายใน HSM และกุญแจไม่ถูกส่งออกไปที่ gateway

Microsoft ระบุว่าการเชื่อมต่อนี้ช่วยให้องค์กรเก็บกุญแจไว้ในขอบเขตของ HSM เฉพาะ ใช้ managed identity และ RBAC คุมสิทธิ์เข้าถึงกุญแจ ดูการเซ็นแต่ละครั้งผ่าน diagnostic log ของ Managed HSM และมีหลักฐานทางการเข้ารหัสว่ากุญแจ TLS ถูกสร้างและเก็บใน HSM ที่ผ่านการรับรอง FIPS 140-3 Level 3 วันเดียวกัน Azure Updates ยังประกาศอัปเดตด้านเครือข่ายอีก 2 รายการ คือ service tag match ใน WAF ของ Azure Front Door Premium และการปิด peering route ของ Virtual Network

Azure keyless TLS ทำงานอย่างไร

ในคู่มือของ Microsoft ขั้นแรก gateway ทดสอบยังใช้ใบรับรองจากไฟล์ .pfx ที่มีกุญแจส่วนตัวอยู่ในตัว ก่อนเปลี่ยนเป็นใบรับรองที่ผูกกับ HSM ส่วน Azure keyless TLS ให้ gateway ถือเฉพาะส่วนสาธารณะของใบรับรอง แล้วเรียก Managed HSM ทุกครั้งที่ต้องใช้กุญแจ ลำดับการทำงานตามเอกสาร Microsoft Learn คือ

  1. ผู้ใช้เปิดการเชื่อมต่อ HTTPS ไปที่ listener ของ gateway
  2. gateway เรียก Managed HSM ให้เซ็นด้วยกุญแจที่ส่งออกไม่ได้ (non-exportable)
  3. Managed HSM ส่งลายเซ็นกลับ และ TLS handshake เสร็จสมบูรณ์
  4. WAF ตรวจคำขอ แล้วส่งต่อไปยังเซิร์ฟเวอร์ปลายทาง (backend)
  5. backend ส่งคำตอบกลับมาที่ gateway
  6. gateway ส่งคำตอบให้ผู้ใช้ผ่าน TLS

เอกสารระบุว่าแนวทางนี้เหมาะเมื่อต้องการให้ Application Gateway ยังทำ TLS termination ได้ แต่กุญแจต้องอยู่ในขอบเขตของ HSM และยังช่วยเรื่องการแยกหน้าที่ การจัดการกุญแจจากศูนย์กลาง และการตรวจสอบย้อนหลัง

หน้า Microsoft Learn ส่วน Why use it, Requirements และ Considerations ของ keyless TLS บน Azure Application Gateway
เอกสาร Microsoft Learn ส่วน Why use it และ Requirements ของ Azure keyless TLS ระบุประโยชน์ เช่น เก็บกุญแจใน HSM และหลักฐาน FIPS 140-3 Level 3 กับสิ่งที่ต้องมี เช่น Application Gateway v2 และ OpenSSL 3.0.13 ภาพ: Microsoft Learn (ภาพหน้าจอ)

สิ่งที่ต้องเตรียมก่อนเปิด Azure keyless TLS

  • Application Gateway v2 และ Azure Key Vault Managed HSM หนึ่งชุด
  • user-assigned managed identity สำหรับ Application Gateway พร้อมสิทธิ์ RBAC บทบาท Managed HSM Crypto User บนกุญแจ Microsoft แนะนำให้จำกัดสิทธิ์ให้แคบที่สุด ซึ่งกำหนดได้ถึงระดับกุญแจเดียว (/keys/<key-name>)
  • เครื่อง Linux ที่มี OpenSSL 3.0.13 และ TLS offload library ของ Managed HSM สำหรับสร้างใบรับรอง คู่มือแนะนำ Ubuntu 24.04 LTS และเตือนว่า OpenSSL รุ่นอื่นอาจโหลด engine ไม่ได้
  • ระหว่างตั้งค่าต้องมีบทบาท Managed HSM Crypto Officer สำหรับตั้งค่า HSM ครั้งแรก และ Owner หรือ User Access Administrator สำหรับมอบสิทธิ์
  • ตัวอย่างในคู่มือสร้างกุญแจชนิด RSA-HSM ขนาด 2048 บิตใน HSM แล้วใช้กุญแจนั้นเซ็นใบรับรอง ก่อนนำส่วนสาธารณะไปผูกกับ listener ใหม่

การตรวจสอบหลังเปิดใช้ทำผ่าน diagnostic setting ของ Managed HSM โดยส่งหมวด AuditEvent ไปยัง Log Analytics workspace แล้วค้นรายการ KeySign เพื่อยืนยันว่า gateway ส่งงานเซ็นไปที่ HSM จริงระหว่าง handshake

ข้อจำกัดของ Azure keyless TLS

ประเด็น เงื่อนไขตามคู่มือ Microsoft Learn
เวอร์ชัน TLS listener ต้องใช้ TLS 1.2 ขึ้นไป
SSL policy AppGwSslPolicy20220101, AppGwSslPolicy20220101S และ CustomV2 เท่านั้น
ยังไม่รองรับ AGIC, WebSockets, L4 TCP/TLS proxy, FIPS mode และกุญแจแบบ EC
การเปลี่ยนใบรับรอง อาจไม่มีผลในการอัปเดตครั้งแรก ต้องแก้ gateway อีกเล็กน้อย เช่น แก้ tag หรือถอดแล้วใส่การอ้างอิง HSM ใหม่
listener ถูกปิด เกิดได้เมื่อ gateway ยืนยันตัวตนกับ HSM ไม่ได้เพราะ RBAC ผิด หรือกุญแจที่อ้างถึงถูกลบ
ปริมาณงาน ให้ดูแนวทาง scaling และ service limits ของ Managed HSM ประกอบการวางแผน
หน้า Microsoft Learn ส่วน Limitations ของ Azure keyless TLS ระบุ TLS 1.2 ขึ้นไป SSL policy ที่รองรับ และสถานการณ์ที่ยังไม่รองรับ
รายการข้อจำกัดของ Azure keyless TLS ในคู่มือ Microsoft Learn เช่น ต้องใช้ TLS 1.2 ขึ้นไป SSL policy ที่รองรับ และสถานการณ์ที่ยังไม่รองรับอย่าง WebSockets และกุญแจแบบ EC ภาพ: Microsoft Learn (ภาพหน้าจอ)

อัปเดตเครือข่าย Azure อื่นในวันเดียวกัน

  • Service tag match ใน WAF ของ Azure Front Door Premium (GA) custom rule ตรวจ IP ต้นทางของคำขอเทียบกับ service tag ได้ จึงอนุญาตบริการ Azure ที่แอปพึ่งพา เช่น monitoring และ health check บล็อกบริการที่ไม่ควรติดต่อเข้ามา จำกัดเส้นทางอ่อนไหวอย่างหน้าผู้ดูแล หรือจำกัดอัตรา (rate limit) แทนการบล็อก เอกสารเตือนว่าการอนุญาตด้วย RemoteAddr ซึ่งอ่านจาก X-Forwarded-For ปลอมได้ง่ายกว่า SocketAddr
  • Disable VNet peering route (public preview) ระงับ peering route ที่ระบบสร้างเองบน subnet ที่ผูกกับ route table โดยยังคงการ peering ไว้ ใช้คู่กับ user-defined route แบบสรุปเพื่อบังคับทราฟฟิกผ่าน Azure Firewall หรือ NVA ในเครือข่าย hub-and-spoke ขนาดใหญ่ แต่ฟีเจอร์ไม่สร้าง UDR ให้เอง และช่วงพรีวิว next hop ต้องอยู่ใน VNet เดียวกับ network interface ของงานต้นทาง
แผนภาพเปรียบเทียบเส้นทางใน hub subnet เมื่อเปิด peering route ตามปกติ กับเมื่อตั้ง disablePeeringRoute เป็น All ให้ทราฟฟิกจาก on-premises ผ่าน Azure Firewall หรือ NVA
แผนภาพของ Microsoft เทียบเส้นทางจาก on-premises ไปยัง spoke เมื่อเปิด peering route ตามปกติซึ่งทราฟฟิกข้าม firewall กับเมื่อตั้ง disablePeeringRoute เป็น All ซึ่งทราฟฟิกผ่าน Azure Firewall หรือ NVA ภาพ: Microsoft

ทำไมเรื่องนี้สำคัญ

เอกสารของ Microsoft ระบุว่า Azure keyless TLS ช่วยลดการเปิดเผยกุญแจที่อ่อนไหวบนอุปกรณ์เครือข่าย และให้หลักฐานว่ากุญแจ TLS ถูกสร้างและเก็บใน HSM ที่ผ่าน FIPS 140-3 Level 3 ซึ่งตอบโจทย์องค์กรที่ผู้ตรวจสอบต้องการเห็นว่ากุญแจของใบรับรองหน้าเว็บอยู่ที่ไหนและใครใช้ได้ ประกาศนี้ออกมาไม่กี่วันหลัง Azure Updates ลงประกาศเมื่อ 16 ตุลาคมว่าAzure External Key Management ที่ให้เก็บกุญแจหลักไว้ใน HSM ของตัวเองเปิดใช้ทั่วไป ทั้งสองฟีเจอร์ทำงานบน Azure Key Vault Managed HSM ตัวหนึ่งดูแลกุญแจเข้ารหัสข้อมูล อีกตัวดูแลกุญแจ TLS ของ gateway

ผลต่อองค์กรไทย

  • เช็กความพร้อมของ gateway ก่อน Azure keyless TLS ใช้ได้เฉพาะ Application Gateway v2 ที่ listener ใช้ TLS 1.2 ขึ้นไปและ SSL policy ที่รองรับ แอปที่ใช้ WebSockets หรือรันผ่าน AGIC บน AKS ยังใช้ไม่ได้
  • ทดสอบโหลดก่อนใช้จริง เพราะทุก TLS handshake ต้องเรียก Managed HSM ให้เซ็น ควรดูแนวทาง scaling และ service limits ของ Managed HSM ตามที่ Microsoft แนะนำ ก่อนย้ายเว็บที่มีผู้ใช้มาก
  • แบ่งหน้าที่ให้ชัดเมื่อใช้ Azure keyless TLS ทีมความปลอดภัยถือ Managed HSM และกุญแจ ทีมเครือข่ายดูแล gateway และจำกัดสิทธิ์ของ managed identity ไว้ที่กุญแจเดียว
  • เปิด log การเซ็นตั้งแต่วันแรก ส่ง AuditEvent ของ Managed HSM ไป Log Analytics เพื่อใช้เป็นหลักฐานสำหรับผู้ตรวจสอบและใช้ตรวจหาความผิดปกติ
  • ปรับขั้นตอนต่ออายุใบรับรอง คู่มือระบุว่าการเปลี่ยนใบรับรองอาจไม่มีผลในการอัปเดตครั้งแรก ทีมควรเขียนขั้นตอนตรวจซ้ำไว้ใน runbook

ติดตามข่าว Microsoft Azure และบริการคลาวด์อื่นได้ที่หมวดคลาวด์

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

Azure keyless TLS คืออะไร?

Azure keyless TLS คือความสามารถของ Azure Application Gateway ที่ถอดรหัส TLS ด้วยใบรับรองซึ่งกุญแจส่วนตัวอยู่ใน Azure Key Vault Managed HSM ตลอดเวลา gateway ได้เพียงส่วนสาธารณะของใบรับรอง และเรียก Managed HSM ให้เซ็นทุกครั้งที่มี TLS handshake เปิดใช้ทั่วไปเมื่อ 20 ตุลาคม 2026

Azure keyless TLS ใช้กับแอปแบบไหนไม่ได้?

เอกสาร Microsoft Learn ระบุว่า Azure keyless TLS ยังไม่รองรับ Application Gateway Ingress Controller (AGIC), WebSockets, L4 TCP/TLS proxy, FIPS mode และกุญแจแบบ EC ส่วน listener ต้องใช้ TLS 1.2 ขึ้นไปและ SSL policy ที่รองรับเท่านั้น

ต้องเตรียมอะไรก่อนใช้ keyless TLS บน Application Gateway?

ต้องมี Application Gateway v2, Azure Key Vault Managed HSM, user-assigned managed identity ที่ได้สิทธิ์ RBAC บนกุญแจใน HSM และเครื่อง Linux ที่ติดตั้ง OpenSSL 3.0.13 กับ TLS offload library ของ Managed HSM สำหรับสร้างใบรับรอง Microsoft แนะนำ Ubuntu 24.04 LTS

ตรวจสอบได้อย่างไรว่า Application Gateway เรียก HSM จริง?

Microsoft แนะนำให้เปิด diagnostic setting ของ Managed HSM ส่งหมวด AuditEvent ไปยัง Log Analytics workspace แล้วค้นรายการ OperationName เป็น KeySign เพื่อยืนยันว่า Application Gateway ส่งงานเซ็นไปที่ Managed HSM ระหว่าง TLS handshake

แหล่งอ้างอิง

  1. Generally Available: Keyless TLS on Application Gateway with Azure Key Vault Managed HSM — Microsoft Azure
  2. What is keyless TLS for Azure Application Gateway and Azure Key Vault Managed HSM? — Microsoft Learn
  3. Configure keyless TLS termination with Azure Key Vault Managed HSM — Microsoft Learn
  4. Generally Available: Service tag match condition for Azure Front Door Premium WAF — Microsoft Azure
  5. Public Preview: Disable VNet peering route — Microsoft Azure

บุคคล องค์กร และสถานที่ในข่าวนี้

เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว

องค์กรและบริษัท
Microsoft81
ผลิตภัณฑ์และเทคโนโลยี
Microsoft Azure30Azure Application Gateway2Azure Key Vault3Linux33Ubuntu8Azure Firewall3
แท็กTLSAzure Front Door
แชร์FacebookXLINELinkedIn

พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ