הצפנת תעבורה מקצה לקצה בין שירותים: TLS/mTLS

הצפנת תעבורה בין שירותים: היכן נשברת ההגנה

ההיקף בדרך כלל סגור: סיום TLS במאזן העומסים, כללים מחמירים לתעבורה נכנסת, בדיקות סדירות מבחוץ. בתוך האשכול התמונה שונה — קריאות בין שירותים עוברות ברשת האשכול בטקסט גלוי.

HTTP, gRPC, פניות למטמון ולתורים עוברות ללא הצפנה, ותהליך שקיבל הרשאות במרחב השמות שלו יכול להאזין לתעבורה של אחרים.

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

קריאות שירות — בדיקות מוכנות, איסוף מדדים, פניות ל-broker — בכלל לעיתים רחוקות נכנסות לחשבון, ולכן חיבורים לא מאובטחים בין שירותים חיים שנים מחוץ לאחריות של מישהו.

מכאן החומרה של טעות: יירוט נתונים בתוך הרשת מוסר טוקנים לגישה, מפתחות סשן ונתונים אישיים בטקסט גלוי, וכמעט אין במה להבחין בכך בדיעבד. מדיניות רשת גם לא סוגרת את השאלה — היא מגבילה מי יכול לדבר עם מי, אבל לא מה בדיוק הם מעבירים.

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

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

מה משתנה באמינות ובלוחות הזמנים לאחר ההטמעה

אפקטים מדידים כאן נוח יותר לבחון לפי ארבעה גדלים: שיעור הפעולות הידניות בהנפקה וברוטציה של אישורים, זמן ההתאוששות לאחר כשל של שירות, מספר האירועים בנקודות החיבור ושיעור החיבורים שבכלל עוברים אימות זהות של שני הצדדים. לפני ההטמעה בדרך כלל שניים מתוך הארבעה כלל לא נמדדים — וזה הדבר הראשון שמשתנה.

סוג הכשלים שנעלם לחלוטין — אמון משתמע בתוך ההיקף. כששירות מקבל בקשה רק כי היא הגיעה מהרשת הפנימית, כל התחזות או שגיאת ניתוב נראית כמו «התנהגות מוזרה» ומחפשים אותה שעות. בדיקת אישורים הדדית הופכת זאת לדחייה מפורשת בכניסה: החיבור לא נוצר, ובלוג רואים מי ולמה לא עבר בדיקה.

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

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

מצבי הצפנת תעבורה: מה מתאים היכן

מצב הגנת הערוץ נבחר לא לפי העיקרון «מחמיר יותר — טוב יותר», אלא לפי גבול האמון ולפי מי מנהל את המפתחות בכל צד. בבדיקה חד-צדדית השרת מציג אישור, והלקוח — לא: הערוץ מוגן מפני האזנה, אבל הצד הקורא נשאר אנונימי. בדיקה הדדית של הצדדים (mTLS) מוסיפה דרישה נגדית — שירות בלי אישור תקף לא יקבל חיבור.

על הבחירה בסכמת ההגנה משפיעים שלושה דברים: היכן מסתיימת ההצפנה, האם אתם מוכנים להנפיק ולהוציא ברוטציה אישור לכל משתתף ומה יקרה אם מפתח אחד ייחשף.

מעבר בין מצבים כמעט לעולם לא נעשה בבת אחת. התואם ביותר הוא מצב ביניים שבו נקודת הכניסה מקבלת גם חיבורים מאומתים וגם לא מאומתים, ושיעור חיבורי mTLS משמש קריטריון לסיום המיגרציה: הגיע לאפס — המצב המחמיר מופעל בהגדרה אחת.

כלי הניהול המובנים של רשת השירותים, למשל Istio, תומכים במעבר כזה באופן מובנה, ולכן החזרה לאחור מסתכמת בהחזרת המדיניות הקודמת, ולא בבנייה מחדש של הקונפיגורציה.

מלאי, סכמת אמון והנפקת אישורים

הצפנת תעבורה בין שירותים מתחילה לא בהגדרה, אלא בתמונה אמיתית: מי מתחבר למי, מי בזוג הוא לקוח ומי שרת, היכן הערוץ כבר מוגן והיכן הנתונים עוברים בטקסט גלוי. בלי מרשם כזה כל הגדרה הופכת לניחוש, והשירות הנשכח הראשון שובר את החילוף.

