Docker, Remote Servers, and Enterprise — Docker, שרתים מרוחקים וארגונים

למה Docker ל-Claude Code?

יש לכם pipeline שרץ מצוין על המחשב שלכם. claude -p "run the content pipeline" — הכל עובד. אתם שולחים את הקוד לעמית בצוות ו... זה לא עובד. "אצלי לא מותקן Python 3.11." "אין לי את ה-dependencies האלה." "אצלי ה-path שונה." בעיית "Works on My Machine" — הבעיה הקלאסית ביותר בפיתוח תוכנה.

Docker פותר את זה ברמה הבסיסית ביותר: הקוד שלכם רץ בתוך container — סביבה מבודדת שמכילה בדיוק את מה שהוא צריך. אותו container רץ זהה על הלפטופ שלכם, על השרת של הצוות, ועל ה-CI/CD. אם זה עובד ב-Docker — זה עובד בכל מקום.

אבל ל-Claude Code יש סיבה נוספת, חשובה אפילו יותר: אבטחה. Claude Code מריץ פקודות shell, קורא קבצים, וכותב קוד. כשהוא רץ על המחשב שלכם, ה-sandbox המובנה (Seatbelt ב-macOS, bubblewrap ב-Linux) מגביל אותו. אבל כשאתם פורסים לפרודקשן, אתם רוצים שכבת הגנה נוספת: ה-Docker container עצמו הוא ה-sandbox. גם אם הסוכן "מצליח" לברוח מההגבלות — הוא תקוע בתוך container עם גישה מוגבלת.

Anthropic מספקים תמיכה רשמית ב-Docker: devcontainer.json, Dockerfile, ו-init-firewall.sh — שלושה קבצים שנותנים לכם סביבה מאובטחת ומוכנה לפיתוח. זה לא פתרון שצריך להמציא — זה פתרון מוכן.

Dev Containers — סביבה אחידה לכל הצוות

Dev Containers הם סטנדרט של VS Code (ורלוונטי גם ל-GitHub Codespaces ו-JetBrains): אתם מגדירים תיקיית .devcontainer/ בפרויקט, ומי שפותח אותו ב-VS Code מקבל סביבה זהה אוטומטית — כל הכלים, הגדרות, extensions, ו-firewall rules. "Clone, open, everything works."

Anthropic מספקים devcontainer רשמי ל-Claude Code. הוא כולל: Node.js, Python, Claude Code CLI מותקן, חוקי firewall שמגבילים תקשורת רשת, ו-security hardening בסיסי. בואו נבנה אחד מאפס.

מבנה התיקייה

.devcontainer/
├── devcontainer.json     # הגדרות ה-container: image, extensions, ports
├── Dockerfile            # מה מותקן בפנים
└── init-firewall.sh      # הגבלת תקשורת רשת

devcontainer.json

{
  "name": "Claude Code Dev Environment",
  "build": {
    "dockerfile": "Dockerfile"
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "anthropic.claude-code"
      ],
      "settings": {
        "terminal.integrated.defaultProfile.linux": "bash"
      }
    }
  },
  "forwardPorts": [3000, 8080],
  "postCreateCommand": "bash .devcontainer/init-firewall.sh",
  "remoteEnv": {
    "ANTHROPIC_API_KEY": "${localEnv:ANTHROPIC_API_KEY}"
  },
  "runArgs": [
    "--memory=4g",
    "--cpus=2"
  ]
}

שימו לב לשלוש נקודות חשובות: (1) ה-API key מועבר מהסביבה המקומית שלכם — לא נכתב בקובץ. (2) ה-postCreateCommand מריץ את סקריפט ה-firewall אוטומטית. (3) runArgs מגביל משאבים — כך שסוכן שהשתולל לא יאכל את כל ה-RAM.

Dockerfile

FROM node:20-slim

# Install Claude Code CLI
RUN npm install -g @anthropic-ai/claude-code

