הרצת Claude Code בצורה מאובטחת על שרת: מדריך הגדרות

מה המשמעות של הרצת Claude Code בצורה מאובטחת על שרת

כדי להריץ את Claude Code בצורה מאובטחת על שרת, השאירו את בקשות האישור להרשאות פעילות, הריצו אותו כמשתמש ייעודי ללא הרשאות מיוחדות (unprivileged), והגדירו עבור הרצות ללא השגחה גבולות גזרה ממשיים במקום להסתמך על אמון: השתמשו ב-sandbox המובנה, במכולה (container), או ב-VPS חד-פעמי שאינו מכיל מידע רגיש. הדגל --dangerously-skip-permissions מסיר את שלב אישור הפעולות בין המודל לבין ה-shell שלכם. פשרה זו עשויה להיות סבירה עבור עבודה ללא השגחה, אך רק בתוך גבולות גזרה המגבילים את טווח ההשפעה של פקודה שגויה. מדריך זה מסביר מה הדגל משנה בפועל, וכיצד לבנות את גבולות הגזרה הללו בשלבים של בידוד הולך וגובר.

מה Claude Code יכול לעשות בשרת שלך

Claude Code הוא סוכן תכנות הפועל בתוך ה-terminal. הוא קורא קבצים, כותב קבצים ומריץ פקודות shell בתור המשתמש שהפעיל אותו. זהו הערך המוסף המלא של הכלי: הוא מסוגל לשכפל מאגר (repository), לערוך קוד, להריץ בדיקות, לקרוא את השגיאות ולתקן את הקוד בלולאה, מבלי שתצטרך להקליד כל פקודה בעצמך. אם טרם הגדרת אותו בשרת, המדריך הרצת Claude Code על VPS עם tmux מכסה את ההתקנה ואת ניהול ה-session. דף זה עוסק בעוצמה שאתה מעניק לו ברגע שהוא מותקן.

הסיכון הוא אותו משפט שנקרא פעם שנייה. תהליך שמריץ פקודות shell תחת המשתמש שלך יכול לעשות כל מה שהמשתמש שלך יכול לעשות. הוא יכול לקרוא את ~/.ssh/id_ed25519, ~/.aws/credentials, וכל קובץ .env שהמשתמש שלך יכול לפתוח. הוא יכול להריץ את curl ולשלוח נתונים לכל host שהשרת יכול להגיע אליו. הוא יכול להריץ את git push --force. לסוכן אין מניעים משלו. הסכנה היא שמשימה תשתבש, או שהטקסט שהוא קרא במהלך העבודה הכיל הוראות שנכתבו על ידי מישהו אחר: דף אינטרנט שהוא משך, או הערה ב-issue שהוא התבקש לתקן. למקרה השני הזה קוראים prompt injection, וזו הסיבה ש"המודל בדרך כלל הגיוני" אינו מהווה תוכנית אבטחה. הוראות יכולות להגיע גם ממקור קרוב יותר, כיוון ש-שני sessions של Claude Code על אותו שרת יכולים לשלוח טקסט זה לזה, והודעה מ-session מקביל היא בסך הכל עוד טקסט שהסוכן המקבל קורא. עליך לתכנן עבור ההרצה הכושלת, לא עבור המקרה הממוצע.

מערכת ההרשאות במילים פשוטות

במצב Manual,‏ Claude Code מבקש אישור לפני ביצוע פעולות. קריאת קבצים בתוך הפרויקט מתבצעת בשקט, אך עריכת קובץ או הרצת פקודת shell מציגות לך תחילה את העריכה או הפקודה המדויקת וממתינות לאישור. ניתן לאשר פעולה בודדת, או להורות לכלי לא לשאול שוב. בחירה זו תקפה עד לסיום הסשן עבור עריכות קבצים, אך עבור פקודות shell היא נשמרת לצמיתות עבור אותו מאגר ופקודה, כך שאישור מהיר בשרת נשמר גם לאחר סיום הסשן. עבור כללים שברצונך לשמור באופן קבוע, קובץ ההגדרות מכיל רשימות של אישורים (allow), שאלות (ask) וחסימות (deny). לדוגמה: אישור ל-git status, בקשת אישור ב-git push, וחסימת קריאה של .env. כללי חסימה תמיד גוברים על כל השאר. קו הבסיס הזה השתנה גם הוא. מצב Auto, שבו מסווג (classifier) בוחן פעולות במקומך, הפך לברירת המחדל עבור סשנים חדשים בתוכניות Pro, Max ו-Team ב-14 באוגוסט 2026, והחל מגרסה Claude Code v2.1.283 הוא מצב ההתחלה המובנה עבור סשנים בטרמינל אינטראקטיבי וב-VS Code בכל תוכנית, אלא אם הגדרת ברירת מחדל אחרת. לכן כדאי לדעת מה כל מצב הרשאה מאפשר בפועל לפני שתחליט באיזה מצב להריץ שרת שאינך יכול להשגיח עליו.

