📘 תיעוד 192

פריסה מאובטחת של סוכני AI

מדריך לאבטחת פריסות של Claude Code ו-Agent SDK באמצעות בידוד, ניהול פרטי גישה ובקרות רשת

Claude Code ו-Agent SDK יכולים להריץ קוד, לגשת לקבצים ולתקשר עם שירותים חיצוניים בשמך.

בניגוד לתוכנה מסורתית שעוקבת אחרי נתיבי קוד שנקבעו מראש, הכלים האלה מייצרים את הפעולות שלהם באופן דינמי לפי הקשר ולפי מטרות. הגמישות הזאת היא מה שהופך אותם לשימושיים, אבל היא גם אומרת שההתנהגות שלהם יכולה להיות מושפעת מהתוכן שהם מעבדים: קבצים, דפי אינטרנט או קלט משתמש. לפעמים קוראים לזה הזרקת פרומפט (prompt injection). לדוגמה, אם קובץ README של מאגר מכיל הוראות חריגות, Claude Code עשוי לשלב אותן בפעולות שלו בדרכים שהמפעיל לא צפה. המדריך הזה מכסה דרכים מעשיות להקטין את הסיכון הזה.

לא כל פריסה צריכה אבטחה מרבית. למפתח שמריץ את Claude Code על המחשב הנייד שלו יש דרישות שונות מחברה שמעבדת נתוני לקוחות בסביבה מרובת דיירים (multi-tenant). המדריך הזה מציג אפשרויות, מיכולות האבטחה המובנות של Claude Code ועד ארכיטקטורות ייצור מוקשחות, כדי שתוכל לבחור מה שמתאים למצב שלך.

#מודל איומים

סוכנים יכולים לבצע פעולות לא מכוונות בגלל הזרקת פרומפט (הוראות שמוטמעות בתוכן שהם מעבדים) או בגלל שגיאת מודל. מודלים של Claude מתוכננים לעמוד בזה. לפרטי הערכה ראה את סקירת המודלים ואת כרטיס המערכת (system card) של המודל שאתה פורס.

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

#יכולות אבטחה מובנות

Claude Code כולל כמה יכולות אבטחה שמטפלות בחששות נפוצים. לפרטים המלאים ראה את תיעוד האבטחה.

• מערכת הרשאות: כללי הרשאה מחליטים אם קריאת כלי רצה, נחסמת, או מבקשת אישור קודם. לצורות שכלל Bash מפספס, ולאופן שבו כללים משתלבים עם מצבי הרשאה, ראה מה שכלל Bash לא מתאים והגדרת הרשאות. מנהלים יכולים גם להגדיר כללים בהגדרות מנוהלות.
• הסרות של נתיבים קריטיים: כשמצב ההרשאה מוגדר ל-default, פקודת rm או rmdir שמזוהה כמסירה את ספריית העבודה שלך או נתיב קריטי אחר דורשת אישור. כלל allow תואם לא מדלג על האישור הזה. זה שער הרשאה, לא ארגז חול (sandbox). כדי לשלוט במה שהסוכן יכול לכתוב, השתמש בבקרות מערכת קבצים.
• סיכום חיפוש באינטרנט: תוצאות החיפוש מסוכמות, במקום להעביר תוכן גולמי ישירות להקשר, וכך קטן הסיכון להזרקת פרומפט מתוכן אינטרנט זדוני.
• מצב ארגז חול: פקודות Bash יכולות לרוץ בסביבת ארגז חול שמגבילה גישה למערכת הקבצים ולרשת. לפרטים ראה את תיעוד ארגז החול.

#עקרונות אבטחה

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

#גבולות אבטחה

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

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

#הרשאה מזערית

כשצריך, אפשר להגביל את הסוכן רק ליכולות שנדרשות למשימה הספציפית שלו:

#הגנה לעומק

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

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

השילוב הנכון תלוי במודל האיומים ובדרישות התפעול שלך.

#טכנולוגיות בידוד

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

הערה

בכל התצורות האלה, Claude Code (או יישום Agent SDK שלך) רץ בתוך גבול הבידוד (ארגז החול, הקונטיינר או ה-VM). בקרות האבטחה שמתוארות בהמשך מגבילות את מה שהסוכן יכול לגשת אליו מתוך הגבול הזה.

