בקרת גישה, ניהול זהות וסודות — אבטחה וממשל תאגידי

רווחים:

יכולת להפריד בין אימות והרשאה ולהחיל הרשאה מינימלית עם RBAC/ABAC
יכולת להימנע מסיכון פרוקסי מעורב על ידי הפעלת המודל בהקשר המשתמש
יכולת אחסון וסיבוב מפתחות API עם מערכת הניהול הסודי

חלק ניכר מההתקפות על מערכת AI מתחילות לא ב"הטעיה" של המודל, אלא עם מפתח API גנוב או חשבון מורשה יתר. שכבת אבטחה זו מגיעה מאבטחת מידע קלאסית, אך מוסיפה סיכונים חדשים בהקשר של AI: דגם קורא טרמפ מטעם מישהו אחר, חשבון שירות ניגש לכל הנתונים, דליפה מפתח ל-GitHub. ביחידה זו נלמד כיצד לצמצם את הגישה למערכת הבינה המלאכותית עם אימות, הרשאה (RBAC/ABAC), הרשאות מינימום וניהול סודי.

ההבדל בין אימות והרשאה

לעתים קרובות מבולבלים בין שני המונחים:

אימות: "מי אתה?" - הוכחה שהמשתמש/השירות הוא באמת מי שהם טוענים שהוא (סיסמה, אסימון, אישור, MFA).
אישור: "מה אתה יכול לעשות?" - לקבוע לאיזה משאב/פעולה הצד המאומת יכול לגשת.

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

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

RBAC ו-ABAC

RBAC (בקרת גישה מבוססת תפקידים): גישה תלויה בתפקיד המשתמש. תפקיד "מומחה תמיכה" יכול לקרוא הערות של לקוחות, אך אינו יכול למחוק אותן. פשוט ונפוץ.
ABAC (בקרת גישה מבוססת תכונות): הגישה תלויה בתכונות: מחלקת המשתמש, תווית הפרטיות של הנתונים, השעה ביום, הרשת ממנה מגיעה הבקשה. יותר מכוונן אבל מורכב יותר.

רוב הארגונים מתחילים עם RBAC ומעמיקים ל-ABAC עבור נתונים רגישים. כלל אצבע עבור AI: המודל צריך לסנן כל סוכן שהוא מתקשר אליו וכל נתונים שהוא ניגש אליו בהתבסס על התפקיד/התכונות של המשתמש שמבצע את הבקשה.

צעד אחר צעד: הפעלת סמכות מינימלית

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

ניהול סודי

סוד הוא אישורים שחייבים להישאר סודיים, כגון מפתח API, סיסמה, אסימון או אישור. התאונה הנפוצה ביותר בפרויקטים של בינה מלאכותית היא כאשר מפתח ה-API של ספק הדגם מוטבע בקוד ודולף לבקרת גרסאות (Git).

יישום נכון:

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

ארבע תבניות הניתנות להעתקה

גישה לבקשת בקרת ביקורת:

עבור כל כלי ברשימת הכלים שלהלן, הערך: האם כלי זה נדרש לביצוע תפקידו של עוזר זה? (כן/לא) - האם זה לקריאה בלבד או כתיבה/מחיקה? - האם הכלי הזה נקרא עם הסמכות או חשבון השירות של המשתמש? סמן כאלה מיותרים או מורשים מדי כ"הסר/הסרה".<tools>{{ tool_list }}</tools>

הודעת סריקת דליפות סודית:

מצא כל דבר שיכול להיות סוד מקודד בקטע הקוד הבא: מפתח API, סיסמה, אסימון, מחרוזת חיבור, מפתח פרטי. תן שורה וסוג עבור כל אחד. COPY value into response;mask (4 התווים הראשונים + ***).<code>{{ source }}</code>

כלל ההחלטה הפחותה ביותר:

כאשר מגיעה בקשת גישה חדשה לכלי, שאל: 1. האם ניתן לבצע את המשימה ללא גישה זו? -> אם כן: REJECT2. האם קריאה בלבד מספיקה? -> אם כן: הענק הרשאת כתיבה3. האם ניתן לצמצם את ההיקף למקור יחיד? -> אם כן: darat תשובת ברירת המחדל היא "לא"; גישה מתקבלת על ידי סיבה.