תכנון זה מניח שבן אדם צופה בטרמינל, ובלפטופ זה אכן המצב. בשרת, המטרה היא לעיתים קרובות שאף אחד לא צופה. אתה מתחיל משימה ארוכה בתוך tmux והולך לישון, וסוכן שעוצר לשאול שאלה ב-2 לפנות בוקר לא מתקדם עד הבוקר. העצירה עולה כסף וזמן, כיוון ש-סשן Claude Code לא פעיל מאבד את ה-prompt cache החם שלו והשלב הבא דורש תשלום על בנייתו מחדש. זו הסיבה הכנה לכך שאנשים משתמשים ב-flag של דילוג (skip) בשרתים, והבעיה שהיא פותרת היא אמיתית. שאר המדריך הזה עוסק בפתרון הבעיה מבלי לוותר על כל אמצעי הבטיחות.

מה משנה הדגל --dangerously-skip-permissions

claude --dangerously-skip-permissions מבטל את שלב האישור. עריכות מתבצעות ללא בקשת אישור. פקודות shell רצות ללא בקשת אישור. גם בדיקות הנתיבים המוגנים, שבאופן רגיל מאבטחים מיקומים רגישים, מדלגות על הפעולה. חוקי ה-deny המפורשים שלכם עדיין תקפים, ומספר פעולות קיצוניות עדיין יעצרו לבקשת אישור, אך השורה התחתונה פשוטה: כל מה שהמודל מחליט להריץ, ירוץ.

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

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

ארגז החול המובנה של Claude Code

לפני המעבר על השלבים, דעו כי Claude Code כולל כעת ארגז חול (sandbox) ברמת מערכת ההפעלה עבור הפקודות שהוא מריץ, דבר המייתר את רוב הסיבות שבגללן משתמשים נזקקו בעבר לדגל ה-skip. בלינוקס, הכלי משתמש ב-bubblewrap לצורך בידוד מערכת הקבצים, וב-socat כדי לנתב תעבורת רשת דרך proxy. בתוך ארגז החול, פקודה יכולה לכתוב רק לספריית הפרויקט ולספריית זמנית של הסשן, והיא יכולה לגשת לרשת רק דרך proxy שבודק כל דומיין מול רשימת היתרים (allow list). בפעם הראשונה שפקודה מבקשת גישה לדומיין חדש, Claude Code יבקש את אישורכם; במצב אוטומטי, המסווג (classifier) בוחן את המארח החדש במקומכם.

הפעילו אותו באמצעות הפקודה /sandbox בתוך סשן. ב-Ubuntu וב-Debian, התקינו תחילה את שתי החבילות הנדרשות:

sudo apt install bubblewrap socat

ב-Ubuntu 24.04 ומעלה, מדיניות ה-AppArmor המוגדרת כברירת מחדל מונעת מ-bubblewrap ליצור את מרחבי השמות (user namespaces) להם הוא זקוק. לוח הבקרה של ארגז החול יתריע כאשר משהו חסר, ותיעוד ה-sandboxing של Claude Code מכיל את פרופיל ה-AppArmor הקצר שמתקן זאת.

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

היו כנים לגבי מגבלותיו. כברירת מחדל, פקודה בתוך ארגז החול עדיין יכולה לקרוא את רוב מערכת הקבצים, כולל קובצי הרשאות, אלא אם תחסמו נתיבים אלו; הגדרת sandbox.credentials קיימת בדיוק עבור מטרה זו. ה-proxy של הרשת בודק שמות דומיין ואינו בוחן את התעבורה עצמה, לכן היתר רחב כמו github.com עדיין מותיר מרחב להוצאת נתונים. Docker אינו עובד בתוכו. ארגז החול מעלה את רף האבטחה משמעותית. הוא אינו מהווה גבול בידוד מוחלט, וזו הסיבה שהשלבים להלן עדיין חשובים.

סולם הבידוד

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

שלב 1: משתמש ייעודי ללא הרשאות (unprivileged user). הסוכן מקבל חשבון משלו, תיקיית בית משלו, תיקיית פרויקט משלו, וללא הרשאות sudo:

sudo adduser --disabled-password --gecos "" agent

גבולות החשבון מונעים מהסוכן גישה לקבצים שלכם: מפתחות ה-SSH שלכם וכל פרויקט אחר על המכונה. זה גם מאפשר להשתמש בדגל ה-skip, שכן הדגל מסרב לרוץ כ-root. זהו אותו עיקרון כמו הרצת כל שירות כמשתמש ללא הרשאות, המיושם כאן עבור סוכן. מה שלב 1 אינו מגביל: את הרשת, וכל דבר על המכונה שזמין לקריאה לכל משתמש (world-readable).

