מדריך קלאודפלייר בעברית
לאתר הראשי כל המדריכים קלוד קוד קלוד דסקטופ גרוק CLI גרוק בוט MCP קרסור וואטסאפ OpenClaw n8n בענן n8n בהתקנה עצמית

תיעוד 189

Access

הרשמה ל-RSS

#2026-11-02

ארגון והרשאה של אסימוני שירות של Access באמצעות תגיות

אפשר עכשיו להקצות תגיות מפתח-ערך לאסימוני שירות של Access ולהשתמש בתגיות האלה כדי לארגן אישורים או לשלוט בגישה ליישומים. כל אסימון תומך בעד חמש תגיות, למשל environment: production או team: payments.

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

בורר המדיניות Service Token Tag מתאים לאסימונים תקפים עם זוג מפתח-ערך מדויק. השתמשו בו במדיניות Service Auth כדי לאשר אסימונים לפי סביבה או צוות בלי לרשום כל אסימון בנפרד. לדוגמה, תצורת מדיניות ה-API הזו מקבלת אסימונים תקפים שמתויגים environment: production:

{
	"name": "Production service tokens",
	"decision": "non_identity",
	"include": [
		{
			"service_token_tag": {
				"key": "environment",
				"value": "production"
			}
		}
	]
}

להוראות הגדרה, עיינו בתיוג אסימוני שירות ובהרשאת אסימוני שירות לפי תגית.

#2026-10-30

בדיקת משתמשים וקבוצות שהוקצו באמצעות מציג אוכלוסיית SCIM

מציג אוכלוסיית SCIM מאפשר לבדוק את המשתמשים והקבוצות שכל ספק זהויות הקצה ל-Cloudflare One. אפשר לבדוק אילו משאבים Cloudflare קיבלה בלי לבצע בקשות API ובלי לפתוח פניית תמיכה.

ב-Zero Trust > Integrations > Identity providers, בחרו ספירת משתמשים או קבוצות ב-SCIM resources כדי לפתוח את המציג. אפשר:

  • לחפש משתמשים לפי שם משתמש, דוא"ל, שם או מזהה משאב, וקבוצות לפי שם או מזהה משאב.
  • לבדוק מאפייני משאב בתצוגה מעוצבת או בתצוגת JSON.
  • להציג חברי קבוצה ולהשוות מזהי משאבים של Cloudflare ושל ה-IdP עם יומני הקצאה.
  • למחוק משאבים בודדים מאוכלוסיית ה-SCIM של Cloudflare כשיש הרשאת עריכה.

טבלת משתמשי SCIM עם פקדי חיפוש ומידע אישי מטושטש

המציג מציג משאבים שהוקצו, ולא את היסטוריית אירועי ההקצאה. השתמשו ביומני הקצאת SCIM כדי לחקור בקשות שנכשלו. ביטול הקצאה קיים ב-SCIM והתנהגות המדיניות נשארים ללא שינוי.

להוראות לוח הבקרה ולדוגמאות API, עיינו בהצגת משתמשי SCIM וקבוצות.

#2026-10-28

הקצאת משתמשי SCIM של Google Workspace דרך SAML גנרי

System for Cross-domain Identity Management (SCIM) הוא תקן פתוח שמסנכרן זהויות משתמשים בין ספק זהויות לבין שירות. למידע נוסף, עיינו בהקצאת SCIM. Google Workspace משיקה פרופילי SCIM מותאמים אישית בבטא. ארגונים עם גישה ליכולת יכולים להשתמש בשירות ההקצאה המובנה של Google כדי לשלוח עדכוני משתמשים ואירועי ביטול הקצאה אל Cloudflare One.

חובה להשתמש בספק זהויות SAML גנרי ב-Cloudflare One. השילוב הייעודי של Google Workspace אינו תומך ב-SCIM. הגדירו יישום SAML ב-Google, ואז הזינו את נקודת הקצה והסוד של SCIM של Cloudflare בהגדרות ההקצאה האוטומטית של היישום. הפעילו את Enable user deprovisioning ב-Cloudflare One כדי לבטל הפעלות Access פעילות כש-Google מבטלת הקצאה של משתמש. השהיית ביטול ההקצאה שהוגדרה ב-Google עדיין חלה. תמיכה בלקוח OIDC הקיים של Google Workspace תתווסף אחרי ש-Google תוסיף תמיכה ב-OIDC + SCIM.

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

משתמשי Cloudflare One חייבים קודם לבצע אימות מול Access או לרשום מכשיר עם Cloudflare One Client לפני שעדכוני SCIM יכולים לחול. הזמינות של פרופילי SCIM מותאמים אישית תלויה בהשקת הבטא של Google.

להוראות הגדרה, עיינו בGoogle Workspace (SAML/SCIM).

#2026-10-28

סינון ניתוח קריאות כלי MCP לפי סטטוס תגובה

ניתוח קריאות כלי MCP תומך בפרמטר שאילתה response_status בנקודות הקצה של סדרות זמן ברמת החשבון, הפורטל והשרת. השתמשו ב-success, ב-error או ב-cached כדי לספור סטטוס אחד, או ב-all כדי לכלול כל סטטוס.

ברירת המחדל היא success. קודם לכן, הספירות כללו קריאות שנכשלו וקריאות שנשמרו במטמון. אם צריך את ספירות כל הסטטוסים הקודמות, הגדירו במפורש response_status=all:

GET /accounts/{account_id}/access/ai-controls/mcp/analytics/tool-calls/timeseries?response_status=all

התגובה כוללת את response_status שנבחר. ערכים לא תקפים, כולל ערך ריק, מחזירים 400.

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

#2026-10-27

התאמה מלאה של דפי Access שמוצגים למשתמשים

Cloudflare Access תומך עכשיו בתבניות HTML ו-Liquid לדפי התחברות, דחיית זהות, איסור ואישור משורת הפקודה. תבניות מותאמות אישית מאפשרות לשלוט במיתוג ובמראה של כל דף נתמך. משתני Liquid מאפשרים לספק למשתמשים הוראות מותאמות אישית או סיבה ברורה לחסימה.

צרו תבניות בלוח הבקרה של Cloudflare One, אמתו אותן בעורך, והקצו אותן ליישומים או הגדירו ברירות מחדל לחשבון.

תבניות מותאמות אישית זמינות בתוכניות Zero Trust Pay-as-you-go ו-Enterprise. הן אינן זמינות בתוכנית Zero Trust Free.

דף דחיית Access מותאם אישית שמציג בדיקות מדיניות שנכשלו והסברים לסיבת דחיית הגישה

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

#2026-10-14

הקשר חשבון בהפניות דחייה של Access

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

לדוגמה, הפניה מותאמת אישית יכולה לכלול:

https://denied.example.com/?kid=<APP_AUD>&account_id=<ACCOUNT_ID>&original_url=app.example.com%2Fadmin

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

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

#2026-10-14

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

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

הגדרת משך הפעלה בתצורת יישום תשתית

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

כשיעד תואם לכמה יישומי תשתית, חל משך ההפעלה הקצר ביותר.

למידע נוסף, עיינו במשך הפעלה.

#2026-10-02

הגדרת אימות מחמירה חדשה לאסימוני שירות של Access

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

  • אם האימות או ההרשאה נכשלים, Access תמיד מחזיר 401 או 403 במקום להפנות את הלקוח לדף ההתחברות עם 302.
  • רק מדיניות Service Auth יכולה לאשר את הבקשה. Access מתעלם ממדיניות Allow ומכל עוגיית CF_Authorization שנשלחה עם הבקשה.
  • Access אינו מחזיר עוגיית CF_Authorization ללקוח אחרי אימות מוצלח. בקשות המשך צריכות להמשיך להשתמש בכותרות אסימון שירות.
  • בקשות שנכשלו עבור אסימוני שירות מזוהים מופיעות ביומני אימות של Access.

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

ארגונים שנוצרו לפני 5 באוקטובר 2026 יכולים להגדיר את ההגדרה בלוח הבקרה או דרך ה-API.

  1. בלוח הבקרה של Cloudflare ↗︎, עברו אל Zero Trust > Access controls > Access settings. מעבר אל Access settings ↗
  2. תחת Manage service tokens, הפעילו את Strict service token authentication.
  3. בתיבת האישור, בחרו Enable.

כדי לכבות אימות אסימון שירות מחמיר, כבו את ההגדרה ובחרו Disable.

curl "https://api.cloudflare.com/client/v4/accounts/%7Baccount_id%7D/access/organizations" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"strict_service_token_auth": true
	}'

כדי לכבות אימות אסימון שירות מחמיר, הגדירו את strict_service_token_auth ל-false.

לפרטי התנהגות ותצורה, עיינו באימות אסימון שירות מחמיר.

#2026-10-01

