ה־AI רץ על השרת שלכם. לאן הוא מתחבר?
העברתם את מערכת ה־AI לשרת Linux משלכם. המודל רץ על כרטיס המסך שלכם, המסמכים נשמרים במסד נתונים שבשליטתכם, והגישה למערכת מוגנת בהזדהות.
ואז עולה שאלה פשוטה: לאילו שירותים חיצוניים המערכת הזאת התחברה אתמול?
התשובה לא תמיד זמינה.
מערכת AI יכולה לכלול שרת מודלים, ממשק צ׳אט, רכיב לעיבוד מסמכים, פלטפורמת אוטומציה וכלים שפונים לשירותים חיצוניים. לכל רכיב הגדרות משלו, וכל אחד מהם עשוי לייצר חיבורי רשת.
הרצת המודל אצלכם מבהירה היכן מתבצע העיבוד שלו. כדי להבין לאן המידע עשוי להגיע, צריך להכיר גם את הפעילות של שאר המערכת.
מה קורה בדרך אל המודל?
ניקח לדוגמה עוזר לניתוח מסמכים, המבוסס על מודל שפה מקומי. משתמש מעלה קובץ PDF ומבקש סיכום.
בהתאם להגדרות, המערכת עשויה לשלוח עמודים סרוקים לשירות חיצוני לזיהוי טקסט, להשתמש בשירות ענן ליצירת ייצוגים מספריים של התוכן — Embeddings — או להעביר שאילתה למנוע חיפוש. את התשובה הסופית המודל עדיין יכול לייצר על השרת שלכם.
זו דוגמה אפשרית לאופן שבו מערכת כזאת בנויה. המשמעות פשוטה: עוד לפני שהמסמך מגיע למודל המקומי, רכיבים אחרים עשויים לעבד אותו או להעביר ממנו מידע הלאה.
לעיתים האפשרויות האלה מפורטות בתיעוד של הכלים עצמם. בתיעוד של Ollama, למשל, מצוין שכאשר המודל רץ מקומית, Ollama אינה רואה את הבקשות או את הנתונים שלכם. לצד זאת, התוכנה מציעה גם מודלים בענן וחיפוש ברשת, ומאפשרת להשבית את יכולות הענן בהגדרות.
בדומה לכך, התיעוד של n8n מתאר איסוף נתוני שימוש ותפעול שמופעל כברירת מחדל גם בהתקנה עצמאית, ומסביר כיצד לבטל אותו. דיווח נתוני שימוש, עיבוד בענן ופנייה לשירות חיצוני כחלק מתהליך אוטומציה הם שימושים שונים, וכל אחד דורש בדיקה בפני עצמו.
כדאי לדעת אילו מהאפשרויות האלה פעילות אצלכם, והאם הן תואמות את האופן שבו התכוונתם להפעיל את המערכת.
גם החיבורים היוצאים צריכים להיות בשליטתכם
תעבורה יוצאת, או Egress, היא תעבורה שיוצאת מהשרת או משירות שרץ עליו אל יעד אחר.
מדיניות הגישה הנכנסת קובעת מי רשאי להתחבר לשירות שלכם. במקביל, צריך להחליט לאילו שירותים חיצוניים הוא רשאי להתחבר בעצמו. גם מערכת שהגישה אליה מוגבלת יכולה ליזום חיבורים החוצה, אם הגדרות הרשת מאפשרות זאת.
אצל סוכני AI, השאלה הזאת מקבלת משמעות נוספת. סוכן שמסוגל לקרוא קבצים, לפנות לכתובות ברשת או להריץ פקודות יכול להשפיע על מערכות ומידע מעבר לשיחה עצמה. היקף הנזק שפעולה שגויה עלולה לגרום תלוי, בין היתר, בהרשאות שלו וביעדים שאליהם הוא יכול להגיע.
ההנחיות של OWASP בנושא הרשאות ויכולות עודפות לסוכני AI מסבירות כיצד מתן יכולות שאינן נחוצות למשימה עלול להגדיל את הסיכון.
הגבלות רשת יכולות לצמצם את מרחב הפעולה הזה. לצדן נדרשים גם בקרת הרשאות באפליקציה, הרשאות מצומצמות למפתחות הגישה ואישור לפעולות רגישות. הדבר חשוב במיוחד כאשר גם שירות חיצוני מאושר יכול לשמש להעברת מידע רגיש.
סך התעבורה בשרת מספר רק חלק מהסיפור
נניח שבמהלך שעה אחת השרת שלכם התחבר לשירות אחסון, למאגר להורדת מודלים ולכתובת HTTPS שאינכם מכירים.
נתון כולל על היקף התעבורה לא יספר לכם איזה רכיב יצר כל חיבור. כשאפשר לשייך חיבור לשירות מסוים, הבדיקה נעשית ממוקדת יותר: גיבוי מתוזמן שפונה לשירות אחסון הוא דבר אחד; עוזר לניתוח מסמכים שפונה לאותו יעד בפעם הראשונה דורש הסבר אחר.
בדיקה מועילה צריכה לענות על ארבע שאלות:
- איזה שירות יצר את החיבור? חשוב לזהות את התהליך או הקונטיינר האחראי.
- לאן הוא התחבר? מהי כתובת היעד, ומה ידוע באופן מבוסס על תפקידה?
- כמה מידע נשלח? חשוב להבחין בין מידע שנשלח החוצה לבין מידע שהתקבל.
- מתי היעד הופיע לראשונה בתצפיות? האם זה קרה בעקבות עדכון, שינוי הגדרות או משימה מתוכננת?
כיוון התעבורה חשוב במיוחד כשבוחנים את הנפח. הורדת מודל גדול מכניסה בעיקר מידע אל השרת. העלאת גיבוי שולחת בעיקר מידע החוצה. שתי הפעולות יכולות לייצר תעבורה רבה, אבל המשמעות שלהן שונה.
גם העברה קטנה עשויה להצדיק בדיקה. מפתח API או מסמך חסוי קצר אינם תופסים ג׳יגה־בייטים.
איך מפרשים את הממצאים?
שם מוכר של ספק יכול לעזור להבין חיבור, אך תשתיות משותפות משרתות לקוחות רבים. כתובת IP לבדה לא תמיד מגלה לאיזה חשבון, משאב או גורם מסוים נשלח המידע.
גם חיבור שחוזר על עצמו אינו בהכרח חיבור שאישרתם. רכיב שהוגדר בצורה לא רצויה יכול לפעול לאורך כל תקופת המעקב ולהיראות כחלק מהשגרה.
לנתוני הרשת יש גם גבולות. כתובת יעד, שעת חיבור וכמות הבתים שנשלחו אינן חושפות את התוכן של בקשה מוצפנת. כדי לקבוע אם מידע רגיש נחשף, ייתכן שיהיה צורך לבדוק גם את יומני האפליקציה, את ההגדרות שלה או מקורות מידע נוספים.
חשוב להבין גם מה המעקב הצליח לראות. אם הניטור לא פעל בחלק מהזמן, חסרה תמונה של אותה תקופה. כאשר המעקב מבוסס על דגימות, חיבורים קצרים עלולים להתפספס. את המסקנות מהדוח צריך להתאים להיקף הכיסוי שלו.
בודקים, מבינים ואז משנים
אפשר להתחיל משירות אחד שמטפל במידע רגיש. הגדירו לאילו שירותים חיצוניים הוא אמור להתחבר, ובחנו את הפעילות שלו לאורך תקופה שמכסה גם עבודה רגילה, גם משימות מתוזמנות וגם תחזוקה.
בדקו יעדים שאין לכם הסבר ברור לגביהם. אם חיבור לא רצוי נובע מאפשרות שאינכם צריכים, התחילו מבדיקת ההגדרות של אותה אפשרות. אם נדרשת הגבלת רשת, החילו אותה באופן ממוקד על השירות והיעד המתאימים, בדקו מה תהיה ההשפעה שלה, ודאגו שתוכלו לבטל אותה בקלות.
כדאי לחזור על הבדיקה אחרי הוספת כלים או שינוי חיבורים לשירותים חיצוניים. צורכי הרשת של המערכת יכולים להשתנות גם כשהמודל המקומי נשאר בדיוק אותו מודל.
איך nuDefend עוזר?
nuDefend מאפשר לבצע את הבדיקה הזאת על שרת ה־Linux עצמו. הוא מזהה כלי AI נתמכים ומציג את יעדי החיבור שנצפו עבורם, את נפח התעבורה שנשלחה ואת המועד שבו כל יעד נראה לראשונה. כאשר היעד מזוהה, מוצג גם מידע שעוזר להבין את תפקידו.
בשרת שמותקן עליו nuDefend אפשר להתחיל בפקודות הבאות:
sudo nudefend workloads
sudo nudefend egress
sudo nudefend egress review Ollama
הפקודה האחרונה היא דוגמה לבדיקת שירות Ollama שזוהה במערכת. הפקודות האלה מציגות את הממצאים ואינן משנות את מדיניות הרשת.
אם החלטתם להגביל יעד מסוים, nuDefend מאפשר לחסום אותו עבור השירות הרלוונטי, עם תצוגה מקדימה של השפעת החסימה ואפשרות לבטל אותה. השליטה הזאת פועלת לצד החסימה האוטומטית של כתובות זדוניות מוכרות.
המעקב אחר כלים בקונטיינרים מבוסס על דגימות, ולכן חיבורים קצרים עלולים שלא להיקלט. פערים בתקופת המעקב מוצגים במפורש, ונפח תעבורה לבדו אינו מסווג כדליפת מידע. דוחות הפעילות והיסטוריית התעבורה נשמרים על השרת שלכם. פרטים על היכולות והכיסוי זמינים בתיעוד.
הפעלת מערכת AI על שרת משלכם נותנת לכם שליטה בתשתית. מעקב אחר החיבורים היוצאים עוזר לממש את השליטה הזאת ולקבל החלטות מבוססות לגבי המקומות שאליהם המערכת רשאית להעביר מידע.