במדריך הזה מוסבר איך פועלים הצפנה ופענוח באמצעות Google Workspace (API להצפנה מצד הלקוח) ב-Google Workspace.
צריך להוסיף לרשימת ההיתרים כל שירות של ספק זהויות (IdP) שמשמש משתמשים שמשתפים קבצים מוצפנים. בדרך כלל אפשר למצוא את פרטי ה-IdP הנדרשים בקובץ ה- .well-known שזמין. אם לא, צריך לפנות לאדמין של הארגון ב-Google Workspace כדי לקבל את פרטי ה-IdP שלו.
הצפנת נתונים
כשמשתמש ב-Google Workspace מבקש לשמור או לאחסן נתונים עם הצפנה מצד הלקוח (CSE), מערכת Google Workspace שולחת בקשה מסוג wrap
לכתובת ה-URL של נקודת הקצה ב-KACLS לצורך הצפנה. נוסף לבדיקות אבטחה אופציונליות, כמו בדיקות היקפיות ובדיקות JWT שמבוססות על הצהרה על זכויות יוצרים, בכל ה-KACLS צריך לבצע את השלבים הבאים:
מאמתים את המשתמש ששלח את הבקשה.
- מאמתים את אסימון האימות ואת אסימון ההרשאה.
- חשוב לוודא שאסימוני ההרשאה ואסימוני האימות מיועדים לאותו משתמש, על ידי ביצוע התאמה לא תלוית-רישיות בהצהרות באימייל.
- אם אסימון האימות מכיל את הצהרת
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. הבדיקה הזו מאפשרת לזהות שרתים פוטנציאליים מסוג אדם בתווך שהוגדרו על ידי גורמים מבפנים או מנהלי דומיינים בעייתיים. - מבצעים בדיקה היקפית גם באמצעות הצהרות אימות וגם באמצעות הצהרות הרשאה.
יש להצפין את החלקים הבאים באמצעות אלגוריתם הצפנה מאומת:
- מפתח להצפנת נתונים (DEK)
- הערכים
resource_name
ו-perimeter_id
מאסימון ההרשאה - מידע אישי רגיש נוסף
מתעדים את הפעולה, כולל המשתמש שיצר אותה, ה-
resource_name
והסיבה שהועברה בבקשה.החזרת אובייקט בינארי אטום שיאוחסן על ידי Google Workspace לצד האובייקט המוצפן, וישלח כפי שהוא בכל פעולה לאחר מכן של פתיחת האריזה של מפתח. לחלופין, הצג תשובה של שגיאה מובנית.
- האובייקט הבינארי צריך להכיל את העותק היחיד של ה-DEK המוצפן. אפשר לשמור בו נתונים ספציפיים להטמעה.
פענוח הנתונים
כשמשתמש ב-Google Workspace מבקש לפתוח נתונים עם הצפנה מצד הלקוח (CSE), מערכת Google Workspace שולחת בקשת unwrap
לכתובת ה-URL של נקודת הקצה ב-KACLS לצורך פענוח. נוסף לבדיקות אבטחה אופציונליות, כמו בדיקות היקפיות ובדיקות JWT שמבוססות על הצהרה על זכויות יוצרים, צריך לבצע את השלבים הבאים במאגרי ה-KACLS:
מאמתים את המשתמש ששלח את הבקשה.
- מאמתים את אסימון האימות ואת אסימון ההרשאה.
- חשוב לוודא שאסימוני ההרשאה ואסימוני האימות מיועדים לאותו משתמש, על ידי ביצוע התאמה לא תלוית-רישיות בהצהרות באימייל.
- אם אסימון האימות מכיל את הצהרת
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. כך מתאפשר זיהוי של שרתים פוטנציאליים מסוג אדם בתווך שהוגדרו על ידי גורמים מבפנים או מנהלי דומיינים זדוניים.
פענח את החלקים הבאים באמצעות אלגוריתם הצפנה מאומת:
- מפתח להצפנת נתונים (DEK)
- הערכים
resource_name
ו-perimeter_id
מאסימון ההרשאה - מידע אישי רגיש נוסף
צריך לוודא שה-
resource_name
באסימון ההרשאה וב-blob מפוענח תואמים.ביצוע בדיקה היקפית באמצעות הצהרות על אימות וגם באמצעות הצהרות הרשאה.
מתעדים את הפעולה, כולל המשתמש שיצר אותה, ה-
resource_name
והסיבה שהועברה בבקשה.מחזירים את ה-DEK שהאריזה שלו נפתחה או תשובה על שגיאה מובנית.