הרשאות מפושטות לתיוג יעדים עם Access for Infrastructure

אפשר עכשיו לתייג יעדים באמצעות הרשאת אסימון ה-API Zero Trust Write בלבד. קודם לכן, תיוג יעדים דרך ה-API דרש גם את ההרשאה Zero Trust Write וגם את ההרשאה Tag Write באסימון ה-API.

השינוי חל על תיוג יעדים בשורה דרך Infrastructure Access Targets API. תיוג משאבים דרך Resource Tagging API הכללי עדיין דורש את התפקיד Tag Admin, את התפקיד Tag Write, או תפקיד שווה ערך.

למידע נוסף, עיינו בתיוג יעדים.

#2026-09-24

פורטלי שרת MCP זמינים עכשיו באופן כללי

פורטלי שרת MCP זמינים עכשיו באופן כללי לכל לקוחות Cloudflare. פורטל נותן למשתמשים נקודת קצה אחת לשרתי Model Context Protocol (MCP) מאושרים. Cloudflare Access רושם פעילות של כלים, הנחיות ומשאבים.

מאז הבטא הפתוחה, פורטלי שרת MCP הוסיפו:

כדי ליצור פורטל ולחבר לקוח MCP, עיינו בפורטלי שרת MCP.

#2026-09-23

אפשרויות אימות לספקי זהות של Google Workspace

שילובי ספק הזהות של Google Workspace כוללים עכשיו בקרי הנחיה ורמזי התחברות בהיקף מכשיר בלוח הבקרה של Cloudflare וב-API.

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

Access יכול גם לשלוח רמז התחברות שתואם לדומיין. הוא שולח את הרמז כשכתובת דוא"ל אחת מהתחברות Access קודמת באותו מכשיר תואמת לדומיין של Google Workspace.

לפרטי תצורה, עיינו באפשרויות אימות של Google Workspace.

#2026-09-22

ניהול אוטומטי של אסימוני שירות לא פעילים של Access

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

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

להוראות תצורה, עיינו בניהול אסימוני שירות לא פעילים.

#2026-09-22

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

פורטלי שרת MCP יכולים עכשיו להתחבר לשרתי MCP שזמינים רק ברשת הפרטית. הפורטל משתמש בCloudflare Gateway כדי להגיע לשמות מארח פרטיים ולכתובות IP בלי לחשוף את שרת ה-MCP לאינטרנט הציבורי.

חברו את רשת השרת אל Cloudflare באמצעות Cloudflare Tunnel, Cloudflare Mesh, או מחבר Cloudflare One אחר. הגדירו שם מארח פרטי או נתיב CIDR, ואז הפעילו את Route traffic through Cloudflare Gateway כשמוסיפים את השרת. נקודות קצה של שרת הרשאת OAuth, כמו נקודות הקצה של הרשאה ושל אסימון, חייבות להיות נגישות באינטרנט הציבורי. אם Cloudflare רושמת את לקוח ה-OAuth באופן אוטומטי דרך Dynamic Client Registration (DCR), גם נקודת הקצה של הרישום חייבת להיות נגישה באינטרנט הציבורי.

להוראות הגדרה, עיינו בחיבור שרת MCP פרטי.

#2026-09-15

Access for Infrastructure תומך כעת ביעדים מתויגים ובקריטריוני יעד לפי תגיות

Access for Infrastructure משתלב כעת עם Resource Tagging. אפשר לצרף תגיות של מפתח וערך ליעדי תשתית ולהשתמש בהן במדיניות גישה.

אפשר לנהל תגיות על יעדים ישירות בעת יצירה או עריכה של יעד, או דרך Resource Tagging API המרכזי. Cloudflare שומר על סנכרון התגיות בין שתי השיטות.

יישומי תשתית תומכים גם במודל קריטריוני יעד עם האופרטורים include, require ו-exclude. כל אופרטור יכול להתאים יעדים לפי hostname, לפי תגית, או לפי שניהם.

  • Include מתאים יעדים שיש להם אחד מהערכים שצוינו.
  • Require מתאים יעדים שיש להם את כל הערכים שצוינו.
  • Exclude דוחה יעדים שיש להם אחד מהערכים שצוינו.

בונה יישום תשתית שמציג קריטריוני יעד עם תגית כלולה, פורט 22, ו-SSH כפרוטוקול שנבחר

למידע נוסף, עיינו בהוספת יישום תשתית.

#2026-09-14

דרישת אימות מחדש עבור ספקי זהות SAML

Cloudflare Access יכול כעת לבקש אימות מחדש מספק זהות SAML בכל כניסה. הפעילו את Require reauthentication בלוח הבקרה של Cloudflare, או הגדירו את force_authn ל-true דרך ה-API. Access יגדיר אז את ForceAuthn ל-true בבקשות אימות SAML חתומות ולא חתומות.

אפשרות זו שימושית כשיישום דורש מהמשתמשים לאמת מחדש אצל ספק הזהות במקום להסתמך על סשן קיים של ספק הזהות. ערך ברירת המחדל הוא false.

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

#2026-08-26

סודות של אסימוני שירות ב-Access משתמשים בפורמט שניתן לסריקה

סודות Client Secret של אסימוני שירות ב-Cloudflare Access שנוצרו ב-26 באוגוסט 2026 או לאחר מכן משתמשים בפורמט cfast_[40 alphanumeric characters][8-character checksum]. הקידומת וסכום הביקורת מקלים על כלי סריקת סודות לזהות את פרטי הגישה האלה, עם פחות תוצאות חיוביות שגויות.

סודות קיימים של אסימוני שירות ממשיכים לעבוד ואין צורך להחליף אותם. שני הפורמטים משתמשים באותו Client ID ובאותן כותרות אימות CF-Access-Client-Id ו-CF-Access-Client-Secret.

למידע נוסף, עיינו באסימוני שירות.

#2026-08-25

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

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

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

להוראות הגדרה, עיינו בהחלפת סודות של אסימון שירות.

#2026-08-25

כיבוי זמני של אסימוני שירות ב-Access

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

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

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

#2026-08-25

פורטלי שרת MCP תומכים במפרט MCP 2026-07-28

פורטלי שרת MCP תומכים במפרט MCP ללא מצב 2026-07-28 עבור חיבורי לקוח ושרת upstream.

נקודת הקצה /mcp של הפורטל מקבלת באופן אוטומטי בקשות MCP ללא מצב 2026-07-28 ולקוחות Streamable HTTP מוקדמים יותר משנת 2025. כשהפורטל מתחבר לשרת Streamable HTTP בצד ה-upstream, הוא בודק תמיכה ב-MCP 2026-07-28 וחוזר ללחיצת היד של 2025 בעת הצורך. בחירת הפרוטוקול של הלקוח ושל ה-upstream נעשית בנפרד, כך שלקוחות ושרתים יכולים לשדרג בנפרד בלי שינויים בהגדרות הפורטל.

חיבורי SSE ממשיכים להשתמש בפרוטוקול הישן. לפרטים, עיינו בתאימות תעבורה ופרוטוקול של פורטל שרת MCP.

#2026-08-19

רשימות משאבים ב-Access תומכות כעת בתפקידים בהיקף משאב

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

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

עבור חברים עם התפקיד Cloudflare Access App Admin, רשימות המדיניות כוללות מדיניות שמצורפת ישירות ליישום הנבחר. מדיניות לשימוש חוזר מופיעה רק כשלחבר יש את התפקיד Cloudflare Access Policy Admin עבור המדיניות הזו.

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

#2026-08-14

אפשר כעת להפעיל את Access על Worker או על כל ה-Workers בבת אחת

יש כעת שתי דרכים חדשות להגן על Workers באמצעות Cloudflare Access.

הגנה על יישום בכל הדומיינים שלו בבת אחת

עד עכשיו, אם Worker היה נגיש ב-route, ב-Custom Domain ובכתובת workers.dev, היה צריך להוסיף כל אחד מהם ידנית ליישום Access ולשמור את הרשימה מסונכרנת בכל פעם שנתיבים או דומיינים השתנו.

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

הגדרת Access להגנה על Worker יחיד

הגנה על כל ה-Workers החדשים והקיימים כברירת מחדל

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

הגדרת Access לכל החשבון שמגנה על כל ה-Workers

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

הפיכת Worker לציבורי כשכל ה-Workers מוגנים

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

לאפשרויות מדיניות מתקדמות יותר, ערכו את המדיניות ב-Zero Trust ↗︎.

הגדרת מדיניות Access לשליטה במי יכול להיכנס

צפייה בכל מדיניות ה-Access של ה-Workers

אפשר לצפות בכל מדיניות ה-Access ולנהל אותה בלשונית Access במקטע Workers & Pages בלוח הבקרה.

לשונית Access שמציגה את כל מדיניות ה-Access שהוגדרה