שלב 2: מכולה (container). חברת Anthropic מפרסמת devcontainer רשמי שמריץ את Claude Code כמשתמש שאינו root, עם חוקי firewall שמגבילים את המארחים אליהם הסוכן יכול להגיע; מכולה שתבנו בעצמכם תבצע את אותה עבודה. מערכת הקבצים מצטמצמת לנפחים (volumes) שאתם מעגנים, והתעבורה היוצאת מצטמצמת למה שחוקי המכולה מתירים. זהו שלב הביניים הנכון כאשר השרת מארח שירותים אחרים שחשובים לכם. המגבלה שלו היא שמכולות חולקות את ה-kernel של המארח, ועיגון (mount) אחד לא זהיר מבטל את הגבול; תנו למכולה את /var/run/docker.sock והיא תוכל להגיע לכל המארח.

שלב 3: שרת VPS ייעודי. השלב החזק ביותר הוא גם הבוטה ביותר: תנו לסוכן מכונה שלמה שאינה מכילה שום דבר שחשוב לכם. שרת VPS קטן עולה דולרים בודדים בחודש. הגדירו אותו לפי ספר הנהלים לעשר הדקות הראשונות ב-VPS חדש, צלמו snapshot של המצב הנקי, ותנו לסוכן לעבוד. שום דבר אחר לא רץ שם. אין מפתח SSH אישי, רק deploy key שמוגבל למאגר (repository) אחד בלבד. אין פרטי גישה לענן, אין נתוני ייצור (production data). כאשר הרצה משתבשת, או כשאתם פשוט רוצים התחלה נקייה, שחזרו את ה-snapshot או השמידו ובנו מחדש את המכונה תוך דקות. רדיוס הנזק מוגבל לעלות השכירות. זוהי התצורה שבה --dangerously-skip-permissions מפסיק להיות מפחיד, כי התוצאה הריאלית הגרועה ביותר היא שרת שנבנה מחדש ואסימון (token) אחד שבוטל.

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

הגנה על פרטי הזיהוי

הכלל החשוב ביותר: המשתמש שמריץ את ה-agent לא אמור להיות מסוגל לקרוא סודות השייכים לשירותים אחרים.

ספקו את ה-API key ל-agent בלבד. שמרו אותו בקובץ בבעלות המשתמש של ה-agent עם הרשאות 600, וטענו אותו בעת הפעלת ה-shell:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

