รูปแบบการนำ Mutual TLS (mTLS) ไปใช้งาน

TLS มาตรฐานยืนยันตัวตนเฉพาะเซิร์ฟเวอร์ต่อไคลเอนต์ผ่านใบรับรอง TLS แบบสองทาง (mTLS) ขยายความสามารถนี้โดยให้ทั้งสองฝ่ายนำเสนอและตรวจสอบใบรับรอง ไคลเอนต์จะนำเสนอใบรับรองของไคลเอนต์หลังจากเซิร์ฟเวอร์ร้องขอผ่าน CertificateRequest ในการจับมือของ TLS เซิร์ฟเวอร์ตรวจสอบใบรับรองของไคลเอนต์กับ CA ที่เชื่อถือได้ mTLS เป็นรากฐานของเครือข่ายแบบไม่ไว้วางใจโดยปริยาย แทนที่จะพึ่งพาการรักษาความปลอดภัยที่ขอบเขตเครือข่าย บริการต่าง ๆ จะยืนยันตัวตนระหว่างกันด้วยการเข้ารหัสในการเชื่อมต่อทุกครั้ง Service mesh อย่าง Istio, Linkerd และ Consul Connect ใช้ mTLS ระหว่างไมโครเซอร์วิสอย่างโปร่งใส

การจับมือของ mTLS ขยาย TLS 1.3 ดังนี้ หลังจาก ServerHello และใบรับรอง/ข้อความเสร็จสิ้นของเซิร์ฟเวอร์ เซิร์ฟเวอร์จะส่งข้อความ CertificateRequest ซึ่งระบุผู้ออกใบรับรองและอัลกอริทึมลายเซ็นที่ยอมรับได้ ไคลเอนต์ตอบกลับด้วย Certificate (ห่วงโซ่ใบรับรองของไคลเอนต์) และ CertificateVerify (ลายเซ็นบนบันทึกการจับมือ ซึ่งสร้างด้วยกุญแจส่วนตัวของไคลเอนต์) เซิร์ฟเวอร์ตรวจสอบห่วงโซ่ใบรับรองของไคลเอนต์กับที่เก็บ CA ที่เชื่อถือได้ และตรวจสอบลายเซ็น CertificateVerify หากการตรวจสอบทั้งสองรายการผ่าน การเชื่อมต่อจะได้รับการยืนยันตัวตนร่วมกัน ไคลเอนต์ไม่สามารถปลอมแปลง CertificateVerify ได้หากไม่มีกุญแจส่วนตัวที่สอดคล้องกับใบรับรอง

ในสภาพแวดล้อมของ Service mesh ใบรับรองของไคลเอนต์มักออกโดย CA ภายใน Istio ใช้ SVID ของ SPIFFE (กรอบงานข้อมูลประจำตัวสำหรับการใช้งานจริงที่ปลอดภัยสำหรับทุกคน): เวิร์กโหลดแต่ละรายการจะได้รับใบรับรองที่มี URI SAN ของ SPIFFE (ชื่อทางเลือกของหัวเรื่อง) เช่น spiffe://cluster.local/ns/default/sa/payment-service ใบรับรองเหล่านี้มีอายุสั้น (24 ชั่วโมง) และถูกสับเปลี่ยนโดยอัตโนมัติโดยระนาบควบคุมของ mesh (istiod) ใน mTLS สำหรับผู้ใช้ทั่วไป (เช่น VPN ระดับองค์กรและไคลเอนต์ API) ใบรับรองอาจออกโดย CA ขององค์กร มีอายุการใช้งานนานกว่า และส่งไปยังอุปกรณ์ของพนักงานผ่าน MDM

