📘 תיעוד 151

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

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

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

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

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

#מודל איומים

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

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

#מאפייני אבטחה מובנים

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

• מערכת הרשאות: ניתן להגדיר כל כלי ופקודת bash כך שיאפשרו, יחסמו, או יבקשו אישור מהמשתמש. השתמשו בתבניות glob כדי ליצור כללים כמו "אפשר את כל פקודות npm" או "חסום כל פקודה עם sudo". ארגונים יכולים להגדיר מדיניות שחלה על כל המשתמשים. ראו הרשאות.
• ניתוח פקודות לצורך הרשאות: לפני הרצת פקודות bash, המערכת של Claude Code מנתחת אותן לעץ תחביר מופשט (AST) ומשווה את התוצאה מול כללי ההרשאות שלכם. פקודות שלא ניתן לנתח באופן נקי, או שאינן תואמות לכלל התרה, דורשות אישור מפורש. קבוצה קטנה של מבנים כגון eval דורשת תמיד אישור ללא קשר לכללי ההתרה. זהו שער הרשאות ולא סביבת בידוד (sandbox), מלבד בדיקות בטיחות מובנות כגון בדיקת נתיב קריטי על rm ועל rmdir ורשימת הנתיבים המוגנים, הוא אינו מסיק אם פקודה היא מסוכנת לפי נתיב היעד שלה או השפעותיה.
• תמצות חיפוש באינטרנט: תוצאות החיפוש מתומצתות במקום להעביר תוכן גולמי ישירות לתוך ההקשר, מה שמפחית את הסיכון להזרקת הנחיות מתוכן אינטרנט זדוני.
• מצב סביבת בידוד (Sandbox mode): פקודות bash יכולות לרוץ בסביבת בידוד שמגבילה גישה למערכת הקבצים ולרשת. ראו את תיעוד סביבת הבידוד לפרטים.

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

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

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

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

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

#עיקרון ההרשאה המינימלית

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

#הגנה לעומק

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

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

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

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

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

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

#סביבת ריצה מבודדת (Sandbox runtime)

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

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

כיצד זה עובד:

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

התקנה והגדרה:

npm install @anthropic-ai/sandbox-runtime

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

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

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

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

#קונטיינרים

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

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

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 (Unix socket):

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

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

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

#gVisor

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

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

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

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

לאחר מכן הריצו קונטיינרים באמצעות:

docker run --runtime=runsc agent-image

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

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

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

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

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

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

#פריסות ענן

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

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

#ניהול אישורים ופרטי גישה

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

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

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

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

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

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

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

אפשרות 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: פרוקסי מטמון עם רשימות בקרת גישה (access control lists).
• LiteLLM: שער LLM עם הזרקת פרטי גישה והגבלת קצב (rate limiting).

#אישורים עבור שירותים אחרים

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

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

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

לדוגמה, שרת git MCP יכול לקבל פקודות מהסוכן אך להעביר אותן לפרוקסי 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 כדי לנתב מחדש תעבורה יוצאת לפרוקסי שקוף (transparent proxy).

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

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

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

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

#עיגון קוד לקריאה בלבד

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

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

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

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

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

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

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

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

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

#קריאה נוספת

• תיעוד אבטחה של Claude Code
• אירוח ה-Agent SDK
• טיפול בהרשאות
• Sandbox runtime
• The Lethal Trifecta for AI Agents
• OWASP Top 10 for LLM Applications