#Sandbox runtime

לבידוד קל בלי קונטיינרים, sandbox-runtime אוכף הגבלות על מערכת הקבצים ועל הרשת ברמת מערכת ההפעלה.

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

איך זה עובד:

• מערכת קבצים: משתמש ברכיבי יסוד של מערכת ההפעלה (bubblewrap ב-Linux, sandbox-exec ב-macOS) כדי להגביל גישת קריאה וכתיבה לנתיבים שהוגדרו
• רשת: מריץ פקודות במרחב שמות רשת משלהן (Linux) או תחת פרופיל Seatbelt (macOS), ומנתב את התעבורה שלהן דרך פרוקסי מובנה שמתיר את הדומיינים שהוגדרו. חיבור למארח חיצוני שמדלג על הפרוקסי נכשל.
• הגדרה: רשימות היתר מבוססות JSON לדומיינים ולנתיבי מערכת קבצים

התקנה:

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

שיקולי אבטחה:

1. ליבת אותו מארח: בניגוד למכונות וירטואליות, תהליכים בארגז חול חולקים את ליבת המארח. פגיעות בליבה יכולה תאורטית לאפשר בריחה. לחלק ממודלי האיומים זה קביל, אבל אם צריך בידוד ברמת הליבה, השתמש ב-gVisor או במכונה וירטואלית נפרדת.
2. בלי בדיקת TLS: כברירת מחדל, הפרוקסי מתיר דומיינים לפי שם המארח שהלקוח מספק, ולא מסיים או בודק תעבורה מוצפנת. קוד שרץ בתוך ארגז החול יכול פוטנציאלית להשתמש בהסוואת דומיין (domain fronting) או בטכניקות דומות כדי להגיע למארחים מחוץ לרשימת ההיתר. אם מודל האיומים שלך דורש ערבויות חזקות יותר, השתמש בפרוקסי שמסיים TLS ובודק תעבורה, כפי שהעברת תעבורה מתאר. למידע נוסף ראה את מגבלות האבטחה של ארגז החול.
3. פרטי גישה לדומיינים מותרים: אם לסוכן יש פרטי גישה מתירניים לדומיין מותר, ודא שהוא לא יכול להשתמש בדומיין הזה כדי להפעיל בקשות רשת אחרות או כדי להוציא נתונים.

למקרי שימוש רבים של מפתח יחיד ושל CI/CD, sandbox-runtime מעלה את הרף במידה משמעותית עם הגדרה מזערית. הסעיפים בהמשך מכסים קונטיינרים ומכונות וירטואליות לפריסות שדורשות בידוד חזק יותר.

#קונטיינרים

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

תצורת קונטיינר מוקשחת מבחינת אבטחה יכולה להיראות כך:

docker run \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --security-opt seccomp=/path/to/seccomp-profile.json \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /home/agent:rw,noexec,nosuid,size=500m \
  --network none \
  --memory 2g \
  --cpus 2 \
  --pids-limit 100 \
  --user 1000:1000 \
  -v /path/to/code:/workspace:ro \
  -v /var/run/proxy.sock:/var/run/proxy.sock:ro \
  agent-image

זה מה שכל אפשרות עושה:

ארכיטקטורת שקע Unix:

עם --network none, חיפוש DNS או חיבור ישיר למארח אחר נכשל בתוך הקונטיינר. כדי לאפשר לקוד בקונטיינר להגיע למארחים אחרים, הרץ פרוקסי על המארח ועגן את שקע ה-Unix שלו לתוך הקונטיינר. אם אתה מפנה את ANTHROPIC_BASE_URL או את HTTP_PROXY לפורט ב-localhost, כפי שהגדרת Claude Code לשימוש בפרוקסי מראה, העבר את הפורט הזה בתוך הקונטיינר אל השקע.

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

אזהרה

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

אפשרויות הקשחה נוספות:

#gVisor

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

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

כדי להשתמש ב-gVisor עם Docker, התקן את זמן הריצה runsc והגדר את ה-daemon בקובץ /etc/docker/daemon.json:

{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}

ואז הרץ קונטיינרים עם:

docker run --runtime=runsc agent-image