การตรวจสอบ mTLS ฝั่งเซิร์ฟเวอร์ประกอบด้วยหลายขั้นตอน: (1) การตรวจสอบห่วงโซ่ — ตรวจสอบว่าใบรับรองของไคลเอนต์เชื่อมโยงย้อนกลับไปยัง CA รากที่เชื่อถือได้ในที่เก็บ CA ของไคลเอนต์บนเซิร์ฟเวอร์ (2) การตรวจสอบช่วงเวลาที่มีผล — ตรวจสอบว่าใบรับรองยังไม่หมดอายุและมีผลใช้งานแล้ว (3) การตรวจสอบการเพิกถอน — ตรวจสอบผ่าน OCSP หรือ CRL ว่าใบรับรองยังไม่ถูกเพิกถอน (4) การจับคู่ SAN/CN — ดึงข้อมูลระบุตัวตนจาก SAN ของใบรับรอง เช่น URI ของ SPIFFE ชื่อ DNS หรืออีเมล (5) การอนุญาต — ตรวจสอบว่าข้อมูลระบุตัวตนที่ผ่านการยืนยันแล้วมีสิทธิ์เข้าถึงทรัพยากรที่ร้องขอ ขั้นตอนที่ 4 และ 5 ต้องใช้ตรรกะระดับแอปพลิเคชันเพิ่มเติมนอกเหนือจากการกำหนดค่า TLS พื้นฐาน

ใบรับรองอายุสั้นช่วยขจัดความจำเป็นในการเพิกถอนอย่างชัดแจ้ง หากใบรับรองหมดอายุภายใน 24 ชั่วโมง ช่วงเวลาที่ได้รับผลกระทบจากการถูกบุกรุกก็จะจำกัด การสับเปลี่ยนต้องดำเนินการดังนี้: (1) การสับเปลี่ยนล่วงหน้า — ออกใบรับรองใหม่ก่อนใบรับรองเก่าหมดอายุ โดยสับเปลี่ยนเมื่อใช้งานไปแล้ว 80% ของอายุการใช้งาน (2) การสลับโดยไม่หยุดให้บริการ — บริการต้องยอมรับทั้งใบรับรองเก่าและใหม่ในช่วงเปลี่ยนผ่าน (3) การโหลดใหม่อย่างราบรื่น — สแตก TLS ต้องโหลดข้อมูลรับรองใหม่โดยไม่ตัดการเชื่อมต่อที่มีอยู่ (nginx: nginx -s reload; Envoy: การอัปเดตใบรับรองแบบไดนามิกผ่าน xDS) SPIFFE Workload API ซึ่ง SPIRE นำไปใช้ จะทำให้การส่งมอบและการสับเปลี่ยนใบรับรองเป็นแบบอัตโนมัติผ่าน API ของซ็อกเก็ตโดเมน Unix

Istio ทำ mTLS อย่างโปร่งใสผ่านพร็อกซีไซด์คาร์ของ Envoy ที่แทรกเข้าไปในแต่ละพ็อด ระนาบควบคุม (istiod) ทำหน้าที่เป็น CA โดยใช้ใบรับรองขั้นกลางที่ลงนามโดย CA รากของเมช ไซด์คาร์ของแต่ละพ็อดจะได้รับ SPIFFE SVID ผ่านส่วนติดต่อ SDS (บริการค้นหาความลับ) นโยบาย PeerAuthentication ใช้กำหนดโหมด mTLS ได้แก่ STRICT (ต้องใช้ mTLS), PERMISSIVE (ยอมรับทั้ง mTLS และข้อความธรรมดาสำหรับการย้ายระบบ) หรือ DISABLE ทรัพยากร AuthorizationPolicy ใช้กำหนดว่าบริการใดสามารถสื่อสารกันได้ โดยตรวจสอบกับข้อมูลประจำตัว SPIFFE ในใบรับรองของไคลเอนต์ วิธีนี้ทำให้เกิดสถาปัตยกรรมความเชื่อถือเป็นศูนย์ภายในคลัสเตอร์โดยไม่ต้องแก้ไขโค้ดของแอปพลิเคชัน

