TLS הדדי (mTLS)

Mutual TLS (mTLS) מרחיב את ה-TLS הסטנדרטי על ידי דרישה מהלקוח להציג אישור שהשרת מאמת. לחיצת היד מסתיימת כששני הצדדים מאומתים זה לזה באופן קריפטוגרפי. בהשוואה לאימות מבוסס סיסמה או אסימון, mTLS מציע ערבויות זהות חזקות יותר, סיבוב אישורים אוטומטי דרך מחזורי חיים של תעודות וביטול בעיות הפצה בסוד משותף.

הפרש לחיצת היד

In TLS סטנדרטי הלקוח מאמת את תעודת השרת מול חנויות אמון. השרת אינו מאמת את הלקוח מבחינה קריפטוגרפית - הוא מסתמך על מנגנוני שכבת יישומים (עוגיות, אסימוני נושא, אישור בסיסי).

ב-mTLS השרת מוסיף CertificateRequest במהלך לחיצת היד של TLS. הלקוח חייב להגיב עם אישור משלו בתוספת חתימה המוכיחה את החזקת המפתח הפרטי. השרת מאמת את אישור הלקוח מול חנות האמון שלו. אם האימות נכשל, החיבור נופל.

Where mTLS פרוס

• Microservices. מסגרות רשת שירות כמו Istio, Linkerd ו-Consul Connect משתמשות ב-mTLS לאימות שירות לשירות. לכל שירות מיקרו יש תעודה המזהה את זהותו; הרשת אוכפת מי יכול לקרוא למי.
• API gateways. ממשקי API פנימיים דורשים יותר ויותר אישורי לקוח ולא מפתחות API. זהות חזקה יותר, רוטציה אוטומטית באמצעות אישורים קצרי מועד.
• VPN ומוצרי Zero Trust. Cloudflare Access, Tailscale, BeyondCorp משתמשות בתעודות מכשיר לאימות.
• Government Bank-FRAM27XGovernment ו-Financial APIs. מערכות, ממשקי API צבאיים מחייבים לעתים קרובות את mTLS.
• IoT. תעודות לכל מכשיר קובעות זהות לניהול צי. AWS IoT, Azure IoT Hub, Google Cloud IoT כולם משתמשים באינטגרציות mTLS.
• WebHooks ו-B2B. משלוחי ה-webhook באבטחה גבוהה יותר מאמתים את שני הצדדים באמצעות אישורים. אסימונים
  • אין סודות משותפים. לכל צד יש רק מפתח פרטי משלו. התפשרות על האחסון של צד אחד לא חושפת את השני.
  • זהות חזקה. התעודה מאמת שהבעלים שולט במפתח הפרטי המתאים, ש-CA מהימן כובל לזהות מאומתת.
  • סבב אוטומטי של 5 ימים (חלונות קצרים-שעתיים) מוגבל לחלון 5 ימים. כל פשרה.
  • אין שימוש חוזר בסיסמה. לכל שירות יש אישור משלו; אין מושג של שימוש חוזר בסיסמאות בשירותים.
  • אין הפעלה חוזרת. האישור לבדו אינו שימושי ללא המפתח הפרטי, שלעולם אינו זז.
  • אימות הדדי קריפטוגרפי מובנה. שני הצדדים מאמתים זה את זה בסיבוב אחד. handshake.

  כיצד מונפקים אישורים

  סיפור הפריסה של mTLS סובב סביב הנפקת אישורים:

  • Internal PKI. הארגון מפעיל רשות אישורים משלו. כל שירות או לקוח מקבל אישור שהונפק על ידי אותו CA. אמון הוא פנימי.
  • SPIFFE / SPIRE. מסגרת זהות מקורית בענן. מנפיק אישורים קצרי מועד לעומסי עבודה המזוהים על ידי מזהים בסגנון URI. רשתות שירות משתמשות בדפוס זה.
  • HashiCorp Vault. Vault יכול לשמש כ-CA עבור mTLS פנימי, להנפיק אישורים קצרי מועד על פי דרישה לעומסי עבודה מאומתים.
  • Step CA-Source-Certifikat פתוח לשימוש פנימי ACPLZXX-style. מפחית את המורכבות התפעולית.
  • Public CAs. עבור B2B mTLS שבו שני הצדדים זקוקים לזהות מהימנה גלובלית, CAs מסחריים מנפיקים אישורי mTLS.

  האתגרים התפעוליים

  XLZT10000000000000000000000000000000000ul>