# Install Python (for multi-language pipelines)
RUN apt-get update && apt-get install -y \
    python3 python3-pip \
    git curl iptables \
    && rm -rf /var/lib/apt/lists/*

# Create non-root user
RUN useradd -m -s /bin/bash developer
USER developer
WORKDIR /home/developer/project

המפתח: אנחנו יוצרים משתמש developer שאינו root. Claude Code ירוץ בתור המשתמש הזה — אין לו הרשאות root בתוך ה-container. שכבת הגנה נוספת.

init-firewall.sh

#!/bin/bash
# Allow only Anthropic API and specified domains
iptables -A OUTPUT -d api.anthropic.com -j ACCEPT
iptables -A OUTPUT -d cdn.anthropic.com -j ACCEPT
# Allow DNS
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
# Allow established connections
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Block everything else
iptables -A OUTPUT -j DROP

echo "Firewall configured: only Anthropic API allowed"

הסקריפט הזה קריטי: הוא מבטיח שהקונטיינר יכול לתקשר רק עם ה-API של Anthropic. אם סוכן מנסה לשלוח נתונים לשרת חיצוני, או להוריד קוד זדוני — ה-firewall חוסם. זו הגנה מפני prompt injection — תרחיש שבו קוד שהסוכן קורא מכיל הוראות זדוניות שמנסות לגרום לו "לצלצל הביתה" (phone home) עם נתונים רגישים.

אבטחת Docker — Best Practices

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

כלל 1: לעולם אל תחברו את Docker Socket

# !!!!! לעולם אל תעשו את זה !!!!!
docker run -v /var/run/docker.sock:/var/run/docker.sock my-agent

# למה? כי Docker socket = גישת root למערכת כולה
# הסוכן יכול ליצור container חדש עם full root access
# ולברוח מהסנדבוקס לחלוטין

/var/run/docker.sock הוא הדרך לתקשר עם Docker daemon. אם אתם מחברים אותו לקונטיינר, הסוכן יכול ליצור קונטיינרים חדשים, למחוק קונטיינרים קיימים, ואפילו לקבל גישה לכל ה-filesystem של ה-host. זה שווה ערך לגישת root למערכת שלכם.

כלל 2: Source code כ-read-only

docker run \
  -v $(pwd)/src:/project/src:ro \
  -v $(pwd)/output:/project/output \
  my-claude-agent

ה-:ro אומר read-only. הסוכן יכול לקרוא את קוד המקור, אבל לא לשנות אותו. הוא יכול לכתוב רק לתיקיית /project/output. אם משהו משתבש — קוד המקור שלכם שלם.

כלל 3: Resource Limits

docker run \
  --memory=4g \
  --memory-swap=4g \
  --cpus=2 \
  --pids-limit=100 \
  --storage-opt size=10G \
  my-claude-agent

בלי limits, סוכן שנכנס ללולאה אינסופית יאכל את כל ה-RAM וה-CPU של השרת. ה-flags מגבילים: 4GB RAM (בלי swap נוסף), 2 CPUs, 100 processes מקסימום, 10GB דיסק. אם הסוכן חורג — ה-container נהרג אוטומטית.

כלל 4: Non-root User

# ב-Dockerfile:
RUN useradd -m -s /bin/bash agent
USER agent

# או ב-runtime:
docker run --user 1000:1000 my-claude-agent

כלל 5: Network Isolation

# אפשרות א: הריצו init-firewall.sh כ-postCreate
# אפשרות ב: השתמשו ב-Docker network policy
docker network create --internal isolated-net
docker run --network isolated-net my-claude-agent

כלל 6: Secrets דרך Environment Variables

# נכון: מעבירים בזמן ריצה
docker run -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY my-agent

# לא נכון: בונים לתוך ה-image
# ENV ANTHROPIC_API_KEY=sk-ant-...   # !!!!! לעולם אל !!!!!
# כל מי שמושך את ה-image רואה את המפתח

כלל 7: Image Scanning

# סרקו את ה-image לפני פריסה
docker scout cves my-claude-agent:latest
# או השתמשו ב-Trivy:
trivy image my-claude-agent:latest

פריסה על VPS — שרת מרוחק

Docker על הלפטופ זה טוב לפיתוח. אבל pipeline שצריך לרוץ כל לילה ב-2:00, או סוכן שצריך להיות זמין 24/7, צריך שרת שעובד גם כשהלפטופ סגור. זה VPS — Virtual Private Server.

Claude Code הוא קל מאוד. כל העיבוד הכבד קורה ב-API של Anthropic. ה-VPS שלכם צריך רק: 2GB RAM (מספיק ב-90% מהמקרים), 1-2 CPU cores, ו-20GB דיסק. זה עולה $5-10 לחודש — DigitalOcean, Linode, Hetzner, או AWS EC2 t3.small. סטארטאפים ישראליים רבים מריצים על Hetzner בגלל היחס מחיר-ביצועים.

התקנת Claude Code על VPS

# התחברו לשרת
ssh [email protected]

# התקינו Node.js
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo bash -
sudo apt-get install -y nodejs

# התקינו Claude Code
sudo npm install -g @anthropic-ai/claude-code

# הגדירו API key
echo 'export ANTHROPIC_API_KEY=sk-ant-...' >> ~/.bashrc
source ~/.bashrc

# בדקו שעובד
claude --version
claude -p "say hello" --bare

Systemd Service — סוכן כ-daemon

אתם רוצים שהסוכן/pipeline ירוץ אוטומטית כשהשרת עולה, ויתחיל מחדש אם הוא נופל? Systemd service — הדרך הנכונה ב-Linux.

# /etc/systemd/system/claude-pipeline.service
[Unit]
Description=Claude Code Production Pipeline
After=network.target docker.service

[Service]
Type=simple
User=deploy
WorkingDirectory=/home/deploy/my-project
Environment=ANTHROPIC_API_KEY=sk-ant-your-key-here
ExecStart=/usr/bin/docker run --rm \
  --memory=4g --cpus=2 \
  -v /home/deploy/my-project/src:/project/src:ro \
  -v /home/deploy/my-project/output:/project/output \
  -e ANTHROPIC_API_KEY \
  my-claude-pipeline
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target

# הפעלה
sudo systemctl enable claude-pipeline  # התחלה אוטומטית עם boot
sudo systemctl start claude-pipeline   # התחלה מיידית
sudo systemctl status claude-pipeline  # סטטוס
journalctl -u claude-pipeline -f       # logs בזמן אמת

Monitoring — ניטור ב-Production

שרת VPS שרץ סוכנים 24/7 צריך ניטור. אתם לא רוצים לגלות שה-pipeline נפל רק כשהלקוח מתלונן. הנה setup בסיסי עם כלים חינמיים:

# Healthcheck script — שמרו כ-/home/deploy/healthcheck.sh
#!/bin/bash
CONTAINER_STATUS=$(docker inspect --format='{{.State.Status}}' claude-pipeline 2>/dev/null)
if [ "$CONTAINER_STATUS" != "running" ]; then
    curl -X POST "https://hooks.slack.com/services/YOUR/WEBHOOK" \
        -d '{"text":"⚠️ Claude pipeline container is DOWN"}'
fi

# Disk space check
DISK_USAGE=$(df -h / | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$DISK_USAGE" -gt 85 ]; then
    curl -X POST "https://hooks.slack.com/services/YOUR/WEBHOOK" \
        -d "{\"text\":\"⚠️ Disk usage at ${DISK_USAGE}%\"}"
fi

# הוסיפו ל-crontab:
# */5 * * * * /home/deploy/healthcheck.sh

