# Cloudflare Access for Workers: איך לסגור את האפליקציות שהסוכן פרסם לכם, בקליק אחד

> המדריך הזה מראה בדיוק איך סוגרים את זה, כולל האפליקציות שכבר פרסמתם. ב-14 באוגוסט 2026 Cloudflare השיקו יכולת חדשה: אפשר להצמיד מדיניות Access ישירות ל-Worker עצמו, ולא לכתובת ספציפית.

מאת קווין ליאקס. פורסם 2026-08-15. נושא: אבטחה ופרטיות.
העמוד המלא: https://kevinliaks.ai/guides/cloudflare-access-workers

## למה המדריך הזה קיים

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

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

**המדריך הזה מראה בדיוק איך סוגרים את זה, כולל האפליקציות שכבר פרסמתם.**

## קצת מספרים שממחישים את הבעיה

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

## מה זה Cloudflare Access for Workers

ב-14 באוגוסט 2026 Cloudflare השיקו יכולת חדשה: אפשר להצמיד מדיניות Access ישירות ל-Worker עצמו, ולא לכתובת ספציפית.

ההבדל הזה הוא כל הסיפור. בעבר הייתם צריכים להגן על כל דומיין בנפרד, ואם הסוכן יצר כתובת חדשה, היא נשארה פתוחה. עכשיו ההגנה נוסעת עם האפליקציה: כל דומיין מותאם, כל route, כתובת ה-workers.dev, וגם כתובות התצוגה המקדימה שנוצרות בכל פריסה.

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

## מה בדיוק מוגן

| סוג הכתובת | מה קורה אחרי הפעלת Access |
|---|---|
| **workers.dev** | דורש התחברות. זו הכתובת שהסוכן בדרך כלל נותן לכם. |
| **Custom Domain** | דורש התחברות, גם אם תחליפו דומיין בהמשך. |
| **Routes** | כל ה-routes שמצביעים על ה-Worker מכוסים אוטומטית. |
| **Preview URLs** | הכתובות הזמניות שנוצרות בכל פריסה, הנקודה שהכי הרבה אנשים שוכחים. |

## שלוש דרכים להפעיל את זה

### 1. ברמת החשבון: הכי מומלץ

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

- נכנסים לדשבורד של Cloudflare.
- עוברים ל-Workers & Pages ומשם ללשונית Access.
- מפעילים את ברירת המחדל שמגנה על כל ה-Workers בחשבון.
- בוחרים מי מורשה להיכנס: בדרך כלל כתובת המייל שלכם, או הדומיין של החברה.

### 2. על Worker בודד

נכנסים ל-Worker הספציפי, ללשונית Access שלו, ומפעילים. ההגנה נצמדת ל-Worker עצמו ומכסה את כל הכתובות שלו.

### 3. רק על התצוגות המקדימות

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

## הפרומפט לסוכן

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

```
Configure an account-level Cloudflare Access policy that blocks
access to all of my Workers - existing and future ones -
except for my own email address.
```

ובעברית, אם הסוכן שלכם עובד בעברית:

**"תגדיר מדיניות Access ברמת החשבון שחוסמת כניסה לכל ה-Workers שלי, קיימים ועתידיים, חוץ מהמייל שלי."**

## לקרוא את זהות המשתמש בקוד

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

```bash
export default {
  async fetch(request, env, ctx) {
    const identity = await ctx.access.getIdentity();
    // identity.email, identity.name, identity.groups
    return new Response(`Hello ${identity.email}`);
  }
};
```

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

## לבדוק מקומית לפני שפורסים

כדי שהקוד לא ייפול בפיתוח, אפשר להגדיר משתמש מדומה בקובץ ההגדרות:

```json
{
  "access": {
    "dev": {
      "aud": "my-app",
      "identity": { "email": "admin@example.com" }
    }
  }
}
```

שמים את זה ב-wrangler.jsonc. בפיתוח מקומי תקבלו את המשתמש הזה, ובייצור את המשתמש האמיתי שהתחבר.

## איך בודקים שזה באמת סגור

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

## טיפים

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

## מגבלות שכדאי להכיר

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

## לינקים

- ההכרזה הרשמית בבלוג של Cloudflare: [blog.cloudflare.com/workers-protected-by-access](https://blog.cloudflare.com/workers-protected-by-access/)
- היומן הרשמי של השינוי: [developers.cloudflare.com/changelog](https://developers.cloudflare.com/changelog/post/2026-08-14-workers-access/)
- תיעוד כתובות התצוגה המקדימה: [developers.cloudflare.com/workers/preview-urls](https://developers.cloudflare.com/workers/versions-and-deployments/preview-urls/)

---
קווין ליאקס מעביר סדנאות AI, הרצאות והטמעה לארגונים: https://kevinliaks.ai/workshops