חדשות אימות · המקורות נבדקו ב־7 בנובמבר 2026
כניסה מוצלחת היא רק חלק מהטמעה בטוחה של בקרת גישה. כאשר שיטת כניסה חדשה משנה את פרטי הזהות שמגיעים למדיניות היישום, הבדיקה החשובה היא האם האנשים הנכונים עדיין נכנסים, וכל היתר נשארים בחוץ.
מה השתנה ב־Cloudflare Access?
ההכרזה של Cloudflare מ־6 בנובמבר מוסיפה כניסה במפתחות גישה ליישומים המוגנים ב־Access ול־App Launcher. מפתח שנשמר במכשיר, במפתח אבטחה או במנהל סיסמאות יכול להחליף את ההקלדה החוזרת של קוד חד־פעמי. לפני הרישום המשתמש מאמת את זהותו בשיטת כניסה קיימת, ומנהלי המערכת קובעים אילו יישומים יקבלו את השיטה החדשה.
לצוות קטן שמגן על כלי פנימי, השינוי עשוי לפשט כניסות חוזרות. שאלת ההטמעה החשובה היא מה קורה לפני שקיים מפתח ראשון, אחרי שהוא אובד וכאשר תפקיד המשתמש משתנה. המאמר מציע תוכנית בדיקה, ואינו מדווח על ניסוי מעשי שביצענו בתכונה.
שימו לב לפער במידע על קבוצות
תיעוד מפתחות הגישה מציין שהאימות אינו מביא קבוצות או מאפיינים מותאמים מספק זהות אחר. כאשר מפתחות גישה הם שיטת הכניסה היחידה ליישום, הרישום משתמש בקוד אימות בדוא״ל. הסרת כפתורי הכניסה האחרים אינה מסירה אפוא את הדוא״ל ממסלול הרישום הזה.
נבחן לוח תמיכה דמיוני שמיועד לצוות התמיכה בלבד. לפני השינוי, כניסה ארגונית מוצלחת ומאפיין הקבוצה המתאים היו חלק מהבדיקה. פיילוט של מפתחות גישה צריך לכלול עובד תמיכה, עובד שאינו בצוות, עובד שעזב את הצוות וזהות בדיקה חיצונית. כתבו מראש מה אמור לקרות לכל אחד מהם. מסך כניסה נוח אינו ראיה לכך שארבע ההחלטות נכונות.
בזמן בירור כשל בפיילוט, שמרו על מדיניות מצומצמת. החלפת דרישת קבוצה בכלל שמתיר לכל כתובות הדוא״ל של הארגון עשויה לפתור כניסה של משתמש בדיקה, אבל משנה את קהל היעד. זהו שינוי נפרד בתכנון ההרשאות, שדורש בעל תפקיד אחראי, ולא קיצור דרך לפתרון תקלה.
בדקו את הלוגיקה של המדיניות
תיעוד מדיניות Access מפריד בין פעולות, סוגי כללים ותנאי בדיקה. כמה תנאי Include הם חלופות; כל תנאי Require חייבים להתקיים; התאמה ל־Exclude מונעת גישה. ברירת המחדל היא דחייה. בדקו את מכלול המדיניות ואת סדר הכללים, ולא רק את אפשרות הכניסה החדשה.
הכינו רשימה קצרה לכל יישום: משתמשים מיועדים, שיטות כניסה מותרות, מאפייני זהות נדרשים, דרישות מהמכשיר, אחראי למדיניות ואיש קשר לשחזור. לפני הוספת ספק זהות, סמנו לבדיקה מפורשת יישומים שמקבלים את כל הספקים הזמינים. בכל מקרה ניסוי תעדו את שיטת הכניסה, החלטת המדיניות והאם היישום המוגן נפתח בפועל. השתמשו בזהויות דמה ובתוכן בדיקה שאינו רגיש.
הסרת מפתח וביטול הפעלה הם שני דברים שונים
מדריך מפתחות הגישה של Cloudflare מבחין בין חסימת כניסות עתידיות באמצעות מפתח שנמחק לבין סיום הפעלות Access פעילות. תיעוד ניהול ההפעלות מתאר ביטול לפי משתמש או יישום, ומזהיר שזהות שעדיין רשאית להיכנס יכולה ליצור הפעלה חדשה.
כתבו את נוהל אובדן המכשיר סביב שלוש שאלות: איזה מפתח חייב להפסיק לעבוד, אילו הפעלות קיימות חייבות להסתיים ואילו דרכי אימות אחרות נשארות זמינות? עזיבת עובד מוסיפה שאלה רביעית: מה מונע ממנו להירשם או להיכנס מחדש? שייכו כל בדיקה לתפקיד תפעולי ברור. פעולת מחיקה מוצלחת אחת אינה עונה על כל השאלות.
פיילוט מוגבל עם תנאי סיום ברורים
- בחרו יישום אחד בסיכון נמוך. הסכימו על קהל היעד והשאירו את מסלול השחזור הנתמך הקיים זמין במהלך הפיילוט.
- בדקו רישום ראשוני וכניסה חוזרת בנפרד. כללו פרופיל דפדפן חדש, מכשירים שבאמת נמצאים בשימוש ותרחיש שבו אמצעי האימות אינו זמין. ציינו אילו שלבים דורשים דוא״ל או עזרה מתמיכה.
- בדקו זהויות מותרות ואסורות. כללו שינוי תפקיד מכוון. השוו את התוצאות לציפיות הכתובות, במקום לסמן כל כניסה מוצלחת כהצלחה.
- תרגלו שחזור עם חשבון בדיקה. בדקו בנפרד כניסה חדשה והפעלה שכבר פתוחה. מדדו את זמן הטיפול וזהו מי יכול לבצע אותו גם מחוץ לשעות התמיכה הרגילות.
- קבעו מראש מתי מרחיבים. הרחיבו רק לאחר שהודגמו החלטות ההרשאה הצפויות, השחזור והוראות המשתמש. כשמקרה נכשל, עצרו את ההרחבה ותקנו את התצורה בלי להרחיב את הקהל רק כדי לעבור את הבדיקה.
התוצר הוא דף ראיות קטן: היישום, הזהויות שנבדקו, מסלולי הכניסה, ההחלטות, תוצאת השחזור, מגבלות ידועות ואחראי. כך המנהל הבא מקבל משהו שימושי יותר מהודעה ש״מפתחות גישה הופעלו״.