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

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

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

הצפנת נתונים

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

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

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

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. בקשות עם הערך google בשדה email_type או עם email_type לא מוגדר ימשיכו להתקבל.
   • בודקים שההצהרה role באסימון ההרשאה היא 'reader' או 'writer'.
   • בודקים שההצהרה kacls_url באסימון ההרשאה תואמת לכתובת ה-URL הנוכחית של KACLS. כך אפשר לזהות שרתים פוטנציאליים של אדם בתווך (MitM) שהוגדרו על ידי גורמים פנימיים או על ידי מנהלי דומיינים זדוניים.

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

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

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

4. ביצוע בדיקת היקף באמצעות הצהרות אימות והרשאה.

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

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