mTLS: כשגם השרת רוצה לדעת מי אתה

מאת צוות מדיה דיל · 03.07.2026 · אבטחת מידע · 4 דק׳

Mutual TLS, handshake דו-כיווני, Certificate Authority פנימי, Service Mesh עם Istio ו-Linkerd, רוטציית תעודות קצרת-טווח, ותפקיד mTLS במודל Zero Trust.

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

איך handshake דו-כיווני עובד בפועל

ב-TLS רגיל ה-handshake מסתיים אחרי שהלקוח קיבל ואימת את תעודת השרת מול Certificate Authority מהימן. ב-mTLS יש שלב נוסף: השרת שולח CertificateRequest ומחייב את הלקוח להציג תעודה חתומה משלו, ואז מאמת אותה מול אותו CA לפני שהוא ממשיך את ה-handshake. אם התעודה חסרה, לא חתומה על ידי CA מוכר, או פגה - החיבור נחסם עוד לפני שכל בקשת HTTP מגיעה לשכבת האפליקציה, מה שהופך את mTLS לשכבת הגנה שקודמת אפילו ל-authorization ברמת ה-API.

Certificate Authority פנימי לתקשורת שירות-שירות

בניגוד לתעודות ציבוריות שמאומתות מול CA כמו Let's Encrypt, בסביבת mTLS פנימית בונים בדרך כלל CA פרטי שמנפיק תעודות רק לשירותים בתוך הארגון. כל שירות מקבל זהות קריפטוגרפית ייחודית - בדרך כלל מבוססת על SPIFFE ID שמקודד את השם, ה-namespace והסביבה שלו - ותעודה קצרת-טווח שמונפקת אוטומטית. ניהול ה-CA הזה, כולל הגנה על המפתח הפרטי שלו, הוא בעל חשיבות קריטית: מי ששולט ב-CA יכול להנפיק תעודה למי שהוא רוצה ולהתחזות לכל שירות ברשת.

Service Mesh כשכבת תשתית שמנהלת את זה בשבילך

מימוש mTLS ידני בכל שירות ושירות - כולל rotation, revocation וטיפול בשגיאות handshake - הוא עומס תפעולי כבד. Service Mesh כמו Istio או Linkerd פותר את זה על ידי הצבת sidecar proxy (בדרך כלל Envoy) לצד כל instance של שירות, כשה-proxy הוא זה שמנהל את כל שכבת ה-mTLS בצורה שקופה לחלוטין לקוד האפליקציה. השירות עצמו ממשיך לדבר HTTP רגיל מקומית, וה-sidecar דואג להצפין, לאמת ולפענח בלי לשנות שורת קוד באפליקציה.

רוטציה אוטומטית וזמן חיים קצר לתעודות

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

מה קורה כשתעודה מתבטלת - Revocation בזמן אמת

לפעמים צריך לבטל תעודה מיידית - שירות שהתגלה כפגוע, מפתח פרטי שדלף, או שינוי מדיניות פתאומי. הבעיה עם CRL ו-OCSP המסורתיים היא latency: הם דורשים בדיקה מול שרת חיצוני בכל handshake, מה שמוסיף עיכוב ונקודת כשל יחידה. גישות מודרניות יותר מסתמכות על TTL קצר כתחליף חלקי ל-revocation אקטיבי, בשילוב עם mesh control plane שיכול לדחוף מדיניות "אל תסמוך על זהות X" לכל ה-proxies כמעט בזמן אמת בלי לחכות שהתעודה תפוג באופן טבעי.

mTLS כרכיב מרכזי במודל Zero Trust

mTLS הוא לא תחליף למדיניות הרשאות - הוא התשתית שעליה בונים אותה. במודל Zero Trust ההנחה היא שהרשת הפנימית לא בטוחה יותר מהאינטרנט, ושכל בקשה חייבת להוכיח זהות בכל שכבה. mTLS נותן את שכבת הזהות הקריפטוגרפית ברמת התעבורה, ומעליה אפשר להוסיף authorization מבוסס תפקיד שבודק לא רק "מי אתה" אלא גם "האם מותר לך לקרוא ל-endpoint הזה". בלי mTLS, כל בקרת הרשאות אחרת בונה על הנחת יסוד רעועה שהמבקש הוא באמת מי שהוא טוען.

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

תגיות: mTLS · Mutual TLS · Service Mesh · Istio · Certificate Authority · Zero Trust

← חזרה לבלוג · צור קשר