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

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

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

הצפנת נתונים

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

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

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

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

   • Data Encryption Key (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), הצהרה על זכויות יוצרים באימייל בתוך אסימון האימות צריך להשוות אותו להצהרת האימייל באסימון ההרשאה, באמצעות method שלא תלוית-רישיות.
   • בתרחישים שבהם Google מנפיקה אסימון הרשאה עבור הודעת אימייל שלא נשלחה המשויך לחשבון Google, ההצהרה email_type חייבת להיות קיימת. התכונה הזו היא חלק חיוני בתכונה 'גישה לאורחים', והיא מספקת מידע ל-KACLS לאכיפת אמצעי אבטחה נוספים על משתמשים.
     • דוגמאות לאופן שבו KACLS יכולה להשתמש במידע הזה:
     • כדי לאכוף דרישות נוספות לרישום ביומן.
     • כדי להגביל את המנפיק של אסימון האימות ל-IdP ייעודי של אורח.
     • כדי לדרוש הצהרות נוספות באסימון האימות.
     • אם לקוח לא הגדיר גישת אורח, כל הבקשות כאשר email_type מוגדר כ-google-visitor או customer-idp יכול להיות נדחה. בקשות עם email_type של google או עם הגדרה לא מוגדרת email_type אמור להמשיך להתקבל.
   • צריך לוודא שההצהרה role באסימון ההרשאה היא "Reader" או "author".
   • צריך לוודא שההצהרה kacls_url באסימון ההרשאה תואמת כתובת ה-URL הנוכחית של ה-KACLS. כך מתאפשרת זיהוי של אדם בתווך פוטנציאלי שהוגדרו על ידי גורמים פנימיים או על ידי מנהלי דומיינים נוכלים.

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

   • Data Encryption Key (DEK)
   • הערכים resource_name ו-perimeter_id מאסימון ההרשאה
   • מידע אישי רגיש נוסף

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

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

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

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