Redis TLS: מה נשבר בעת העברת תעבורה
כברירת מחדל Redis אינו מצפין את התעבורה: פקודות הלקוח, תגובות השרת והחלפת השירות עוברות בטקסט גלוי. יחד עם עומס העבודה השימושי עוברים ברשת הפנימית סיסמאות מ-AUTH, אסימוני הפעלה, מפתחות מטמון ותוכן התורים — כל מה שמקובל לסווג כמידע רגיש.
כל צומת באותו סגמנט יכול לראות את הזרימה הזו. די בפורט מראה על המתג, בקונטיינר שנפרץ או במחשב של מהנדס ברשת משנה מהימנה, כדי שהאזנה פסיבית לרשת הפנימית תאסוף את תוכן החיבורים ל-Redis בשלמותם. פרטי הזדהות עוברים יחד עם הנתונים, ומשם אפשר להתחבר ל-Redis בשם האפליקציה.
מלכודת נפרדת — התפיסה שהמעגל הפנימי בטוח מעצם הגדרתו. בפועל, באותה רשת משנה חיים אפליקציות, אוספי מטריקות, סוכני גיבוי וקונטיינרים של צוותים שונים, והאמון ביניהם אינו מאומת בשום דבר. שגיאת קונפיגורציה אחת בכל אחד מהצמתים הללו הופכת לדליפת נתונים של כל האינסטנסים השכנים.
Redis TLS סוגר את הפער: החיבור עולה כבר מוצפן, התעודה מאשרת שהלקוח הגיע לאינסטנס הנכון, ואימות הדדי חוסם חיבור ל-Redis מצומת זר. יחד עם זאת, לא רק הפורט נשבר — יש להעביר גם את הרפליקציה, מנגנוני העמידות לתקלות, סקריפטי השירות והניטור, אחרת חלק מהתעבורה נשאר פתוח.
להלן נפרט כיצד סוגרים זאת ללא השבתה: סדר ההפעלה, אימות תעודות, רפליקות ופיקוח לכך שלא נותרו חיבורים לא מוצפנים ל-Redis.
מה נותן הצפנת הערוץ בין השירות לאחסון
כברירת מחדל, החיבור של השירות אל Redis בתוך הפרימטר עובר בטקסט גלוי: פקודות, שמות מפתחות וערכים נגישים לכל מי שרואה את תעבורת הסגמנט או מחובר לאותה רשת. פורמלית המעגל סגור, בפועל הגישה לנתונים אינה דורשת דבר מלבד כתובת ומחרוזת חיבור.
ביקורת האבטחה הראשונה כבר מתעדת זאת כממצא בחומרה גבוהה, ומשם יש לסגור זאת בדחיפות ומחוץ לתוכנית, או להסביר זאת בכתב בכל פעם מחדש.
הצפנת הערוץ משנה את עקרון ההרשאה עצמו: במקום "יודע את הכתובת והסיסמה" — "הציג תעודה תקפה". האחסון מקבל תעודה מרשות תעודות פנימית, הלקוח מאמת את השרשרת עד לשורש ואת התאמת שם הצומת, ובאימות הדדי גם השירות עצמו מציג את תעודתו.
לאחר מכן לא כל מי שהשיג את מחרוזת החיבור יכול להתחבר, אלא שירות ספציפי עם תעודה שהונפקה ולא בוטלה — האחרים נחסמים בשלב לחיצת היד, לפני העברת הנתונים.
מכאן האפקט מתפרק לשלושה דברים מדידים. סיווג הממצאים על העברת נתונים בטקסט גלוי מוסר: המדיניות מאושרת בקונפיגורציה ובמרשם תעודות, ולא בטקסט של נהלים.
חיבור שירות חדש מפסיק להיות עבודה ידנית מהזיכרון — הנפקת תעודה, סט פרמטרים תקני ובדיקת חיבור אורכים דקות ומשוחזרים באותו אופן אצל כל מהנדס.
נוצרת שקיפות גישה: מיומן התעודות רואים מי ומתי מחובר, מתי הגישה ניתנה ומתי בוטלה, כשביטול סוגר את הגישה בלי החלפת סיסמה בכל השירותים בבת אחת.
חלק נפרד בעבודה — תפעול: תוקף התעודות, סדר רוטציה בלי לעצור שירותים ותקנון בדיקה בעת הוספת צמתים חדשים. בלי זה חיבור מאובטח חי עד לתאריך התפוגה הראשון, ואז נופל יחד עם החלפת הנתונים.
אפשרויות הגדרה: אימות חד-כיווני והדדי
Redis כברירת מחדל מתקשר עם לקוחות בטקסט גלוי, ולכן מפעילים הצפנה באמצעות מצבי חיבור: או שהשרת מציג תעודה והלקוח מאמת אותה, או ששני הצדדים מחליפים תעודות. אימות חד-כיווני מוטמע מהר יותר ומתאים למעגל סגור, אימות הדדי חוסם לקוחות זרים — בלי תעודה תקפה החיבור לא יעלה.
שאלה נפרדת — היכן בדיוק להציב את ההצפנה: על צומת הנתונים עצמו או להוציא את סיום ההצפנה לצומת פרוקסי שמחזיק את התעודות ומעביר את התעבורה פנימה לסגמנט המהימן. הבחירה תלויה במספר האפליקציות ובשאלה אם הן יודעות לעבוד עם תעודות בעצמן.
השוואת מצבים
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אימות חד-כיווני על הצמתים | מעגל סגור, לקוחות מהימנים, נדרש מינימום שינויים | הלקוח אינו מאשר את עצמו: גישה לרשת למעשה שווה לגישה לנתונים |
| אימות הדדי של תעודות | כמה צוותים, צרכנים חיצוניים, נדרש פיקוח על כל לקוח | נדרשים הנפקה, מסירה ורוטציה של תעודות לקוח; שגיאה בשרשרת האמון קוטעת חיבורים |
| סיום הצפנה בצומת פרוקסי | אפליקציות רבות ומגוונות, חלקן אינן יודעות להצפין את הערוץ | צומת הפרוקסי הופך לנקודת כשל יחידה ודורש סקיילינג נפרד; בתוך הסגמנט התעבורה עוברת גלויה |
בפועל מתחילים באימות חד-כיווני אם המעגל סגור, ועוברים להדדי כשהלקוחות מרובים מאחד ועל הגישה אחראים צוותים שונים. צומת פרוקסי בוחרים כשהנפקה מחדש של תעודות בצד האפליקציות יקרה יותר מנקודת סיום אחת.
סדר הטמעת Redis TLS במעגל העבודה
בין האפליקציה ל-Redis עובר כברירת מחדל טקסט גלוי: התעבורה גלויה לכל מי שהשיג גישה לסגמנט הרשת, ופקודת פריקה או דאמפ זיכרון נושאת את הנתונים בשלמותם. הפעלת הצפנה בשינוי קונפיגורציה אחד אינה מסובכת — מסובך לעשות זאת כך שלקוחות שכבר פתוחים להם חיבורים במאגר לא ייפלו. לכן הסדר הפוך מהרגיל: תחילה מיפוי מלאי, אחר כך תעודות, ורק אז הפעלה בפרודקשן.
-
מיפוי מלאי הלקוחות. אוספים את כולם שמתחברים לאינסטנס: אפליקציות, עובדי תורים, משימות גיבוי, לוחות ניטור, חיבורים ידניים של מהנדסים. עבור כל אחד מתעדים את הספרייה, אם היא תומכת בהצפנה ומאין היא שואבת את פרמטרי החיבור.
-
הנפקת תעודות. מכינים רשות תעודות פנימית או משתמשים בקיימת: תעודת שורש, תעודת צומת עם רשימת כל הכתובות שפונות אליו, ותעודות לקוח נפרדות אם נדרש אימות הדדי של הצדדים.
-
הגדרת השרת. מתארים פורט מאובטח ומשאירים פורט פתוח לזמן המעבר, מגדירים נתיבים לתעודה ולמפתח, רשימת גרסאות פרוטוקול מותרות. אם הבילד אינו תומך בהצפנה באופן מובנה, מרימים שכבת פרוקסי לפני האינסטנס — קונפיגורציית הלקוחות כמעט אינה משתנה בכך.
-
הגדרת הלקוחות. מתקנים את פרמטרי החיבור בקונפיגורציה של השירותים, מוסיפים אימות תעודת הצומת לפי השורש, ולא "לסמוך על הכול". זוהי משימה נפרדת בכל שפה וספרייה, ואי אפשר לבצע אותה ברגע ההפעלה.
-
בדיקת חיבורים. על מעגל בדיקות ועל צומת אחד מריצים פרופיל פניות מלא: קריאות בכמות גדולה, כתיבות, תרחישי חיבור מחדש לאחר ניתוק, התנהגות עם תעודה שפג תוקפה.
-
הפעלה בפרודקשן. מעבירים תעבורה בגלים לפי צמתים או קבוצות שירותים, בהשוואת מספר החיבורים, ההשהיה ושיעור השגיאות לקו הבסיס שנלקח מראש.
-
סגירת הפורט הפתוח. לאחר תקופת תצפית מכבים גישה לא מוצפנת ומשאירים בניטור התראה על תוקף התעודה, כדי שעדכון מתוכנן לא יהפוך להפתעה.
בדיקת המפתח בכל שלב — לא "האם זה עלה", אלא "כמה לקוחות כבר עברו ומה קורה עם אלה שטרם". סדר כזה נותן הפיכות: אפשר לעצור את ההפעלה בכל גל, והפורט הפתוח נשאר כרשת ביטחון עד הצומת האחרון.
ערכת מסמכים וקונפיגורציות לאחר המסירה
לאחר הפעלת TLS ב-Redis אמורים להישאר בידי צוות הלקוח לא "קופסה שחורה" עובדת, אלא סט מלא של ארטיפקטים: קונפיגורציות, תעודות, תרשימים ותקנונים. בלעדיהם הרוטציה הראשונה של התעודה הופכת לניסוי פרמטרים בעיוורון ולחפירה בהיסטוריית ההתכתבות. להלן — מה בדיוק אנו מוסרים ובאילו סעיפים זה מתקבל.
- קונפיגורציות עובדות של כל הצמתים: פרמטרי פורט TLS, רשויות תעודות מהימנות, נתיבים למפתחות ולשרשראות תעודות, מצב אימות תעודות לקוח.
- תעודות ומפתחות שהונפקו עם ציון תוקף, בעלים וסדר הנפקה של חדש ללא השבתה.
- תרשים זרימות החיבורים: אילו שירותים ובאיזה פורט פונים לאחסון, היכן מאמתים רק את השרת והיכן מופעל אימות הדדי.
- תקנון רוטציה: סדר החלפת התעודה, רגע רענון הקונפיגורציה, בדיקת חיות לאחר כל שלב ונקודת חזרה לאחור.
- מדיניות גישה: מרשם חשבונות ותפקידים, הרשאות מינימליות נדרשות, סדר מתן וביטול גישה לשירות חדש.
- צ'ק-ליסט קבלה: פקודות שבאמצעותן המהנדס שלכם מאשר בעצמו שההצפנה מופעלת וחיבור בלי תעודה נדחה.
- הוראות אבחון: שגיאות לחיצת יד טיפוסיות, סיבותיהן ועל מה להסתכל בלוגים תחילה.
הערכה מותאמת למעמדות שלכם: שמות הקבצים, הנתיבים ושמות השירותים — שלכם, ולא דוגמאות מופשטות מהתיעוד.
מקרה בוחן: קלאסטר על חיבורים מוצפנים
נקודת הפתיחה
קלאסטר של כמה צמתים שירת שירות מבצעי שבו שיא העומס עלה פי כמה על הממוצע. התעבורה בין הלקוחות ל-Redis עברה גלויה בתוך מעגל סגור — בבדיקת האבטחה זה התברר כנקודה היחידה שלא כוסתה.
מעבר ישיר לחיבורים מוצפנים איים בכך שלקוחות מגרסה ישנה יאבדו קשר בו-זמנית עם שינוי הקונפיגורציה, וזו השבתה של כל השירות.
מה שינינו — ומה קיבלנו
הרמנו פורט מאובטח שני במקביל לפתוח ופיצלנו את הלקוחות לגלים: תחילה שירותי השירות, אחר כך התורים, ולבסוף הרגישים ביותר להשהיה. את הרפליקה העברנו בשלב נפרד: הצומת הורם מחדש עם פורט מאובטח, הדביק את הנתונים ורק אז נכנס לפעולה. בחירת המנהיג החדש נבדקה על מעמד תחת עומס — הפלנו צומת בכוונה כדי לראות את זמן המיתוג האמיתי.
אף מיתוג לא ארך יותר מכמה שניות, ההשבתה המתוכננת — אפס: השירות לא נעצר. שיעור הכשלים בזמני המתנה חזר לרקע הרגיל, וההשהיה בקריאה עלתה בגבולות טעות המדידה — ההצפנה לא הפכה לצוואר בקבוק. את הפורט הפתוח סגרנו אחרון, לאחר שבוע של תצפית: וידאנו שלא נותרו לקוחות ישנים בתעבורה.
הצפנה באפליקציה או בפרוקסי?
נקודת הפעלת ההצפנה קובעת היכן מסתיים הערוץ המאובטח, מי אחראי לתעודות וכמה חוליות מופיעות בין האפליקציה ל-Redis. יש שלוש אפשרויות: ספריית לקוח בתוך האפליקציה, צומת מתווך לצד השרת ותרשים משולב שבו חלק מהלקוחות פונים ישירות וחלק דרך צומת.
הצפנה באפליקציה: הספרייה מרימה ערוץ מאובטח עד השרת עצמו, התעבורה סגורה לאורך כל הנתיב, ואין נקודות כשל מיותרות.
המחיר — תיקון הקונפיגורציה של כל לקוח, סט נפרד של תעודות שורש ומשמעת אימות: אם מכבים את התאמת שם השרת לתעודה "כדי שזה יעבוד", הערוץ נשאר מוצפן, אבל ההגנה מפני החלפת צומת נעלמת.
צומת מתווך מסיים את ההצפנה לצד השרת, ומשם התעבורה עוברת בסגמנט המקומי. זה מועיל כשיש הרבה לקוחות, חלקם אינם יודעים TLS או שאי אפשר לשכתב את האפליקציה.
המחיר — חוליה מיותרת, נקודת כשל נפרדת, והעובדה שרק הכתף החיצונית נשארת מאובטחת: בתוך הסגמנט התעבורה פתוחה, וזו החלטה שצריך לקבל במודע, ולא כברירת מחדל.
תרשים משולב — אפשרות עובדת לזמן המיגרציה: לקוחות קריטיים מתחברים ישירות עם אימות תעודה, האחרים — דרך הצומת, ורשימתם מצטמצמת בהדרגה. הקריטריון המעשי פשוט: אם אתם שולטים בכל הלקוחות — הפעילו הצפנה באפליקציה; אם לא — הקימו צומת והשאירו ערוץ ישיר למי שאתם יכולים לעדכן. בהמשך נפרט כיצד כל אפשרות מוגדרת בפועל.
ספקות טכניים לפני הפעלת הצפנה
הצפנת חיבורים ל-Redis היא תיקון קונפיגורציה בשרת ובדרך כלל הנחיה אחת בלקוח. הספקות לפני ההפעלה טבעיים: השהיות, תאימות ספריות, התנהגות בעת כשל תעודה.
בנפרד לגבי העומס על המעבד: ההוצאה נוצרת בלחיצת היד בעת כינון החיבור, ולא בהעברת הנתונים עצמה. עם מאגר חיבורים קבוע ושימוש חוזר בסשן, היא חלה על חלק זעיר מהבקשות, וההחלפה מתבצעת בהצפנה סימטרית — ההוצאות הנלוות נכנסות בגבולות טעות המדידה של פרופיל העומס.
בכמה יעלו ההשהיות והעומס על המעבד?
התוספת נובעת מלחיצת היד, ולא מכל בקשה. מודדים זמן תגובה עם מאגר ובלעדיו: בחיבורים קבועים ההבדל בגבולות טעות המדידה, ואם החיבור נפתח לכל בקשה — תחילה מגדירים מאגר, ואחר כך מפעילים הצפנה.
לקוחות ישנים אינם תומכים בהצפנה — מה עושים?
אוספים מטריצה: ספרייה, גרסה, תמיכה במצב מוצפן. לתקופת המעבר השירות מאזין לשני פורטים, חריגים מנהלים במפורש, עם תאריך כיבוי של הרגיל. לקוח בלי תמיכה מעדכנים או מבודדים בסגמנט נפרד.
מה יקרה עם תפוגת תעודה?
חיבורים קיימים ימשיכו לעבוד, חדשים יתחילו ליפול — המערכת נראית חיה, אף שהחיבורים אינם עוברים. תרחיש כזה תופסים בניטור תוקף, בהארכה אוטומטית ובבדיקת לחיצת יד נפרדת בבדיקות תקינות.
איך לחזור לאחור אם משהו ישתבש?
הקונפיגורציה והתעודות נמצאות במאגר, הפעלת ההצפנה היא תיקון נפרד, ולא סדרת צעדים ידניים. החזרת הפרופיל הקודם והפעלה מחדש מחזירים את העבודה, הלקוחות בינתיים עוברים דרך הפורט השני; את החזרה לאחור בודקים על המעמד לפני ההעלאה.
נדון במשימה ונחזור עם תוכנית עבודה
שולחים קלטים על המעגל — טופולוגיה (צומת בודד, Sentinel, קלאסטר), רשימת אפליקציות וספריות לקוח, מצב הפורטים הנוכחי וכיצד מופצות כיום התעודות. זה מספיק כדי לדון במשימה עניינית ולחזור עם הערכת היקף ותוכנית עבודה: אילו צמתים נוגעים בהם, באיזה סדר, והיכן יידרש חלון להפעלה מחדש.
מה מכינים בשלב זה:
- רשימת קלטים שצריך לאסוף על המעגל שלכם — כדי שלא נברר דבר כבר במהלך התהליך;
- תרשים חיבורים: היכן מסתיימת ההצפנה, האם נדרשת שכבת פרוקסי, כיצד עוברות הרפליקציות השירות בין הצמתים;
- תוכנית רוטציה של תעודות עם סימון מה דורש הפעלה מחדש ומה קולט קבצים חדשים תוך כדי תנועה;
- פרק על מצב האימות: מתי מספיקה הצפנת הערוץ ומתי נדרש אימות הדדי של הלקוח;
- סדר קבלה: במה נוודא שהאפליקציות עלו בערוץ מאובטח, ולא נסוגו לפורט פתוח דרך נתיב גיבוי;
- רשימת סיכונים ותרחיש חזרה לאחור, אם לאחר שינוי המדיניות חלק מהלקוחות אינם עוברים לחיצת יד;
- אחראים משני הצדדים ונקודות שבהן נדרשת החלטה שלכם.
השלב הבא — ניתוח הקלטים: מאשרים את גבולות העבודה, סדר השלבים והרגע שבו המיתוג בטוח לעומס. תארו את המשימה ושלחו את מה שיש — נחזור עם תוכנית.