בסטארטאפים ישראליים, שימוש ב-UptimeRobot (חינם, עד 50 monitors) נפוץ מאוד — הוא יכול לעקוב אחרי שרת HTTP שאתם מגדירים כ-healthcheck endpoint. אם ה-endpoint לא מגיב — אתם מקבלים התראה ב-SMS, אימייל, או Slack. אפשר גם להשתמש ב-Better Stack (לשעבר Better Uptime) שיש לו tier חינמי נדיב.

SSH Workflows — עבודה מרחוק

Claude Code על שרתים מרוחקים דרך SSH הוא first-class workflow — לא workaround, לא hack. Anthropic עיצבו את הכלי לעבוד מצוין מעל SSH. בואו נראה שלושה דפוסי עבודה.

Pattern 1: Remote Execution — פקודה אחת

# הריצו משימה על השרת וקבלו תוצאה
ssh deploy@server "cd /project && claude -p 'run all tests and report failures' --bare"

# שלבו עם cron לריצה לילית
# crontab -e:
0 2 * * * ssh deploy@server "cd /project && claude -p 'nightly quality check' --bare" >> /var/log/nightly.log 2>&1

שימו לב לדגלים: -p מפעיל headless mode (בלי ממשק אינטראקטיבי), --bare מדלג על hooks, LSP, plugins — התחלה מהירה. זה מה שלמדנו בפרק 1 — עכשיו אנחנו מפעילים את זה מרחוק.

