איך להריץ Claude Code בבטחה על שרת

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

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

מה Claude Code יכול לעשות על המחשב שלכם

Claude Code הוא סוכן תכנות (coding agent) הפועל בתוך ה-terminal שלכם. הוא קורא קבצים, כותב קבצים ומריץ פקודות shell כמשתמש שהפעיל אותו. זהו הערך המרכזי של הכלי: הוא יכול לשכפל (clone) מאגר, לערוך קוד, להריץ בדיקות, לקרוא את השגיאה ולתקן את הקוד בלולאה, מבלי שתצטרכו להקליד כל פקודה. אם עדיין לא הגדרתם אותו על שרת, המדריך running Claude Code on a VPS with tmux מסביר על ההתקנה וניהול הסשנים. עמוד זה עוסק בכוח שאתם מעניקים לו מרגע שהוא מותקן.

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

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

מחוץ לקופסה, Claude Code מבקש אישור לפני שהוא פועל. קריאת קבצים בתוך הפרויקט מתבצעת בשקט, אך עריכת קובץ או הרצת פקודת shell מציגה לכם תחילה את העריכה או הפקודה המדויקת ומחכה לאישור (yes). ניתן לאשר פעולה אחת, או לאשר סוג פעולה מסוים למשך שאר הסשן. האישורים הללו הם בטווח הסשן (session-scoped): אם תסגרו את ה-CLI, הסשן הבא יתחיל שוב במצב זהיר. עבור כללים שברצונכם לשמור, קובץ ההגדרות מחזיק רשימות קבועות של allow, ask, ו-deny. לדוגמה: allow git status, ask ב-git push, deny קריאה של .env. כללי ה-deny תמיד גוברים.

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

מה --dangerously-skip-permissions משנה

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

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

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

ה-sandbox המובנה של Claude Code

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

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

sudo apt install bubblewrap socat

ב-Ubuntu 24.04 ומעלה, מדיניות ה-AppArmor الافتراضית מונעת מ-bubblewrap ליצור את ה-user namespaces שהוא זקוק להם. לוח ה-sandbox יגיד לכם מתי משהו חסר, ותיעוד ה-sandboxing של Claude Code מכיל את פרופיל ה-AppArmor הקצר שמתקן זאת.

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

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

סולם ההכלה (The containment ladder)

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

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

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

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

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

שלב 3: VPS ייעודי. השלב החזק ביותר הוא הפשוט ביותר: תנו לסוכן מכונה שלמה שאינה מכילה שום דבר שחשוב לכם. VPS קטן עולה כמה דולרים בחודש. הגדירו אותו באמצעות the first ten minutes on a new VPS runbook, צרו snapshot למצב הנקי, ואפשרו לסוכן לעבוד. שום דבר אחר לא חי שם. אין מפתח SSH אישי, רק deploy key המוגבל למאגר אחד בלבד. אין אישורי ענן, אין נתוני ייצור (production). אם הרצה משתבשת, או כשאתם פשוט רוצים דף חלק, שחזרו את ה-snapshot או השמידו ובנו מחדש את המכונה בדקות. רדיוס הפיצוץ הוא מחיר השכירות. זהו המצב שבו --dangerously-skip-permissions מפסיק להיות מפחיד, מכיוון שהתוצאה הריאלית הגרועה ביותר היא שרת שנבנה מחדש וטוקן אחד שבוטל.

השלבים נערמים. סוכן בתוך sandbox, הרץ כמשתמש ללא הרשאות, על VPS זמני, עולה כמעט אפס נוסף והופך את סיפורי הכישלון למייגעים. מייגע הוא המטרה.

הגנה על האישורים (Credentials)

הכלל שמשתלם עבור כל שאר הדברים: המשתמש של הסוכן לא יכול לקרוא סודות השייכים לכל דבר אחר.

תנו את מפתח ה-API לסוכן ולשום דבר אחר. שימו אותו בקובץ בבעלות משתמש הסוכן עם הרשאת 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/* ותקנו כל דבר שחשבון הסוכן יכול לרשום (list).

הגדירו טווח (scope) לכל טוקן. GitHub token מפורט המוגבל למאגר אחד, או deploy key לכל מאגר, פירושו שאישור שדלף מאבד פרויקט אחד ולא את כל החשבון שלכם. אם אתם משתמשים ב-sandbox, הוסיפו את הגדרות האישורים שלו כך ש-~/.ssh ו-~/.aws ייחסמו אפילו לקריאה. ושמרו על אישורי ייצור (production credentials) מחוץ למכונה לחלוטין, מכיוון שסוכן לא יכול לדלוף סוד שלא היה שם מעולם.

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

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

git switch -c agent/refactor-auth

בדקו את ההרצה לאחר מכן באמצעות git diff main...agent/refactor-auth, מזגו את מה שטוב, ומחקו את ה-branch אם ההרצה לא הובילה לשום דבר. הגנו על ה-main branch בצד של ה-forge, כך שהטוקן של הסוכן לא יוכל לבצע push אליו ולא יוכל לבצע force-push בשום מקום. היסטוריית ה-commit משמשת גם כיומן ביקורת (audit log) למה שקרה בזמן שישנתם, וזה שווה יותר מכל היקף של היסטוריית terminal.

הרשת היא חלק מרדיוס הפיצוץ

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

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

אם אתם בונים סוכן משלכם מול ה-API במקום להריץ את Claude Code, אותה מחשבה תקפה ללא שינוי. Building an AI agent with Claude on a VPS מסביר את הנתיב הזה, והסוכן שלו ראוי לאותו משתמש ייעודי, אותם טוקנים מוגדרים, ואותו קופסה זמנית.

הקשיחו את המכונה תחילה

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

FAQ

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

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

האם ל-Claude Code יש sandbox?

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

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

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

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

הוא יכול לקרוא כל מה שהמשתמש שמריץ אותו יכול לקרוא, ואפילו המדיניות الافتراضית של ה-sandbox מאפשרת קריאה לנתיבי אישורים עד שתחסמו אותם. לכן, הריצו את הסוכן כמשתמש משלו, שמרו על ספריית הבית שלכם במצב 750 או הדוק יותר, חסמו נתיבי אישורים בהגדרות ה-sandbox, ושמרו על סודות ייצור מחוץ למכונה לחלוטין. סוד שמכונה מעולם לא החזיקה לא ניתן לקרוא או לדלוף.

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

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