התוכן הזה עודכן לאחרונה באוקטובר 2026, והוא מציג את המצב הקיים במועד כתיבתו. מדיניות האבטחה ומערכות האבטחה של Google עשויות להשתנות בעתיד, כי אנחנו כל הזמן פועלים לשיפור ההגנה על הלקוחות שלנו.
במסמך הזה מתוארים המאפיינים והמוצרים שעוזרים לכם לשלוט בגישה של צוות Google לנתוני הלקוחות שלכם. כפי שמוגדר בתנאים ובהגבלות שלGoogle Cloud , נתוני הלקוחות הם נתונים שהלקוחות ומשתמשי הקצה מספקים ל-Google באמצעות השירותים שבחשבון שלהם.
סקירה כללית על גישה מיוחדת
בדרך כלל, רק לכם ולשירותי Google Cloudשהפעלתם יש גישה לנתוני הלקוחות שלכם. במקרים מסוימים, יכול להיות שצוות Google יצטרך גישה לנתונים שלכם כדי לספק שירות שמופיע בחוזה (לדוגמה, אם אתם צריכים תמיכה או התאוששות מהפסקה זמנית בפעילות). סוג הגישה הזה נקרא גישה מורשית.
עובדים עם הרשאות גבוהות, שקיבלו באופן זמני הרשאות מוגברות או רכשו אותן, מהווים סיכון פנימי גבוה יותר. הגישה שלנו לגישה מורשית מתמקדת בצמצום מספר וקטורי התקיפה האפשריים. לדוגמה, אנחנו משתמשים באמצעי הבקרה הבאים:
- סכימות אימות מיותרות
- נתיבי גישה מוגבלת לנתונים
- פעולות רישום ביומן והתראות במערכות שלנו
- הרשאות מפוקחות
הגישה הזו עוזרת לנו לזהות מתקפות פנימיות ולשלוט בהן, להגביל את ההשפעה של אירועים ולצמצם את הסיכון לנתונים שלכם.
אסטרטגיית ניהול הרשאות הגישה ב- Google Cloud מגבילה את היכולת של צוות Google לראות או לשנות את נתוני הלקוחות. ב-Google Cloud, הגבלות על גישה מורשית הן חלק בלתי נפרד מהאופן שבו המוצרים שלנו מתוכננים לפעול.
בנספח לעיבוד נתונים ב-Cloud מפורט באילו מקרים צוות Google יכול לגשת לנתונים שלכם.
הפילוסופיה של גישה מיוחדת
הפילוסופיה של Google בנושא גישה מורחבת מבוססת על העקרונות המנחים הבאים:
הגבלות הגישה חייבות להתבסס על תפקידים ואישורים ממספר גורמים: כברירת מחדל, לעובדי Google אין גישה למערכת. הגישה ניתנת באופן זמני, ורק במידה שנדרשת לביצוע התפקיד. הגישה לנתוני לקוחות, לפעולות קריטיות במערכות הייצור ולשינויים בקוד המקור נשלטת על ידי מערכות אימות ידניות ואוטומטיות. צוות Google לא יכול לגשת לנתוני לקוחות בלי שאדם נוסף יאשר את הבקשה. הם יכולים לגשת רק למשאבים שנדרשים לביצוע העבודה שלהם, והם צריכים לספק הצדקה תקפה כדי לגשת לנתוני לקוחות. למידע נוסף, קראו את המאמר איך Google מגינה על שירותי הייצור שלה.
עומסי העבודה חייבים להיות מוגנים מקצה לקצה: באמצעות הצפנה במעבר, הצפנה במנוחה וConfidential Computing להצפנה בשימוש, Google Cloud יכול לספק הצפנה מקצה לקצה של עומסי העבודה של הלקוחות.
רישום ביומן וביקורת מתבצעים באופן רציף: הגישה של צוות Google לנתוני הלקוחות מתועדת ביומן, ומערכות לזיהוי איומים מבצעות ביקורות בזמן אמת ומתריעות לצוות האבטחה כשערכים ביומן תואמים לאינדיקטורים של איומים. צוותי האבטחה הפנימיים בודקים את ההתראות והיומנים כדי לזהות ולחקור פעילויות חריגות, וכך להגביל את ההיקף וההשפעה של כל אירוע. מידע נוסף על תגובה לאירועים זמין במאמר תהליך התגובה לאירועי אבטחת מידע.
הגישה חייבת להיות שקופה ולכלול אמצעי בקרה של הלקוח: אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) כדי לנהל את מפתחות ההצפנה שלכם ולשלוט בגישה אליהם. בנוסף, בעזרת Access Transparency אפשר לוודא שלכל גישה עם הרשאות ניהול יש הצדקה עסקית שמתועדת ביומן. אישור גישה מראש מאפשר לכם לאשר או לדחות בקשות גישה של צוות Google למערכי נתונים מסוימים.
גישה של צוות Google לנתוני לקוחות
כברירת מחדל, לצוות של Google אין גישה לנתוני הלקוחות של Google Cloud .
כדי לקבל גישה, צוות Google צריך לעמוד בתנאים הבאים:
- להיות חברים ברשימות הרלוונטיות של בקרת גישה (ACL).
- לקרוא ולאשר באופן קבוע את מדיניות הגישה לנתונים של Google.
- להשתמש במכשיר מהימן.
- כניסה באמצעות אימות רב-שלבי עם מפתח אבטחה Titan, שמצמצם את הסיכון לפישינג של פרטי הכניסה.
- כלים לגישה שמעריכים את ההצדקה שסופקה (לדוגמה, כרטיס התמיכה או מזהה הבעיה), את תפקיד המשתמש ואת ההקשר.
- אם הכלים דורשים זאת, צריך לקבל אישור הרשאה מעובד מוסמך אחר של Google.
- אם נרשמתם ל-Access Approval, אתם צריכים לקבל אישור.
לתפקידים שונים נדרשות רמות גישה שונות. לדוגמה, לתפקידי תמיכה יש גישה מוגבלת לנתוני לקוחות שקשורים ישירות לכרטיס תמיכת לקוחות. יכול להיות שמהנדסים יצטרכו הרשאות מערכת נוספות כדי לטפל בבעיות מורכבות יותר שקשורות לאמינות השירות או לפריסת שירותים.
כש-Google עובדת עם צדדים שלישיים (כמו ספקי תמיכת לקוחות) כדי לספק את שירותי Google, אנחנו בודקים את הצד השלישי כדי לוודא שהוא מספק את רמת האבטחה והפרטיות המתאימה. Google Cloud מפרסמת רשימה של כל מעבדי המידע המשניים שמשמשים לסיוע במתן השירות.
למה צוות Google צריך לגשת לנתוני לקוחות
למרות ש- Google Cloud נועד להפוך את הצורך של צוות Google לגשת לנתוני לקוחות לאוטומטי, לצמצם אותו או לבטל אותו, עדיין יש מקרים שבהם צוות Google עשוי לגשת לנתוני לקוחות. לדוגמה, תמיכה ביוזמת הלקוח, הפסקת פעילות או כשל בכלי, בקשות משפטיות של צד שלישי ובדיקות ביוזמת Google.
בקשה לתמיכה ביוזמת הלקוח
בדרך כלל, אנשי הצוות של Google ניגשים לנתוני לקוחות בשירותים שמשתמשים ב-Access Transparency בעקבות אירועים שהלקוחות יזמו, כמו פנייה ל-Cloud Customer Care. כשאתם פונים לנציגי שירות הלקוחות כדי לפתור בעיה, הם מקבלים גישה רק לנתונים ברמת רגישות נמוכה. לדוגמה, אם איבדתם את הגישה לקטגוריה, לצוות שירות הלקוחות יש גישה רק לנתונים ברמת רגישות נמוכה, כמו שם הקטגוריה.
הפסקה זמנית בשירות או תקלה בכלי
במהלך הפסקות זמניות בשירות או כשלים בכלים, הצוות של Google יכול לגשת לנתוני הלקוחות כדי לבצע גיבוי או שחזור לפי הצורך. במצבים כאלה, צוות Google משתמש בכלים שיכולים לגשת ישירות לנתוני הלקוחות כדי למקסם את היעילות ולפתור את הבעיה במהירות. הכלים האלה מתעדים את הגישה ואת ההצדקות שמספקים המהנדסים. צוות התגובה לאירועי אבטחה של Google גם מבצע ביקורת על הגישה ומתעד אותה ביומן. שירותים Google Cloudנתמכים יוצרים יומני Access Transparency שגלויים לכם במהלך הפסקה זמנית בפעילות. במהלך הפסקה, המהנדסים לא יכולים לעקוף את רשימת ההיתרים של המשאב, אבל הם יכולים לגשת לנתונים בלי אישור שלכם.
בקשות משפטיות של צד שלישי
בקשות משפטיות של צד שלישי הן נדירות, ורק הצוות המשפטי יכול ליצור הצדקה חוקית תקפה לגישה. הצוות המשפטי בודק את הבקשה כדי לוודא שהיא עומדת בדרישות המשפטיות ובמדיניות של Google, שולח לכם הודעה כשהחוק מאפשר זאת, ושוקל התנגדויות לחשיפת הנתונים במידה שהחוק מאפשר זאת. מידע נוסף זמין במאמר בקשות מרשויות ממשלתיות לנתוני לקוחות ב-Cloud (קובץ PDF).
בדיקה ש-Google התחילה
גם בדיקות ש-Google יוזמת הן נדירות. כשהן מתרחשות, הן נועדו להבטיח שנתוני הלקוחות בטוחים, מאובטחים ולא נחשפו. הסיבות העיקריות לבדיקות האלה הן חששות בנוגע לאבטחה, הונאה, ניצול לרעה או ביקורות תאימות. לדוגמה, אם גלאים אוטומטיים של כריית ביטקוין מזהים שמכונה וירטואלית משמשת לכריית ביטקוין, Google בודקת את הבעיה ומאשרת שתוכנה זדונית במכשיר של המכונה הווירטואלית מנצלת את הקיבולת של המכונה הווירטואלית. Google מסירה את התוכנה הזדונית כדי שהשימוש במכונה הווירטואלית יחזור למצב רגיל.
איך Google שולטת בגישה לנתוני לקוחות ומנטרת אותה
אמצעי הבקרה הפנימיים של Google כוללים:
- מערכות בקרה נרחבות בכל התשתית למניעת גישה לא מורשית
- זיהוי גישה לא מורשית וטיפול בה באמצעות אמצעי בקרה רציפים
- מעקב, התראות על הפרות וביקורות קבועות של צוות ביקורת פנימי ושל מבקרי צד שלישי בלתי תלויים
בסקירה הכללית על תכנון האבטחה בתשתית של Google מוסבר בהרחבה איך Google שומרת על האבטחה בתשתית הפיזית.
אמצעי בקרה ברמת התשתית
התשתית של Google נבנתה עם דגש על אבטחה. התשתית הגלובלית של Google היא די הומוגנית, ולכן Google יכולה להשתמש בתשתית אוטומטית כדי להטמיע אמצעי בקרה ולהגביל את הגישה של משתמשים בעלי הרשאות. בקטעים הבאים מתוארים חלק מאמצעי הבקרה שעוזרים ליישם את העקרונות שלנו בנושא גישה עם הרשאות.
אימות חזק לכל גישה
ל-Google יש דרישות אימות מחמירות כדי שמשתמשים (כמו עובדים) ותפקידים (כמו שירות) יוכלו לגשת לנתונים. משימות שפועלות בסביבת הייצור שלנו משתמשות בזהויות האלה כדי לגשת למאגרי נתונים או לשיטות של קריאה לשירות מרוחק (RPC) של שירותים אחרים. אפשר להריץ משימות שונות עם אותה זהות. התשתית שלנו מגבילה את היכולת לפרוס או לשנות משימות עם זהות מסוימת, ומאפשרת זאת רק לאחראים על הפעלת השירות – בדרך כלל מהנדסי אמינות האתר (SRE). כשמשימה מתחילה, מקצים לה פרטי כניסה קריפטוגרפיים. פרטי הכניסה האלה משמשים להוכחת הזהות של המשימה כששולחים בקשות לשירותים אחרים (באמצעות אבטחת שכבת התעבורה של אפליקציה (ALTS)).
בקרת גישה מבוססת הקשר
כדי להשיג אבטחה במודל של אפס אמון, התשתית של Google משתמשת בהקשר כדי לאמת משתמשים ומכשירים ולתת להם הרשאות. החלטות לגבי גישה לא מבוססות רק על פרטי כניסה סטטיים או על השאלה אם ההחלטות מגיעות מרשת אינטראנט ארגונית. ההקשר המלא של הבקשה (כמו זהות המשתמש, המיקום, הבעלות על המכשיר וההגדרות שלו, וכללי מדיניות גישה מפורטים) נבדק כדי לקבוע את תוקף הבקשה ולהגן מפני ניסיונות פישינג ותוכנות זדוניות לגניבת פרטי כניסה.
כשמשתמשים בהקשר, כל בקשת אימות והרשאה חייבת להשתמש בסיסמאות חזקות עם אסימוני אבטחה או פרוטוקולים אחרים של אימות דו-שלבי. משתמשים מאומתים ומכשירים מהימנים מקבלים גישה מוגבלת וזמנית למשאבים הנדרשים. מלאי המכונות מנוהל באופן מאובטח, והמצב של כל מכשיר שמתחבר (לדוגמה, עדכוני מערכת הפעלה, תיקוני אבטחה, אישורי מכשיר, תוכנות מותקנות, סריקות וירוסים וסטטוס הצפנה) נבדק כדי לאתר סיכוני אבטחה פוטנציאליים.
לדוגמה, Chrome Enterprise Premium עוזר לוודא שפרטי הכניסה של העובדים לא נגנבים או מנוצלים לרעה, ושהמכשירים המחוברים לא נפגעים. העברת אמצעי בקרת הגישה מהיקף הרשת להקשר של משתמשים ומכשירים ספציפיים מאפשרת לעובדי Google לעבוד בצורה מאובטחת יותר כמעט מכל מקום, בלי צורך ב-VPN.
בדיקה ואישור של כל תוכנות הייצור
התשתית שלנו מנוהלת בקונטיינרים באמצעות תוכנה לניהול אשכולות שנקראת Borg. Binary Authorization for Borg מבטיחה שהתוכנות בסביבת הייצור ייבדקו ויאושרו לפני הפריסה, במיוחד כשלקוד שלנו יש גישה למידע רגיש. הכלי Binary Authorization ל-Borg עוזר לוודא שהפריסות של הקוד וההגדרות עומדות בתקנים מסוימים, ומתריע לבעלי השירות כשהדרישות האלה לא מתקיימות. הדרישה שהקוד יעמוד בתקנים מסוימים ובשיטות מסוימות לניהול שינויים לפני הגישה לנתוני משתמשים, מאפשרת ל-Binary Authorization for Borg להפחית את הסיכון שצוות Google (או חשבון שנפרץ) יפעל לבד כדי לגשת לנתוני משתמשים באופן פרוגרמטי.
גישה לקובצי יומן
התשתית של Google מתעדת את הגישה לנתונים ואת השינויים בקוד. סוגי הרישום ביומן כוללים:
- יומני לקוחות: זמינים באמצעות יומני הביקורת של Cloud.
יומני גישה של אדמינים: זמינים באמצעות Access Transparency.
יומני תקינות הפריסה: יומנים פנימיים לגבי חריגים שמנוטרים על ידי צוות אבטחה מרכזי, שמוקדש לביקורת הגישה לנתוני הלקוחות. מעקב אחרי חריגות עוזר להגן על מידע רגיש ולשפר את האמינות של סביבת הייצור. מעקב אחרי חריגות עוזר לוודא שקוד מקור שלא נבדק או לא נשלח לא ירוץ בסביבות עם הרשאות, בין אם בטעות או כתוצאה מהתקפה מכוונת.
זיהוי אירועים ותגובה אליהם
כדי לזהות הפרות גישה חשודות ולהגיב להן, Google משתמשת בצוותי חקירה פנימיים של מומחים ובאמצעי בקרה ידניים ואוטומטיים שמשלבים למידת מכונה, צינורות עיבוד נתונים מתקדמים ואירועים של מודיעין איומי סייבר.
פיתוח אותות
הליבה של יכולות הזיהוי והתגובה של Google היא מודיעין איומי סייבר, שמתחזק באמצעות ניתוח מתמשך של אירועים קודמים, תנועה ברשת, נתונים פנימיים, יומני גישה למערכת, דפוסי התנהגות חריגים, תוצאות של תרגילי אבטחה התקפית והרבה התראות קנייניות נוספות. הנתונים האלה מנותחים על ידי צוותים ייעודיים שמפיקים מסד נתונים דינמי של אותות, או אינדיקטורים לאיומים, שכוללים את כל Google. צוותי ההנדסה משתמשים באינדיקטורים לאיומים כדי לפתח מערכות זיהוי מיוחדות, שנועדו לעקוב אחרי פעילות זדונית במערכות הפנימיות, להתריע לצוות המתאים ולהטמיע תגובות אוטומטיות (לדוגמה, ביטול הגישה למשאב).
זיהוי איומים
האיומים מזוהים בעיקר על ידי סריקת יומנים והתאמה של רשומות ביומן לאינדיקטורים של איומים. כתוצאה מהאימות החזק, Google יכולה להבחין ביומנים בין אירועים אנושיים, אירועי שירות ואירועי התחזות לשירות, כדי לתת עדיפות לחקירות של גישה אנושית בפועל. פעילויות שכוללות גישה לנתוני משתמשים, לקוד מקור ולמידע רגיש מתועדות ביומן, ונדרשת הצדקה עסקית או חריגה. האיומים יכולים לכלול אדם שמנסה לבצע פעולה חד-צדדית במערכות רגישות, או מנסה לגשת לנתוני משתמשים בלי סיבה עסקית מוצדקת. לסוגי הפעילויות האלה יש נהלי התרעה מוגדרים.
חקירת אירועים
כשמזוהות הפרות מדיניות, צוותי אבטחה שפועלים בנפרד מצוותי ההנדסה והתפעול העיקריים מספקים פיקוח עצמאי ומבצעים חקירה ראשונית. צוותי האבטחה מבצעים את המשימות הבאות:
- בודקים את פרטי האירוע וקובעים אם הגישה הייתה מכוונת, לא מכוונת, מקרית, נגרמה על ידי באג או הגדרה שגויה, או שהיא נבעה מבקרות לא מספיקות (לדוגמה, תוקף חיצוני שגנב את פרטי הכניסה של עובד שהחשבון שלו נפרץ והשתמש בהם).
- אם הגישה לא מכוונת או מקרית (לדוגמה, אם צוות Google לא היה מודע לפרוטוקולי הגישה או הפר אותם בטעות), הצוותים יכולים לנקוט צעדים מיידיים כדי לתקן את הבעיה (לדוגמה, על ידי שחזור קניין רוחני).
- אם יש חשד להתנהגות זדונית, צוות האבטחה מעביר את האירוע לטיפול ברמה גבוהה יותר ואוסף מידע נוסף, כולל נתונים ויומני גישה למערכת, כדי לקבוע את ההיקף וההשפעה של האירוע.
- בהתאם לתוצאות החקירה, צוות האבטחה מעביר את האירועים לחקירה נוספת, לתיעוד ולפתרון, או במקרים קיצוניים, מפנה את האירוע לרשויות חיצוניות או לרשויות אכיפת החוק.
תיקון שגיאות
צוות האבטחה משתמש באירועים קודמים כדי לזהות ולפתור נקודות חולשה ולשפר את יכולות הזיהוי. כל האירועים מתועדים, והמטא-נתונים נשלפים כדי לזהות שיטות, טכניקות ופעולות (TTPs) ספציפיות לכל ניצול לרעה. הצוות משתמש בנתונים האלה כדי לפתח אינדיקטורים חדשים לאיומים, לחזק את אמצעי ההגנה הקיימים או להגיש בקשות להוספת תכונות לשיפור האבטחה.
שירותים שעוקבים אחרי הגישה של Google לנתונים ומנהלים אותה
השירותים הבאים של Google Cloud מספקים לכם אפשרויות להשיג הרשאות גישה ושליטה על הגישה של Google לנתונים שלכם.
| שירותGoogle Cloud | תיאור |
|---|---|
אישור גישה |
אם יש לכם נתונים רגישים או מוגבלים, אתם יכולים לדרוש את אישורכם באמצעות 'אישור גישה מראש' לפני שאדמין מורשה של 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. |
הצדקות גישה למפתחות |
שימוש בהצדקות לגישה למפתחות לצורך ריבונות הנתונים וגילוי. התכונה "הצדקות גישה למפתחות" מספקת הצדקה בכל פעם שנעשה שימוש במפתחות שמתארחים במערכת חיצונית כדי לפענח נתונים. כדי לשפר את השליטה שלכם בנתונים, אתם צריכים להשתמש ב-Cloud KMS עם Cloud HSM או ב-Cloud KMS עם Cloud EKM. כדי שצוות Google יוכל לפענח את הנתונים שלכם במנוחה, אתם צריכים לאשר את הגישה. |
המאמרים הבאים
- במאמר Google Cloud ועקרונות פרטיות נפוצים מוסבר בהרחבה על המחויבות שלנו להגנה על פרטיות נתוני הלקוחות.
במאמר סקירה כללית על אמצעי בקרה לגישה אדמיניסטרטיבית מוסברים העקרונות המרכזיים של אמצעי הבקרה שמונעים גישה אדמיניסטרטיבית לא מורשית.
כדי לראות את רשימת ההצדקות העסקיות שבגללן צוות Google יכול לבקש גישה לנתוני לקוחות, קראו את המאמר קודי סיבות להצדקה.