Pattern 2: Interactive Session — עבודה אינטראקטיבית

# SSH עם -t (terminal allocation) — חובה ל-interactive mode
ssh -t deploy@server "cd /project && claude"

# עכשיו אתם בתוך Claude Code interactive mode
# על השרת — לא על הלפטופ
# כל הקבצים, ה-git, וה-Docker הם של השרת

הדגל -t קריטי — הוא מקצה pseudo-terminal כך ש-Claude Code יכול להציג ממשק אינטראקטיבי. בלעדיו תקבלו שגיאה.

Pattern 3: Persistent Session — tmux

# צרו session בשם "pipeline" על השרת
ssh deploy@server "tmux new-session -d -s pipeline 'cd /project && claude'"

# התנתקו מ-SSH — ה-session ממשיך לרוץ
exit

# שעה אחרי — התחברו בחזרה ובדקו סטטוס
ssh -t deploy@server "tmux attach -t pipeline"

# או: השתמשו ב-Remote Control מהנייד 📱
# claude.ai/code -> ה-session מופיע חי

tmux הוא הכלי שמשנה את הכל. הסוכן ממשיך לרוץ גם כשאתם מנותקים מ-SSH. שילוב של tmux + Remote Control נותן את חוויית העבודה הטובה ביותר: התחילו משימה ארוכה על השרת, התנתקו, עקבו מהנייד, התחברו בחזרה כשצריך להתערב.

SSH Configuration — טיפים מעשיים

הגדרת ~/.ssh/config חוסכת הקלדה חוזרת ומאפשרת חיבור מהיר:

# ~/.ssh/config
Host claude-server
    HostName your-server.com
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    ForwardAgent yes
    ServerAliveInterval 60
    ServerAliveCountMax 3

# עכשיו במקום:
#   ssh -t -A [email protected]
# פשוט:
#   ssh -t claude-server

ServerAliveInterval 60 שולח ping כל 60 שניות — מונע ניתוק בזמן שהסוכן עובד. ServerAliveCountMax 3 מתנתק אחרי 3 pings שלא נענו (3 דקות ללא תגובה). ForwardAgent yes מעביר את ה-SSH agent שלכם לשרת — כך שהסוכן יכול לעשות git push בלי שה-private key נמצא על השרת.

Latency: Claude Code מעל SSH מוסיף כ-10-50ms לכל tool call — זניח לחלוטין. ה-bottleneck הוא תמיד ה-API, לא ה-SSH. אתם לא תרגישו הבדל. שרת ב-Hetzner Falkenstein (גרמניה) נותן latency של כ-50-70ms מישראל — מצוין לעבודה מרחוק.

version: '3.8'
services:
  claude-pipeline:
    build: .
    environment:
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
    volumes:
      - ./src:/project/src:ro
      - ./output:/project/output
      - ./prompts:/project/prompts:ro
    deploy:
      resources:
        limits:
          memory: 4G
          cpus: '2'
    healthcheck:
      test: ["CMD", "claude", "-p", "echo ok", "--bare"]
      interval: 60s
      timeout: 30s
      retries: 3