สำหรับไคลเอนต์ภายนอกของส่วนติดต่อโปรแกรมประยุกต์ mTLS ให้การตรวจสอบสิทธิ์ที่รัดกุมกว่าคีย์ส่วนติดต่อโปรแกรมประยุกต์หรือโทเค็น OAuth ไคลเอนต์เก็บคีย์ส่วนตัวไว้ในพื้นที่จัดเก็บที่ปลอดภัย (HSM, ที่เก็บคีย์ของ OS หรือคีย์ซอฟต์แวร์ที่มีรหัสผ่าน) ใบรับรองของไคลเอนต์จะถูกผูกไว้กับ CA ที่คาดหมายของปลายทางส่วนติดต่อโปรแกรมประยุกต์ คำขอแต่ละรายการของส่วนติดต่อโปรแกรมประยุกต์จะได้รับการตรวจสอบสิทธิ์ที่ชั้น TLS จึงไม่ต้องใช้ส่วนหัว Authorization แยกต่างหาก API Shield ของ Cloudflare, ใบรับรองไคลเอนต์ของ AWS API Gateway และ mTLS ของบัญชีบริการใน Google Cloud ล้วนใช้รูปแบบนี้ คีย์ส่วนติดต่อโปรแกรมประยุกต์ที่ถูกเจาะสามารถนำไปใช้จากที่ใดก็ได้ แต่คีย์ส่วนตัว mTLS ที่ถูกเจาะยังต้องขโมยอุปกรณ์ที่ใช้เรียกไคลเอนต์ด้วย

การนำ mTLS ไปใช้งานมีความท้าทายด้านปฏิบัติการหลายประการ (1) การแจกจ่ายใบรับรอง — ต้องส่งใบรับรองไคลเอนต์ให้บริการทั้งหมดอย่างปลอดภัย โดยเฉพาะในสภาพแวดล้อมแบบพลวัตที่จำนวนพ็อดเพิ่มและลดอยู่เสมอ (2) CA ถูกเจาะ — CA ภายในเป็นเป้าหมายมูลค่าสูง หากถูกเจาะ ใบรับรองของบริการทั้งหมดจะถูกทำให้ใช้ไม่ได้ CA ที่มี HSM รองรับและ CA รากแบบออฟไลน์ช่วยลดความเสี่ยงนี้ (3) การแก้ไขข้อบกพร่อง — เครื่องมือแก้ไขข้อบกพร่องทั่วไปไม่สามารถมองเห็นทราฟฟิก mTLS ที่เข้ารหัสได้ จึงต้องใช้การสังเกตการณ์ของเมชบริการ เช่น Jaeger และ Kiali (4) ความเข้ากันได้กับอุปกรณ์คั่นกลาง — พร็อกซีตรวจสอบ TLS จะทำให้ mTLS ใช้งานไม่ได้ เว้นแต่จะกำหนดค่าอย่างชัดเจนให้ส่งต่อใบรับรองไคลเอนต์ (5) เหตุการณ์ใบรับรองหมดอายุ — ความล้มเหลวในการหมุนเวียนใบรับรองอาจทำให้บริการทั้งหมดหยุดทำงาน

SPIFFE (กรอบงานข้อมูลประจำตัวสำหรับเวิร์กโหลดในระบบการผลิตสำหรับทุกคน) กำหนดมาตรฐานสำหรับข้อมูลประจำตัวของเวิร์กโหลดโดยใช้ SVID แบบ X.509 SPIRE (สภาพแวดล้อมขณะทำงานของ SPIFFE) คือการนำมาตรฐานดังกล่าวมาใช้เป็นต้นแบบ SPIRE Server ทำหน้าที่เป็นหน่วยงานลงทะเบียนและ CA SPIRE Agents ทำงานบนแต่ละโหนด รับรองข้อมูลประจำตัวของเวิร์กโหลดโดยใช้ตัวรับรองโหนด (ข้อมูลประจำตัวอินสแตนซ์ของ AWS, JWT ของบัญชีบริการ Kubernetes และ TPM) และตัวรับรองเวิร์กโหลด (PID ของ Unix และข้อมูลเมทาดาทาของรันไทม์คอนเทนเนอร์) ส่วนติดต่อ Workload จะส่ง SVID ให้เวิร์กโหลดผ่านซ็อกเก็ตโดเมน Unix โดยใช้ส่วนติดต่อ gRPC แบบง่าย SPIRE ทำงานร่วมกับ Envoy, Nginx และเมชบริการหลักในฐานะแหล่งใบรับรอง