סדר העבודות

1. מלאי שירותים. אוספים את משתתפי החילוף: שם, סביבה, מי יוזם את החיבור, על איזה פורט מאזין, מה כבר מוגן. המרשם הופך למקור האמת שלפיו בודקים בכל שלב הבא.

2. סכמת אמון. מחליטים מי מנפיק אישורים, כמה זמן חי המרכז המתווך והאישור עצמו, היכן נשמרים מפתחות פרטיים ולמי יש זכות חתימה. כללי השמות מקבעים מיד, כדי שהאישור יהיה משויך לשירות ולא למכונה.

3. הנפקת אישורים. מעבירים הנפקה והארכה לאוטומציה: סוכן על הצומת מקבל אישור, מחדש אותו הרבה לפני תום התוקף ומודיע אם החידוש לא עבר. ידנית נשארים רק שלילה ופתרון תקלות.

4. מתחם פיילוט. את השירותים הראשונים מעבירים למצב ניטור: החיבור נבדק, אבל במקרה של אי-התאמה הוא לא נקטע — אי-ההתאמה נרשמת בלוג. כך עולים זוגות «מי פונה למי» שלא היו במרשם.

5. בדיקת כשלים. שוברים בכוונה: מרכז ההנפקה לא זמין בזמן ההארכה, בצומת השעה לא מסונכרנת, האישור נשלל, הלקוח הגיע עם ישן. לכל מקרה צריך להיות תוצאה צפויה ורישום בלוג, ולא ניתוק שקט.

6. בדיקה מחייבת לפי קבוצות. למצב מחמיר מעבירים בזוגות, משירותים לא קריטיים לשירותים עיקריים, עם ניטור שיעור הכשלים ואפשרות להחזיר את ההתנהגות הקודמת בהגדרה אחת.

נהלי רוטציה של מפתחות ומדיניות גישה

הצפנה שהוגדרה פעם אחת בין שירותים חיה בדיוק עד השינוי הראשון בתשתית: הוסיפו pod, העבירו שירות לאשכול אחר, החליף אחראי — והאמון בין הרכיבים נשען על הזיכרון של מהנדס אחד. נבחן אילו ארטיפקטים מתעדים בכתב, כדי שהסדר ישחזר גם בלעדינו.

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

התוצאה — תפעול צפוי: שירות חדש נכנס למתחם האמון בתוך שעות, שלילת מפתח אורכת דקות, ובדיקת אבטחה עוברת לפי מסמכים, לא לפי סיפורים.

ניתוח הטמעה: מדידות לפני ואחרי המעבר

הלקוח — שירות תשלומים של ארבעים רכיבים פנימיים. החילוף ביניהם עבר בערוץ פתוח, והשירותים זיהו זה את זה לפי כתובת רשת: די היה בגישה לאשכול כדי לקרוא תעבורה של אחרים ולהתחזות לכל רכיב.

האישורים ששימשו בהיקף הונפקו ידנית — מהבקשה ועד לקובץ המוכן עברו עד יומיים, ורוטציה מתוכננת הפכה לאירוע נפרד עם חלון לילה.

התחילו במלאי: הפיקו מפת חילוף, סימנו נתיבים שכבר מוגנים וקבעו מדדי בסיס — שיעור השירותים עם אימות הדדי, זמן הנפקת אישור, מספר הכשלים ברוטציה.

מה שינו

בתוך מתחם האמון הקימו שירות הנפקה עצמאי והעבירו את הניהול שלו לרשת השירותים Istio במצב אימות הדדי. תוקף החיים של האישור קוצר לכמה שעות עם רוטציה אוטומטית בלי הפעלה מחדש של שירותים, וההצפנה הופעלה תחילה במצב ניטור — טלמטריה הראתה אילו כיוונים עדיין עוברים גלויים. המצב המחמיר הופעל רק אחרי שלגבי כל נתיב אושר שאין תעבורה לא מוצפנת.

בנפרד בדקו את ההפיכות: החזרת המדיניות למצב ניטור פותחת את הערוץ בתוך דקות, ולכן שגיאת קונפיגורציה לא משאירה שירותים בלי קישוריות. מספר האירועים הקשורים לגישה בין רכיבים ירד לאפס, ופעולות ידניות עם אישורים הפסיקו לתפוס זמן הנדסי.