# .env.example — DO NOT put real values here
ANTHROPIC_API_KEY=sk-ant-your-key-here
PIPELINE_OUTPUT_DIR=./output
LOG_LEVEL=info

ספקי ענן — Bedrock, Vertex, Foundry

עד עכשיו עבדנו ישירות מול ה-API של Anthropic — עם ANTHROPIC_API_KEY. זה מצוין למפתחים בודדים ולצוותים קטנים. אבל ארגונים גדולים צריכים משהו אחר: בילינג מרכזי (לא 50 API keys אישיים), data residency (הנתונים נשארים ב-AWS/GCP שלכם), compliance (SOC 2, HIPAA, GDPR), ו-אינטגרציה עם IAM (Identity and Access Management).

שלושה ספקי ענן תומכים ב-Claude Code:

Amazon Bedrock

# הגדרה חד-פעמית
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
export AWS_PROFILE=my-org-profile

# אם משתמשים ב-role:
export ANTHROPIC_MODEL='arn:aws:bedrock:us-east-1:123456789:inference-profile/my-profile'

# עכשיו claude עובד דרך AWS Bedrock
claude -p "analyze this code" --bare

Bedrock inference profiles מאפשרים לנתב לגרסאות מודל ספציפיות דרך ARN. השתמשו ב-modelOverrides ב-settings.json כדי למפות את שמות המודלים ל-ARN-ים.

Google Vertex AI

# הגדרה חד-פעמית
export CLAUDE_CODE_USE_VERTEX=1
export CLOUD_ML_REGION=us-central1
export ANTHROPIC_VERTEX_PROJECT_ID=my-gcp-project

# אם משתמשים ב-service account:
export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account.json

# עכשיו claude עובד דרך GCP Vertex AI
claude -p "review this PR" --bare

Azure AI Foundry

# הגדרה חד-פעמית
export CLAUDE_CODE_USE_FOUNDRY=1
# הגדירו Azure credentials בהתאם לתיעוד

# עכשיו claude עובד דרך Azure
claude -p "generate report" --bare

modelOverrides — מיפוי מודלים לספקי ענן

אם הארגון שלכם משתמש ב-Bedrock inference profiles עם ARN-ים מותאמים, או רוצה למפות שמות מודלים ספציפיים, השתמשו ב-modelOverrides ב-settings.json:

// .claude/settings.json
{
  "modelOverrides": {
    "opus": "arn:aws:bedrock:us-east-1:123456789:inference-profile/my-opus-profile",
    "sonnet": "arn:aws:bedrock:us-east-1:123456789:inference-profile/my-sonnet-profile"
  }
}

עכשיו כשמפתח מחליף מודל עם /model ובוחר "opus" — הוא מנותב אוטומטית ל-Bedrock ARN שהגדרתם. זה שקוף לחלוטין למפתח — הוא לא צריך לדעת שמדובר ב-Bedrock.

Enterprise — מדיניות מנוהלת וניהול ארגוני

לארגונים גדולים (50+ מפתחים), Anthropic מציעים Enterprise plan שנותן שליטה מלאה על Claude Code ברמת הארגון. זה מה שמאפשר אימוץ בטוח — לא 50 מפתחים שכל אחד עושה מה שהוא רוצה, אלא מערכת מנוהלת עם כללים, לוגים, ותקציבים.

Managed Policies — מדיניות שלא עוקפים

מנהלי מערכת מגדירים managed policies — כללים שהמשתמש לא יכול לעקוף. ה-hierarchy:

Enterprise Managed Policy   ← הגבוה ביותר, לא ניתן לעקיפה
  ↓
User Allow Rules            ← לא יכולים לעקוף managed deny
  ↓
Project Settings            ← .claude/settings.json
  ↓
Defaults                    ← ברירות מחדל של Claude Code

דוגמאות למדיניות מנוהלת:

• חובת code review לפני commit: hooks שמונעים commit ישיר — כל שינוי עובר PR
• חסימת פקודות מסוכנות: rm -rf, DROP TABLE, git push --force חסומות ברמת הארגון
• חובת MCP servers ספציפיים: כל session חייב לטעון את שרת ה-logging של הארגון
• CLAUDE.md ארגוני: קובץ CLAUDE.md שנטען אוטומטית בכל session — סטנדרטים, קונבנציות, כללי אבטחה

CLAUDE.md ארגוני — סטנדרטים מרוכזים

אחת היכולות החזקות ביותר של managed policies היא CLAUDE.md ארגוני שנטען אוטומטית בכל session של כל מפתח. דמיינו קובץ שמגדיר:

# Organizational CLAUDE.md (managed, non-overridable)
## Code Standards
- All new code MUST include unit tests (minimum 80% coverage)
- Follow ESLint config from .eslintrc.json — no exceptions
- Hebrew comments for user-facing code, English for infrastructure
- Never use `console.log` in production code — use structured logger

## Security
- Never hardcode secrets — use environment variables or vault
- All API calls MUST go through the company API gateway
- PII must be masked before logging

## Review Process
- Every change requires PR with at least one human reviewer
- Auto-generated code MUST be tagged with [AI-GENERATED] in PR description

המפתח לא יכול לעקוף את הכללים האלה — הם נטענים ברמת הארגון, מעל כל CLAUDE.md אישי או של פרויקט. זה מה שהופך אימוץ ארגוני לבטוח.

Audit Logging — לוגים לכל פעולה

כל פעולה שכל מפתח מריץ דרך Claude Code נרשמת: איזה כלי הופעל, אילו קבצים נקראו, איזו פקודה הורצה, מה היה ה-output. זה קריטי ל-compliance — אם מבקר שואל "מי שינה את הקובץ הזה ומתי" — התשובה קיימת. ב-Enterprise plan, הלוגים מרוכזים ב-dashboard אחד — מנהל הפיתוח רואה את כל הפעילות של כל הצוות.

דוגמה לרשומת audit: "User: [email protected] | Tool: Bash | Command: npm run test | Files read: 12 | Timestamp: 2026-03-24T14:32:00Z | Duration: 45s | Cost: $0.12". מידע כזה מאפשר לזהות patterns — מי משתמש הכי הרבה? על איזה פרויקטים? מה העלות הממוצעת לסשן?

SSO — חיבור למערכת ההזדהות הארגונית

במקום 50 API keys אישיים, כל מפתח מתחבר עם חשבון הארגון שלו (SAML או OIDC). בורד — החשבון מבוטל, הגישה נחסמת מייד. לא צריך לזכור לבטל API key.

ניהול עלויות

Cowork — Claude Code לצוותים לא-טכניים

Cowork (השיק בינואר 2026) הוא Claude Code בלי ה-Code. אפליקציית דסקטופ שנותנת את היכולות של Claude Code — גישה לקבצים, sub-agents, מחקר אינטרנט — אבל בלי טרמינל, בלי CLI, בלי git. מיועד לאנשים שאינם מפתחים.

מה Cowork יכול לעשות:

• פעולות על קבצים: קריאה, כתיבה, ארגון של קבצים ותיקיות
• יצירת מסמכים: Excel, PowerPoint, CSV, PDF — מקובץ נתונים גולמי למסמך מוכן
• Sub-agents: פירוק משימות מורכבות לתת-משימות שרצות במקביל
• מחקר אינטרנט: חיפוש, סיכום, השוואה

מה Cowork לא יכול לעשות:

• אין טרמינל: לא מריץ shell commands
• אין git: לא מנהל version control
• אין Docker: לא יוצר containers

דוגמאות שימוש בפועל

למה זה חשוב לפרק הזה? כי אימוץ ארגוני של Claude Code לא מוגבל למפתחים. מנהלת המוצר יכולה להשתמש ב-Cowork ליצירת specs. המעצב יכול לארגן assets. המשווקת יכולה ליצור חומרי קמפיין. כולם באותו פרויקט — המפתחים עם Claude Code CLI, שאר הצוות עם Cowork.