תזכורת לוח שנה סיבוב:

עבור כל סוד, רשום: בעלים, תאריך יצירה, תפוגה, היקף. דווח על כל מפתח שחרג מ-90 יום או שלא נעשה בו שימוש במשך 30 יום כ"מועמד לרוטציה/ביטול".

הנחיה חלשה / הנחיה חזקה

גישה גרועה

גישה חזקה

המודל ניגש לכל הנתונים באמצעות חשבון שירות יחיד

המודל ניגש בסמכות המשתמש שמבצע את הבקשה

מפתח API מוטבע בקוד, הוא לעולם לא משתנה

רוטציה במנהל סודי מפתח, 90 יום

סמכות רחבה של "עשה הכל" לעוזרת

ברירת מחדל לקריאה בלבד, כתוב צר

גישה לעולם לא נבדקת

בדיקה וביטול גישה רגילה

שלושה מיני מארזים

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

מקרה 2 - מפתח דלף, חשבון של 190,000 TL תוך שבועיים. מפתח הטמיע את מפתח ה-API של הדגם בסקריפט עוזר ודחף אותו למאגר ציבורי. בוט מצא את המפתח תוך 40 דקות והשתמש בו במשך שבועיים; החשבון הגיע ל-190,000 TL. כשהמפתח הועבר למנהל הסוד, חובר לרוטציה ונוספה סריקת מאגר, האירוע לא חזר על עצמו.

מקרה 3 - ברירת מחדל לקריאה בלבד מונעת הפרעה. עוזר DevOps קיבל פקודת "איפוס מסד נתונים של ייצור" באמצעות הזרקה מהירה. עם זאת, העוזרת קיבלה רק אסימון לקריאה בלבד; כתיבה/מחיקה הייתה בתהליך מאושר נפרד. הפקודה נדחתה עם שגיאת הרשאה והאירוע נרשם כאזעקה; לא היה אובדן נתונים.

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

טעויות נפוצות

הפעלת המודל עם חשבון שירות גדול ואיבוד הקשר המשתמש (פרוקסי מעורב).
הטמעת מפתח ה-API בקוד והדלפתו לבקרת גרסאות.
לא מסובב את המקשים בכלל ("עובד, אל תיגע").
מתן הרשאות כתיבה/מחיקה למסייע כברירת מחדל.
מתן גישה פעם אחת ולעולם לא שוקל אותה מחדש.
מבלבל בין אימות להרשאה ובהנחה ש"הוא מחובר, הוא יכול לגשת להכל".

לסיכום

אימות הוא שאלה של "מי אתה", הרשאה היא שאלה של "מה אתה יכול לעשות"; ב-AI, שניהם חייבים לפעול בהקשר של המשתמש.
המודל צריך לפעול בסמכות המשתמש המגיש את הבקשה, ולא בסמכות רחבה משלו (למנוע את הסיכון של סוכנות מעורבת).
התחל עם RBAC, העמיק עם ABAC על נתונים רגישים; הפוך את הסמכות המינימלית לברירת המחדל.
אל תקבור סודות בקוד; אחסן אותו במנהל הסודי, צמצם אותו והכניס אותו לסיבוב רגיל.
ברירת המחדל לקריאה בלבד והכתיבה המצומצמת מגבילים מאוד את השפעת ההזרקה.

משימת יישום

רשום את כל הכלים והנתונים שעוזר ה-AI שלך ניגש אליהם. ענה על שלוש שאלות לכל אחת מהן: (1) האם זה באמת הכרחי? (2) האם קריאה בלבד מספיקה? (3) האם זה פועל בהקשר משתמש? לאחר מכן חפש את כל הסודות המקודדים (באמצעות הודעת הסריקה למעלה) וכתוב תוכנית סיבוב עבור כל מפתח שאתה מוצא. הסר לפחות הרשאה מיותרת אחת.

רשימת בדיקה

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