ראו מי ניגש ל-Worker

כש-Access מופעל על ה-Worker, כל בקשה מאומתת כוללת את ctx.access. קראו ל-ctx.access.getIdentity() כדי לקבל את האימייל, השם והקבוצות של המשתמש. אין צורך באימות JWT ידני.

export default {
  async fetch(request, env, ctx) {
    if (!ctx.access) {
      return new Response("Access did not run", { status: 401 });
    }

    const identity = await ctx.access.getIdentity();
    return Response.json({ aud: ctx.access.aud, email: identity?.email });
  },
};

בדיקת Access באופן מקומי

אפשר כעת לבדוק את Cloudflare Access באופן מקומי עם wrangler dev. הוסיפו בלוק dev לקובץ wrangler.jsonc:

{
  "access": {
    "dev": {
      "aud": "my-app",
      "identity": { "email": "[email protected]" }
    }
  }
}

ה-Worker יקבל את הזהות הזו דרך ctx.access ודרך ctx.access.getIdentity(), וכך אפשר לבדוק זרימות מאומתות וזרימות לא מאומתות בלי לפרוס. הסירו את בלוק dev כדי לדמות בקשות לא מאומתות.

גישה דרך API ובאופן תכנותי

אפשר גם להגדיר את המדיניות הזו דרך Workers API במקום דרך לוח הבקרה.

#2026-08-12

MFA עצמאי תומך ב-FIDO2 עבור יישומי תשתית

יישומי תשתית תומכים באימות רב גורמי עצמאי (MFA) עם מפתחות FIDO2. אפשר לאפשר את ssh_fido2_key, את piv_key, או את שניהם בהגדרות MFA ברמת היישום וברמת המדיניות.

משתמשים רושמים מפתחות FIDO2 דרך App Launcher ומתחברים עם זהות ה-SSH שנוצרה. מפתחות FIDO2 עבור SSH נפרדים ממפתחות אבטחה WebAuthn מבוססי דפדפן וממפתחות Personal Identity Verification (PIV).

להוראות הגדרה, עיינו ברישום מפתח FIDO2 עבור יישומי תשתית ובהגדרת MFA עבור יישומי תשתית.

#2026-08-05

בקרי מודעות לזהות זמינים כעת ב-AI Gateway

AI Gateway משתלב כעת עם Cloudflare Access, ומעניק שתי יכולות חדשות:

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

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

להוראות הגדרה, עיינו ב-Cloudflare Access.

#2026-08-03

שליטה בעוגיות הרשאה עבור יישומי Access מרובי דומיינים

מנהלי Cloudflare Access יכולים כעת לשלוט אם יישום self-hosted מגדיר מראש עוגיות הרשאה בכל שמות המארח הציבוריים שלו.

בעבר Access השתמש באופן אוטומטי בהפניות eager עבור יישומים עם חמישה שמות מארח או פחות. יישומים עם יותר מחמישה שמות מארח קיבלו עוגיות כשמשתמשים ביקרו בכל שם מארח. מנהלים יכולים כעת לבחור כל אחת משתי ההתנהגויות, בלי תלות במספר שמות המארח.

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

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

כדי להגדיר את ההגדרה, עיינו בעוגיית הרשאה.

#2026-07-31

פרטי גישה סטטיים של לקוח OAuth עבור פורטלי שרת MCP

פורטלי שרת MCP יכולים כעת להתחבר לשרתי MCP בצד ה-upstream שדורשים לקוח OAuth שנרשם מראש. זה תומך בספקי OAuth שאינם מציעים Dynamic Client Registration או שהשביתו אותו. כך נפתחים חיבורי פורטל לספקי SaaS גדולים כמו Slack ו-GitHub, ששרתי ה-MCP שלהם עדיין אינם תומכים ב-DCR.

בעת הוספת שרת MCP, מנהלים יכולים להזין את מזהה הלקוח ואת סוד הלקוח מיישום OAuth שנרשם אצל ספק ה-upstream. ההגדרה תומכת גם בנקודות קצה OAuth מותאמות, ב-scopes, ובשיטות האימות של נקודת הקצה לאסימונים client_secret_post ו-client_secret_basic.

Cloudflare שומר את סוד הלקוח מוצפן. משתמשים עדיין מאמתים מול שרת ה-upstream עם החשבונות שלהם כשהם מתחברים דרך פורטל.

להוראות הגדרה, עיינו בהגדרת פרטי גישה ידניים של OAuth.

#2026-07-30

מנהלים יכולים להפעיל את Code Mode כברירת מחדל עבור משתמשי פורטל MCP

פורטלי שרת MCP תומכים כעת בארבע מדיניות Code Mode: Off, Opt-in, On by default ו-Enforced. מנהלים יכולים לבחור אם Code Mode אינו זמין, אופציונלי, מופעל כברירת מחדל, או נדרש בכל סשן.

פורטלים קיימים שומרים על ההתנהגות הנוכחית שלהם. פורטלים שאפשרו בעבר את Code Mode משתמשים ב-Opt-in, ופורטלים שלא אפשרו את Code Mode משתמשים ב-Off. גם פורטלים חדשים משתמשים ב-Opt-in כברירת מחדל.

לקוחות מפעילים את Code Mode עבור פורטל Opt-in באמצעות ?codemode=search_and_execute. מדיניות On by default מאפשרת ללקוחות לבטל את ההפעלה באמצעות ?codemode=off, וכך נמנעת הרצת קוד מקוננת כשלקוח מריץ מימוש Code Mode משלו. מדיניות Off ו-Enforced מתעלמות מעקיפות של הלקוח.

ה-API של Cloudflare חושף את המדיניות האלה דרך השדה code_mode:

{
	"code_mode": "default_on"
}

הערכים הנתמכים הם off, opt_in, default_on ו-enforced. הערך הבוליאני הקודם allow_code_mode הוצא משימוש.

לפרטי הגדרה ולהתנהגות הלקוח, עיינו במדיניות Code Mode.

#2026-07-20

כניסה מבוססת דפדפן עבור יישומים פרטיים ב-HTTP בטקסט גלוי

Cloudflare Access משתמש כעת בזרימת הכניסה הסטנדרטית מבוססת הדפדפן עבור יישומים פרטיים שמוגשים ב-HTTP בטקסט גלוי בפורט 80.

בעבר, יישומים פרטיים ב-HTTP בטקסט גלוי חזרו לאותה זרימת סשן שמשמשת את SSH, RDP ופרוטוקולים אחרים שאינם HTTP: המשתמשים קיבלו חלון קופץ Authentication required מ-Cloudflare One Client, ואז היה עליהם לבחור בהתראה כדי לפתוח דפדפן ולהיכנס. כעת, משתמשים שמגיעים ליישום פרטי ב-HTTP רואים את דף הכניסה של Access ישירות בדפדפן ומקבלים אסימון יישום סטנדרטי של Access בהצלחה.

זה מביא את חוויית ה-HTTP להתאמה עם יישומי HTTPS (כשפענוח TLS של Gateway מופעל). אין צורך בשינוי הגדרה. Cloudflare One Client עדיין נדרש כדי לנתב תעבורה לרשת הפרטית, אבל הוא כבר אינו מנהל את סשן ה-Access עבור יישומי HTTP.

פרוטוקולים אחרים שאינם HTTP (SSH, RDP, TCP/UDP שרירותי) ממשיכים להשתמש בזרימת ההתראות של Cloudflare One Client.

#2026-07-16

הדפסה מרובה של קובצי PDF ל-RDP מבוסס דפדפן

משתמשים בהפעלות RDP מבוססות דפדפן יכולים עכשיו להדפיס כמה קובצי PDF כעבודת הדפסה אחת. העתיקו את הקבצים ללוח במחשב המרוחק, ואז בחרו Print all PDFs בחלונית הלוח. הקבצים משולבים לקובץ PDF אחד ונשלחים למדפסת המקומית.

חלונית הלוח מציגה את האפשרות Print all PDFs לכמה קובצי PDF שנבחרו.

הדפסה מרובה זמינה בדפדפנים מבוססי Chromium וב-Firefox. למידע נוסף, ראו הדפסת קובצי PDF ל-RDP מבוסס דפדפן.

#2026-07-07

בקרות העברת קבצים ל-RDP מבוסס דפדפן (בטא)

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

הגדרות חיבור להעברת קבצים בתצורת מדיניות Access.

היכולת הזו שימושית לארגונים שתומכים במדיניות bring-your-own-device (BYOD) או בקבלנים מצד שלישי שמשתמשים במכשירים לא מנוהלים. הגבלת העברות קבצים מונעת העברת נתונים רגישים אל מחוץ להפעלה המרוחקת, אל המכשיר האישי של המשתמש.

