השיעור הזה יעסוק ב:
- אבטחה בהקשר של מערכות AI.
- סיכונים ואיומים נפוצים על מערכות AI.
- שיטות ושיקולים לאבטחת מערכות AI.
לאחר השלמת השיעור, תבינו:
- את האיומים והסיכונים על מערכות AI.
- שיטות ופרקטיקות נפוצות לאבטחת מערכות AI.
- כיצד יישום בדיקות אבטחה יכול למנוע תוצאות בלתי צפויות ופגיעה באמון המשתמשים.
ככל שטכנולוגיות הבינה המלאכותית (AI) והלמידה החישובית (ML) משפיעות יותר על חיינו, חשוב להגן לא רק על נתוני הלקוחות אלא גם על מערכות ה-AI עצמן. AI/ML משמשות יותר ויותר בתהליכי קבלת החלטות בעלי ערך גבוה בתעשיות שבהן החלטה שגויה עשויה להוביל לתוצאות חמורות.
הנה נקודות מפתח שיש לקחת בחשבון:
- השפעת AI/ML: ל-AI/ML יש השפעה משמעותית על חיי היומיום ולכן הפיכתם לבטוחים הפכה להכרחית.
- אתגרי אבטחה: ההשפעה של AI/ML דורשת תשומת לב מתאימה כדי להתמודד עם הצורך להגן על מוצרים מבוססי AI מפני התקפות מתוחכמות, בין אם על ידי טרולים או קבוצות מאורגנות.
- בעיות אסטרטגיות: תעשיית הטכנולוגיה חייבת להתמודד באופן יזום עם אתגרים אסטרטגיים כדי להבטיח בטיחות לקוחות ארוכת טווח ואבטחת נתונים.
בנוסף, מודלים של למידה חישובית אינם מסוגלים לרוב להבחין בין קלט זדוני לבין נתונים חריגים שאינם מזיקים. מקור משמעותי לנתוני אימון נגזר ממאגרי נתונים ציבוריים שאינם מסוננים או מבוקרים, אשר פתוחים לתרומות מצד שלישי. תוקפים אינם צריכים לפרוץ למאגרי נתונים כאשר הם יכולים לתרום להם באופן חופשי. עם הזמן, נתונים זדוניים בעלי ביטחון נמוך הופכים לנתונים מהימנים בעלי ביטחון גבוה, אם מבנה הנתונים/פורמט נשאר נכון.
זו הסיבה שחשוב להבטיח את שלמות והגנת מאגרי הנתונים שהמודלים שלכם משתמשים בהם כדי לקבל החלטות.
בהקשר של AI ומערכות קשורות, הרעלת נתונים היא האיום האבטחתי המשמעותי ביותר כיום. הרעלת נתונים מתרחשת כאשר מישהו משנה בכוונה את המידע המשמש לאימון AI, מה שגורם לו לבצע טעויות. זאת בשל היעדר שיטות סטנדרטיות לזיהוי והפחתת נזקים, יחד עם הסתמכותנו על מאגרי נתונים ציבוריים שאינם מבוקרים או מסוננים לאימון. כדי לשמור על שלמות הנתונים ולמנוע תהליך אימון פגום, חשוב לעקוב אחר המקור והשלשלת של הנתונים שלכם. אחרת, האמרה הישנה "זבל נכנס, זבל יוצא" נכונה, מה שמוביל לביצועי מודל פגומים.
הנה דוגמאות כיצד הרעלת נתונים יכולה להשפיע על המודלים שלכם:
- היפוך תוויות: במשימת סיווג בינארית, תוקף הופך בכוונה את התוויות של חלק קטן מנתוני האימון. לדוגמה, דגימות לא מזיקות מתויגות כזדוניות, מה שגורם למודל ללמוד אסוציאציות שגויות.
דוגמה: מסנן דואר זבל שמסווג בטעות מיילים לגיטימיים כדואר זבל עקב תוויות מניפולטיביות. - הרעלת מאפיינים: תוקף משנה בעדינות מאפיינים בנתוני האימון כדי להכניס הטיה או להטעות את המודל.
דוגמה: הוספת מילות מפתח לא רלוונטיות לתיאורי מוצרים כדי להשפיע על מערכות המלצה. - הזרקת נתונים: הזרקת נתונים זדוניים למערך האימון כדי להשפיע על התנהגות המודל.
דוגמה: הכנסת ביקורות משתמש מזויפות כדי לעוות תוצאות ניתוח רגשות. - התקפות דלת אחורית: תוקף מכניס תבנית נסתרת (דלת אחורית) לנתוני האימון. המודל לומד לזהות את התבנית הזו ומתנהג בצורה זדונית כאשר היא מופעלת.
דוגמה: מערכת זיהוי פנים שאומנה עם תמונות דלת אחורית שמזהה בטעות אדם מסוים.
תאגיד MITRE יצר את ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems), מאגר ידע של טקטיקות וטכניקות שמיושמות על ידי תוקפים בהתקפות אמיתיות על מערכות AI.
ישנם יותר ויותר פגיעויות במערכות המופעלות על ידי AI, שכן שילוב AI מגדיל את שטח ההתקפה של מערכות קיימות מעבר לאלו של התקפות סייבר מסורתיות. פיתחנו את ATLAS כדי להעלות את המודעות לפגיעויות ייחודיות ומתפתחות אלו, ככל שהקהילה הגלובלית משלבת AI במערכות שונות. ATLAS מבוסס על מסגרת MITRE ATT&CK® והטקטיקות, הטכניקות והנהלים (TTPs) שלו משלימים את אלו ב-ATT&CK.
בדומה למסגרת MITRE ATT&CK®, אשר משמשת באופן נרחב באבטחת סייבר מסורתית לתכנון תרחישי אמולציה של איומים מתקדמים, ATLAS מספק סט TTPs שניתן לחפש בקלות כדי להבין טוב יותר ולהתכונן להגנה מפני התקפות מתפתחות.
בנוסף, פרויקט אבטחת יישומי האינטרנט הפתוחים (OWASP) יצר "רשימת עשרת הגדולים" של הפגיעויות הקריטיות ביותר שנמצאות ביישומים המשתמשים ב-LLMs. הרשימה מדגישה את הסיכונים של איומים כמו הרעלת נתונים שהוזכרה לעיל יחד עם אחרים כמו:
- הזרקת פקודות: טכניקה שבה תוקפים משנים מודל שפה גדול (LLM) באמצעות קלטים שנכתבו בקפידה, מה שגורם לו להתנהג מחוץ להתנהגות המיועדת לו.
- פגיעויות שרשרת אספקה: הרכיבים והתוכנות שמרכיבים את היישומים המשמשים את ה-LLM, כמו מודולי Python או מאגרי נתונים חיצוניים, יכולים בעצמם להיות פגיעים ולהוביל לתוצאות בלתי צפויות, הטיות שהוכנסו ואפילו פגיעויות בתשתית הבסיסית.
- הסתמכות יתר: LLMs אינם מושלמים ונוטים לייצר תוצאות שגויות או לא בטוחות. במקרים מתועדים רבים, אנשים קיבלו את התוצאות כפי שהן, מה שהוביל לתוצאות שליליות בלתי צפויות בעולם האמיתי.
רוד טרנט, מומחה ענן במיקרוסופט, כתב ספר אלקטרוני חינמי, Must Learn AI Security, שמעמיק באיומי AI מתפתחים אלו ומספק הנחיות נרחבות כיצד להתמודד עם תרחישים אלו בצורה הטובה ביותר.
בינה מלאכותית (AI) משנה תחומים ותעשיות רבות, ומציעה אפשרויות חדשות ויתרונות לחברה. עם זאת, AI גם מציבה אתגרים וסיכונים משמעותיים, כמו פרטיות נתונים, הטיה, חוסר הסבריות ושימוש לרעה פוטנציאלי. לכן, חשוב להבטיח שמערכות AI יהיו בטוחות ואחראיות, כלומר שיעמדו בסטנדרטים אתיים וחוקיים ויוכלו להיות מהימנות על ידי משתמשים ובעלי עניין.
בדיקות אבטחה הן תהליך של הערכת האבטחה של מערכת AI או LLM, על ידי זיהוי וניצול הפגיעויות שלהן. ניתן לבצע זאת על ידי מפתחים, משתמשים או מבקרים חיצוניים, בהתאם למטרת הבדיקה והיקפה. כמה משיטות בדיקות האבטחה הנפוצות ביותר למערכות AI ו-LLMs הן:
- טיהור נתונים: זהו תהליך של הסרת או אנונימיזציה של מידע רגיש או פרטי מנתוני האימון או הקלט של מערכת AI או LLM. טיהור נתונים יכול לעזור למנוע דליפת נתונים ומניפולציה זדונית על ידי הפחתת החשיפה של נתונים חסויים או אישיים.
- בדיקות עוינות: זהו תהליך של יצירה ויישום דוגמאות עוינות לקלט או פלט של מערכת AI או LLM כדי להעריך את החוסן והעמידות שלהן נגד התקפות עוינות. בדיקות עוינות יכולות לעזור לזהות ולהפחית את הפגיעויות והחולשות של מערכת AI או LLM שעשויות להיות מנוצלות על ידי תוקפים.
- אימות מודל: זהו תהליך של אימות נכונות ושלמות הפרמטרים או הארכיטקטורה של מערכת AI או LLM. אימות מודל יכול לעזור לזהות ולמנוע גניבת מודל על ידי הבטחת שהמודל מוגן ומאומת.
- אימות פלט: זהו תהליך של אימות איכות ואמינות הפלט של מערכת AI או LLM. אימות פלט יכול לעזור לזהות ולתקן מניפולציה זדונית על ידי הבטחת שהפלט עקבי ומדויק.
OpenAI, מובילה במערכות AI, הקימה סדרת הערכות בטיחות כחלק מיוזמת רשת red teaming שלה, שמטרתה לבדוק את פלט מערכות ה-AI בתקווה לתרום לבטיחות AI.
הערכות יכולות לנוע מבדיקות שאלות ותשובות פשוטות ועד סימולציות מורכבות יותר. כדוגמאות מוחשיות, הנה הערכות לדוגמה שפותחו על ידי OpenAI להערכת התנהגויות AI מזוויות שונות:
- MakeMeSay: עד כמה מערכת AI יכולה לשכנע מערכת AI אחרת לומר מילה סודית?
- MakeMePay: עד כמה מערכת AI יכולה לשכנע מערכת AI אחרת לתרום כסף?
- Ballot Proposal: עד כמה מערכת AI יכולה להשפיע על תמיכת מערכת AI אחרת בהצעה פוליטית?
- Steganography: עד כמה מערכת AI יכולה להעביר הודעות סודיות מבלי להיתפס על ידי מערכת AI אחרת?
- Text Compression: עד כמה מערכת AI יכולה לדחוס ולפרוס הודעות, כדי לאפשר הסתרת הודעות סודיות?
- Schelling Point: עד כמה מערכת AI יכולה לתאם עם מערכת AI אחרת, ללא תקשורת ישירה?
חשוב מאוד להגן על מערכות AI מפני התקפות זדוניות, שימוש לרעה או תוצאות בלתי צפויות. זה כולל נקיטת צעדים להבטחת בטיחות, אמינות ואמינות של מערכות AI, כגון:
- אבטחת הנתונים והאלגוריתמים המשמשים לאימון והפעלת מודלים של AI.
- מניעת גישה לא מורשית, מניפולציה או חבלה במערכות AI.
- זיהוי והפחתת הטיה, אפליה או בעיות אתיות במערכות AI.
- הבטחת אחריות, שקיפות והסבריות של החלטות ופעולות AI.
- התאמת המטרות והערכים של מערכות AI לאלו של בני אדם והחברה.
אבטחת AI חשובה להבטחת שלמות, זמינות וסודיות של מערכות AI ונתונים. כמה מהאתגרים וההזדמנויות של אבטחת AI הם:
- הזדמנות: שילוב AI באסטרטגיות אבטחת סייבר, שכן הוא יכול לשחק תפקיד מכריע בזיהוי איומים ושיפור זמני התגובה. AI יכול לעזור באוטומציה והרחבת זיהוי והפחתת התקפות סייבר, כמו פישינג, תוכנות זדוניות או כופר.
- אתגר: AI יכול גם להיות מנוצל על ידי תוקפים כדי להשיק התקפות מתוחכמות, כמו יצירת תוכן מזויף או מטעה, התחזות למשתמשים, או ניצול פגיעויות במערכות AI. לכן, למפתחי AI יש אחריות ייחודית לעצב מערכות שיהיו חזקות ועמידות נגד שימוש לרעה.
LLMs יכולים להוות סיכונים לפרטיות ואבטחת הנתונים שהם משתמשים בהם. לדוגמה, LLMs יכולים לזכור ולדלוף מידע רגיש מנתוני האימון שלהם, כמו שמות אישיים, כתובות, סיסמאות או מספרי כרטיסי אשראי. הם גם יכולים להיות מנוצלים או מותקפים על ידי שחקנים זדוניים שרוצים לנצל את הפגיעויות או ההטיות שלהם. לכן, חשוב להיות מודעים לסיכונים אלו ולנקוט צעדים מתאימים להגנת הנתונים המשמשים עם LLMs. ישנם מספר צעדים שניתן לנקוט כדי להגן על הנתונים המשמשים עם LLMs. צעדים אלו כוללים:
- הגבלת כמות וסוג הנתונים שמשתפים עם LLMs: יש לשתף רק את הנתונים הנחוצים והרלוונטיים למטרות המיועדות, ולהימנע משיתוף נתונים רגישים, חסויים או אישיים. משתמשים צריכים גם לאנונימיזציה או הצפנה של הנתונים שהם משתפים עם LLMs, כמו הסרת או הסתרת מידע מזהה, או שימוש בערוצי תקשורת מאובטחים.
- אימות הנתונים ש-LLMs מייצרים: תמיד לבדוק את דיוק ואיכות הפלט שנוצר על ידי LLMs כדי להבטיח שהם לא מכילים מידע לא רצוי או לא מתאים.
- דיווח והתראה על כל פריצת נתונים או אירועים: להיות ערניים לכל פעילות או התנהגות חשודה או חריגה מ-LLMs, כמו יצירת טקסטים שאינם רלוונטיים, לא מדויקים, פוגעניים או מזיקים. זה יכול להיות סימן לפריצת נתונים או אירוע אבטחה.
אבטחת נתונים, ממשל וציות הם קריטיים לכל ארגון שרוצה לנצל את כוח הנתונים וה-AI בסביבה מרובת עננים. אבטחת וניהול כל הנתונים שלכם היא משימה מורכבת ורב-ממדית. עליכם לאבטח ולנהל סוגים שונים של נתונים (מובנים, לא מובנים ונתונים שנוצרו על ידי AI) במיקומים שונים ברחבי עננים מרובים, ועליכם לקחת בחשבון תקנות אבטחת נתונים, ממשל ו-AI קיימות ועתידיות. כדי להגן על הנתונים שלכם, עליכם לאמץ כמה פרקטיקות והזהרות טובות, כגון:
- שימוש בשירותי ענן או פלטפורמות שמציעים תכונות הגנת נתונים ופרטיות.
- שימוש בכלי איכות ואימות נתונים כדי לבדוק את הנתונים שלכם לאיתור שגיאות, אי התאמות או חריגות.
- שימוש במסגרת ממשל ואתיקה נתונים כדי להבטיח שהנתונים שלכם משמשים בצורה אחראית ושקופה.
חיקוי איומים בעולם האמיתי נחשב כיום לפרקטיקה סטנדרטית בבניית מערכות AI עמידות, על ידי שימוש בכלים, טקטיקות ונהלים דומים כדי לזהות את הסיכונים למערכות ולבחון את תגובת המגנים.
הפרקטיקה של צוותי אדום ב-AI התפתחה למשמעות רחבה יותר: היא לא רק כוללת בדיקה של פגיעויות אבטחה, אלא גם בדיקה של כשלי מערכת אחרים, כמו יצירת תוכן שעלול להיות מזיק. מערכות AI מביאות עמן סיכונים חדשים, וצוותי אדום הם מרכזיים להבנת הסיכונים החדשים הללו, כמו הזרקת פקודות ויצירת תוכן שאינו מבוסס. - Microsoft AI Red Team building future of safer AI
להלן תובנות מרכזיות שעיצבו את תוכנית צוותי האדום של Microsoft AI.
- היקף רחב של צוותי אדום ב-AI: צוותי אדום ב-AI כיום כוללים גם תוצאות אבטחה וגם תוצאות AI אחראי (RAI). באופן מסורתי, צוותי אדום התמקדו בהיבטי אבטחה, תוך התייחסות למודל כווקטור (לדוגמה, גניבת המודל הבסיסי). עם זאת, מערכות AI מציגות פגיעויות אבטחה חדשות (לדוגמה, הזרקת פקודות, הרעלה), שדורשות תשומת לב מיוחדת. מעבר לאבטחה, צוותי אדום ב-AI גם בודקים סוגיות של הוגנות (לדוגמה, סטריאוטיפים) ותוכן מזיק (לדוגמה, האדרת אלימות). זיהוי מוקדם של סוגיות אלו מאפשר תעדוף השקעות בהגנה.
- כשלי זדון וכשלי תום לב: צוותי אדום ב-AI מתייחסים לכשלים הן מנקודת מבט זדונית והן מנקודת מבט של תום לב. לדוגמה, כאשר בודקים את Bing החדש, אנו בוחנים לא רק כיצד יריבים זדוניים יכולים לשבש את המערכת, אלא גם כיצד משתמשים רגילים עשויים להיתקל בתוכן בעייתי או מזיק. בניגוד לצוותי אדום מסורתיים באבטחה, שמתמקדים בעיקר בשחקנים זדוניים, צוותי אדום ב-AI מתייחסים למגוון רחב יותר של פרסונות וכשלים אפשריים.
- הטבע הדינמי של מערכות AI: יישומי AI מתפתחים באופן מתמיד. ביישומי מודלים שפתיים גדולים, מפתחים מתאימים את עצמם לדרישות משתנות. צוותי אדום מתמשכים מבטיחים ערנות מתמדת והתאמה לסיכונים מתפתחים.
צוותי אדום ב-AI אינם מקיפים את כל ההיבטים ויש להתייחס אליהם כתוספת לבקרות נוספות כמו בקרת גישה מבוססת תפקידים (RBAC) ופתרונות ניהול נתונים מקיפים. הם נועדו להשלים אסטרטגיית אבטחה שמתמקדת בשימוש בפתרונות AI בטוחים ואחראיים, תוך התחשבות בפרטיות ובאבטחה, ושואפת למזער הטיות, תוכן מזיק ומידע שגוי שיכולים לפגוע באמון המשתמשים.
להלן רשימת קריאה נוספת שתעזור לכם להבין טוב יותר כיצד צוותי אדום יכולים לעזור בזיהוי והפחתת סיכונים במערכות AI שלכם:
- תכנון צוותי אדום עבור מודלים שפתיים גדולים (LLMs) ויישומיהם
- מהי רשת צוותי אדום של OpenAI?
- צוותי אדום ב-AI - פרקטיקה מרכזית לבניית פתרונות AI בטוחים ואחראיים יותר
- MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems), מאגר ידע של טקטיקות וטכניקות שמיושמות על ידי יריבים במתקפות אמיתיות על מערכות AI.
מה יכולה להיות גישה טובה לשמירה על שלמות נתונים ומניעת שימוש לרעה?
- שימוש בבקרות חזקות מבוססות תפקידים לגישה לנתונים ולניהול נתונים
- יישום ובקרה של תיוג נתונים כדי למנוע ייצוג שגוי או שימוש לרעה בנתונים
- הבטחת תשתית AI שתומכת בסינון תוכן
תשובה: 1, בעוד שכל שלושת ההמלצות הן מצוינות, הבטחת מתן הרשאות גישה נכונות לנתונים למשתמשים תסייע רבות במניעת מניפולציה וייצוג שגוי של הנתונים המשמשים את LLMs.
קראו עוד על איך ניתן לנהל ולהגן על מידע רגיש בעידן ה-AI.
לאחר שסיימתם את השיעור הזה, עיינו באוסף הלמידה שלנו על Generative AI כדי להמשיך ולהעמיק את הידע שלכם על Generative AI!
עברו לשיעור 14 שבו נבחן את מחזור החיים של יישומי Generative AI!
כתב ויתור:
מסמך זה תורגם באמצעות שירות תרגום AI Co-op Translator. למרות שאנו שואפים לדיוק, יש להיות מודעים לכך שתרגומים אוטומטיים עשויים להכיל שגיאות או אי דיוקים. המסמך המקורי בשפתו המקורית צריך להיחשב כמקור סמכותי. עבור מידע קריטי, מומלץ להשתמש בתרגום מקצועי אנושי. איננו אחראים לאי הבנות או לפרשנויות שגויות הנובעות משימוש בתרגום זה.