לאחר מכן, הגבילו את הגישה לכיוון השני. בהתקנות ישנות של Debian ו-Ubuntu, ובחשבונות שנוצרו במהלך ההתקנה, תיקיות הבית עשויות להיות קריאות לכל משתמש במערכת; לכן, הדקו את ההרשאות באמצעות: chmod 750 /home/youruser. בצעו בדיקה עם ls -ld /home/* ותקנו כל נתיב שהחשבון של ה-agent יכול להציג.

הגדירו Scope לכל token. שימוש ב-GitHub token בעל הרשאות מצומצמות למאגר יחיד, או ב-deploy key לכל מאגר, מבטיח שדליפת פרטי זיהוי תפגע בפרויקט אחד בלבד ולא בכל החשבון שלכם. אם אתם משתמשים ב-sandbox, הגדירו את הרשאות הגישה כך ש-~/.ssh ו-~/.aws ייחסמו אפילו לקריאה. הרחיקו פרטי זיהוי של סביבת הייצור מהשרת לחלוטין, שכן ה-agent לא יכול להדליף סוד שלא קיים בו. אם הסודות מאוחסנים ב-password manager בניהול עצמי, שמרו אותו בשרת נפרד מה-agent ובצעו לו ביקורת נפרדת, כיוון ש-נקודות התורפה של Vaultwarden הן ה-admin token וקובץ הגיבוי ולא הכספת המוצפנת עצמה.

Git הוא רשת הביטחון

כל שינוי שהסוכן מבצע ניתן לסקירה ולביטול, ו-git מספקת את שתי האפשרויות הללו בחינם אם הסוכן עובד על branch ומבצע commit תוך כדי עבודה:

git switch -c agent/refactor-auth

עבודה שהסוכן לא ביצע עבורה commit אינה נהנית מהגנה זו: הפקודה git reset --hard משליכה שינויים שלא עברו commit בקבצים במעקב, ו-git אינה מכסה דבר מחוץ ל-repository. סקרו את הריצה לאחר מכן באמצעות git diff main...agent/refactor-auth כדי לראות מה בוצע ב-commit, ולאחר מכן השתמשו ב-git status וב-git diff HEAD ב-branch כדי לראות מה נותר ללא commit. מיזגו את מה שראוי, ומחקו את ה-branch אם הריצה לא הניבה תוצאות. קל הרבה יותר לקרוא בבוקר ריצה שנגעה בשלושה קבצים מאשר ריצה שכתבה מחדש חצי מה-module, וזהו המקרה המעשי עבור מיומנות שמחייבת את הסוכן לבצע את השינוי הקטן ביותר שעובד. הגנו על ה-branch הראשי בצד ה-forge, כך שה-token של הסוכן לא יוכל לבצע אליו push ולא יוכל לבצע force-push לשום מקום. היסטוריית ה-commit משמשת גם כ-audit log למה שקרה בזמן שישנתם, וערכה רב יותר מכל כמות של גלילה ב-terminal.

הרשת היא חלק מטווח הפגיעה

סוכן יכול להריץ את curl. משפט זה מתמצת את כל בעיית ה-egress: כל מה שהסוכן מסוגל לקרוא, הוא מסוגל גם לשלוח למקום כלשהו, וסוכן שחווה prompt injection עלול לעשות זאת. משתמש רגיל ללא הרשאות מיוחדות אינו מגביל זאת כלל, שכן כל משתמש יכול להגיע לכל יעד שהשרת עצמו יכול להגיע אליו. ה-sandbox מגביל זאת לפי דומיין באמצעות ה-proxy שלו. מכולה (container) יכולה להגביל זאת באמצעות חוקי firewall משלה. שרת VPS ייעודי מגביל את המידע שקיים מלכתחילה לדליפה, וזוהי התשובה החסונה ביותר מבין השלוש.

אל תנסו לפתור את בעיית ה-egress באמצעות ufw בלבד. כברירת מחדל, ufw מאפשר את כל התעבורה היוצאת, וכתיבת חוקים יוצאים שעדיין מאפשרים פעולות כמו apt, npm, git וגישה ל-Claude API היא עבודה מורכבת שנוטה להישבר בשקט. בחרו להציב את הגבול ברמת ה-sandbox, המכולה או המכונה, שם רשימת היתרים (allow list) מבוססת דומיינים או מכונה ריקה מבצעים את אותה עבודה בצורה נקייה.

אם אתם בונים סוכן משלכם מול ה-API במקום להריץ את Claude Code, אותה תפיסה תקפה ללא שינוי. המדריך בניית סוכן AI עם Claude על גבי VPS מכסה נתיב זה, והסוכן שלכם ראוי לאותו משתמש ייעודי, לאותם אסימונים (tokens) מוגבלים בהרשאותיהם, ולאותה סביבה חד-פעמית.

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

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

FAQ

האם בטוח להשתמש ב---dangerously-skip-permissions על שרת?

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

האם ל-Claude Code יש ארגז חול (sandbox)?

כן. Claude Code מגיע עם ארגז חול מובנה לפקודות shell, שנפתח באמצעות הפקודה /sandbox. הוא משתמש ב-bubblewrap ב-Linux וב-Seatbelt ב-macOS, מגביל כתיבה לספריית הפרויקט, ומנתב גישה לרשת דרך proxy שמאפשר רק דומיינים מאושרים. מצב ה-auto-allow שלו מריץ פקודות בתוך ארגז החול ללא בקשות אישור, כך שהוא מצמצם הפרעות בדומה לדגל הדילוג, תוך שמירה על גבולות אכיפה של מערכת ההפעלה. זהו אינו גבול בידוד מוחלט, לכן יש לשלב אותו עם משתמש ייעודי או מכונה ייעודית עבור הרצות ללא השגחה.

מדוע דגל הדילוג מסרב לרוץ כ-root?

מכיוון ש-root ללא בקשות אישור הרשאות יכול לשנות כל קובץ וכל שירות במערכת, Claude Code חוסם את --dangerously-skip-permissions כאשר הוא רץ כ-root או תחת sudo ב-Linux וב-macOS. הפתרון הוא לא להילחם בבדיקה. צרו משתמש ללא הרשאות עבור הסוכן והריצו אותו שם; גבול החשבון הזה הוא שכבת ההגנה הראשונה והזולה ביותר.

האם Claude Code יכול לקרוא את מפתחות ה-SSH וקובצי ה-.env שלי?

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

מהי הדרך הבטוחה ביותר להריץ את Claude Code ללא השגחה?

שרת VPS ייעודי וזול המשמש רק לעבודת הסוכן: מוקשח תוך עשר דקות, עם snapshot נקי, מריץ את Claude Code תחת משתמש ללא הרשאות עם ארגז חול פעיל, קובץ במצב 600 שמחזיק את מפתח ה-API, מפתח deploy לכל מאגר (repository), וכל העבודה מתבצעת על ענפים (branches) שאתם בוחנים לפני המיזוג. אם הרצה משתבשת, אתם מבטלים טוקן אחד ומשחזרים את ה-snapshot, ושום דבר אחר בבעלותכם אינו מושפע.