#אפשרויות תצורה

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

  • Client to remote RDP session allowed: משתמשים יכולים להעלות קבצים מהמחשב המקומי אל הפעלת ה-RDP מבוססת הדפדפן.
  • Remote RDP session to client allowed: משתמשים יכולים להוריד קבצים מהפעלת ה-RDP מבוססת הדפדפן אל המחשב המקומי.
  • Both directions allowed: משתמשים יכולים להעלות ולהוריד קבצים בין המחשב המקומי להפעלת ה-RDP מבוססת הדפדפן.
  • Disable copying/pasting: משתמשים לא רשאים להעביר קבצים בין המחשב המקומי להפעלת ה-RDP מבוססת הדפדפן.

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

#איך זה עובד

כדי להעלות, גררו קבצים אל חלון הדפדפן או בחרו את סמל גלגל השיניים של ההגדרות בצד שמאל של הפעלת ה-RDP. כדי להוריד, העתיקו קובץ בהפעלה המרוחקת ובחרו את גלגל השיניים של ההגדרות כדי להוריד אותו, להוריד כמה קבצים כקובץ zip, או להדפיס קובצי PDF למדפסת מקומית.

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

היכולת הזו בבטא וזמינה בכל תוכניות Zero Trust. למידע נוסף, ראו העברת קבצים ל-RDP מבוסס דפדפן.

#2026-07-01

תיקון קידוד fragment של כתובת URL בהפניה ליישומי עמוד יחיד

Access שומר עכשיו בצורה נכונה על תווי ה-fragment בכתובת ה-URL (/, ?, =, &, ;) כשמפנים משתמשים בחזרה ליישום אחרי התחברות. בעבר התווים האלה קודדו באמצעות encodeURIComponent, וזה שיבש נתיבים מבוססי fragment שבהם משתמשים יישומי עמוד יחיד (SPA).

לדוגמה, כתובת SPA כמו https://app.example.com/#/dashboard?tab=settings&view=advanced הופנתה בעבר לכתובת שבורה אחרי ההתחברות. עכשיו זה מטופל בצורה נכונה.

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

#2026-07-01

MFA עצמאי ליישומי תשתית

Access for Infrastructure תומך עכשיו באימות רב-גורמי עצמאי (MFA) לחיבורי SSH באמצעות מפתחות YubiKey PIV. זה מוסיף גורם שני שמגובה בחומרה לגישת SSH, וכך הפעלה של מכשיר שנפרץ לא מספיקה לבדה כדי להגיע לשרתים.

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

#הרשמה

משתמשים רושמים את מפתח ה-YubiKey PIV שלהם דרך App Launcher. להוראות הרשמה ולהגדרת לקוח SSH, ראו רישום מפתח PIV ליישומי תשתית.

#תצורה

להוראות הגדרה, ראו אכיפת MFA ליישומי תשתית.

#2026-06-26

תמיכה באסימון שירות בפורטלי שרת MCP

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

כדי להגדיר זאת:

  1. הוסיפו מדיניות Service Auth שתואמת לאסימון השירות שלכם ליישום Access של הפורטל.
  2. הוסיפו מדיניות Service Auth שתואמת לאותו אסימון ליישום Access של כל שרת MCP מקושר.
  3. כבו את Require user auth (on_behalf: false) לכל שרת מקושר, כדי שהפורטל ישתמש באישור המנהל במקום בהרשאת OAuth לכל משתמש.

הבוט מתחבר עם הכותרות CF-Access-Client-Id ו-CF-Access-Client-Secret, ורואה את הכלים מכל שרת מקושר שהוא מורשה אליו. שרתים שעדיין דורשים OAuth לכל משתמש מוחרגים מהפעלות של אסימון שירות, כי אסימון שירות לא יכול להשלים הרשאת OAuth לכל משתמש.

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

#2026-06-18

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

כשיוצרים ארגון Zero Trust חדש, Cloudflare מוסיפה עכשיו את ספק הזהות של Cloudflare כשיטת ההתחברות שמוגדרת כברירת מחדל. בעבר, ארגונים חדשים התחילו עם PIN חד-פעמי (OTP).

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

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

#2026-06-04

שיתוף ספקי זהות בין חשבונות עם איחוד IdP

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

במקום להגדיר את אותו IdP (לדוגמה, Okta או Entra ID) בנפרד בכל חשבון, מגדירים אותו פעם אחת בחשבון מקור ומשתפים אותו עם שאר החשבונות בארגון. כל חשבון נמען מקבל חיבור IdP לקריאה בלבד, שמנתב את האימות בחזרה לחשבון המקור דרך גשר: יישום מוסתר בחשבון המקור שמתווך את ההתחברות בין החשבונות. משתמשי הקצה מתחברים עם פרטי ה-IdP הקיימים שלהם, ומדיניות ה-Access של כל חשבון מעריכות את הזהות שמתקבלת כמו כל התחברות IdP אחרת.

יכולות מרכזיות:

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

כדי להתחיל, ראו איחוד IdP.

#2026-06-03

הצפנת הצהרות SAML לספקי זהות

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

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

מתג הצפנת SAML בתצורת ספק הזהות

הצפנת SAML כוללת ניהול מובנה של מחזור חיי האישור:

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

כדי להתחיל, ראו הצפנת הצהרות SAML.

#2026-05-28

כינויים לכלים ולהנחיות בפורטלי שרת MCP

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

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

חלון עריכת כלי שמציג שדות שם ותיאור לכלי של שרת MCP

כלים ששונו מציגים תווית Modified ברשימת הכלים, כדי שמנהלים יראו במבט אחד אילו כלים הותאמו.

רשימת כלים מורשים שמציגה תווית modified על כלי ששמו שונה

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

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

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

למידע נוסף, ראו כינויים לכלים ולהנחיות.

#2026-05-19

Cloudflare כספק זהות ובורר חברות בחשבון

Cloudflare Access תומך עכשיו בשימוש ב-Cloudflare עצמה כספק זהות. אם מפרסמים יישום Access ובוחרים ב-Cloudflare כשיטת ההתחברות, משתמשים יכולים להתחבר עם חשבון Cloudflare הקיים שלהם, בלי קודי PIN חד-פעמיים, בלי הגדרת IdP של צד שלישי, ובלי תיבות דואר משותפות. האימות נשען על אבטחת החשבון של Cloudflare עצמה (כולל אימות רב-גורמי), ולכן ההגדרה פשוטה יותר וההתחברות מאובטחת יותר מהתחברות מבוססת OTP, ברוב תרחישי השימוש.

Cloudflare היא עכשיו ספק הזהות שמוגדר כברירת מחדל לכל חשבונות Zero Trust חדשים, במקום One-time PIN.

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

  • בורר Cloudflare Account Member: בורר מדיניות חדש, שמתאים משתמשים לפי החברות שלהם בחשבון Cloudflare. אפשר לכוון אל החשבון הנוכחי, או לציין מזהה חשבון אחר לתרחישי גישה בין חשבונות.
  • Restrict to account members: אפשרות בתצורת ספק הזהות, שמגבילה את האימות למשתמשים שהם חברים בחשבון Cloudflare.

כדי להתחיל, הוסיפו את Cloudflare כספק זהות בהגדרות Zero Trust.

#2026-05-12

דף התחברות Access מחודש

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

לפני:

צילום מסך של דף ההתחברות הקודם של Access

אחרי:

צילום מסך של דף ההתחברות המעודכן של Access

חוויית ההתחברות המעודכנת כוללת:

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

#2026-04-23

הגבלות AAGUID והתאמת AMR ל-MFA העצמאי של Access

MFA עצמאי ב-Cloudflare Access תומך עכשיו בשתי בקרות נוספות ברמת הארגון:

  • הגבלת מאמתים לפי AAGUID: הגבלת ההרשמה לקבוצה מסוימת של מאמתי WebAuthn, באמצעות ה-AAGUID ↗︎ שלהם. זה שימושי לארגונים שדורשים מפתחות אבטחה עם אימות FIPS, או חומרה שהחברה הנפיקה. מזהי AAGUID מנוהלים באמצעות סוג List חדש.
  • התאמת AMR: דילוג על בקשת ה-MFA העצמאי כשספק הזהות כבר ביצע MFA שווה ערך. Access קורא את ה-claim amr שמוגדר ב-RFC 8176 ↗︎, ומתאים ערכים נתמכים כמו hwk, otp ו-fpt לסוגי המאמתים המותרים ביישום או במדיניות. הדבר מונע מהמשתמשים להשלים MFA פעמיים כשספק הזהות שלהם כבר אוכף אותו.

כדי להתחיל, ראו MFA עצמאי.

#2026-04-17

דף בית והתנתקות עבור פורטלי שרתי MCP