שיקולי ביצועים:

בסביבות מרובות דיירים, או כשמעבדים תוכן לא מהימן, הבידוד הנוסף שווה לעתים קרובות את התקורה.

#מכונות וירטואליות

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

Firecracker מתוכנן לבידוד microVM קל. הוא יכול לאתחל מכונות וירטואליות בפחות מ-125ms עם תקורה של פחות מ-5 MiB בזיכרון, תוך הסרה של אמולציית התקנים מיותרת כדי להקטין את משטח התקיפה.

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

#פריסות ענן

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

1. הרץ קונטיינרי סוכן בתת-רשת פרטית בלי שער אינטרנט
2. הגדר כללי חומת אש בענן (AWS Security Groups, GCP VPC firewall) כך שיחסמו את כל התעבורה היוצאת חוץ מאשר לפרוקסי שלך
3. הרץ פרוקסי (למשל Envoy עם המסנן credential_injector שלו) שמאמת בקשות, אוכף רשימות היתר של דומיינים, מזריק פרטי גישה ומעביר ל-API חיצוניים
4. הקצה הרשאות IAM מזעריות לחשבון השירות של הסוכן, ונתב גישה רגישה דרך הפרוקסי כשאפשר
5. תעד את כל התעבורה בפרוקסי לצורכי ביקורת

#ניהול אישורים

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

#דפוס הפרוקסי

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

לדפוס הזה כמה יתרונות:

1. הסוכן אף פעם לא רואה את האישורים בפועל
2. הפרוקסי יכול לאכוף רשימת היתרים של נקודות קצה מותרות
3. הפרוקסי יכול לתעד את כל הבקשות לצורכי ביקורת
4. האישורים נשמרים במיקום מאובטח אחד במקום להיות מופצים לכל סוכן

#הגדרת Claude Code לשימוש בפרוקסי

Claude Code תומך בשתי שיטות לניתוב בקשות דגימה דרך פרוקסי:

אפשרות 1: ANTHROPIC_BASE_URL (פשוטה אבל רק לבקשות API של דגימה)

export ANTHROPIC_BASE_URL="http://localhost:8080"

זה אומר ל-Claude Code ול-Agent SDK לשלוח בקשות דגימה לפרוקסי שלך במקום ל-API של Claude ישירות. הפרוקסי שלך מקבל בקשות HTTP בטקסט גלוי, יכול לבדוק ולשנות אותן (כולל הזרקת אישורים), ואז מעביר ל-API האמיתי.

אפשרות 2: HTTP_PROXY / HTTPS_PROXY (ברמת המערכת)

export HTTP_PROXY="http://localhost:8080"
export HTTPS_PROXY="http://localhost:8080"

Claude Code ו-Agent SDK מכבדים את משתני הסביבה הסטנדרטיים האלה, ומנתבים את כל תעבורת ה-HTTP דרך הפרוקסי. עבור HTTPS, הפרוקסי יוצר מנהרת CONNECT מוצפנת: הוא לא יכול לראות או לשנות את תוכן הבקשה בלי יירוט TLS.

#מימוש פרוקסי

אפשר לבנות פרוקסי משלך או להשתמש בפרוקסי קיים:

• Envoy Proxy: פרוקסי ברמת ייצור עם מסנן credential_injector להוספת כותרות אימות
• mitmproxy: פרוקסי שמסיים TLS לבדיקה ושינוי של תעבורת HTTPS
• Squid: פרוקסי מטמון עם רשימות בקרת גישה
• LiteLLM: שער LLM עם הזרקת אישורים והגבלת קצב

#אישורים לשירותים אחרים

מעבר לדגימה מ-API של Claude, סוכנים זקוקים לעיתים קרובות לגישה מאומתת לשירותים אחרים, כמו מאגרי git, מסדי נתונים, ו-API פנימיים. יש שתי גישות עיקריות:

#כלים מותאמים אישית

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

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

יתרונות:

• בלי יירוט TLS: השירות החיצוני מבצע בקשות מאומתות ישירות
• האישורים נשארים בחוץ: הסוכן רואה רק את ממשק הכלי, לא את האישורים שמתחת

#העברת תעבורה

