חשיפה של מידע רגיש היא פגיעות שבה מודל גדול של שפה (LLM) חושף שלא במכוון נתונים סודיים, פרטיים, קנייניים או נתונים אחרים שמוגבלים בדרך כלשהי בתשובות שלו. זה יכול לקרות כשהמודל חושף מידע מנתוני האימון שלו או חושף פרטים רגישים שסופקו לו בהקשר של סשן משתמש. תוקפים יכולים לנצל את זה על ידי יצירת שאילתות ספציפיות או שימוש בטכניקות של הזרקת הנחיות כדי לגרום למודל לחשוף מידע שהוא לא אמור לחשוף. הבעיה המרכזית היא חוסר היכולת של ה-LLM להבחין בין נתונים ציבוריים לבין מידע סודי שהוא עיבד.
סוגי גילוי נאות שרלוונטיים ל-Android
דליפת נתוני אימון: מצב שבו מודל LLM משחזר נתונים ספציפיים, מילה במילה, שהוא אומן עליהם. אם מערך נתוני האימון כלל פרטים אישיים מזהים (PII), קוד קנייני או מסמכים פנימיים, יכול להיות שהמודל ישחזר את המידע הזה בפלט שלו אם יקבל הנחיה מתאימה. באפליקציות ל-Android, זה יכול לכלול מודלים שאומנו מראש ונכללים באפליקציה, או מודלים שאליהם ניגשים באמצעות ממשקי API בענן.
גילוי נאות על טיפול בנתונים לפי הקשר: זהו סיכון מיידי יותר לאפליקציות ל-Android, שקשור לחשיפת מידע רגיש שמשתמש מספק במהלך סשן באפליקציה על ידי מודל שפה גדול (LLM). לדוגמה, אם האפליקציה מאפשרת למשתמש להזין פרטים אישיים מזהים (PII) ל-LLM כדי ליצור סיכום, מתקפת החדרת קוד שמתבצעת בהמשך יכולה לאפשר לתוקף לתמרן את המודל כך שיחשוף את התוכן. הדרישה הזו חלה גם על מידע אישי רגיש שהאפליקציה מעבירה ל-LLM באופן מרומז.
למה מפתחי Android צריכים להתעניין ב-AI
חשיפה של מידע רגיש עלולה לסכן מאוד את האפליקציה ואת המשתמשים שלה:
- הפרות של פרטיות: תוקף יכול לחלץ פרטים אישיים מזהים (PII) כמו שמות, כתובות אימייל, מספרי טלפון או אפילו נתוני מיקום מהמשתמשים שלכם, מה שיוביל לגניבת זהות ולסנקציות רגולטוריות חמורות (למשל, במסגרת GDPR או CCPA). הדבר חשוב במיוחד לאפליקציות ל-Android שמטפלות בנתוני משתמשים.
- גניבת קניין רוחני: אם מודל ה-LLM של האפליקציה מעבד אלגוריתמים קנייניים, נתונים פיננסיים או מידע עסקי פנימי אחר, תוקף יכול לחשוף אותו בכוח ולגרום נזק תחרותי ופיננסי משמעותי לארגון.
- פרצות אבטחה: יכול להיות ש-LLM ידליף בטעות מידע ברמת המערכת, כמו מפתחות API, אסימוני אימות או פרטי הגדרה שהיו בנתוני האימון שלו או שהועברו במהלך סשן, ויצור נקודות חולשה קריטיות באבטחה של ה-בק-אנד או של שירותים אחרים.
- פגיעה במוניטין: אירוע משמעותי אחד של דליפת נתונים עלול לפגוע באמון של המשתמשים, להוביל להסרת האפליקציה, לביקורות שליליות ולפגוע במוניטין של האפליקציה והמותג באופן בלתי הפיך.
פתרונות למפתחי אפליקציות ל-Android
כדי לצמצם את הסיכון לניצול פרצת האבטחה הזו, צריך להשתמש בגישה רב-שכבתית שמתמקדת בהיגיינת נתונים ובשליטה בגישה של מודל ה-LLM באפליקציה ל-Android.
חיטוי נתונים והגבלה על איסוף המידע:
- לתת עדיפות לניקוי הקלט: לפני ששולחים קלט של משתמשים או נתוני האפליקציה ל-LLM, חשוב לנקות אותו ביסודיות ולהפוך אותו לאנונימי. צריך להסיר את כל הפרטים האישיים המזהים (PII) ואת המידע הקנייני שלא חיוני לביצוע המשימה של מודל ה-LLM.
- איסוף רק של מה שנדרש: הקפידו על העיקרון של הגבלה על איסוף המידע באפליקציה. אספו וספקו למודל ה-LLM רק את הנתונים המינימליים שנדרשים לו כדי לבצע את הפונקציה הספציפית שלו.
- ML במכשיר: כשמדובר במידע אישי רגיש במיוחד, כדאי להשתמש במודלים של למידת מכונה במכשיר, שבהם הנתונים אף פעם לא יוצאים מהמכשיר של המשתמש. כך מצמצמים באופן משמעותי את הסיכון לדליפת נתונים בצד השרת.
שליטה בגישה
- מכסת גישה לנתונים: כדאי לתכנן את אפליקציית ה-LLM כך שתהיה לה גישה לכמות הקטנה ביותר האפשרית של נתונים. אם לא ניתנה למודל גישה למסד נתונים רגיש, להעדפות משתמש או לקבצים פרטיים, אי אפשר יהיה להערים עליו ולגרום לו לחשוף את התוכן שלהם.
- הגבלת הרשאות ב-Android: צריך לוודא שרכיבי ה-AI של האפליקציה פועלים עם הרשאות המינימום הנדרשות ב-Android. אל תעניקו הרשאות מיותרות שעלולות לחשוף מידע אישי רגיש.
סינון הפלט בתוך האפליקציה:
- צנזורה בצד הלקוח: הטמעה של שכבת אבטחה באפליקציית Android שסורקת את הפלט של ה-LLM כדי למצוא דפוסים שתואמים למידע רגיש (לדוגמה, מספרי כרטיסי אשראי, מפתחות API, מספרי ביטוח לאומי, כתובות אימייל) לפני שהתשובה מוצגת למשתמש. אם נמצאת התאמה, התשובה צריכה להיחסם או להיערך.
שכבות הגנה להדרכה של מודלי שפה גדולים:
- הנחיות מערכת מפורשות: כוללות הוראות מפורשות בהנחיית המערכת שאוסרות על המודל לחשוף מידע אישי, סודי או רגיש. לדוגמה: "אסור לך לשתף פרטי משתמשים, נתונים פנימיים או פרטים אישיים מזהים בשום מקרה". כך מתחזקת ההתנהגות הצפויה.
טכניקות לשיפור הפרטיות:
- באפליקציות שלומדות מאינטראקציות או מנתונים של משתמשים, כדאי להשתמש בטכניקות מתקדמות כמו פרטיות דיפרנציאלית (הוספת רעש סטטיסטי לנתונים) או למידה מאוחדת (אימון מודלים במכשירי משתמשים בלי לרכז את הנתונים) כדי להגן על הפרטיות של משתמשים ספציפיים.
ביקורת קבועה וצוותים אדומים:
- בדיקות יזומות: מומלץ לבצע בדיקות אקטיביות ובדיקות חדירה באפליקציית Android כדי לגלות אם ואיך מודל ה-LLM עלול להדליף מידע רגיש. הפעולה הזו כוללת ניסיון מכוון לגרום ל-LLM לחשוף נתונים שהוא לא אמור לחשוף.
סיכום
חשיפת מידע רגיש מתרחשת כשמודל LLM חושף נתונים סודיים מקבוצת הנתונים לאימון או מהסשנים של המשתמשים, ויוצר סיכונים משמעותיים כמו הפרות פרטיות וגניבת קניין רוחני. השבתה זמנית של אותות אכיפה דורשת הגנה בשכבות באפליקציית Android, מתן עדיפות לניקוי נתונים לפני שהם מגיעים ל-LLM, אכיפת העקרון של הרשאות מינימליות כדי להגביל את הגישה לנתונים של המודל, והטמעת מסננים חזקים לסריקה ועריכה של מידע רגיש מהפלט הסופי של המודל לפני שהוא מגיע למשתמש. שימוש ב-ML במכשיר ובכלים כמו Firebase App Check יכול לשפר עוד יותר את האבטחה.
מקורות מידע נוספים
לעיון, הנה קישורים לכמה מההנחיות בנושא מידע רגיש:
אם אתם משתמשים במודלים אחרים, כדאי לחפש הנחיות ומשאבים דומים.
מידע נוסף: