מדריך קלאודפלייר בעברית

תיעוד 58

עוגיית הרשאה

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

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

#אסימוני JWT של Access

עוגיית CF_Authorization מכילה את זהות המשתמש בצורת JSON Web Token (JWT). Cloudflare יוצרת את האסימונים האלה באופן מאובטח דרך שילוב OAUTH או SAML בין Cloudflare Access לבין ספק הזהויות שהוגדר.

Access יוצרת שני אסימוני CF_Authorization נפרדים, בהתאם לדומיין:

  • אסימון הפעלה גלובלי: נוצר כשמשתמש מתחבר ל-Access. האסימון נשמר כעוגייה בדומיין הצוות שלכם (לדוגמה, https://<your-team-name>.cloudflareaccess.com) ומונע מהמשתמש את הצורך להתחבר לכל יישום בנפרד.
  • אסימון יישום: נוצר לכל יישום שהמשתמש מגיע אליו. האסימון נשמר כעוגייה בדומיין המוגן (לדוגמה, https://jira.site.com) ואפשר להשתמש בו לאימות בקשות ב-origin שלכם.

#יישומים עם כמה דומיינים

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

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

השתמשו בהגדרת Eager redirect cookie כדי לשלוט בהתנהגות הזו.

הערה

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

#עוגיות Access

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

#CF_Authorization (דומיין צוות)

פרטיםתפוגהHttpOnlySameSiteחובה?
JSON Web Token (JWT) שמוגדר בדומיין הצוות של cloudflareaccess.com, מכיל את זהות המשתמש ומאפשר ל-Access לבצע כניסה יחידה (SSO)אם הוגדר, עוקב אחרי משך ההפעלה הגלובלי. אם לא, עוקב אחרי משך ההפעלה של היישום. אם אף אחד מהם לא הוגדר, ברירת המחדל היא 24 שעות.כןNoneחובה

#CF_Authorization (דומיין יישום Access)

פרטיםתפוגהHttpOnlySameSiteחובה?
JSON Web Token (JWT) שמוגדר בדומיין המוגן על ידי Access, ומאפשר ל-Access לאשר שהמשתמש אומת ושיש לו הרשאה להגיע ל-originאם הוגדר, עוקב אחרי משך ההפעלה של המדיניות. אם לא, עוקב אחרי משך ההפעלה של היישום. אם אף אחד מהם לא הוגדר, ברירת המחדל היא 24 שעות.בחירת מנהל (ברירת מחדל: None)בחירת מנהל (ברירת מחדל: None)חובה

#CF_Binding

פרטיםתפוגהHttpOnlySameSiteחובה?
ראו Binding cookieאם הוגדר, עוקב אחרי משך ההפעלה של המדיניות. אם לא, עוקב אחרי משך ההפעלה של היישום. אם אף אחד מהם לא הוגדר, ברירת המחדל היא 24 שעות.כןNoneאופציונלית

#CF_Session

פרטיםתפוגהHttpOnlySameSiteחובה?
אסימון CSRF שמשמש בדומיין הצוות של cloudflareaccess.com4 שעותכןNoneחובה

#CF_AppSession

פרטיםתפוגהHttpOnlySameSiteחובה?
אסימון CSRF שמשמש לכל דומיין יישום, ומוגבל ליישומים בודדים מאחורי Access24 שעותכןNoneחובה

#CF_Device

פרטיםתפוגהHttpOnlySameSiteחובה?
עוגייה שמוגדרת בדומיין הצוות של cloudflareaccess.com, ומשמשת למניעת ניצול לרעה של תהליכי one-time PIN ואימות רב-שלבי30 ימיםכןStrictחובה

#הגדרות עוגיות

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

כדי להפעיל את ההגדרות האלה:

  1. בלוח הבקרה של Cloudflare, היכנסו אל Zero Trust > Access controls > Applications.
  2. אתרו את היישום שברצונכם להגדיר ובחרו Configure.
  3. בחרו Advanced settings וגללו אל Cookie settings.
  4. הגדירו את הגדרות העוגיות הרצויות.
  5. בחרו Save.

#SameSite Attribute

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

אפשרויות הבורר הן:

  • None: העוגיות יישלחו בכל ההקשרים, כולל בקשות cross-origin.
  • Lax: מותר לשלוח עוגיות בניווטים ברמה העליונה, והן יישלחו גם עם בקשות GET שיוזמים אתרים של צד שלישי.
  • Strict: העוגיות יישלחו רק בהקשר של צד ראשון, ולא יישלחו עם בקשות שיוזמים אתרים של צד שלישי.

למידע נוסף ראו את תיעוד Mozilla.

זהירות

אם אתם מקבלים שגיאות ERR_TOO_MANY_REDIRECTS, ודאו שההגדרה SameSite היא None או Lax. הגדרת SameSite ל-Strict עלולה לגרום להפניות מחדש רבות מדי.

#מתי לא להשתמש ב-SameSite

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

#HttpOnly

הדגל HttpOnly הוא מאפיין עוגייה שמונע גישה לעוגייה מכל סקריפט בצד הלקוח, ומפחית את הסיכוי להתקפות Cross-Site Scripting (XSS). הדגל הזה מופעל כברירת מחדל.

#מתי לא להשתמש ב-HttpOnly

אל תפעילו HttpOnly אם:

  • אתם משתמשים ביישום Access לכלים שאינם מבוססי דפדפן (כמו SSH או RDP).
  • יש לכם תוכנה שמסתמכת על יכולת לגשת לעוגיית המשתמש ש-Access יוצרת.

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

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

אל תפעילו Binding Cookie אם:

מאפיין Cookie Path מוסיף את נתיב ה-URL של היישום לעוגיית CF_Authorization. כשהוא מופעל, משתמש שהתחבר אל example.com/path1 חייב להזדהות מחדש כדי לגשת אל example.com/path2. כשהוא כבוי, עוגיית CF_Authorization מוגבלת רק לדומיין ולתת-הדומיין.

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

זהירות

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

#הפעלת עוגיות צד שלישי בדפדפן

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

כדי להפעיל עוגיות צד שלישי ליישום Access:

#Chrome

  1. היכנסו אל הגדרות > פרטיות ואבטחה > עוגיות ונתוני אתרים אחרים.
  2. תחת אתרים שיכולים תמיד להשתמש בעוגיות, הוסיפו את כתובות ה-URL הבאות:
    • שם המארח של יישום Access (לדוגמה, https://jira.site.com)
    • https://<your-team-name>.cloudflareaccess.com

#Safari

  1. היכנסו אל Safari > הגדרות > פרטיות.
  2. בטלו את הסימון של חסימת כל העוגיות.

#Firefox

  1. היכנסו אל הגדרות > פרטיות ואבטחה.
  2. גללו אל עוגיות ונתוני אתרים.
  3. בחרו ניהול חריגות.
  4. הזינו את כתובת ה-URL של יישום Access (לדוגמה, https://jira.site.com) ובחרו אפשר.
  5. הזינו https://<your-team-name>.cloudflareaccess.com ובחרו אפשר.
  6. בחרו שמירת שינויים.

#Brave

  1. היכנסו אל brave://settings/cookies.
  2. תחת אתרים שיכולים תמיד להשתמש בעוגיות, הוסיפו את כתובות ה-URL הבאות:
    • שם המארח של יישום Access (לדוגמה, https://jira.site.com)
    • https://<your-team-name>.cloudflareaccess.com