פורטלי שרתי MCP מציגים דף בית כאשר משתמשים מבקרים בדומיין של הפורטל בדפדפן.

דף הבית של פורטל שרת MCP, עם סטטוס חיבור והוראות הגדרה

דף הבית מציג:

  • את שם הפורטל ואת המיתוג של הארגון
  • את כתובת ה-URL של נקודת הקצה של MCP, עם לחצן העתקה
  • הוראות חיבור לפי לקוח עבור Claude Desktop, Workers AI Playground, OpenCode, Windsurf ולקוחות MCP אחרים

משתמשים מאומתים רואים את כתובת הדוא"ל שלהם ולחצן Sign out. בחירה ב-Sign out מבטלת את כל הרשאות ה-OAuth ברמת הפורטל, מוחקת מצבי OAuth של שרתי המקור, ומפנה דרך ההתנתקות של Cloudflare Access. דף אישור מציג סיכום של ההפעלות שבוטלו.

למידע נוסף, ראו פורטלי שרתי MCP.

#2026-04-15

MFA עצמאי ליישומי Access

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

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

MFA עצמאי תומך בסוגי המאמתים הבאים:

  • יישום מאמת: סיסמאות חד פעמיות מבוססות זמן (TOTP) באמצעות יישומים כמו Google Authenticator, Microsoft Authenticator או Authy.
  • מפתח אבטחה: מפתחות אבטחה פיזיים כגון YubiKeys.
  • ביומטריה: מאמתים מובנים במכשיר, כולל Apple Touch ID, Apple Face ID ו-Windows Hello.

הערה

יישומי תשתית עדיין אינם תומכים ב-MFA עצמאי.

#רמות הגדרה

אפשר להגדיר דרישות MFA בשלוש רמות:

רמהתיאור
ארגוןאכיפת MFA כברירת מחדל לכל היישומים בחשבון.
יישוםדרישה או כיבוי של MFA ליישום מסוים.
מדיניותדרישה או כיבוי של MFA למשתמשים שתואמים למדיניות מסוימת.

הגדרות ברמות נמוכות יותר (מדיניות) גוברות על הגדרות ברמות גבוהות יותר (ארגון), ומעניקות שליטה מפורטת באכיפת MFA.

#הרשמת משתמשים

משתמשים רושמים את המאמתים שלהם דרך App Launcher. כדי לסייע בקליטה, מנהלים יכולים לשתף קישור הרשמה ישיר: <your-team-name>.cloudflareaccess.com/AddMfaDevice.

כדי להתחיל עם MFA עצמאי, ראו Independent MFA.

#2026-04-02

ניהול סשנים עבור פורטלי שרתי MCP

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

כדי לחזור לדף בחירת השרתים, בקשו מסוכן ה-AI באמצעות הנחיה כמו "take me back to the server selection page". הפורטל מגיב בכתובת הרשאה דרך MCP elicitation ↗︎, שאותה פותחים בדפדפן:

https://<subdomain>.<domain>/authorize?elicitationId=<ELICITATION_ID>

מדף בחירת השרתים אפשר:

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

משתמשים יכולים גם להפעיל או להשבית שרת ישירות בתוך השיחה, על ידי בקשה מסוכן ה-AI, לדוגמה "enable the wiki server" או "disable my Jira server".

הפורטל גם מבקש אוטומטית ממשתמשים מחוברים לאשר שרתים חדשים כאשר מנהל מוסיף אותם לפורטל. לשם כך נדרש שימוש ב-OAuth מנוהל.

למידע נוסף, ראו ניהול סשנים של הפורטל.

#2026-04-01

רענון ממשק היומנים

יומני אימות של Access ויומני פעילות של Gateway ‏(DNS, Network ו-HTTP) כוללים כעת ממשק משתמש מחודש, שמעניק יותר גמישות בצפייה ביומנים ובניתוח שלהם.

צילום מסך של ממשק היומנים החדש, עם יומני שאילתות DNS, עמודות הניתנות להתאמה ואפשרויות סינון

הממשק המעודכן כולל:

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

למידע נוסף, ראו יומני אימות של Access ויומני פעילות של Gateway.

#2026-03-26

Code Mode עבור פורטלי שרתי MCP

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

כדי לכבות אותו, ערכו את הפורטל ב-Access controls > AI controls וכבו את Code Mode תחת Basic information.

כאשר Code Mode פעיל, הפורטל חושף כלי code יחיד במקום לרשום כל כלי מכל שרת MCP במעלה הזרם. סוכן ה-AI המחובר כותב JavaScript שקורא למתודות codemode.* עם טיפוסים עבור כל כלי במעלה הזרם. הקוד שנוצר רץ בסביבת Dynamic Worker מבודדת, וכך פרטי אימות ומשתני סביבה נשארים מחוץ להקשר של המודל.

כדי להשתמש ב-Code Mode, הוסיפו ?codemode=search_and_execute לכתובת ה-URL של הפורטל בעת החיבור מלקוח MCP:

https://<subdomain>.<domain>/mcp?codemode=search_and_execute

למידע נוסף, ראו Code Mode.

#2026-03-26

אופטימיזציה של הקשר עבור פורטלי שרתי MCP

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

#minimize_tools

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

https://<subdomain>.<domain>/mcp?optimize_context=minimize_tools

#search_and_execute

מסתיר את כל הכלים במעלה הזרם וחושף רק שני כלים: query ו-execute. הכלי query מחפש ומאחזר הגדרות כלים. הכלי execute מריץ את הכלים במעלה הזרם בסביבת Dynamic Worker מבודדת. כך עלות האסימונים ההתחלתית יורדת לקבוע קטן, בלי תלות במספר הכלים הזמינים דרך הפורטל.

https://<subdomain>.<domain>/mcp?optimize_context=search_and_execute

למידע נוסף, ראו אופטימיזציה של הקשר.

#2026-03-20

OAuth מנוהל עבור Cloudflare Access

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

בעבר, לקוחות שאינם דפדפן שניסו לגשת ליישום מוגן קיבלו הפניית 302 לדף התחברות שלא יכלו להשלים. הפתרון המקובל היה cloudflared access curl, שדרש התקנת כלים נוספים.

עם OAuth מנוהל, לקוחות מקבלים במקום זאת תגובת 401 עם כותרת WWW-Authenticate שמפנה לנקודות הקצה לגילוי OAuth של Access (RFC 8414 ↗︎ ו-RFC 9728 ↗︎). הלקוח פותח את הדפדפן של משתמש הקצה בדף ההתחברות של Access. משתמש הקצה מבצע אימות מול ספק הזהות שלו, והלקוח מקבל אסימון גישה של OAuth לבקשות הבאות.

Access אוכף את אותן מדיניות כמו בהתחברות בדפדפן. שכבת ה-OAuth היא מנגנון תעבורה חדש, ולא נתיב אימות נפרד.

אפשר להפעיל OAuth מנוהל בכל יישום Access באירוח עצמי או ב-פורטל שרתי MCP. עבור יישומים קיימים ההפעלה היא opt-in, כדי לא להפריע ליישומים שמריצים שרתי OAuth משלהם ומסתמכים על כותרות WWW-Authenticate משלהם.

הערה

בפורטלי שרתי MCP, OAuth מנוהל מופעל כברירת מחדל בפורטלים חדשים. ביישומים באירוח עצמי הוא נשאר opt-in.

כדי להפעיל OAuth מנוהל, עברו אל Zero Trust > Access controls > Applications, ערכו את היישום, והפעילו את Managed OAuth תחת Advanced settings.

אפשר גם להפעיל זאת דרך ה-API על ידי הגדרת oauth_configuration.enabled ל-true ב-נקודת הקצה של יישומי Access.

הגדרות OAuth מנוהל בלוח הבקרה של Cloudflare

להוראות הגדרה, ראו הפעלת OAuth מנוהל.

#2026-03-20

ניתוב תעבורת פורטל שרתי MCP דרך Cloudflare Gateway

פורטלי שרתי MCP יכולים כעת לנתב תעבורה דרך Cloudflare Gateway לצורך תיעוד עשיר יותר של בקשות HTTP וסריקת מניעת אובדן נתונים (DLP).

כאשר ניתוב דרך Gateway מופעל, תעבורת הפורטל מופיעה ב-יומני HTTP של Gateway. אפשר ליצור מדיניות HTTP של Gateway עם פרופילי DLP כדי לזהות ולחסום נתונים רגישים שנשלחים לשרתי MCP במעלה הזרם.

הערה

פרופילי הנחיות AI של DLP אינם חלים על תעבורת פורטלי שרתי MCP.

כדי להפעיל ניתוב דרך Gateway, עברו אל Access controls > AI controls, ערכו את הפורטל, והפעילו את Route traffic through Cloudflare Gateway תחת Basic information.

