החלפת מפתח, התחברות מחדש או אימות מחדש: מה אתם צריכים?

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

ההחלטה תלויה בשאלה איזו שכבה באמת פגה.

שלוש פעולות שנקראות רוטציה

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

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

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

מה המשתמשים שמים לב אליו בחידוש

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

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

היכן השלושה נפרדים בפועל

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

ברירות המחדל של הפרוטוקול בדרך כלל מכילות את התשובה הנכונה. WireGuard מחליף מפתחות לאחר סף זמן ונפח נתונים בלי פעולה של המשתמש; משכי החיים של IKEv2 מנוהלים במשא ומתן לכל שיוך בן; מנהרות מבוססות TLS מסובבות מפתחות בתוך ההפעלה הקיימת. העלאת משכי החיים כדי להימנע משגיאה חוזרת דוחה את הכשל ומאריכה את החשיפה אם מפתח נחשף.

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

בחרו ברירות מחדל, ואז תעדו את השלב

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

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

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