Capability-Based Security — הרשאות לפי יכולת במקום לפי משתמש

מאת צוות מדיה דיל · 12.08.2026 · AI Security · 5 דק׳

למה מודל הרשאות מבוסס זהות (RBAC/ACL) נשבר עם Agents, ואיך Capability-Based Security - אסימונים צרים ובלתי-ניתנים-לזיוף לכל פעולה - סוגר את הפער.

מהנדס אבטחה שבדק הרשאות ב-Agent פנימי גילה תבנית מוכרת: בדיקת ההרשאה מתבצעת פעם אחת, בתחילת השיחה, לפי זהות המשתמש - "קובי מחלקת מכירות, מותר לו לקרוא לקוחות". מרגע זה ואילך, כל כלי שה-Agent קורא לו סומך על התוצאה הזו בעיוורון, גם שעה ושמונים קריאות כלים אחר כך, וגם אם בינתיים ה-Agent "שוכנע" דרך פרומפט עוין לבצע פעולה שקובי מעולם לא ביקש. זו הבעיה המובנית במודלי הרשאה מבוססי זהות (Identity-Based): הם שואלים "מי אתה" ועונים עם רשימת כל מה שמותר לך, לתמיד, בכל הקשר. Capability-Based Security הופך את השאלה: במקום "מי אתה", השאלה היא "האם בידיך אסימון קונקרטי שמאשר בדיוק את הפעולה הזו, עכשיו".

ההבדל המהותי בין ACL לבין Capability

במודל מבוסס-רשימות-בקרה (ACL) או תפקידים (RBAC), ההרשאה שמורה במערכת מרכזית ומשויכת לזהות: "המשתמש X מורשה לפעולה Y". כל רכיב שרוצה לפעול בשם X בודק מול המערכת המרכזית הזו, ולכן כל רכיב כזה יורש בפועל את מלוא ההרשאות של X - זו הנקראת Ambient Authority, סמכות שנמצאת "באוויר" סביב הזהות ולא קשורה לפעולה הספציפית. במודל Capability, ההרשאה עצמה היא אובייקט: אסימון בלתי-ניתן-לזיוף (Unforgeable Token) שמצביע על משאב ספציפי ופעולה ספציפית - "מותר לקרוא בדיוק לרשומת הלקוח מספר 4471, פעם אחת, בתוך עשר הדקות הקרובות". מי שמחזיק את האסימון הזה יכול לבצע בדיוק את הפעולה הזו, ושום דבר מעבר לכך - גם אם הוא "המשתמש X" עם כל ההרשאות הרחבות שלו במערכת המרכזית.

ההבדל הזה קריטי במיוחד ל-Agent, כי ל-Agent אין "כוונה" קבועה כמו לקוד שכתב מפתח - הכוונה שלו נגזרת מפרומפט שיכול להיות מושפע מתוכן עוין. אם ה-Agent פועל תחת Ambient Authority של המשתמש, כל פרומפט שמצליח "לשכנע" אותו לבצע פעולה לא מכוונת מקבל אוטומטית את מלוא ההרשאות של המשתמש לביצועה. אם הוא פועל רק עם Capabilities קונקרטיים שהוענקו לו מראש לכל שלב, אין לו במה "לשכנע" את עצמו - אין לו גישה לשום דבר שלא הוענק לו במפורש כאסימון.

איך זה נראה בפועל בארכיטקטורת Agent

במקום שה-Agent יחזיק מפתח API רחב שמאפשר לו "לגשת לכל מה שקובי יכול לגשת אליו", כל קריאת כלי מקבלת Capability צר משלה שמונפק ברגע הצורך. לדוגמה, כשה-Agent צריך לקרוא קובץ בודד מ-Google Drive, שכבת התיווך מנפיקה אסימון שמצביע רק על אותו קובץ, לזמן קצר, ולפעולת קריאה בלבד - לא Refresh Token רחב שמעניק גישה לכל הדרייב. הדוגמה המוכרת ביותר למימוש כזה היא URLs חתומים (Signed URLs) עם תוקף מוגבל, ומודלים דומים קיימים ב-Macaroons (אסימונים שניתן לצמצם אך לא להרחיב לאחר ההנפקה) וב-Cap'n Proto RPC, שבו כל Reference בין רכיבים הוא בעצם Capability.