ניתוב תעבורת פורטל שרתי MCP דרך Cloudflare Gateway

לפרטים נוספים, ראו ניתוב תעבורה דרך Gateway.

#2026-03-04

בורר ציון סיכון משתמש במדיניות Access

אפשר כעת להשתמש ב-ציוני סיכון משתמש ב-מדיניות Access. הבורר החדש User Risk Score מאפשר ליצור מדיניות Access שמגיבה לדפוסי התנהגות משתמשים שמערכת ניקוד הסיכון של Cloudflare מזהה, כולל נסיעה בלתי אפשרית (impossible travel), התאמות רבות למדיניות DLP, ועוד.

למידע נוסף, ראו שימוש בציוני סיכון במדיניות Access.

#2026-03-01

בקרות לוח כתיבה עבור RDP מבוסס דפדפן

אפשר כעת להגדיר בקרות לוח כתיבה עבור RDP מבוסס דפדפן עם Cloudflare Access. בקרות לוח הכתיבה מאפשרות למנהלים להגביל אם משתמשים יכולים להעתיק או להדביק טקסט בין המחשב המקומי שלהם לשרת Windows המרוחק.

הפעלת אפשרות למשתמשים להעתיק ולהדביק תוכן מהמחשב המקומי שלהם לסשני RDP מרוחקים בלוח הבקרה של Cloudflare One

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

#אפשרויות הגדרה

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

  • Copy from local client to remote RDP session: משתמשים יכולים להעתיק ולהדביק טקסט מהמחשב המקומי שלהם אל סשן ה-RDP מבוסס הדפדפן.
  • Copy from remote RDP session to local client: משתמשים יכולים להעתיק ולהדביק טקסט מסשן ה-RDP מבוסס הדפדפן אל המחשב המקומי שלהם.

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

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

למידע נוסף, ראו בקרות לוח כתיבה עבור RDP מבוסס דפדפן.

#2026-02-27

ייצוא יומני פורטל שרתי MCP עם Logpush

זמינות

זמין רק בתוכניות Enterprise.

פורטלי שרתי MCP תומכים כעת בשילוב Logpush. אפשר לייצא אוטומטית יומני פעילות של פורטל שרתי MCP ליעדי אחסון של צד שלישי או לכלי ניהול מידע ואירועי אבטחה (SIEM) לצורך ניתוח וביקורת.

#שדות יומן זמינים

מערך הנתונים של יומני פורטל שרתי MCP כולל שדות כגון:

  • Datetime: חותמת זמן של הבקשה
  • PortalID / PortalAUD: מזהי הפורטל
  • ServerID / ServerURL: פרטי שרת MCP במעלה הזרם
  • Method: שיטת JSON-RPC (לדוגמה, tools/call, prompts/get, resources/read)
  • ToolCallName / PromptGetName / ResourceReadURI: מזהים לפי השיטה
  • UserID / UserEmail: פרטי המשתמש המאומת
  • Success / Error: תוצאת הבקשה
  • ServerResponseDurationMs: זמן התגובה משרת המקור

לעיון המלא בשדות, ראו יומני פורטל MCP.

#הגדרת Logpush

כדי להגדיר Logpush עבור יומני פורטל שרתי MCP, ראו שילוב Logpush.

הערה

פורטלי שרתי MCP נמצאים כרגע בבטא.

#2026-02-17

בידוד דפדפן בלי לקוח ליישומים פרטיים, בצורה פשוטה יותר

הגדרה חדשה, Allow clientless access, מקלה על חיבור משתמשים בלי לקוח במכשיר ליישומים פנימיים, בלי שימוש ב-DNS ציבורי.

הגדרת Allow clientless access בלוח הבקרה של Cloudflare One

