מה חדש ב-Keycloak בשנת 2026? אבטחה חזקה יותר עבור משתמשים, אפליקציות וסוכני AI
גרסאות Keycloak לשנת 2026 מציגות יכולות חדשות לאבטחת אפליקציות, ניהול זהויות ובקרת גישה לרוחב המערכות הארגוניות.
הן מספקות גם אבני בניין שימושיות עבור ארגונים המאמצים עוזרי AI וסוכני AI.
עבור לקוחות שכבר משתמשים ב-Keycloak עבור התחברות אחידה (SSO), העדכונים מציעים הזדמנויות להפחתת התלות באישורים סטטיים, אוטומציה של ניהול זהויות, חיזוק האימות ופישוט התחזוקה.
עבור ארגונים המטמיעים סוכני AI, השאלה המרכזית הופכת לחשובה יותר:
כיצד אנו מזהים סוכן, מגבילים את הרשאותיו ומבינים מניאבו הוא פועל?
מספר עדכונים ב-Keycloak מסייעים לתת מענה לדרישות אלו, ולנו (ALM Toolbox) יש את הניסיון לעזור לכם לתכנן ולפרוס אותם.
מאמר זה סוקר את התכונות והשיפורים שהוכרזו בין ינואר לאוקטובר 2026, ומכסה את גרסאות Keycloak 26.5 עד 26.8 ותיקוני אבטחה רלוונטיים.
בנקודת זמן זו, הגרסה העדכנית ביותר היא Keycloak 26.8.1.
הערה לגבי זמינות: חלק מהיכולות מוגדרות כ-Supported (נתמכות), בעוד שאחרות נשארות ב-Preview (תצוגה מקדימה) או Experimental (ניסיוניות). הבחנות אלו חשובות בעת תכנון פריסה בסביבת ייצור (Production).
פחות סודות סטטיים עבור אפליקציות וסוכני AI
אחת ההתפתחויות השימושיות ביותר היא ההבשלה של Federated Client Authentication (אימות לקוחות פדרטיבי).
בהמשך לשיפורים ב-Keycloak 26.5, אימות באמצעות מנפיקי OpenID Connect חיצוניים וחשיבונות שירות של Kubernetes הפך ל-Supported בגרסה 26.6. אינטגרציית SPIFFE נותרה ב-Preview.
אפליקציות יכולות להשתמש באישורים שהונפקו על ידי ספק זהות מהימן כדי להזדהות מול Keycloak, מה שמפחית את הצורך בתחזוקת סודות לקוח (Client Secrets) נפרדים וארוכי טווח.
כיצד זה משפר את האבטחה?
כל סוד סטטי יוצר אישור נוסף שיש לאחסן, לאבטח, לבצע לו רוטציה ובסופו של דבר להסיר. סודות עלולים לדולף בטעות למאגרי קוד (Repositories), לקובצי קונפיגורציה, לפלט ניפוי שגיאות או ליומני רישום (Logs) של האפליקציה.
אימות פדרטיבי יכול להפחית חשיפה זו על ידי שימוש באישורים לטווח קצר מתוך מערכת זהות עומסי עבודה (Workload Identity) מבוססת.
לדוגמה, עובד AI הרץ ב-Kubernetes יכול להזדהות באמצעות חשבון שירות יעודי במקום לחלוק סוד לקוח קבוע עם אפליקציות אחרות. הרשאותיו עדיין יצטרכו להיות מוגבלות ל-APIs ולפעולות הנדרשות לו בלבד.
Keycloak 26.8 משפר גם את גילוי המנפיק (Issuer Discovery) עבור סביבות Kubernetes מנוהלות כגון Amazon EKS, Google GKE ו-Microsoft AKS.
לפרטים טכניים, ראו את ההסבר של Keycloak על Federated Client Authentication.
שליטה רבה יותר בטוקנים ובאישורי לקוח
Keycloak 26.5 מציג את JWT Authorization Grant במצב Preview, וגרסה 26.6 מקדמת אותו למצב Supported.
יכולת זו מאפשרת ל-Keycloak לקבל JWT חתום מספק חיצוני מהימן ולהנפיק טוקנים של גישה (Access Tokens) מקומיים. זה מסייע לשלב אפליקציות הפועלות במתחמי זהות שונים מבלי להעביר סיסמת משתמש בין המערכות.
האבטחה תלויה בהגדרה נכונה של יחסי האמון, אימות הטענה והגבלת ההרשאות של הטוקן המתקבל.
שני שינויים נוספים מסייעים לארגונים לנהל אישורי אפליקציות:
- אחזור סוד לקוח דרך Vault SPI, שנוסף ב-26.6, מאפשר לסודות לקוח להיפתר דרך ממשק הרחבת ה-Vault של Keycloak.
- רוטציית סודות לקוח (Client Secret Rotation), שקודמה ל-Supported ב-26.8, מאפשרת חפיפה בין הסוד הישן לחדש בזמן שהאפליקציות עוברות מעבר.
התועלת המעשית היא החלפת אישורים מבוקרת יותר עם פחות השבתות. ארגונים צריכים לוודא כיצד אינטגרציית אחסון הסודות שלהם פועלת מול מנגנון הרוטציה; Vault SPI אינו אומר שלכל מנהל סודות יש מחבר מובנה.
מורשות מבוקרת וטובה יותר עבור שרתי MCP וכלי AI
פרוטוקול Model Context Protocol (MCP) מאפשר לאפליקציות AI להתחבר לכלים ומקורות נתונים חיצוניים. חיבורים אלה דורשים בקרות גישה ניתנות לאכיפה, במיוחד כאשר כלים נחשפים למערכות פנימיות.
עבודת ה-MCP של Keycloak מתקדמת לאורך 2026:
- 26.5: מדריך אינטגרציה ייעודי לשרת הרשאות MCP.
- 26.6: תמיכה ניסיונית במסמכי מטא-נתונים של מזהי לקוח OAuth (או CIMD).
- 26.7: הנחיות אינטגרציה מורחבות עבור לקוחות כגון Claude Code ו-Visual Studio Code.
- תיעוד נוכחי: הנחיות נוספות המכסות את Claude Desktop ו-Resource Indicators ניסיוניים.
CIMD מאפשר ל-Keycloak לאחזר מטא-נתונים של לקוחות מכתובת URL מבוקרת.
Resource Indicators מסייעים לשייך טוקן גישה לשרת המשאבים המיועד לו.
מדוע זה חשוב לאבטחת AI?
חשבו על עוזר המתחבר הן לשירות תיעוד והן לשירות פריסה (Deployment).
טוקן המיועד לשירות התיעוד לא אמור לעבוד באופן אוטומטי מול שירות הפריסה. שיוך טוקנים לקהל היעד המיועד (Audience), בשילוב אימות על ידי כל שרת, מסייע לשמור על הפרדה זו.
שרת ה-MCP חייב גם לאכוף את ההרשאות הקשורות לבקשה. אימות (Authentication) לבדו אינו קובע באילו כלים או פעולות הסוכן מורשה להשתמש.
הבחנת הבשלות חשובה: המדריך הנוכחי של Keycloak מסווג תאימות עם מפרטי MCP החדשים יותר – כולל 2025-06-18, 2025-11-25 ו-2026-07-28 – כ-Experimental.
ראו את מדריך אינטגרציית Keycloak MCP הרשמי עבור הדרישות הספציפיות לגרסה.
האצלת גישה מבלי לאבד את זהות הסוכן
Token Exchange Delegation (האצלת החלפת טוקנים) רלוונטית במיוחד לסוכני AI.
היא הוצגה כ-Experimental ב-26.7 וקודמה ל-Preview ב-26.8, ומאפשרת למשתמש להסמיך גורם אחר לפעול מטעמו. היישום ב-26.8 מוסיף האצלת לקוח, הסכמת משתמש והרשאה דרך Fine-Grained Admin Permissions V2.
טוקנים מואצלים מזהים הן את המשתמש והן את הגורם הפועל (Actor).
לדוגמה, עוזר פיתוח יכול לפעול עבור מפתח בעת אינטראקציה עם שירות פנימי. השירות יוכל לרשום שהעוזר ביצע את הפעולה עבור אותו מפתח, במיוחד במקום לייחס הכל ישירות לאדם.
זה יוצר בסיס חזק יותר לביקורת (Auditing) ולהגבלת פעילות אוטומטית.
עם זאת, הטווחים (Scopes) וקהלי היעד של הלקוח עדיין דורשים הגדרה קפדנית, וה-API המקבל חייב לאכוף אותם. האצלת לקוח אינה מעניקה גישה ל-Keycloak Admin API.
גרסה 26.8 משפרת גם ביקורת התחזות (Impersonation) על ידי הוספת מידע על הגורם הפועל לטוקנים ולאירועים קשורים.
Parameterized scopes (טווחים פרמטריים)
טווחים פרמטריים מתקדמים ל-Preview ב-26.8, בהמשך לאימות פרמטרים מוקלדים ב-26.7.
טווח כגון project:12345 יכול לשאת הקשר משאב מבלי שדרשי מנהלי מערכת להגדיר הגדרת טווח נפרדת עבור כל פרויקט.
זה יכול להיות שימושי עבור אינטגרציות סוכנים הפועלות לרוחב משאבים רבים. האפליקציה עדיין חייבת לבדוק שהפונה מורשה לקבל גישה לפרויקט המצוין.
מידע נוסף זמין ב-תיעוד החלפת טוקנים והאצלה.
אונבורדינג, אופבורדינג ותחזוקת חשבונות אוטומטיים
יכולת ה-Workflows (תהליכי עבודה) של Keycloak עוברת מ-Preview ב-26.5 ל-Supported ב-26.6, בהתבסס על יישום ניסיוני שהוצג ב-2025.
תהליכי עבודה מאפשרים למנהלי מערכת להגדיר תהליכים המופעלים על ידי אירועים, תנאים ולוחות זמנים. הם מסייעים להחליף ולתקנן ניהול זהויות ולהפחית תלות במשימות ידניות.
גרסה 26.8 מוסיפה שלב invite-user השולח הזמנה עם פעולות נדרשות, כגון אימות כתובת דוא"ל או הגדרת סיסמה.
מבחינת אבטחה, יכולות אלו מסייעות לארגונים:
- לייצר מעקב אחר חשבונות לא פעילים.
- להחיל נהלי אונבורדינג עקביים.
- להסיר גישה כאשר אחריות משתנה.
- להפחית את הזמן בין שינוי ארגוני לביצועו במערכות הזהות.
תהליכי עבודה הם אוטומציה מורשת. תנאים המעניקים גישה צריכים להתבסס על מידע שמשתמשים אינם יכולים למניפולציה בעצמם.
SCIM הופך ל-Supported
Keycloak מוסיפה יכולות SCIM ב-Preview ב-26.7 ומקדמת אותן ל-Supported ב-26.8.
**SCIM – System for Cross-domain Identity Management –** מספק ממשק תקני עבור מערכות חיצוניות לניהול משתמשים וקבוצות ב-Keycloak.
היכולות כוללות פעולות משתמשים וקבוצות, סינון, עימוד (Pagination), בקשות PATCH והרחבות סכמה. גרסה 26.8 משפרת טיפול בתכונות, אכיפת הרשאות וביצועים.
זה מפשט אינטגרציה עם מערכות ממשל זהויות (Identity Governance) ופלטפורמות פרוביז'נינג. מדובר ב-API פרוביז'נינג נכנס (Inbound), ולא במחבר אוניברסלי שמספק אוטומטית כל אפליקציית SaaS במורד הזרם.
עבור אפליקציות מבוססות AI, אופבורדינג עקבי מסייע להסיר את הגישה האנושית שבה תלויה הפעילות המואצלת. יש לקחת בחשבון גם סשנים פעילים, טוקנים קיימים ואישורי סוכן עצמאיים.
ניהול מדויק יותר עבור ארגונים ולקוחות
יכולות הארגון (Organizations) ב-Keycloak מתרחבות לרוחב מספר גרסאות:
- 26.6: היררכיות קבוצות תלויות-ארגון ומערך מיפוי ספקי זהות.
- 26.7: תפקידי ניהול ארגוניים, הרשאות ניהול עדינות יותר והורשת תפקידים דרך קבוצות ארגון.
- 26.8: ספקי זהות משותפים לרוחב ארגונים, עם הגדרות חברות נפרדות וניתוב מבוסס דומיין.
שיפורים אלה שימושיים עבור אפליקציות B2B, פורטלי לקוחות וארגונים המשרתים יחידות עסקיות מרובות.
לדוגמה, מנהל מערכת אצל לקוח יכול לקבל סמכות על הארגון שלו מבלי לקבל הרשאות ניהול רחבות ברמת ה-Realm.
זה תומך בעקרון ההרשאה המינימלית (Least Privilege) ויכול לצמצם את ההשפעה של פריצה לחשבון מנהל מערכת. אפליקציות עדיין חייבות לאכוף את גבולות הדיירים (Tenants) שלהן.
גישה בטוחה יותר לטוקנים של ספקי זהות חיצוניים
Identity Brokering API V2 הופך ל-Preview ב-26.6 ול-Supported ב-26.7.
הוא מציג הרשאה ספציפית ללקוח לאחזור טוקנים של ספק זהות חיצוני, דורש לקוחות חסויים (Confidential Clients) ותומך באחסון טוקנים חיצוניים בסשנים של משתמשים.
זה חשוב כאשר אפליקציה או Backend של סוכן זקוקים לאישורים כדי לקרוא לשירות אחר. הגישה לאישורים אלה יכולה להיות מוגבלת לאינטגרציה הרלוונטית בלבד.
V2 מבוטל כברירת מחדל, כך ששדרוג בלבד אינו מעביר פריסה קיימת.
אימות חזק יותר וניהול סשנים
מספר עדכונים מחזקים את האימות היומיומי ובקרות החשבון.
אימות מוגבר ב-SAML (Step-up authentication) הופך ל-Supported ב-26.7 לאחר הצגתו ב-Preview ב-26.6. אפליקציית SAML יכולה לבקש הקשר אימות חזק יותר עבור פעולות רגישות.
לדוגמה, ארגון יכול לעצב תהליך אישור הדורש אימות אנושי חזק יותר לפני ששינוי ייצור מתבצע לבקשת סוכן. תהליך האישור חייב להיות מיושם על ידי האפליקציה; Keycloak אינה מוסיפה אותו באופן אוטומטי.
שיפורים נוספים כוללים:
- תאימות Passkeys טובה יותר: אפשרויות מדיניות אישורים נגלים (Discoverable Credentials) חדשות ב-26.7 מספקות גמישות רבה יותר לרוחב מאמתים.
- אכיפת שינוי סיסמה ב-LDAP: הגדרה אופציונלית שהוצגה ב-26.6 מאפשרת ל-Keycloak לכבד חובת שינוי סיסמה של ספריית השרת.
- רענון אוטומטי של רשימת סיסמאות נפסלות: רשימות מעודכנות יכולות להיכנס לתוקף מבלי לאתחל את השרת.
- נתוני כישלון התחברות עמידים: ב-26.8, נעילות זמניות שורדות איתחולי קלסטר דרך שמירה במסד הנתונים, למעט במצבי פריסה מסוימים של מטמון חיצוני.
- סיום סשן ברמת האפליקציה: ה-Account Console מקבל שליטה עדינה יותר בסשנים ב-26.8.
התנהגות התנתקות (Logout) של האפליקציה עדיין תלויה באינטגרציה. הסרת סשן לקוח ב-Keycloak אינה מבטיחה דחייה מיידית של כל טוקן גישה שהונפק בעבר.
Passkeys עצמם היו זמינים לפני 2026; השינויים השנה משפרים את הקונפיגורציה והתאימות שלהם.
אותות אבטחה חדשים וממשקי הרשאה
Keycloak 26.7 מציגה מספר יכולות ניסיוניות הרלוונטיות לארכיטקטורות אבטחה עתידיות.
Shared Signals Framework
Shared Signals Framework (SSF) מאפשרת ל-Keycloak לשלוח אירועי אבטחה חתומים למקבלים רשומים. אלה יכולים לתקשר שינויים בסשנים, אישורים ומצבי חשבון.
גרסה 26.8 מרחיבה את אותות החשבון הזמינים ומשפרת טיפול באירועים.
אפליקציה משולבת או Gateway של סוכנים יכולים להשתמש באותות אלה כדי להגיב מהר יותר כאשר גישה צריכה להסתיים. המקבל חייב לאמת את האות וליישם את התגובה.
כך ש-SSF הוא אבן בניין לשינויי גישה מתואמים – ולא מנגנון אוטומטי שעוצר כל סוכן פעיל.
AuthZEN
AuthZEN מספק ממשק תקני דרכו אפליקציות יכולות לבקש החלטות הרשאה.
API או Gateway יכולים לשאול האם נושא מסוים מורשה לבצע פעולה על משאב.
עבור אינטגרציות AI, זה יכול לסייע לרכז החלטות הרשאה מחוץ לסוכן עצמו. ה-Gateway או האפליקציה חייבים לאכוף את התוצאה בהתבסס על הקשר בקשה מהימן.
Identity Assertion JWT Grant
Identity Assertion JWT Grant (ID-JAG) מוסיף יישום שרת מקבל ניסיוני ב-26.7.
הוא רלוונטי לגישה לרוחב מתחמי הרשאה, אך Keycloak עדיין אינה מממשת את התהליך המלא מקצה לקצה.
יש להעריך יכולות אלה בהתאם לבשלות המתועדת שלהן ומגבלות הפריסה.
ארנקים דיגיטליים ואישורים ניתנים לאימות
Keycloak מקדמת גם את התמיכה שלה באישורים דיגיטליים.
OpenID for Verifiable Credential Issuance (OID4VCI) מגיע ל-Preview ב-26.8, לצד שיפורים בניהול אישורים, ביטול (Revocation), פעולות הנפקה וטיפול באישורים (Attestation).
אימות OpenID for Verifiable Presentations (OID4VP) נותר ניסיוני (Experimental), וכך גם mdoc ומספר יכולות קשורות.
תכונות אלו יוצרות הזדמנויות להערכת אימות מבוסס ארנק ואישורים חתומים קריפטוגרפית. ערך האבטחה שלהם תלוי בפורמט האישור, במודל האמון ובתהליך האימות.
אין לפרש אותם כקובעים באופן אוטומטי האם סוכן AI הוא מהימן.
תפעול קל יותר מסייע לצוותים לתחזק פריסה מאובטחת יותר
מורכבות תפעולית עלולה לעכב עדכוני אבטחה ולעודד קיצורי דרך בקונפיגורציה. מספר שיפורים בשנת 2026 הופכים את Keycloak לקל יותר לתפעול.
Rolling updates (עדכונים רציפים) עבור גרסאות תיקון הופכים ל-Supported ב-26.6. הם חלים בתוך אותו ערוץ גרסה ראשי/משני ודורשים קונפיגורציית פריסה מתאימה. הם אינם מבטיחים שדרוגים ללא השבתה בין גרסאות שונות באופן שרירותי.
Multi-cluster v2 הופך ל-Supported ב-26.8 לאחר הצגתו ב-Preview ב-26.7. מצב ה-Stateless שלו מסיר את הצורך בקלסטר Infinispan חיצוני, ומפשט את הארכיטקטורה.
הפריסה עדיין דורשת מסד נתונים מתאים, שכפול סינכרוני, שיהוי (Latency) נמוך, שעונים מסונכרנים ואיזון עומסים (Load Balancing).
Client Admin API v2 ומשאבי לקוח של Operator מתקדמים מ-Experimental ב-26.7 ל-Preview ב-26.8. ניהול לקוחות דקלרטיבי ב-OIDC ו-SAML מסייע לצוותים לסקור שינויי קונפיגורציה ולשחזר פריסות.
שיפורים תפעוליים נוספים הקשורים לאבטחה כוללים תמיכה במפתח פרטי PEM מוצפן, קונפיגורציית TLS פשוטה יותר למסד הנתונים ומדיניות אימות שם מארח אופציונלית לרישום צומתי לקוח ירושה.
גם יומני הרישום (Logging) משתפרים דרך מידע MDC הקשרי, אפשרויות OpenTelemetry נוספות, קובצי יומן גישה נפרדים ורוטציה ניתנת להגדרה. הסתרת כותרות ועוגיות רגישות ספציפיות מפחיתה חלק מחשיפת האישורים, למרות שיומני רישום עדיין דורשים טיפול זהיר.
תכונות ושיפורים נוספים לפי גירסה
הגרסאות כוללות גם שיפורי אינטגרציה, ניהול ושימושיות קטנים יותר.
Keycloak 26.5
לצד תכונות הזהות והאוטומציה שתוארו לעיל:
- כותרות CORS ומדיניות רישום לקוחות ניתנות להגדרה.
- דף אישור התנתקות אופציונלי.
- בקרות לפרסום טווחים דרך מטא-נתונים של גילוי.
- הזמנות ארגון עמידות עם סינון, שליחה מחדש ומחיקה.
- אירוע מחיקת סשן שפג תוקפו חדש,
USER_SESSION_DELETED. - אימג'י קונטיינר עבור PowerPC ppc64le.
- שיפורים במיקומי מטמון סשן וניקוי סשנים שפג תוקפם.
- סריאליזציית HTTP JSON ממוטבת ב-Preview.
- ניסיונות חוזרים (Retries) ניתנים להגדרה עבור בקשות HTTP יוצאות.
- אפשרויות הפעלת תכונות פרטניות.
- העברת תעודות לקוח לפי RFC 9440.
- התקנה כ-Windows Service.
- ייצוא יומני OpenTelemetry ב-Preview, ייצוא מטריקות ניסיוני וכותרות ייצוא עקבות מותאמות אישית.
- קידום רישום MDC ל-Supported.
Keycloak 26.6
שינויים נוספים כוללים:
- מדריך יישום DPoP חדש; DPoP עצמו קודם ל-2026.
- טווח ניהולי ספציפי יותר לניהול חברות בקבוצות.
- תמיכה ב-Java 25.
- הוראות פריסה עבור CloudNativePG.
- הגדרות Timeouts במסד הנתונים, בדיקות קידוד ושיפורי בדיקות מיגרציה.
- כיבוי נקי (Graceful shutdown) ב-HTTP.
- קידומת משתנה סביבה
KCRAW_לשמירה על ערכים מילוליים, כולל סודות המכילים תווים מיוחדים. - אתחול אוטומטי של Truststore ב-Kubernetes ו-OpenShift.
- אחזור תעודות לקוח עבור Traefik ו-Envoy.
- שמות ופורטים של Kubernetes Service ניתנים להגדרה.
- שדות שירות יומן JSON וקונפיגורציית טלמטריה של Operator.
- כותרות מייצא טלמטריה ו-ServiceMonitor metadata ניתנים להגדרה.
- תרגומים נוספים ותמיכה ראשונית ב-Account UI עבור שפות מימין לשמאל.
- שלד בדיקות Keycloak Test Framework מבוסס JUnit בסטטוס Supported.
Keycloak 26.7
שינויים נוספים כוללים:
- שיפורי ניהול, רענון ותאימות של אישורים ניתנים לאימות.
- אימות לקוח מבוסס אישור (Attestation) ניסיוני ופונקציונליות קוד מורשה מראש בבקרה נפרדת.
- חיפוש Realm לפי שם תצוגה.
- החרגה אופציונלית של מקורות נתונים נוספים מבדיקות תקינות (Health checks).
- Truststores מסוג BCFKS שנוצרו במצב FIPS מחמיר.
- הנחיות Reverse-proxy מורחבות עבור HAProxy ו-Traefik.
- התקנת Operator מבוססת Kustomize.
- פריסת Operator לרוחב הקלסטר ב-Preview.
שינויים נוספים כוללים:
Keycloak 26.8
- אכיפה חזקה יותר של רשימת היתרים (Allow-list) עבור Protocol-mapper דרך ה-Admin REST API.
- שמות קלסטר וצומת ניתנים להגדרה.
- יצירת אינדקסים בלתי-חוסמת אוטומטית במסד הנתונים במידה ונתמכת.
- לקוח HTTP יוצא Vert.x ניסיוני.
- התקנת Operator מבוססת Helm ניסיונית.
- כפתורי ספקי זהות מעודכנים בדף ההתחברות.
- שיפורי זיכרון במיון אפליקציות והאשינג של סיסמאות.
- הוצאה משימוש (Deprecation) של Multi-cluster v1 לטובת הארכיטקטורה החדשה יותר.
הודעות השחרור הרשמיות מספקות את יומני השינויים ההנדסיים המפורטים, וקישור זמין למטה.
תיקוני אבטחה נותרים חיוניים
תכונות חדשות הן רק חלק מתמונת האבטחה.
גרסאות תיקון (Patch releases) במהלך 2026 כוללות שינויים בהסתרת יומני גישה, מגבלות פרמטרים ב-Token endpoint, אימות Redirect-URI וניהול לקוחות מבוטלים.
Keycloak 26.8.1 מתקנת גם בעיות המשפיעות על אימות, הרשאות ניהול, Identity brokering והחלפת טוקנים (Token exchange).
ארגונים צריכים לסקור את מדריך השדרוג ולבדוק אינטגרציות לפני הפריסה, כולל כאשר תיקון אבטחה משנה התנהגות שהתקבלה בעבר.
מה זה אומר עבור ארגונים המשתמשים בסוכני AI?
ההמלצה שלנו היא להתחיל עם מודל גישה ברור עבור כל אינטגרציית סוכן:
- הקצו זהות ובעלים נפרדים. דעו איזו אפליקציה או עומס עבודה פועלים.
- הגבילו הרשאות למשימה הנדרשת בלבד. הימנעו ממתן אישורי ניהול רחבים לסוכנים.
- צמצמו סודות קבועים. העריכו אימות פדרטיבי ואישורים לטווח קצר.
- אכפו הרשאות ב-APIs וב-Gateways. אמתו טוקנים והרשאות מחוץ למודל ה-AI.
- תעדו את המשתמש ואת הגורם הפועל. קשרו אירועי זהות לפעילות האפליקציה והכלים.
- בחנו אופבורדינג וביטול גישה. ודאו מה קורה לסשנים וטוקנים קיימים.
- שימרו על פעולות רגישות תחת אישורים מתאימים. אימות והסכמה אינם מחליפים אישור ברמה העסקית.
Keycloak יכולה לספק את תשתית הזהות ובקרת הגישה עבור תכנונים אלה. היא אינה בודקת Prompts, אינה מזהה Prompt Injection, אינה מבודדת (Sandbox) סוכן ואינה קובעת אם פעולה מורשית היא הגיונית.
סוכן שעבר מניפולציה עשוי עדיין לנצל לרעה את ההרשאות הלגיטימיות שלו. הגבלות בזמן ריצה, בקרות ברמת הכלים והשגחה אנושית נותרו חשובות.
כיצד החברה שלנו יכולה לעזור לכם?
חברת ALM Toolbox מספקת שירותי תכנון, הטמעה, אינטגרציית SSO, תחזוקה ותמיכה ב-Keycloak.
אנו יכולים לעזור להעריך את הפריסה הנוכחית שלכם, לזהות אילו עדכונים רלוונטיים, לתכנן שדרוג ולסקור את דרישות הזהות והגישה של האפליקציות והאוטומציה שלכם.
אם אתם מציגים סוכני AI או מרחיבים גישה לכלים פנימיים, זו גם הזדמנות טובה לסקור זהויות עומסי עבודה, ניהול אישורים, הרשאות וביקורת.
צרו קשר לדיון בדרישות ה-Keycloak והאבטחה שלכם: "keycloak@almtoolbox.com או התקשרו אלינו: 072-240-5222