สำหรับการนำ mTLS ไปใช้กับระบบความปลอดภัยสูง ควรเก็บคีย์ส่วนตัวไว้ในโมดูลความปลอดภัยฮาร์ดแวร์ (HSM) แทนที่เก็บคีย์ซอฟต์แวร์ ไลบรารี TLS (OpenSSL, BoringSSL) โหลดคีย์ส่วนตัวผ่านส่วนติดต่อ PKCS#11 ซึ่งเปลี่ยนเส้นทางการดำเนินการลงนามไปยัง HSM คีย์ส่วนตัวจะไม่ออกจากขอบเขตของ HSM ในรูปแบบข้อความธรรมดา ตัวเลือก HSM บนคลาวด์ ได้แก่ AWS CloudHSM, Azure Dedicated HSM และ Google Cloud HSM สำหรับ mTLS ระดับอุปกรณ์ (อินเทอร์เน็ตของสรรพสิ่งและแล็ปท็อปขององค์กร) TPM 2.0 มีหน้าที่คล้ายกัน โดยคีย์ไคลเอนต์ TLS จะผูกกับ TPM และการลงนามต้องได้รับการอนุญาตจาก TPM ทำให้การดึงคีย์ออกจากอุปกรณ์ที่ถูกเจาะทำได้ยากอย่างยิ่ง

การทดสอบ mTLS ต้องใช้เครื่องมือที่รองรับการส่งใบรับรองไคลเอนต์ OpenSSL s_client: openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem. curl: curl --cert client.pem --key client.key --cacert server-ca.pem https://host. สำหรับการทดสอบเมชบริการ istioctl proxy-config secret pod/name จะแสดงใบรับรองปัจจุบันและเวลาหมดอายุ ใช้ kubectl exec เข้าไปในพ็อด แล้วใช้ curl กับปลายทางผู้ดูแลระบบของไซด์คาร์ (localhost:15000) เพื่อตรวจสอบตัวรับฟังที่ทำงานอยู่และการกำหนดค่า mTLS ของตัวรับฟังเหล่านั้น การทดสอบการหมุนเวียนอัตโนมัติควรตรวจสอบว่าการเชื่อมต่อยังคงเสถียรตลอดเหตุการณ์หมุนเวียนใบรับรอง

mTLS เพิ่มขั้นตอนใดเมื่อเทียบกับ TLS มาตรฐาน

mTLS เพิ่มการตรวจสอบสิทธิ์ด้วยใบรับรองไคลเอนต์ให้กับ TLS โดยทั้งสองฝ่ายจะตรวจสอบใบรับรองของอีกฝ่าย SVID ของ SPIFFE ให้ข้อมูลประจำตัวเวิร์กโหลดที่เป็นมาตรฐานผ่าน URI ของ SPIFFE ใน SAN ของใบรับรอง Istio ทำ mTLS อย่างโปร่งใสผ่านไซด์คาร์ของ Envoy โดยมีโหมด STRICT และ PERMISSIVE ใบรับรองอายุสั้น (24 ชั่วโมง) ทำให้ไม่จำเป็นต้องเพิกถอนใบรับรองและจำกัดช่วงเวลาที่ผู้โจมตีใช้ประโยชน์ได้ SPIRE ทำให้การออกและหมุนเวียนใบรับรองเป็นอัตโนมัติผ่านส่วนติดต่อ Workload ควรเก็บคีย์ส่วนตัว mTLS ไว้ใน HSM หรือ TPM สำหรับการนำไปใช้กับระบบความปลอดภัยสูง ความท้าทายด้านปฏิบัติการ ได้แก่ การปกป้องคีย์ของ CA ความเข้ากันได้กับอุปกรณ์คั่นกลาง และการหมุนเวียนโดยไม่ทำให้บริการหยุดทำงาน