בעבר, כדי לספק גישה בלי לקוח לשם מארח פרטי או לכתובת IP בלי יישום שפורסם, היה צריך ליצור יישום סימניה נפרד שמפנה לכתובת URL עם קידומת של Clientless Web Isolation (לדוגמה, https://<your-teamname>.cloudflareaccess.com/browser/https://10.0.0.1/). הסימניה הזו הייתה גלויה לכל המשתמשים ב-App Launcher, בין שהייתה להם גישה ליישום הבסיסי ובין שלא.

כעת אפשר לנהל גישה בלי לקוח ישירות בתוך היישום הפרטי המתארח בעצמך. כשההגדרה Allow clientless access מופעלת, משתמשים שעומדים במדיניות יישום ה-Access שלך יראו אריח ב-App Launcher שמפנה לכתובת ה-URL עם הקידומת. כדי לפתוח את הקישור, למשתמשים חייבות להיות הרשאות דפדפן מרוחק.

#2026-02-17

מדיניות ליישומי סימניות

כעת אפשר לשייך מדיניות Access ליישומי סימניות. כך אפשר לשלוט אילו משתמשים רואים סימניה ב-App Launcher לפי זהות, מצב מכשיר וכללי מדיניות נוספים.

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

  • להתאים את ה-App Launcher לכל משתמש: משתמשים רואים רק את היישומים שיש להם גישה אליהם, וכך פוחת העומס ונמנעות לחיצות מקריות על משאבים לא רלוונטיים.
  • להגביל את הנראות של סימניות רגישות: להגביל מי יכול לראות סימניות לכלים פנימיים או למשאבי שותפים לפי חברות בקבוצה, ספק זהות או מצב מכשיר.

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

למידע נוסף, ראו Add bookmarks.

#2026-02-13

הרשאות מפורטות למדיניות Access ולאסימוני שירות

הרשאות מפורטות עבור Access policies ועבור Access service tokens זמינות. תפקידי המשאב החדשים האלה מרחיבים את מודל ה-RBAC הקיים, ומאפשרים למנהלים להעניק הרשאות בהיקף של משאבים בודדים.

#תפקידים חדשים

התפקידים האלה משלימים את התפקידים הקיימים בהיקף משאב עבור יישומי Access, ספקי זהות ויעדי תשתית.

למידע נוסף:

הערה

תפקידים בהיקף משאב נמצאים כרגע בבטא.

#2026-01-22

דרישת הגנת Access עבור zones

כעת אפשר לדרוש הגנת Cloudflare Access לכל שמות המארח בחשבון. כשהאפשרות מופעלת, תעבורה לכל שם מארח שאין לו יישום Access תואם נחסמת אוטומטית.

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

דרישת הגנת Cloudflare Access בלוח הבקרה

#איך זה עובד

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

כדי להפעיל את היכולת הזו, ראו Require Access protection.

#2026-01-22

הרשאות חדשות ומפורטות לאסימוני API עבור Cloudflare Access

שלוש הרשאות חדשות לאסימוני API זמינות עבור Cloudflare Access, ומעניקות שליטה מפורטת יותר בבניית אוטומציות ואינטגרציות:

  • Access: Organizations Revoke: מעניק את היכולת לבטל הפעלות משתמש בארגון Zero Trust. השתמשו בהרשאה הזו כשנדרש אסימון שיכול לסיים הפעלות פעילות בלי גישת כתיבה רחבה להגדרות הארגון.
  • Access: Population Read: מעניק גישת קריאה למשתמשי ולקבוצות SCIM שמסונכרנים מספק זהות אל Cloudflare Access. השתמשו בהרשאה הזו עבור אסימונים שצריכים רק לקרוא נתוני משתמשים וקבוצות מסונכרנים.
  • Access: Population Write: מעניק גישת כתיבה למשתמשי ולקבוצות SCIM שמסונכרנים מספק זהות אל Cloudflare Access. השתמשו בהרשאה הזו עבור אסימונים שצריכים ליצור או לשנות נתוני משתמשים וקבוצות מסונכרנים.

ההרשאות האלה מוגדרות ברמת החשבון, ואפשר לשלב אותן עם הרשאות Access קיימות.

לרשימה המלאה של ההרשאות הזמינות, ראו API token permissions.

#2026-01-08

יומני פעילות מנהלים של Cloudflare מתעדים יצירה של משתמשי DNS over HTTP (DoH)

יומני פעילות מנהלים של Cloudflare מתעדים כעת כל פעם שנוצר משתמש DNS over HTTP (DoH).

אפשר לצפות ביומנים האלה מתוך לוח הבקרה של Cloudflare One ↗︎, למשוך אותם דרך Cloudflare API, ולייצא אותם דרך Logpush.

#2025-11-14

יצירת רשות אישורים (CA) של SSH ב-Cloudflare Access ישירות מלוח הבקרה של Cloudflare

SSH עם Cloudflare Access for Infrastructure מאפשר להשתמש באישורי SSH קצרי חיים, כדי לבטל את ניהול מפתחות ה-SSH ולהפחית סיכוני אבטחה שקשורים למפתחות שאבדו או נגנבו.

בעבר, משתמשים היו צריכים ליצור את האישור הזה באמצעות Cloudflare API ↗︎ ישירות. בעדכון הזה אפשר ליצור ולנהל את האישור בלוח הבקרה של Cloudflare One ↗︎ מתוך העמוד Access controls > Service credentials.

נווטו אל Access controls ואז אל Service credentials כדי לראות היכן אפשר ליצור SSH CA

לפרטים נוספים, ראו Generate a Cloudflare SSH CA.

#2025-10-28

יישומי שם מארח פרטי ב-Access תומכים בכל הפורטים והפרוטוקולים

Cloudflare Access ליישומי שם מארח פרטי יכול כעת לאבטח תעבורה בכל הפורטים והפרוטוקולים.

בעבר, החלת מדיניות Zero Trust על יישומים פרטיים דרשה שהיישום ישתמש ב-HTTPS בפורט 443 ויתמוך ב-Server Name Indicator (SNI).

העדכון הזה מסיר את המגבלה הזו. כל עוד היישום נגיש דרך off-ramp של Cloudflare, אפשר כעת לאכוף את בקרות האבטחה הקריטיות, כמו כניסה יחידה (SSO), MFA, מצב מכשיר ואורכי הפעלה משתנים, על כל יישום פרטי. כך אפשר להרחיב את אבטחת Zero Trust לשירותים כמו SSH, RDP, מסדי נתונים פנימיים ויישומים אחרים שאינם HTTPS.

דוגמה ליישום פרטי בפורט שאינו 443

לדוגמה, כעת אפשר ליצור ב-Access יישום שמתארח בעצמו עבור ssh.testapp.local שרץ בפורט 22. אחר כך אפשר לבנות מדיניות שמתירה רק למהנדסים בארגון להתחבר אחרי שהם עוברים בדיקת SSO/MFA ומשתמשים במכשיר ארגוני.

היכולת הזו זמינה באופן כללי בכל התוכניות.

#2025-10-02

הרשאות מפורטות ב-Access עבור יישומים, IdP ויעדים זמינות כעת ב-Public Beta

הרשאות מפורטות עבור Access Applications, Identity Providers (IdPs), and Targets זמינות כעת ב-Public Beta. זה מרחיב את מודל ה-RBAC מעבר לתפקידים בהיקף חשבון ובהיקף zone, ומאפשר למנהלים להעניק הרשאות בהיקף של משאבים בודדים.

#מה חדש

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

הערה

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

  • Account Read Only ועוד הרשאה מפורטת עבור App, IdP או Target מסוים
  • Cloudflare Zero Trust Read Only ועוד הרשאה מפורטת עבור App, IdP או Target מסוים

למידע נוסף:

#2025-09-22

גישה מאובטחת ליעדי Remote Desktop Protocol (RDP) מהדפדפן: זמין כעת באופן כללי!

RDP מבוסס דפדפן עם Cloudflare Access זמין כעת באופן כללי לכל לקוחות Cloudflare. הוא מאפשר גישה מרחוק ומאובטחת לשרתי Windows בלי VPN ובלי לקוחות RDP.

מאז שהכרזנו על open beta, ביצענו כמה שיפורים:

  • תמיכה ביעדים עם IPv6.
  • תמיכה ב-Magic WAN וב-WARP Connector כ-on-ramps.
  • הודעות שגיאה יציבות יותר בעמוד ההתחברות, כדי לסייע אם נתקלים בבעיה.
  • תמיכה במקלדות ברחבי העולם. בין שהעבודה היומיומית היא בפורטוגזית, בסינית או בשפה שביניהן, חוויית ה-RDP מבוססת הדפדפן תיראה ותורגש בדיוק כמו שימוש בלקוח RDP שולחני.
  • טופלו כמה בעיות שונות נוספות, כולל, אך לא רק, תמיכה משופרת בחשבונות Entra ID ותמיכה בשמות משתמש עם רווחים, מרכאות ותווים מיוחדים.

כתזכורת, אלה כמה יתרונות ש-RDP מבוסס דפדפן מספק:

  • שליטה באופן שבו משתמשים מאמתים את עצמם מול משאבי RDP פנימיים באמצעות כניסה יחידה (SSO), אימות רב-גורמי (MFA) ומדיניות גישה מפורטת.
  • תיעוד מי ניגש לאילו שרתים ומתי, כדי לתמוך בדרישות תאימות רגולטורית ולקבל נראות רבה יותר במקרה של אירוע אבטחה.
  • ביטול הצורך להתקין ולנהל תוכנה במכשירי המשתמשים. נדרש רק דפדפן אינטרנט.
  • צמצום שטח התקיפה על ידי השארת שרתי ה-RDP מחוץ לאינטרנט הציבורי והגנה עליהם מפני איומים נפוצים כמו credential stuffing או מתקפות brute-force.

דוגמה ליישום Access של RDP מבוסס דפדפן

כדי להתחיל, ראו Connect to RDP in a browser.

#2025-08-26

ניהול והגבלת גישה לשרתי MCP פנימיים עם Cloudflare Access

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

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

לדוגמה, אם יש שרת MCP שמיועד לשימוש פנימי בארגון, אפשר להגדיר מדיניות Access כדי להבטיח שרק משתמשים מורשים יכולים לגשת אליו, בלי קשר ללקוח ה-MCP שבו הם משתמשים. התמיכה בשרתי MCP פנימיים שמתארחים בעצמם עובדת גם עם פורטלי שרתי MCP, ומאפשרת לספק נקודת קצה אחת של MCP עבור כמה שרתי MCP. למידע נוסף על פורטלי שרתי MCP, קראו את הפוסט בבלוג ↗︎ בבלוג של Cloudflare.

#2025-08-26

פורטלי שרתי MCP
פורטל שרת MCP

פורטל שרתי MCP מרכז כמה שרתי Model Context Protocol (MCP) בנקודת קצה אחת של HTTP. היתרונות העיקריים כוללים:

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

היכולת הזו זמינה ב-open beta לכל הלקוחות בכל התוכניות! למידע נוסף, עיינו בבלוג ↗︎ של המהדורה הזו.

#2025-08-15

תמיכה ב-SFTP עבור SSH עם Cloudflare Access for Infrastructure

SSH עם Cloudflare Access for Infrastructure תומך כעת ב-SFTP. הוא תואם ללקוחות SFTP, כגון Cyberduck.

#2025-08-14

יומני Cloudflare Access תומכים בגבול מטא-נתונים של לקוח (CMB)

יומני Cloudflare Access תומכים כעת בגבול מטא-נתונים של לקוח (CMB). אם הגדרתם את ה-CMB עבור החשבון שלכם, כל יומני Access יכבדו את התצורה הזו.

הערה

עבור לקוחות CMB באיחוד האירופי, היומנים לא יישמרו על ידי Access ויופיעו כריקים בלוח הבקרה. לקוחות CMB באיחוד האירופי צריכים להשתמש ב-Logpush כדי לשמור את יומני Access שלהם, אם רצוי.

#2025-07-01

גישת RDP מאובטחת מהדפדפן, כעת בבטא פתוחה

RDP מבוסס דפדפן עם Cloudflare Access זמין כעת בבטא פתוחה לכל לקוחות Cloudflare. הוא מאפשר גישה מאובטחת מרחוק לשרתי Windows בלי VPN ובלי לקוחות RDP.

עם RDP מבוסס דפדפן אפשר:

  • לשלוט באופן שבו משתמשים מבצעים אימות מול משאבי RDP פנימיים באמצעות כניסה יחידה (SSO), אימות רב-גורמי (MFA) ומדיניות גישה מפורטת.
  • לתעד מי ניגש לאילו שרתים ומתי כדי לתמוך בדרישות תאימות רגולטורית ולקבל נראות רבה יותר במקרה של אירוע אבטחה.
  • לבטל את הצורך להתקין ולנהל תוכנה במכשירי המשתמשים. תצטרכו רק דפדפן אינטרנט.
  • להקטין את משטח התקיפה על ידי השארת שרתי ה-RDP מחוץ לאינטרנט הציבורי והגנה עליהם מפני איומים נפוצים כמו credential stuffing או מתקפות brute-force.

דוגמה ליישום Access של RDP מבוסס דפדפן

כדי להתחיל, ראו התחברות ל-RDP בדפדפן.

#2025-06-05

לוחות בקרה של Cloudflare One Analytics ודוח Access שניתן לייצוא

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

![Cloudflare One Analytics Dashboards](~/assets/images/changelog/cloudflare-one/Analytics Dashboards.png)

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

Cloudflare One Analytics Dashboards

שתי התכונות נגישות בלוח הבקרה של Zero Trust ↗︎ של Cloudflare, ומעניקות לארגונים נראות ושליטה טובות יותר.

#2025-05-16

אנליטיקת Access חדשה בלוח הבקרה של Cloudflare One

לוח בקרה חדש של Access Analytics זמין כעת לכל לקוחות Cloudflare One. לקוחות יכולים להחיל ולשלב מסננים מרובים כדי להעמיק בפרוסות ספציפיות של מדדי Access שלהם. המסננים האלה כוללים:

  • כניסות שאושרו ונדחו
  • אירועי Access לפי סוג (SSO, Login, Logout)
  • שם יישום (Salesforce, Jira, Slack וכו')
  • ספק זהות (Okta, Google, Microsoft, onetimepin וכו')
  • משתמשים ( [email protected], [email protected], [email protected] וכו')
  • מדינות (US, CA, UK, FR, BR, CN וכו')
  • כתובת IP מקור
  • סוג יישום (self-hosted, Infrastructure, RDP וכו')

Access Analytics

כדי לגשת לסקירה החדשה, התחברו ללוח הבקרה של Zero Trust ↗︎ של Cloudflare ומצאו את Analytics בסרגל הניווט הצדדי.

#2025-04-21

בודק מדיניות Access בכמות גדולה

בודק מדיניות Access בכמות גדולה זמין כעת בלוח הבקרה של Cloudflare Zero Trust. בודק המדיניות בכמות גדולה מאפשר לדמות מדיניות Access מול כל בסיס המשתמשים שלכם לפני ואחרי פריסת שינויים. בודק המדיניות ידמה את המדיניות המוגדרת מול זהות המשתמש ומצב המכשיר שנראו לאחרונה עבור כל משתמש (אם רלוונטי).

דוגמה לבודק מדיניות

#2025-04-09

יומני הקצאת משתמשים וקבוצות SCIM ב-Cloudflare Zero Trust

הקצאת SCIM ב-Cloudflare Zero Trust כוללת כעת יומן ביקורת מלא של כל אירועי היצירה, העדכון והמחיקה מכל IdP עם SCIM מופעל. יומני SCIM תומכים בסינון לפי IdP, סוג אירוע, תוצאה ושדות רבים נוספים. זה יעזור בניפוי באגים ובשאלות על עדכוני משתמשים וקבוצות.

יומני SCIM נמצאים בלוח הבקרה של Zero Trust תחת Logs -> SCIM provisioning.

דוגמה ליומני SCIM

#2025-03-03

שדות SAML ו-OIDC חדשים והמרות SAML עבור Access for SaaS

יישומי Access for SaaS כוללים כעת אפשרויות תצורה נוספות כדי לתמוך במגוון רחב יותר של יישומי SaaS.

תוספות שדות SAML ו-OIDC

יישומי OIDC כוללים כעת:

  • סינון קבוצות באמצעות RegEx
  • מיפוי OIDC Claim מ-IdP
  • שליטה באורך החיים של אסימון OIDC
  • זרימות אימות OIDC מתקדמות, כולל זרימות hybrid ו-implicit

תוספות שדות OIDC

יישומי SAML כוללים כעת מיפוי משופר של מאפייני SAML מ-IdP.

תוספות שדות SAML

המרות SAML

זהויות SAML שנשלחות ליישומי Access ניתנות להתאמה מלאה באמצעות ביטויי JSONata. זה מאפשר למנהלים להגדיר את הצהרת הזהות המדויקת של SAML שנשלחת ליישום SaaS.

הצהרת SAML מוגדרת שנשלחת ליישום

#2025-01-15

ייצוא יומני פקודות SSH עם Access for Infrastructure באמצעות Logpush

זמינות

זמין רק בתוכניות Enterprise.

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

כדי להגדיר משימת Logpush, עיינו בשילוב Logpush.

#2024-10-01

ביטול אישורים ארוכי טווח וחיזוק אבטחת SSH עם Cloudflare Access for Infrastructure

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

SSH עם Access for Infrastructure משתמש באישורי SSH קצרי טווח מ-Cloudflare, מבטל ניהול מפתחות SSH ומפחית את סיכוני האבטחה שקשורים למפתחות שאבדו או נגנבו. הוא גם משתמש במודל פריסה נפוץ ללקוחות Cloudflare One: WARP-to-Tunnel.

SSH עם Access for Infrastructure מאפשר לכם:

  • לכתוב מדיניות מפורטת כדי לשלוט במי רשאי לגשת לשרתי ה-SSH שלכם, כולל פורטים, פרוטוקולים ומשתמשי SSH ספציפיים.
  • לנטר גישה לתשתית עם יומני Access ויומני פקודות SSH, לתמוך בתאימות רגולטורית ולספק נראות במקרה של פרצת אבטחה.
  • לשמור על זרימות העבודה של משתמשי הקצה. SSH עם Access for Infrastructure תומך בלקוחות SSH מקוריים ואינו דורש שינויים בתצורות ה-SSH של המשתמשים.

דוגמה ליישום Access של תשתית

כדי להתחיל, עיינו בSSH עם Access for Infrastructure.

#2025-02-12

מדיניות Access תומכת בסינון

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

#2025-02-11

יישומים פרטיים באירוח עצמי ומדיניות לשימוש חוזר בזמינות כללית

יישומים פרטיים באירוח עצמי ומדיניות Access לשימוש חוזר זמינים כעת באופן כללי (GA) לכל הלקוחות.

#2025-01-21

יישומי Access תומכים בשמות מארח פרטיים או בכתובות IP פרטיות ובמדיניות Access לשימוש חוזר.

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

#2025-01-15

Logpush ליומני פקודות SSH

לקוחות Enterprise יכולים כעת להשתמש ב-Logpush כדי לייצא יומני פקודות SSH עבור יעדי Access for Infrastructure.

#2024-12-04

SCIM בזמינות כללית עבור Okta ו-Microsoft Entra ID

השילובי SCIM של Cloudflare עם Okta ו-Microsoft Entra ID (לשעבר AzureAD) יצאו מבטא וזמינים כעת באופן כללי (GA) לכל הלקוחות. אפשר להשתמש בשילובים האלה עבור מדיניות Access ו-Gateway וניהול משתמשי Zero Trust. הערה: מהדורת GA זו אינה כוללת תמיכה ב-Dashboard SSO SCIM.

#2024-10-23

SSH עם Access for Infrastructure

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

#2024-08-26

הפחתת המינימום לביטול הקצאת מושבים אוטומטי לחודש אחד, במקום חודשיים.

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

#2024-06-06

שיפורי יכולת הרחבה ב-App Launcher

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

#2024-04-28

הוספת אפשרות לעקיפת CORS לשרת המקור

מנהלי Access יכולים לדחות את כל אכיפת CORS לשרת המקור שלהם עבור יישומי Access ספציפיים.

#2024-04-15

יומני ביקורת של זהות משתמש Zero Trust

כל שינויי זהות המשתמש דרך SCIM או אירועי Authentication נרשמים מול זהות הרישום של המשתמש.

#2024-02-22

תמיכת OIDC ב-Access for SaaS

אפשר להגדיר יישומי Access for SaaS עם OIDC כשיטת אימות. OIDC ו-SAML 2.0 נתמכים כעת במלואם.

#2024-02-22

WARP כמקור זהות עבור Access

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

#2023-12-20

מזהי Entity ייחודיים ב-Access for SaaS

לכל יישומי Access for SaaS החדשים יש מזהי Entity ייחודיים. זה מאפשר כמה שילובים עם אותו ספק SaaS אם נדרש. מזהה ה-Entity הייחודי כולל את תג הקהל של היישום שמצורף אליו. יישומים קיימים לא השתנו.

#2023-12-15

תמיכה במצב relay ברירת מחדל ב-Access for SaaS

מאפשר למנהלי Access להגדיר מצב relay ברירת מחדל ביישומי Access for SaaS.

#2023-09-15

App Launcher תומך בתגיות ובמסננים

מנהלי Access יכולים כעת לתייג יישומים ולאפשר למשתמשים לסנן לפי התגיות האלה ב-App Launcher.

#2023-09-15

התאמה אישית של App Launcher

מאפשר למנהלי Access להגדיר את דף App Launcher בתוך Zero Trust.

#2023-09-15

צפייה בזהויות משתמש Access פעילות בלוח הבקרה וב-API

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

#2023-09-08

טענות OIDC מותאמות אישית עבור IdP בשם

מנהלי Access יכולים כעת להוסיף טענות מותאמות אישית לספקי IdP בשם הקיימים. בעבר זה היה נעול לספק OIDC הגנרי.

#2023-08-02

הקשרי אימות של Azure AD

תמיכה בהקשרי אימות של Azure AD ישירות במדיניות Access.

#2023-06-23

דפי חסימה מותאמים אישית עבור יישומי Access

מאפשר למנהלי Access להתאים אישית את דפי החסימה ש-Access מציג למשתמשי הקצה.