Skip to content
עברית

Keycloak 26.8.2: בדקו אמון בזהויות ואת התנהגות השדרוג

Keycloak 26.8.2, שפורסמה ב־5 בנובמבר 2026, כוללת תיקוני אבטחה לקישור חשבונות מספקי זהות, לאימות מנפיק SAML ולבדיקות תעודות בכלי הניהול משורת הפקודה, לצד תיקונים נוספים. לצוותי תפעול כדאי לזהות את הרכיבים הרלוונטיים ולבדוק את התנהגות השדרוג, ולא להסתפק בשינוי מספר הגרסה של השרת.

שלוש בדיקות אמון שכדאי לבחון

קישור דוא״ל לא מאומת, CVE-2026-97175: הודעת ה־CNA של Red Hat מתארת תוקף עם חשבון אצל ספק זהות מתווך. אם כתובת דוא״ל נכנסת שלא אומתה תואמת לקורבן ומקושרת אוטומטית לחשבונו המקומי, התוקף יכול להשתלט עליו. ההתנהגות הרלוונטית היא במאמת idp-auto-link. כתובת שמערכת אחרת מספקת אינה כשלעצמה הוכחה שהמשתמש שלה מחזיק בכתובת.

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

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

היערכו להתנהגות שמשתנה

מדריך השדרוג ל־26.8.2 קובע שספק מדיניות DCR חדש מונע שדרוג מדורג: יש לעצור ולשדרג את האשכול יחד או להשתמש ב־recreate. בנוסף, entityID במתאם SAML חייב להתאים למנפיק, תעודות בחתימה עצמית חייבות להיכלל במפורש במאגרי האמון המותאמים של כלי הפקודה, ולקוחות Admin API מותאמים צריכים scope בשם kc-admin-api. קישור אוטומטי דורש כעת דוא״ל מאומת או Trust Email שמופעל אצל ספק הזהות. אל תפעילו Trust Email רק כדי להחזיר כניסה שנכשלה; ודאו תחילה שהספק אכן מאמת בעלות.

הפכו את ההכרזה לשינוי תחום

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

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

Read in English

Post a Comment

Previous Post Next Post