אימוץ ארגוני — שלב אחר שלב

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

Phase 1: Pilot (2-4 שבועות)

Phase 2: Team Adoption (1-2 חודשים)

Phase 3: Organization-Wide (2-3 חודשים)

Change Management — ניהול שינוי

שלושת החששות הנפוצים ואיך לטפל בהם:

מדדי הצלחה — איך יודעים שזה עובד?

"אנחנו משתמשים ב-Claude Code" זה לא מדד. אתם צריכים מספרים שמראים שזה שווה את ההשקעה:

Compliance ושליטה על מידע

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

Data Residency — איפה הנתונים?

כשאתם משתמשים ב-API ישיר, הנתונים עוברים לשרתי Anthropic (בדרך כלל ב-US). עם Bedrock (AWS) או Vertex (GCP), הנתונים נשארים באזור שבחרתם — EU, US-East, Asia-Pacific. זה קריטי לעמידה ב-GDPR, ולדרישות רגולטוריות ישראליות.

Data Retention — כמה זמן נשמר?

שיחות מוחזקות כ-checkpoints למשך 30 יום כברירת מחדל. בדקו את מדיניות ה-data retention העדכנית של Anthropic — היא עשויה להשתנות. ב-Enterprise plan ניתן להגדיר retention policies מותאמות.

PII Handling — מידע אישי מזהה

# ב-CLAUDE.md — הוסיפו הנחיה ברורה:
## Data Privacy
- NEVER include PII (names, emails, phone numbers, IDs) in outputs
- When processing user data, anonymize before sending to API
- Log PII incidents immediately

# ב-hooks — redaction אוטומטי:
# PreToolUse hook that strips PII patterns from prompts

Compliance Certifications

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

מעבר ל-GDPR ו-SOC 2, חברות ישראליות כפופות לחוק הגנת הפרטיות, התשמ"א-1981 ולתקנות אבטחת מידע (2017). הנקודות הרלוונטיות ל-Claude Code:

• סיווג מאגרי מידע: אם הנתונים שהסוכן מעבד כוללים מידע אישי (שמות, ת.ז., כתובות) — צריך לוודא שהמאגר רשום אצל הרשם. העברת נתונים לשרתי Anthropic ב-US עשויה להיחשב כ"העברה לחו"ל" שדורשת הסכמה מפורשת או עמידה בתנאי התקנות
• אמצעי אבטחה: התקנות מחייבות "אמצעים סבירים" להגנה על המידע. Docker isolation, firewall, encryption in transit, ו-audit logging נחשבים אמצעים סבירים
• בדיקות חדירה: תקנות אבטחת מידע ברמה גבוהה מחייבות בדיקות חדירה תקופתיות — כולל לסביבות AI

Air-Gapped Environments — סביבות מנותקות

לרמת האבטחה הגבוהה ביותר: הריצו Claude Code דרך ספק ענן (Bedrock/Vertex) בתוך VPC ללא גישה לאינטרנט. הנתונים לא יוצאים מהרשת שלכם — כל התקשורת עוברת דרך private endpoints. זה רלוונטי במיוחד לחברות ביטחוניות ופיננסיות בישראל שעובדות עם מידע מסווג.

# AWS — VPC Endpoint ל-Bedrock
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345 \
  --service-name com.amazonaws.us-east-1.bedrock-runtime \
  --vpc-endpoint-type Interface \
  --security-group-ids sg-12345

# עכשיו ה-traffic לא עובר דרך האינטרנט — הכל פנימי ב-AWS

Audit Trails — מסלול ביקורת

ב-Enterprise plan, כל פעולה נרשמת: כל tool call, כל גישה לקובץ, כל פקודת shell. אם מבקר שואל "מי גרם לשינוי הזה בקוד" — יש רשומה מלאה עם timestamp, user ID, ופרטי הפעולה.