הגדירו משימה מדויקת וזהות שמותר לה לפעול
תיאור כמו עוזר שמטפל בלקוחות רחב מדי כדי לבחור הרשאות. רשמו אם התפקיד הוא לסכם פנייה, להכין טיוטת תשובה או לעדכן שדה מסוים. לכל פעולה ציינו מקור מידע, מערכת יעד ובעלים. אם לא ברור איזה מידע נדרש, לא מעניקים גישה לכל התיבה או לכל ה-CRM כברירת מחדל.
הזהות יכולה להיות משתמש, זהות יישום או פעולה בהקשר משתמש לפי המוצר. העיקר הוא להבין מה היא מאפשרת, למי היא שייכת ומי יכול לבטל אותה. אין לשתף חשבון מנהל של עובד רק מפני שקל להפעיל דרכו את החיבור. מנגנון הגישה צריך להיות נתמך ומנוהל.
מפו יכולות עודפות, הרשאות עודפות ואוטונומיה
OWASP מתאר Excessive Agency כסיכון שקשור ליכולות, להרשאות או לאוטונומיה עודפות. ההבחנה עוזרת לבדוק גם כלי שמחובר בזהות מצומצמת אך עדיין כולל פעולות שלא נדרשות. הטבלה היא מטריצה מקורית לעסק, ולא הגדרה מוכנה לכל ספק.
| פעולה | היקף שיש להגדיר | בדיקה לפני הפעלה |
|---|---|---|
| קריאת מסמך | מקור ותיקייה מאושרים | מסמך מחוץ להיקף אינו נקרא |
| יצירת טיוטה | רשומה או מרחב עבודה מוגדר | לא נשלחת הודעה בפועל |
| עדכון שדה | נכס, שדות ותנאים מותרים | אין שינוי ברשומות אחרות |
| שליחת הודעה | נמען, תוכן וכלל אישור | המסירה תואמת לאישור המפורש |
| מחיקה או שינוי גישה | צורך עסקי וסמכות חריגה | חסימה או אישור לפי התכנון |
| חיבור חדש לכלי | מאשר, זהות ותנאי שימוש | אין הרחבה אוטומטית של היקף |
הרשאה ואישור אינם החלטה שהמודל רשאי להמציא
הוראה כתובה לסוכן אינה מחליפה בדיקה טכנית במערכת היעד. OWASP ממליץ על הרשאה מזערית ועל בדיקת הרשאות בכל בקשה. פעולה צריכה לעמוד בכללים גם אם הפלט שיצר המודל טוען שהמשתמש אישר אותה. זה חשוב במיוחד כאשר המודל קורא מסמכים או מיילים של גורם אחר.
אישור אנושי צריך להציג פעולה קונקרטית: איזה משאב, איזה שינוי ולאיזה נמען. אם הערכים משתנים אחרי האישור, יש לבחון מחדש מה אושר ולמנוע ביצוע על בסיס אישור עמום. אדם שמאשר סיכום כללי בלי לראות את השינוי אינו בהכרח בקרה יעילה על הפעולה.
גם גישת קריאה צריכה הגבלה ותוכנית יציאה
קריאה בלבד אינה מאפשרת שינוי באותו מקור, אך עדיין יכולה לחשוף מידע דרך פלט או ערוץ אחר שהתהליך מפעיל. בודקים גם לאן מותר לפלט להגיע, מה נרשם בתיעוד ומי רשאי לראות אותו. צמצום הרשאה במקור אחד אינו מבטיח שכל החיבורים האחרים הוגבלו.
תעדו את התלות במפתח, token או הסכמת משתמש, את תקופת השימוש ואת דרך הביטול הנתמכת. הסרת הכלי ממסך אחד אינה הוכחה שהאישור בוטל אצל הספק. צריך לבדוק את המצב במערכת שמנהלת את הגישה, בלי להעתיק ערכים סודיים למסמך המסירה.
דוגמה: מתחילים בסיכום פנייה בלי יכולת שליחה
התרחיש להמחשה בלבד. העסק רוצה סוכן שמסכם פנייה ומציע תשובה. בסביבת ניסיון נותנים גישה רק לנתונים מלאכותיים הנחוצים ומפרידים טיוטה משליחה. בודקים שגם מסמך שמכיל בקשה לחרוג מהמטרה אינו גורם להודעה לצאת או לרשומה אחרת להשתנות.
אם בהמשך נדרשת שליחה, זהו שינוי יכולת שצריך לאשר ולבדוק בפני עצמו. מציגים נמען ותוכן, בודקים הרשאה ומגדירים טיפול בכשל ובפעולה כפולה לפי המערכת. הצלחת הסיכום אינה אישור אוטומטי להרחבת הפעולות. אין להריץ ניסוי על לקוח אמיתי כדי לגלות שהשליחה כבר הייתה מותרת.
מסירה, מעקב וביטול צריכים להיות חלק מההקמה
מסמך המסירה כולל בעלים, זהות, מקורות, כלים, פעולות, מאשרים ובדיקות קבלה. תיעוד הפעילות צריך לאפשר בירור החלטות ושינויים בלי לשמור סודות או תוכן לקוחות מיותר. מגדירים מי בוחן כשל ומי רשאי לעצור חיבור, ולמי פונים כשהסוכן פועל מחוץ למטרה.
בחינה חוזרת נחוצה כשמוסיפים כלי, משנים מודל, מרחיבים מקור או מעבירים בעלות. אישור שניתן לסביבת ניסיון אינו אישור קבוע לייצור. CyberFixCrew יכולה לסייע במיפוי זהויות וחיבורים לפי השירותים הקיימים ובהיקף מוגדר; המדריך אינו הבטחה לאוטומציה חסינה או להפעלה ללא בקרה.