• ניהול אישורים. כל לקוח זקוק לאישור, שהונפקו, התחלף, נשלל בעת הצורך. ה-PKI הופך לתשתית קריטית.
• Distribution. השגת אישורים ללקוחות הנכונים בצורה מאובטחת - אתחול היא בעיה חוזרת.
• Debugging. כשלי mTLS קשים יותר לניפוי מאשר כשלים בסיסמאות. הכלים והצפיות חשובים.
• LBibrary support. רוב ספריות ה-HTTP המודרניות תומכות ב-mTLS, אבל התצורה מורכבת יותר מאuth.
• Browser limits. תמיכה בדפדפן עבור mTLS אבל קיימת תמיכה ב-client (client) mTLS בהקשרי אינטרנט נפוץ יותר שרת-לשרת מאשר דפדפן-לשרת.

mTLS ב-service meshes

The headline use case modern. רשת שירות כמו Istio:

1. כל שירות מקבל זהות עומס עבודה (SPIFFE ID).
2. מטוס הבקרה של הרשת מנפיק אישורים קצרי טווח (תקפים בדרך כלל לכמה שעות). ה-sidecar עוטף אותו ב-mTLS ליציאת רשת.
3. ה-sidecar של הצד המקבל מסיים את mTLS, מאמת את זהות המקור ומעביר HTTP רגיל לאפליקציית היעד.
4. Policies מכתיבים לאילו עומסי עבודה יכולים להתקשר לאיזה - בהתבסס על אישור ב-sidecar identity.

היישומים מקבלים אימות חזק מבוסס-זהות ללא כל שינויי קוד. הרשת מטפלת בכל המורכבות התפעולית של האישורים והקריפטו.

mTLS לעומת OAuth/OIDC עבור APIs

Tשני דגמי אימות שונים:

• OAuth/OIDCXPLZer-Xen —bebasared-46Xen. האסימון מכיל תביעות זהות. ניתן לחלץ אסימונים ולהפעיל אותם מחדש אם אינם קשורים ללקוח.
• mTLS - מבוסס תעודה. האישור לבדו חסר תועלת ללא המפתח הפרטי. ערבויות זהות חזקה יותר.

עבור אימות פנימי של שירות לשירות, mTLS מועדף יותר ויותר. עבור אימות מול משתמש, OAuth/OIDC נשאר הסטנדרט. גישות היברידיות (OAuth עם כריכת אסימונים, אסימוני OAuth הקשורים ל-mTLS) משלבות את העוצמות.

למפתחים

הוספת mTLS למחסנית שלך כרוכה:

• הגדרת CA (שלב CA פתוח הוא אפשרויות ידידותיות להשגת CA התחיל)
• הנפקת אישורים ללקוחות ושרתים
• הגדרת שרתים לדרישת אישורי לקוח
• הגדרת לקוחות להציג אישורים
• טיפול בסיבוב אישורים (אוטומטי באמצעות ACME-שווה ערך ל-ACME-שווה ערך ל-ACME-שווה ערך ל-ACME-שווה ערך ל-7PLZ06XX9 פנימי) הכניסה ירדה משמעותית במהלך 5 השנים האחרונות. mTLS כעת אפשרי מבחינה תפעולית עבור צוותים קטנים; זה היה בעבר בעיקר נחלתם של ארגונים עם תשתית אבטחה ייעודית.