התוכן הזה עודכן לאחרונה בפברואר 2025, והוא מציג את המצב הקיים במועד כתיבתו. מדיניות האבטחה ומערכות האבטחה של Google עשויות להשתנות בעתיד, מכיוון שאנחנו כל הזמן פועלים לשיפור ההגנה על הלקוחות שלנו.
במאמר הזה מתוארים התכונות והמוצרים שעוזרים לכם לשלוט בגישה של צוות Google לנתוני הלקוחות שלכם. כפי שמוגדר Google Cloud בתנאים ובהגבלות, נתוני הלקוחות הם נתונים שהלקוחות ומשתמשי הקצה מספקים ל-Google באמצעות השירותים שבחשבון שלהם.
סקירה כללית על גישה עם הרשאות
בדרך כלל, רק אתם והשירותים שאתם מפעילים יכולים לגשת לנתוני הלקוחות שלכם. Google Cloudבמקרים מסוימים, יכול להיות שאנשי Google יצטרכו גישה לנתונים שלכם כדי לספק שירות שמוגדר בחוזה (לדוגמה, אם אתם צריכים תמיכה או שחזור אחרי הפסקה זמנית בשירות). סוג הגישה הזה נקרא גישה עם הרשאות מיוחדות.
עובדים עם הרשאות גבוהות במיוחד שמקבלים או רוכשים הרשאות גבוהות באופן זמני מהווים סיכון גבוה יותר לפרצות אבטחה פנימיות. הגישה שלנו לגישה עם הרשאות מיוחדות מתמקדת בהפחתת מספר הווקטורים האפשריים להתקפה. לדוגמה, אנחנו משתמשים באמצעי הבקרה הבאים:
- סכימות אימות מיותרות
- דרכים מוגבלות לגישה לנתונים
- רישום ביומן ופעולות התראה בכל המערכות שלנו
- הרשאות מפוקחות
הגישה הזו עוזרת לנו לשלוט במתקפות פנימיות ולזהות אותן, להגביל את ההשפעה של אירועים ולהפחית את הסיכון לנתונים שלכם.
אסטרטגיית ניהול הגישה המורשית ב- Google Cloud מגבילה את היכולת של צוות Google לצפות בנתוני לקוחות או לשנות אותם. ב-Google Cloud, הגבלות על גישה עם הרשאות הן חלק בלתי נפרד מהאופן שבו המוצרים שלנו מתוכננים לפעול.
מידע נוסף על המקרים שבהם צוות Google עשוי לגשת לנתונים שלכם זמין בנספח לעיבוד נתונים ב-Cloud.
הפילוסופיה של גישה עם הרשאות מיוחדות
הפילוסופיה של Google בנושא גישה עם הרשאות מבוססת על העקרונות המנחים הבאים:
הגבלות הגישה צריכות להתבסס על תפקידים ועל אישורים של כמה גורמים: לעובדי Google אין גישה למערכת כברירת מחדל. הגישה שמוענקת היא זמנית, והיא לא רחבה יותר מהנדרש לביצוע התפקיד. הגישה לנתוני לקוחות, לפעולות קריטיות במערכות ייצור ולשינויים בקוד המקור נשלטת על ידי מערכות אימות ידניות ואוטומטיות. אנשי Google לא יכולים לגשת לנתוני לקוחות בלי שאדם אחר יאשר את הבקשה. אנשי הצוות יכולים לגשת רק למשאבים שדרושים להם כדי לבצע את העבודה שלהם, והם צריכים לספק נימוק תקף כדי לגשת לנתוני הלקוחות. למידע נוסף, אפשר לעיין במאמר איך Google מגנה על שירותי הייצור שלה.
עומסי העבודה צריכים להיות מוגנים מקצה לקצה: באמצעות הצפנה במעבר, הצפנה במנוחה וConfidential Computing להצפנה בשימוש, Google Cloud יכול לספק הצפנה מקצה לקצה של עומסי עבודה של לקוחות.
רישום ביומן וביקורת מתבצעים באופן רציף: הגישה של אנשי Google לנתוני לקוחות מתועדת, ומערכות לזיהוי איומים מבצעות ביקורות בזמן אמת. אם רשומות ביומן תואמות לאינדיקטורים של איומים, צוות האבטחה מקבל על כך התראה. צוותי אבטחה פנימיים מעריכים התראות ויומנים כדי לזהות ולחקור פעילויות חריגות, וכך לצמצם את ההיקף וההשפעה של כל אירוע. מידע נוסף על תגובה לאירועים זמין במאמר תהליך התגובה לאירועי אבטחת מידע.
הגישה צריכה להיות שקופה ולכלול אמצעי בקרה של הלקוח: אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) כדי לנהל את מפתחות ההצפנה שלכם ולשלוט בגישה אליהם. בנוסף, Access Transparency מוודא שלכל גישה עם הרשאות מיוחדות יש הצדקה עסקית שמתועדת ביומן. אישור גישה מאפשר לכם לאשר או לדחות בקשות גישה של אנשי Google למערכי נתונים מסוימים.
גישה של צוות Google לנתוני לקוחות
כברירת מחדל, לאנשי Google אין גישה לנתוני הלקוחות של Google Cloud .
כדי לקבל גישה, אנשי Google צריכים לעמוד בתנאים הבאים:
- להיות חברים ברשימות הרלוונטיות של בקרת גישה (ACL).
- חשוב לקרוא ולאשר באופן קבוע את מדיניות Google בנושא גישה לנתונים.
- שימוש במכשיר מהימן.
- כניסה לחשבון עם אימות רב-שלבי באמצעות מפתח אבטחה Titan, שמצמצם את הסיכון לפישינג של פרטי הכניסה.
- גישה לכלים שמעריכים את ההצדקה שסופקה (לדוגמה, כרטיס התמיכה או מזהה הבעיה), את התפקיד של המשתמש ואת ההקשר.
- אם נדרש אישור הרשאה על ידי הכלים, צריך לקבל אישור כזה מאנשי Google מוסמכים אחרים.
- אם נרשמתם לאישורי גישה, אתם צריכים לקבל אישור.
תפקידים שונים של כוח אדם דורשים רמות גישה שונות. לדוגמה, לתפקידי תמיכה יש גישה מוגבלת לנתוני לקוחות שקשורים ישירות לכרטיס תמיכה של לקוח. תפקידים בתחום ההנדסה עשויים לדרוש הרשאות מערכת נוספות כדי לטפל בבעיות מורכבות יותר שקשורות למהימנות השירות או לפריסת שירותים.
כש-Google עובדת עם צדדים שלישיים (כמו ספקים של תמיכת לקוחות) כדי לספק שירותי Google, אנחנו מעריכים את הצד השלישי כדי לוודא שהוא מספק את רמת האבטחה והפרטיות המתאימה. Google Cloud מפרסמת רשימה של כל מעבדי המשנה שמשמשים לעזרה באספקת השירות.
סיבות לגישה של צוות Google לנתוני לקוחות
למרות ש- Google Cloud נועד לאוטומציה, לצמצום או לביטול הצורך של צוות Google לגשת לנתוני לקוחות, עדיין יש מקרים שבהם צוות Google עשוי לגשת לנתוני לקוחות. המקרים האלה כוללים תמיכה ביוזמת הלקוח, הפסקה זמנית בשירות או כשל בכלי, בקשות משפטיות מצד שלישי ובדיקות ביוזמת Google.
תמיכה ביוזמת הלקוח
הגישה של אנשי Google לנתוני לקוחות בשירותים שבהם נעשה שימוש ב-Access Transparency היא בדרך כלל תוצאה של אירועים שהלקוחות יזמו, כמו פנייה לתמיכת הלקוחות. כשפונים לצוות Customer Care כדי לפתור בעיה, הצוות מקבל גישה רק לנתונים ברמת רגישות נמוכה. לדוגמה, אם איבדתם את הגישה לקטגוריה, לצוות Customer Care יש גישה רק לנתונים ברמת רגישות נמוכה, כמו שם הקטגוריה.
הפסקת שירות או כשל בכלי
במהלך הפסקות שירות או כשלים בכלי, אנשי Google יכולים לגשת לנתוני הלקוחות כדי לבצע גיבוי או שחזור לפי הצורך. במקרים כאלה, צוות Google משתמש בכלים שיכולים לגשת ישירות לנתוני הלקוחות כדי למקסם את היעילות ולפתור את הבעיה במהירות. הכלים האלה מתעדים את הגישה ואת ההצדקות שמספקים המהנדסים. צוות התגובה לאבטחה של Google גם מבצע ביקורת על הגישה ומתעד אותה ביומן. שירותים Google Cloudנתמכים יוצרים יומני Access Transparency שגלויים לכם במהלך הפסקת שירות. במהלך הפסקת שירות, מהנדסים לא יכולים לעקוף את רשימת ההיתרים של המשאב, אבל הם יכולים לגשת לנתונים בלי אישור שלכם.
בקשות משפטיות של צד שלישי
בקשות משפטיות מצד שלישי הן נדירות, ורק הצוות המשפטי יכול ליצור הצדקה משפטית תקפה לגישה. הצוות המשפטי בודק את הבקשה כדי לוודא שהיא עומדת בדרישות המשפטיות ובמדיניות של Google, שולח לך הודעה אם הדבר מותר לפי החוק, ובוחן התנגדויות לחשיפת הנתונים במידה שהחוק מאפשר זאת. מידע נוסף זמין במאמר בקשות מרשויות ממשלתיות לנתוני לקוחות בענן (PDF).
בדיקה שמתבצעת על ידי Google
גם בדיקות שמתבצעות ביוזמת Google הן נדירות. במקרים כאלה, אנחנו מוודאים שנתוני הלקוחות בטוחים ומאובטחים ולא נפרצו. הסיבות העיקריות לביקורות האלה הן חששות לגבי אבטחה, תרמיות, ניצול לרעה או ביקורות תאימות. לדוגמה, אם גלאים אוטומטיים לכריית ביטקוין מזהים שמכונה וירטואלית משמשת לכריית ביטקוין, Google בודקת את הבעיה ומאשרת שתוכנות זדוניות במכשיר של מכונה וירטואלית מנצלות את כל הקיבולת של המכונה הווירטואלית. Google מסירה את התוכנה הזדונית כדי שהשימוש ב-VM יחזור להיות תקין.
איך Google שולטת בגישה לנתוני לקוחות ומנטרת אותה
אמצעי הבקרה הפנימיים של Google כוללים את:
- מערכות בקרה נרחבות בכל התשתית למניעת גישה לא מורשית
- זיהוי וטיפול בגישה לא מורשית באמצעות אמצעי בקרה רציפים
- מעקב, התראות על הפרות וביקורות קבועות על ידי צוות ביקורת פנימית ומבקרים עצמאיים של צד שלישי
במאמר סקירה כללית על תכנון האבטחה בתשתית של Google מוסבר בהרחבה איך Google שומרת על האבטחה של התשתית הפיזית.
אמצעי בקרה לכלל התשתית
התשתית של Google נבנתה עם אבטחה כערך ליבה. התשתית הגלובלית של Google היא הומוגנית למדי, ולכן Google יכולה להשתמש בתשתית אוטומטית כדי להטמיע אמצעי בקרה ולהגביל גישה עם הרשאות מיוחדות. בקטעים הבאים מתוארים חלק מאמצעי הבקרה שעוזרים ליישם את העקרונות שלנו בנוגע לגישה להרשאות.
אימות חזק לכל הגישה
ל-Google יש דרישות אימות מחמירות לגבי גישה לנתונים של משתמשים (כמו עובדים) ותפקידים (כמו שירות). משימות שפועלות בסביבת הייצור שלנו משתמשות בזהויות האלה כדי לגשת למאגרי נתונים או לשיטות של קריאה לשירות מרוחק (RPC) בשירותים אחרים. אפשר להריץ משימות שונות עם אותה זהות. התשתית שלנו מגבילה את האפשרות לפרוס או לשנות משימות עם זהות מסוימת רק לאנשים שאחראים להרצת השירות – בדרך כלל מהנדסי אמינות אתרים (SRE). כשמתחילים משימה, מקצים לה פרטי כניסה קריפטוגרפיים. פרטי הכניסה האלה משמשים להוכחת הזהות של המשימה כששולחים בקשות לשירותים אחרים (באמצעות אבטחת שכבת התעבורה של אפליקציה (ALTS)).
בקרת גישה מבוססת הקשר
כדי להשיג אבטחה של אפס אמון, התשתית של Google משתמשת בהקשר כדי לאמת ולאשר משתמשים ומכשירים. ההחלטות לגבי הגישה לא מבוססות רק על אישורים סטטיים או על השאלה אם ההחלטות נובעות מאינטראנט ארגוני. ההקשר המלא של הבקשה (למשל, זהות המשתמש, המיקום, הבעלות על המכשיר וההגדרה שלו, ומדיניות גישה מפורטת) מוערך כדי לקבוע את התוקף של הבקשה ולהגן מפני ניסיונות פישינג ותוכנות זדוניות לגניבת פרטי כניסה.
בכל בקשת אימות והרשאה צריך להשתמש בסיסמאות חזקות עם אסימוני אבטחה או בפרוטוקולים אחרים של אימות דו-שלבי. למשתמשים מאומתים ולמכשירים מהימנים ניתנת גישה מוגבלת וזמנית למשאבים הדרושים. מלאי המכונות נשמר בצורה מאובטחת, והמצב של כל מכשיר שמחובר (לדוגמה, עדכוני מערכת הפעלה, תיקוני אבטחה, אישורים של המכשיר, תוכנות מותקנות, סריקות וירוסים ומצב ההצפנה) מוערך כדי לזהות סיכוני אבטחה פוטנציאליים.
לדוגמה, Chrome Enterprise Premium עוזר לוודא שפרטי הכניסה של העובדים לא נגנבים או לא נעשה בהם שימוש לרעה, ושהמכשירים שמחוברים לא נפרצים. Chrome Enterprise Premium מאפשר גם לעובדי Google לעבוד באופן מאובטח יותר מכל מקום, ללא צורך ב-VPN, כי הוא מעביר את בקרות הגישה מהרשת ההיקפית להקשר של משתמשים ומכשירים בודדים.
בדיקה ואישור של כל תוכנות הייצור
התשתית שלנו מבוססת על קונטיינרים באמצעות מערכת לניהול אשכולות שנקראת Borg. Binary Authorization for Borg (BAB) מוודא שהתוכנות בסביבת הייצור ייבדקו ויאושרו לפני הפריסה, במיוחד כשלקוד שלנו יש גישה למידע אישי רגיש. Binary Authorization ל-Borg עוזר לוודא שפריסות של קוד והגדרות עומדות בסטנדרטים מסוימים, ומתריע לבעלי השירותים אם הדרישות האלה לא מתקיימות. הדרישה שהקוד יעמוד בסטנדרטים מסוימים ובשיטות עבודה לניהול שינויים לפני הגישה לנתוני המשתמשים, מפחיתה את הסיכון שאנשי Google (או חשבון שנפרץ) יפעלו לבדם כדי לגשת לנתוני המשתמשים באופן פרוגרמטי.
גישה לקובצי יומן
התשתית של Google מתעדת גישה לנתונים ושינויים בקוד. סוגי הרישום ביומן כוללים את האפשרויות הבאות:
- יומנים של לקוחות: זמינים באמצעות יומני הביקורת של Cloud.
יומני גישת אדמין: זמינים באמצעות Access Transparency.
יומנים של תקינות הפריסה: יומנים פנימיים לגבי חריגים שמנוטרים על ידי צוות אבטחה מרכזי שמוקדש לביקורת של גישה לנתוני לקוחות. מעקב אחרי חריגים עוזר להגן על נתונים רגישים ולשפר את המהימנות של הסביבה הפרודקטיבית. מעקב אחרי חריגים עוזר לוודא שקוד מקור שלא נבדק או שלא נשלח לא יפעל בסביבות עם הרשאות מיוחדות, בין אם בטעות או כתוצאה מהתקפה מכוונת.
זיהוי אירועים ותגובה
כדי לזהות הפרות גישה אפשריות ולטפל בהן, Google משתמשת בצוותי חקירה פנימיים מומחים ובאמצעי בקרה ידניים ואוטומטיים שמשלבים למידת מכונה, צינורות מתקדמים לעיבוד נתונים ואירועי מודיעין איומים.
פיתוח אותות
הבסיס ליכולות הזיהוי והתגובה של Google הוא מודיעין איומי סייבר, שמתבסס על ניתוח מתמשך של אירועים קודמים, תעבורת רשת, נתונים פנימיים, יומני גישה למערכת, דפוסי התנהגות חריגים, תוצאות של תרגילי אבטחה התקפית ועוד הרבה התראות קנייניות. הנתונים האלה מנותחים על ידי צוותים ייעודיים שמפיקים מסד נתונים דינמי של אותות, או אינדיקטורים לאיומים, שכולל את כל מוצרי Google. צוותי ההנדסה משתמשים במדדי איומים כדי לפתח מערכות זיהוי ייעודיות למעקב אחרי פעילות זדונית במערכות פנימיות, לשלוח התראות לצוות המתאים וליישם תגובות אוטומטיות (לדוגמה, ביטול גישה למשאב).
זיהוי איומים
איומים מזוהים בעיקר על ידי סריקת יומנים והתאמת רשומות יומן לאינדיקטורים של איומים. כתוצאה מאימות חזק, Google יכולה להבחין בין אירועים שקשורים לבני אדם, אירועים שקשורים לשירותים ואירועים שקשורים להתחזות לשירותים ביומנים, כדי לתת עדיפות לחקירות של גישה אנושית בפועל. פעילויות שכוללות גישה לנתוני משתמשים, לקוד מקור ולמידע רגיש מתועדות ביומן, ונדרש נימוק עסקי או חריג. איומים יכולים לכלול ניסיון של אדם פרטי לבצע פעולה חד-צדדית במערכות רגישות או ניסיון לגשת לנתוני משתמשים ללא סיבה עסקית תקפה. לסוגים האלה של פעילויות מוגדרים נהלים לשליחת התראות.
חקירת אירועים
כשמזוהות הפרות מדיניות, צוותי אבטחה שפועלים בנפרד מצוותי הליבה של ההנדסה והתפעול מספקים פיקוח עצמאי ומבצעים חקירה ראשונית. צוותי האבטחה משלימים את המשימות הבאות:
- בודקים את פרטי האירוע ומחליטים אם הגישה הייתה מכוונת, לא מכוונת, מקרית, נגרמה על ידי באג או הגדרה שגויה, או שהיא תוצאה של אמצעי בקרה לא מספקים (לדוגמה, תוקף חיצוני שגונב את פרטי הכניסה של עובד שנפרץ ומשתמש בהם).
- אם הגישה לא מכוונת או מקרית (לדוגמה, אם צוות Google לא היה מודע לפרוטוקולי הגישה או הפר אותם בטעות), הצוותים יכולים לנקוט צעדים מיידיים לתיקון הבעיה (לדוגמה, לשחזר קניין רוחני).
- אם יש חשד להתנהגות זדונית, צוות האבטחה מעביר את האירוע לטיפול ברמה גבוהה יותר ואוסף מידע נוסף, כולל נתונים ויומני גישה למערכת, כדי לקבוע את היקף האירוע וההשפעה שלו.
- בהתאם לתוצאות הבדיקה, צוות האבטחה שולח דיווחים על אירועים לצורך חקירה, תיעוד ופתרון נוספים, או במקרים קיצוניים, מעביר את האירוע לרשויות חיצוניות או לרשויות אכיפת החוק.
תיקון שגיאות
צוות האבטחה משתמש בתקריות קודמות כדי לזהות ולפתור נקודות חולשה ולשפר את יכולות הזיהוי. כל האירועים מתועדים, ומטא-נתונים מחולצים כדי לזהות טקטיקות, טכניקות ונהלים ספציפיים לכל ניצול לרעה. הצוות משתמש בנתונים האלה כדי לפתח אינדיקטורים חדשים לאיומים, לחזק את אמצעי ההגנה הקיימים או לשלוח בקשות לתכונות לשיפור האבטחה.
שירותים שעוקבים אחרי הגישה של Google לנתונים ושולטים בה
השירותים הבאים Google Cloud מספקים לכם אפשרויות להשגת שקיפות ושליטה בגישה של Google לנתונים שלכם.
| שירותGoogle Cloud | תיאור |
|---|---|
Access Approval |
אם יש לכם נתונים רגישים מאוד או מוגבלים, אישורי הגישה מאפשרים לכם לדרוש אישור לפני שאדמין מורשה של Google יוכל לגשת לנתונים שלכם כדי לתת לכם תמיכה. בקשות גישה שאושרו נרשמות ביומני Access Transparency שמקושרים לבקשת האישור. אחרי שמאשרים בקשה, צריך להגדיר את הגישה בצורה נכונה ב-Google לפני שמאפשרים אותה. במאמר שירותים נתמכים מופיעה רשימה של שירותיGoogle Cloud שתומכים באישור גישה. |
Access Transparency |
יומני Access Transparency מתעדים גישת אדמין של צוות מורשה של Google כשהם מספקים תמיכה לארגון שלכם או מבצעים תחזוקה של זמינות השירות. רשימת Google Cloud השירותים שתומכים ב-Access Transparency מופיעה במאמר שירותים נתמכים. |
Assured Workloads |
אם הארגון שלכם דורש תמיכה אזורית ייעודית, תוכניות רגולטוריות מאושרות (לדוגמה, FedRAMP או ITAR) או תוכניות כמו Sovereign Controls for EU, כדאי להשתמש ב-Assured Workloads. Assured Workloads מספק למשתמשים תהליך עבודה להפעלה, ליצירה ולמעקב אחר משך החיים של חבילות אמצעי הבקרה שנדרשות לכם. Google Cloud |
Cloud KMS |
משתמשים ב-Cloud KMS עם Cloud EKM כדי לשלוט במפתחות ההצפנה. Cloud KMS עם Cloud EKM מאפשר לכם להצפין נתונים באמצעות מפתחות הצפנה שמאוחסנים ומנוהלים במערכת לניהול מפתחות של צד שלישי, שנפרסת מחוץ לתשתית של Google. שירות Cloud EKM מאפשר לכם לשמור על הפרדה בין נתונים באחסון לבין מפתחות הצפנה, ועדיין ליהנות מהעוצמה של ניתוח נתונים ומחשוב ענן. |
Confidential Computing |
הצפנת נתונים בשימוש באמצעות Confidential Computing.Google Cloud כולל את השירותים הבאים שמאפשרים Confidential Computing:
השירותים האלה מאפשרים לצמצם את גבולות האמון כדי שלפחות משאבים תהיה גישה לנתונים הסודיים שלכם. מידע נוסף זמין במאמר בנושא הטמעה של Confidential Computing ב- Google Cloud. |
הצדקות גישה למפתחות |
אפשר להשתמש בהצדקות לגישה למפתחות כדי לשמור על ריבונות הנתונים ולגלות אותם. התכונה 'הצדקות לגישה למפתחות' מספקת הצדקה בכל פעם שהמפתחות שמתארחים מחוץ ל-Google משמשים לפענוח נתונים. כדי לשפר את השליטה שלכם בנתונים, צריך להשתמש ב-Key Access Justifications עם Cloud KMS ו-Cloud HSM או עם Cloud KMS ו-Cloud EKM. כדי שאנשי Google יוכלו לפענח את הנתונים שלכם באחסון, אתם צריכים לאשר את הגישה. |
המאמרים הבאים
- מידע נוסף על המחויבות שלנו להגנה על הפרטיות של נתוני הלקוחות זמין במאמר Google Cloud ועקרונות פרטיות נפוצים.
במאמר סקירה כללית על אמצעי בקרה לגישה אדמיניסטרטיבית מוסבר על העקרונות הבסיסיים של אמצעי בקרה למניעת גישה אדמיניסטרטיבית לא מורשית.
כדי לראות את רשימת ההצדקות העסקיות שבשבילן הצוות של Google יכול לבקש גישה לנתוני לקוחות, אפשר לעיין בקודי ההצדקה.