הצפנה ופענוח של נתונים

במדריך הזה מוסבר איך פועלים הצפנה ופענוח באמצעות Google Workspace (API להצפנה מצד הלקוח) ב-Google Workspace.

צריך להוסיף לרשימת ההיתרים כל שירות של ספק זהויות (IdP) שמשמש משתמשים שמשתפים קבצים מוצפנים. בדרך כלל אפשר למצוא את פרטי ה-IdP הנדרשים בקובץ ה- .well-known שזמין. אם לא, צריך לפנות לאדמין של הארגון ב-Google Workspace כדי לקבל את פרטי ה-IdP שלו.

הצפנת נתונים

כשמשתמש ב-Google Workspace מבקש לשמור או לאחסן נתונים עם הצפנה מצד הלקוח (CSE), מערכת Google Workspace שולחת בקשה מסוג wrap לכתובת ה-URL של נקודת הקצה ב-KACLS לצורך הצפנה. נוסף לבדיקות אבטחה אופציונליות, כמו בדיקות היקפיות ובדיקות JWT שמבוססות על הצהרה על זכויות יוצרים, בכל ה-KACLS צריך לבצע את השלבים הבאים:

  1. מאמתים את המשתמש ששלח את הבקשה.

    • מאמתים את אסימון האימות ואת אסימון ההרשאה.
    • חשוב לוודא שאסימוני ההרשאה ואסימוני האימות מיועדים לאותו משתמש, על ידי ביצוע התאמה לא תלוית-רישיות בהצהרות באימייל.
    • אם אסימון האימות מכיל את הצהרת google_email האופציונלית, צריך להשוות אותו להצהרת האימייל באסימון ההרשאה בגישה לא תלוית-רישיות. אין להשתמש בהצהרת האימייל באסימון האימות לצורך ההשוואה הזו.
    • במקרים שבהם באסימון האימות לא הצהרת google_email האופציונלית, צריך להשוות בין הצהרת האימייל באסימון האימות לבין הצהרת האימייל באסימון האימות, באמצעות שיטה שאינה תלוית-רישיות.
    • במקרים שבהם Google מנפיקה אסימון הרשאה לאימייל שלא משויך לחשבון Google, הצהרת email_type חייבת להיות קיימת. זה חלק חיוני מהתכונה 'גישת אורחים', שמספק מידע חשוב ל-KACLS לאכיפת אמצעי אבטחה נוספים על משתמשים חיצוניים.
      • דוגמאות לאופן שבו רשימות KACLS יכולות להשתמש במידע הזה:
      • לכפות דרישות נוספות לרישום ביומן.
      • כדי להגביל את מנפיק אסימון האימות ל-IdP ייעודי לאורח.
      • כדי לדרוש הצהרות נוספות על זכויות יוצרים באסימון האימות.
      • אם הלקוח לא הגדיר גישת אורח, ניתן לדחות את כל הבקשות שבהן המדיניות email_type מוגדרת לערך google-visitor או לערך customer-idp. אפשר להמשיך לאשר בקשות עם הערך email_type של google או עם ערך email_type לא מוגדר.
    • בודקים שהצהרת role באסימון ההרשאה היא 'writer' או 'upgrader'.
    • צריך לוודא שההצהרה kacls_url באסימון ההרשאה תואמת לכתובת ה-URL הנוכחית של ה-KACLS. הבדיקה הזו מאפשרת לזהות שרתים פוטנציאליים מסוג אדם בתווך שהוגדרו על ידי גורמים מבפנים או מנהלי דומיינים בעייתיים.
    • מבצעים בדיקה היקפית גם באמצעות הצהרות אימות וגם באמצעות הצהרות הרשאה.

  2. יש להצפין את החלקים הבאים באמצעות אלגוריתם הצפנה מאומת:

    • מפתח להצפנת נתונים (DEK)
    • הערכים resource_name ו-perimeter_id מאסימון ההרשאה
    • מידע אישי רגיש נוסף

  3. מתעדים את הפעולה, כולל המשתמש שיצר אותה, ה-resource_name והסיבה שהועברה בבקשה.

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

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

פענוח הנתונים

כשמשתמש ב-Google Workspace מבקש לפתוח נתונים עם הצפנה מצד הלקוח (CSE), מערכת Google Workspace שולחת בקשת unwrap לכתובת ה-URL של נקודת הקצה ב-KACLS לצורך פענוח. נוסף לבדיקות אבטחה אופציונליות, כמו בדיקות היקפיות ובדיקות JWT שמבוססות על הצהרה על זכויות יוצרים, צריך לבצע את השלבים הבאים במאגרי ה-KACLS:

  1. מאמתים את המשתמש ששלח את הבקשה.

    • מאמתים את אסימון האימות ואת אסימון ההרשאה.
    • חשוב לוודא שאסימוני ההרשאה ואסימוני האימות מיועדים לאותו משתמש, על ידי ביצוע התאמה לא תלוית-רישיות בהצהרות באימייל.
    • אם אסימון האימות מכיל את הצהרת google_email האופציונלית, צריך להשוות אותו להצהרת האימייל באסימון ההרשאה בגישה לא תלוית-רישיות. אין להשתמש בהצהרת האימייל באסימון האימות לצורך ההשוואה הזו.
    • במקרים שבהם באסימון האימות לא הצהרת google_email האופציונלית, צריך להשוות בין הצהרת האימייל באסימון האימות לבין הצהרת האימייל באסימון האימות, באמצעות שיטה שאינה תלוית-רישיות.
    • במקרים שבהם Google מנפיקה אסימון הרשאה לאימייל שלא משויך לחשבון Google, הצהרת email_type חייבת להיות קיימת. זה חלק חיוני מהתכונה 'גישת אורחים', שמספק מידע חשוב ל-KACLS לאכיפת אמצעי אבטחה נוספים על משתמשים חיצוניים.
      • דוגמאות לאופן שבו רשימות KACLS יכולות להשתמש במידע הזה:
      • לכפות דרישות נוספות לרישום ביומן.
      • כדי להגביל את מנפיק אסימון האימות ל-IdP ייעודי לאורח.
      • כדי לדרוש הצהרות נוספות על זכויות יוצרים באסימון האימות.
      • אם הלקוח לא הגדיר גישת אורח, ניתן לדחות את כל הבקשות שבהן המדיניות email_type מוגדרת לערך google-visitor או לערך customer-idp. אפשר להמשיך לאשר בקשות עם הערך email_type של google או עם ערך email_type לא מוגדר.
    • מוודאים שהצהרת role באסימון ההרשאה היא 'Reader' או 'writer'.
    • צריך לוודא שההצהרה kacls_url באסימון ההרשאה תואמת לכתובת ה-URL הנוכחית של ה-KACLS. כך מתאפשר זיהוי של שרתים פוטנציאליים מסוג אדם בתווך שהוגדרו על ידי גורמים מבפנים או מנהלי דומיינים זדוניים.

  2. פענח את החלקים הבאים באמצעות אלגוריתם הצפנה מאומת:

    • מפתח להצפנת נתונים (DEK)
    • הערכים resource_name ו-perimeter_id מאסימון ההרשאה
    • מידע אישי רגיש נוסף

  3. צריך לוודא שה-resource_name באסימון ההרשאה וב-blob מפוענח תואמים.

  4. ביצוע בדיקה היקפית באמצעות הצהרות על אימות וגם באמצעות הצהרות הרשאה.

  5. מתעדים את הפעולה, כולל המשתמש שיצר אותה, ה-resource_name והסיבה שהועברה בבקשה.

  6. מחזירים את ה-DEK שהאריזה שלו נפתחה או תשובה על שגיאה מובנית.