// הנפקת Capability צר לקריאה בודדת, לא הרשאה גורפת
const cap = issueCapability({
  resource: "drive://file/4471",
  action: "read",
  ttl_seconds: 300,
  singleUse: true
});
// ה-Agent מקבל את ה-cap, לא את המפתח הרחב

ההבדל הזה משתלב עם עקרון Least Privilege ל-Agents, אבל הוא לא זהה לו: Least Privilege אומר "תן כמה שפחות הרשאות". Capability-Based Security הוא המנגנון שמאפשר לאכוף את זה בפועל ברמת כל קריאה בודדת, ולא רק ברמת המדיניות הכללית שנקבעת מראש.

Confinement: הבעיה שנשארת גם עם Capabilities

Capability-Based Security לא פותר הכל. הבעיה הנותרת נקראת Confinement: מה מונע מ-Agent שקיבל Capability לגיטימי להעביר אותו הלאה למקום שלא היה אמור להגיע אליו - למשל, להטמיע אותו בפלט טקסטואלי שנשלח למשתמש חיצוני, שיכול אז להשתמש בו בעצמו? זו בדיוק הדינמיקה שמנוצלת בהתקפות שמתוארות במדריך על Confused Deputy Attack, שבהן ישות בעלת סמכות "משאילה" אותה בטעות לגורם שלא היה אמור לקבל אותה. הפתרון החלקי הוא Capabilities עם Binding הדוק לזהות המבקש המקורית (לא ניתנות להעברה - Non-Transferable), יחד עם תוקף קצר מספיק כדי שגם אם דלפו, החלון לניצול לרעה קטן.

מחיר המעבר: מה זה עולה בפועל

המעבר למודל Capability דורש שינוי ארכיטקטוני אמיתי, לא רק החלפת שכבת בדיקת הרשאות. כל שירות במערכת צריך לדעת להנפיק ולאמת Capabilities צרים, במקום לבדוק מול טבלת הרשאות מרכזית - מה שמוסיף מורכבות תפעולית ודורש תשתית הנפקה (Capability Issuer) שהיא עצמה רכיב קריטי מבחינת אבטחה. יש גם מחיר תפעולי: כשכל פעולה דורשת אסימון נפרד עם תוקף קצר, עולה תדירות ההנפקה, ויש לוודא שה-Issuer עצמו לא הופך לצוואר בקבוק או לנקודת כשל יחידה. ברוב הארגונים הגישה הפרגמטית היא היברידית: RBAC ברמת המדיניות הגסה ("איזה סוגי כלים מותר ל-Agent הזה בכלל לגשת אליהם"), ו-Capabilities צרים ברמת כל קריאה בפועל - כך משלבים את הפשטות הניהולית של תפקידים עם הדיוק והבטיחות של הרשאה נקודתית.

מתי לא כדאי להשקיע בזה

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

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

צוותים שמכירים Zero Trust נוטים לשאול איפה בדיוק Capabilities שונים מהעיקרון של "לעולם אל תסמוך, תמיד תאמת". התשובה: Zero Trust הוא פילוסופיית תשתית - כל בקשת רשת מאומתת ומוצפנת מחדש בלי הנחה של אמון מובנה בין רכיבים ברשת הפנימית. Capability-Based Security הוא רמה עדינה יותר, שממוקדת בשאלה מה בדיוק כל בקשה מורשית לעשות ברגע הספציפי הזה, לא רק האם היא מגיעה ממקור מאומת. ניתן, וכדאי, להשתמש בשניהם יחד: Zero Trust מוודא שהערוץ עצמו בטוח, ו-Capabilities מוודאים שגם ערוץ בטוח לחלוטין לא מקנה יותר סמכות מהנדרש לפעולה הבודדת. באופן דומה, מנגנון Capability שנשען על אימות זהות חלש בשכבה שמנפיקה את האסימונים שווה בדיוק כמו האימות שמאחוריו - ולכן שילוב עם אימות זהות סוכן תקין הוא תנאי הכרחי, לא אופציונלי, להצלחת המודל כולו.

תגיות: Capability-Based Security · Ambient Authority · object capabilities · Macaroons · agent permissions · RBAC vs capabilities

← חזרה לבלוג · צור קשר