עבור קריאות ל-API של Claude, ANTHROPIC_BASE_URL מאפשר לנתב בקשות לפרוקסי שיכול לבדוק ולשנות אותן בטקסט גלוי. אבל עבור שירותי HTTPS אחרים (GitHub, רישומי npm, API פנימיים), התעבורה מוצפנת לעיתים קרובות מקצה לקצה. גם אם מנתבים אותה דרך פרוקסי באמצעות HTTP_PROXY, הפרוקסי רואה רק מנהרת TLS אטומה ולא יכול להזריק אישורים.

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

1. הרצת הפרוקסי מחוץ לקונטיינר של הסוכן
2. התקנת אישור ה-CA של הפרוקסי במאגר האמון של הסוכן (כדי שהסוכן יסמוך על האישורים של הפרוקסי)
3. הגדרת HTTP_PROXY/HTTPS_PROXY לניתוב התעבורה דרך הפרוקסי

הגישה הזו מטפלת בכל שירות מבוסס HTTP בלי לכתוב כלים מותאמים אישית, אבל מוסיפה מורכבות סביב ניהול אישורים.

שים לב שלא כל התוכניות מכבדות את HTTP_PROXY/HTTPS_PROXY. רוב הכלים (curl, pip, npm, git) כן, אבל חלקם עשויים לעקוף את המשתנים האלה ולהתחבר ישירות. לדוגמה, fetch() של Node.js מתעלם מהמשתנים האלה כברירת מחדל. ב-Node 24 ומעלה אפשר להגדיר NODE_USE_ENV_PROXY=1 כדי להפעיל תמיכה. כדי לכסות כלים שמתעלמים מהמשתנים האלה, אפשר להשתמש ב-proxychains כדי ליירט קריאות רשת, או להגדיר iptables להפניית תעבורה יוצאת לפרוקסי שקוף.

[!NOTE]

פרוקסי שקוף מיירט תעבורה ברמת הרשת, כך שהלקוח לא צריך להיות מוגדר להשתמש בו. פרוקסי רגילים דורשים מהלקוחות להתחבר במפורש ולדבר HTTP CONNECT או SOCKS. פרוקסי שקופים (כמו Squid או mitmproxy במצב שקוף) יכולים לטפל בחיבורי TCP גולמיים שהופנו.

שתי הגישות עדיין דורשות את הפרוקסי שמסיים TLS ואת אישור ה-CA המהימן. הן רק מבטיחות שהתעבורה באמת מגיעה לפרוקסי.

#הגדרת מערכת קבצים

בקרות מערכת הקבצים קובעות אילו קבצים הסוכן יכול לקרוא ולכתוב.

#טעינת קוד לקריאה בלבד

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

docker run -v /path/to/code:/workspace:ro agent-image

[!WARNING]

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

קובץ	סיכון
.env, .env.local	מפתחות API, סיסמאות מסד נתונים, סודות
~/.git-credentials	סיסמאות או אסימוני Git בטקסט גלוי
~/.aws/credentials	מפתחות גישה של AWS
~/.config/gcloud/application_default_credentials.json	אסימוני ADC של Google Cloud
~/.azure/	אישורי Azure CLI
~/.docker/config.json	אסימוני אימות של רישום Docker
~/.kube/config	אישורי אשכול Kubernetes
.npmrc, .pypirc	אסימוני רישום חבילות
*-service-account.json	מפתחות חשבון שירות של GCP
*.pem, *.key	מפתחות פרטיים

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

#מיקומים הניתנים לכתיבה

אם הסוכן צריך לכתוב קבצים, יש כמה אפשרויות בהתאם לשאלה אם רוצים שהשינויים יישמרו:

עבור סביבות עבודה ארעיות בקונטיינרים, השתמש בטעינות tmpfs שקיימות רק בזיכרון ומתנקות כשהקונטיינר נעצר:

docker run \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /workspace:rw,noexec,size=500m \
  agent-image

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

#קריאה נוספת

• תיעוד האבטחה של Claude Code
• אירוח ה-Agent SDK
• טיפול בהרשאות
• סביבת ריצה של ארגז חול
• The Lethal Trifecta for AI Agents
• OWASP Top 10 for LLM Applications
• Docker Security Best Practices
• gVisor Documentation
• Firecracker Documentation