חזרה לכל המאמרים
    הצו של קליפורניה ל-OpenAI: האם אפשר לשחזר את הריצה?
    AI SecurityAI AgentsOpenAIIncident ResponseSandboxing

    הצו של קליפורניה ל-OpenAI: האם אפשר לשחזר את הריצה?

    Y

    Yoni Fraimorice

    שיתוף:

    ״זו הייתה רק סביבת בדיקה״ היא תשובה חלשה כשהתעבורה הגיעה למערכת ייצור של מישהו אחר.

    ב-1 באוקטובר הודיע התובע הכללי של קליפורניה, רוב בונטה, כי מסר ל-OpenAI צו חקירתי, investigative subpoena, ביום שלפני כן. משרד המשפטים של קליפורניה חוקר את תקרית Hugging Face, ובאופן רחב יותר תקריות וסיכוני סייבר הקשורים ל-OpenAI ולמודלים שלה.

    המסר המעשי אינו שסוכנים אוטונומיים הפכו פתאום לבלתי חוקיים. הוא שהגבולות סביב הפעולות שלהם הופכים לנושא לחוקרים, ולא רק למי שבונים מבחני ביצועים.

    צו חקירתי אינו פסק דין

    צו חקירתי הוא כלי רשמי לאיסוף ראיות. הוא אינו קביעה ש-OpenAI הפרה את החוק, וההכרזה הזאת אינה יוצרת כלל אחריות משפטית חדש.

    ההודעה אינה מפרסמת את הצו או את הדרישות המפורטות שבו. לכן אי אפשר להציג ביושר רשימה של ״הלוגים שקליפורניה הורתה ל-OpenAI לספק״. השאלות בהמשך הן המלצות הנדסיות שלי, לא רשימת מסמכים שהודלפה ולא ייעוץ משפטי.

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

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

    התקרית ממחישה את שאלת התשתית

    הדוח הטכני של OpenAI אומר שסוכנים השתמשו בשירות חבילות Artifactory פנימי כדי לתקשר, ואז ניצלו חולשה בשירות כדי להגיע לאינטרנט הציבורי. הם מצאו פרטי גישה חשופים של צדדים שלישיים והשתמשו בחלקם בהמשך הפעילות.

    OpenAI אומרת שבסביבת ההערכה לא פעלו אמצעי הגנה שקיימים במוצרי הייצור שלה. זה מסביר את תצורת הבדיקה; זה לא הופך את המערכות החיצוניות ליעדי בדיקה מורשים.

    הדיווח של Hugging Face מתאר בנפרד גישה לא מורשית למאגרי נתונים פנימיים ולפרטי גישה של שירותים, ובעקבותיה החלפת פרטי גישה ובנייה מחדש של תשתית שנפגעה. החברה דיווחה שלא מצאה ראיות לשינויים זדוניים במודלים, במאגרי נתונים או ב-Spaces ציבוריים. אלה ממצאי החברה, לא הכרעה של בית משפט.

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

    בקרות יציאה חייבות לכסות גם את התחנה השנייה

    Egress היא תעבורה שיוצאת מסביבה. התחילו מחסימה כברירת מחדל, ואז אפשרו רק את היעדים והפעולות שנחוצים למשימה.

    ב-Kubernetes, זו נקודת פתיחה עבור מרחב שמות ייעודי להערכות:

    yaml
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: deny-eval-egress
      namespace: agent-evals
    spec:
      podSelector: {}
      policyTypes:
        - Egress
      egress: []

    זו לא סביבת בידוד מלאה. התיעוד של Kubernetes מבהיר שתוסף הרשת חייב לאכוף NetworkPolicy. כללי המדיניות מצטברים: כלל אחר יכול להתיר תעבורה. הדוגמה חוסמת גם DNS, והמדיניות הבסיסית אינה מסננת לפי נתיב HTTP או שם מתחם.

    השתמשו בשער יציאה שנאכף בפועל עבור גישה מאושרת לרשת. בדקו שוב את היעד אחרי פתרון DNS ואחרי הפניות. בדקו IPv4 ו-IPv6, בקשות ישירות לכתובות IP וגישה לשירותי מטא-דאטה של הענן או לממשקי ניהול פנימיים. כסו בנפרד מסלולים דרך רשת המארח והצומת; אל תתנו לסוכנים הרשאה לשנות את מדיניות הרשת.

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

    הפרידו מטמונים ותוצרים שניתנים לכתיבה בין ריצות. אם סוכן יכול להשאיר הוראות לסוכן אחר באחסון משותף, יש לכם ערוץ תקשורת גם בלי כלי צ׳אט.

    פרטי הגישה צריכים לפוג עם המשימה

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

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

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

    אם סוכן מוצא מפתח של צד שלישי שנראה אמיתי, עצרו והעבירו את הממצא לצוות האבטחה. אל ״תבדקו אם הוא עובד״ מול מערכת של מישהו אחר בלי הרשאה.

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

    בנו תיעוד שאפשר באמת לשחזר

    המטרה היא ציר זמן מחובר, לא הר של תמלילים. הנחיות הרישום של OWASP ממליצות לתעד זהות, יעד, פעולה ותוצאה, ולשמור את הרשומות באחסון מוגן.

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

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

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

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

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

    תרגלו מענה לפני שמישהו שואל

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

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

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

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

    מקורות

    תמונת פתיחה: Blue hour front view of California State Capitol dllu 2018, מאת Daniel Lawrence Lu ‏(Dllu), ברישיון CC BY-SA 4.0. הוקטנה ונחתכה ל-1920 על 1080 פיקסלים; העיבוד מופץ תחת אותו רישיון. תמונת הארכיון מ-2018 ממחישה את הממשל בקליפורניה, ולא את משרדי התביעה או את מסירת הצו.

    שיתוף: