מניעת גניבת קובצי Cookie באמצעות קישור לסשן (בטא)

אדמינים יכולים לשפר את האבטחה של הסשנים של המשתמשים באינטרנט באמצעות הטמעה של פרטי כניסה לסשן לפי מכשיר (DBSC). ה-DBSC נועד למנוע חטיפת סשנים, שנקראת גם גניבת קובצי Cookie.

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

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

דרישות לשימוש ב-DBSC

  • ‫Chrome ל-Windows: נכון לעכשיו, DBSC זמין רק בדפדפן Chrome למכשירי Windows.
  • אבטחת חומרה (TPM): במכשיר של המשתמש צריך להיות מודול פלטפורמה מהימנה (TPM), שהוא רכיב חומרה סטנדרטי שכבר זמין ברוב המכשירים שמופעלת בהם מערכת Windows 11. במכשיר הזה מאוחסנים באופן מאובטח המפתחות הקריפטוגרפיים שמשמשים לקישור הסשן למכשיר. בדרך כלל, המשתמשים יכולים למצוא מידע על הזמינות של TPM בהגדרות המערכת של המכשיר שלהם או במסמכים של יצרן המכשיר.
  • גרסת Chrome: המשתמש צריך להשתמש בגרסה 136 של Chrome ומעלה. פרטים נוספים זמינים במאמר בנושא עדכון Google Chrome.
  • חשבון ראשי: ההגנה על DBSC ונתוני האירועים ביומן זמינים רק לחשבון הראשי בפרופיל של דפדפן Chrome.

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

הפעלת DBSC

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

  1. במסוף Google Admin, נכנסים לתפריט ואז אבטחה ואז שליטה בגישה ובנתונים ואז בקרת סשנים ב-Google.

    כדי לעשות את זה צריך הרשאות אדמין להגדרות האבטחה.

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

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

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

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

אכיפת DBSC באמצעות בקרת גישה מבוססת-הקשר

מוגבל לאפליקציות אינטרנט למחשב ולא רלוונטי לאפליקציות לנייד או לממשקי API

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

כדי להגדיר אכיפה של DBSC:

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

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

חקירת בעיות בסשנים ובהגנה באמצעות DBSC

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

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

שלב 1: מחפשים אירועים של פעילות DBSC ביומן המשתמשים

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

כדי לבדוק אם DBSC מקשר מפתחות:

  1. במסוף Google Admin, נכנסים לתפריט ואז אבטחה ואז מרכז האבטחה ואז כלי חקירה.

    כדי לעשות את זה צריך הרשאות אדמין למרכז האבטחה.

  2. בקטע מקור נתונים, בוחרים באפשרות אירועים ביומן של משתמש.
  3. לוחצים על הוספת תנאי.
  4. בקטע מאפיין, בוחרים באפשרות אירועואזהוא כאופרטורואזקישור של מקש DBSC כאירוע.
  5. לוחצים על חיפוש.
  6. בטבלת התוצאות, בודקים את העמודה סטטוס האירוע:
    • הצלחה – ההגנה באמצעות DBSC מופעלת עבור המשתמש והסשן מוגן.
    • נכשל – הקישור של DBSC נכשל, וההגנה לא מופעלת עבור המשתמש.
    • אין תוצאות – לא נעשה ניסיון להשתמש בהגנה של DBSC בסשן של המשתמש.

כדי לבדוק אם DBSC מאמת סשנים:

  1. במסוף Google Admin, נכנסים לתפריט ואז אבטחה ואז מרכז האבטחה ואז כלי חקירה.

    כדי לעשות את זה צריך הרשאות אדמין למרכז האבטחה.

  2. לוחצים על הוספת תנאי.
  3. בקטע מאפיין, בוחרים באפשרות אירועואזהוא כאופרטורואזאימות מפתח DBSC כאירוע.
  4. לוחצים על חיפוש.
  5. בטבלת התוצאות, בודקים את העמודה סטטוס האירוע:
    • הצלחה – קובץ ה-Cookie אומת בהצלחה.
    • נכשל – אימות ה-DBSC נכשל. לוחצים על הסטטוס כדי לקבל מידע נוסף, כמו קוד שגיאה.

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

שלב 2: בדיקה אם יש דחיות גישה באירועים ביומן של Access Evaluation

אפשר להשתמש במקור הנתונים הזה כדי לבדוק אם נדחתה הגישה לקובץ Cookie של משתמש.

  1. במסוף Google Admin, נכנסים לתפריט ואז אבטחה ואז מרכז האבטחה ואז כלי חקירה.

    כדי לעשות את זה צריך הרשאות אדמין למרכז האבטחה.

  2. בקטע מקור נתונים, בוחרים באפשרות אירועים ביומן של הערכת גישה.
  3. לוחצים על הוספת תנאי.
  4. בקטע מאפיין, בוחרים באפשרות אירועואזהוא כאופרטורואזדחיית בקשה לאימות קובץ Cookie כאירוע.
  5. לוחצים על חיפוש.
  6. בטבלת התוצאות, לוחצים על נדחה בעמודה סטטוס האירוע או על הקישור בעמודה תיאור כדי לפתוח חלונית צד שבה אפשר לבדוק את סיבות הכישלון הבאות:
    • DBSC_BOUND_COOKIE_MISSING
    • DBSC_BOUND_COOKIE_CORRUPTED
    • DBSC_BOUND_COOKIE_EXPIRED

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

שלב 3: בודקים אם הפרעות בסשן נגרמות על ידי DBSC

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

הנקודות הבאות יעזרו לכם לזהות פעילות שקשורה ל-DBSC:

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


‫Google‏, Google Workspace וסימנים וסמלי לוגו קשורים הם סימנים מסחריים של Google LLC. כל שמות החברות והמוצרים האחרים הם סימנים מסחריים של החברות שאליהן הם משויכים.