מה לעשות אם אישורים מונפקים ידנית?

הנפקה ידנית היא מצב שבו מבקשים אישור דרך קונסולת מרכז ההנפקה, ותאריך ההארכה נשמר בלוח שנה ובראש של מהנדס אחד. כל עוד יש עשרה שירותים, הסכמה נסבלת; במאה צמתים היא נותנת סוג כשלים צפוי: פיספסו את ההארכה, שרשרת האמון לא נקלטה, והחיבור בין שירותים נופל עם שגיאת בדיקת אישור. השגיאה נראית לא במקום שבו הסיבה — האבחון נודד לכיוון הרשת ומאזן העומסים.

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

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

מחליפים שירות אחד בכל פעם, ואחרי ההחלפה בודקים לא את עובדת «המנעול הירוק», אלא את הנתיב המלא — אימות הדדי, השם באישור, תוקף, תגובה לשלילה. החזרה לאחור נשארת טריוויאלית: האישור והמפתח הקודמים נשמרים במחסן עד סוף חלון ההחלפה.

תהליך מנוהל הוא מצב שבו ההארכה מתבצעת לפי תוקף החיים שנותר, המפתחות מתחלפים יחד עם האישור, ותוקפי החיים מתקצרים בלי גידול בפעולות ידניות.

המדדים שלפיהם רואים תוצאה: שיעור האישורים שהוארכו אוטומטית, הזמן מהבקשה ועד אישור מוכן, מספר הפעולות הידניות בחודש ומספר הכשלים בגלל תוקף שפג — האחרון יורד לאפס.

ספקות נפוצים: תאימות, כשלים, חזרה לאחור

לפני ההתחלה כמעט תמיד עולים אותם ספקות: האם ההצפנה תעלה בשירותים שלא נגעו בהם שנים, מה יקרה בעת תקלה והאם אפשר להחזיר הכול לאחור. אלה הנקודות שבהן נקבע גורל ההטמעה — נבחן כל אחת.

מה יקרה אם תוקף האישור פג או שהצומת לא זמין?

מתחם האמון הפנימי מגדירים לפי העיקרון «סגור בעת כשל»: חיבור בלי בדיקה מוצלחת לא עובר גלוי, והאירוע נכנס למדדים ולהתראה. חריגים עושים נקודתית — לבדיקות חיות. את הרוטציה של האישורים מתאימים לאוטומציה, כדי שתפוגה לא תהפוך לסיבת כשל.

האם אפשר להחזיר שינויים לאחור אם משהו השתבש?

כן. המדיניות מתוארות באופן דקלרטיבי ומנוהלות בגרסאות, והחזרה לאחור היא החזרת התיאור הקודם, לא עריכה ידנית. השלב הראשון עובר במצב ניטור: התעבורה זורמת כמו קודם, ההפרות רק נרשמות בלוג, ולכן את המצב המחמיר מפעילים לפי עובדות.

איך להבין איזה שירות שובר את החיבור?

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

נדון בסכמת ההגנה שלכם ונחזור עם הערכה

כדי שההערכה תישען על עובדות ולא על הנחות, אנחנו צריכים תמונת מצב של החילוף הנוכחי. בלעדיה שלב הטמעת הגנת החילוף נתקע בקשרים שלא נלקחו בחשבון: שירות שכולם חשבו שהוא פנימי עובר דרך צומת משותף, והתעבורה שלו נשארת גלויה.

לניתוח מספיק סט כזה:

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

נחזור עם הערכה ותוכנית עבודה: רשימת הקשרים שיועברו, סדר ההפעלה לפי מתחמי אמון, תוקפי החיים של אישורים עם הליך רוטציה וסכמת חזרה לאחור. את המצב המחמיר מפעילים כיוון אחד בכל פעם: קודם מתחם בדיקות, אחר כך סביבת הייצור, עם בקרה על שיעור לחיצות הידיים המוצלחות וחיבורים שנפלו בבדיקה.

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

תארו את המשימה כפי שהיא אצלכם — סקיצה של מפת הרשת ורשימת שירותים כבר מספיקות להתחלה.